Permettere l'accesso a un utente creato a livello di programmazione senza compromettere la sicurezza?

Question

Permettere l'accesso a un utente creato a livello di programmazione senza compromettere la sicurezza?

#1 da (1 voti)
#2 da (1 voti)

4

Sto scrivendo un'app che richiede più livelli di utenti, in cui un utente è un amministratore e aggiunge utenti slave.

Non riesco davvero a trovare un modo per consentire l'accesso sicuro agli utenti slave. L'invio tramite e-mail di una password non è sicuro in quanto le e-mail non sono crittografate e potrei anche inviare la password se invio un collegamento occasionale.

Posso ridurre la finestra in modo esponenziale inserendo una password temporanea da modificare al primo accesso, inviare via e-mail un link utilizzabile una sola volta, impostare un timeout su uno di questi o qualsiasi combinazione di tutti questi ...

Ma la finestra sembra ancora estremamente grande rispetto alla crittografia asincrona, per esempio.

Potrei richiedere una comunicazione SSH o qualcosa del genere, ma ovviamente questo non è nemmeno vicino al pragmatico.

Qual è lo standard del settore e quale soluzione, se presente, può fornire sia un'esperienza pragmatica e intuitiva, sia un canale sicuro?

email passwords password-policy end-user

posta Allenph 28.12.2016 - 00:55

fonte

2 risposte

Leggi altre domande sui tag email passwords password-policy end-user

Come gestire la protezione CSRF in un'applicazione a singola pagina? Metodo corretto per bloccare annunci / tracciamento su VPN Server for Clients

score 1 · Answer 1

L'invio di password in una posta non va bene in nessuna circostanza. A mio avviso, la cosa migliore che puoi fare è inviare un collegamento una tantum nell'e-mail, in modo che l'utente possa accedere all'interfaccia esposta esternamente (web?) E creare una password. Per proteggere l'e-mail puoi utilizzare PGP. Questo è una buona guida.

Ciò richiede un certo carico di configurazioni nella parte dell'utente. Se si inviano messaggi a utenti noti (ad es .: in un ambiente aziendale) ciò è fattibile. Ma se invii posta al pubblico in generale, non penso che PGP sia un'opzione praticabile.

score 1 · Answer 2

La sicurezza tende a essere un compromesso con l'usabilità. Quanto sono segreti i dati che gli utenti slave gestiscono in un nuovo account, esattamente? Vale la pena consegnare la password agli utenti finali, verificarne l'id, quindi masterizzare la nota?

L'email non è perfetta, ma è veramente che non è sicura? Che dire se si inviano e-mail solo ai fornitori con cui si comunica in modo sicuro, o addirittura si configura lo scambiatore di posta elettronica per richiedere tls e un certificato valido? Le e-mail da Amazon SES a, ad esempio, Gmail, sono probabilmente piuttosto strette.

L'invio di un nuovo collegamento account / password di creazione sarebbe molto meglio dell'invio di credenziali permanenti.

È sufficiente rilevare che un account è stato sottratto alla posta elettronica in un secondo momento, quando l'utente legittimo non può accedere e parla con l'utente amministratore al riguardo?

I nuovi account possono rimanere in uno stato provvisorio finché l'amministratore non è sicuro che il nuovo utente abbia creato una password?