Domanda:
Qual è il modo più sicuro per informare un nuovo utente della propria password su un sito web solo su invito?
Avrohom Yisroel
2019-06-24 03:31:37 UTC
view on stackexchange narkive permalink

Sto sviluppando un sito web in cui le persone avranno account. Tuttavia, a differenza della maggior parte dei siti web, gli utenti non si registrano, ma sono invitati dagli amministratori del sito. Gli amministratori del sito creeranno un nuovo profilo utente, in base al loro indirizzo email, quindi vorranno che il sito invii loro un'e-mail dicendo loro che il loro profilo è pronto per l'uso.

Tuttavia, non sono sicuro del modo più sicuro per far conoscere alle persone la loro password. In una normale registrazione, l'utente inserisce la password scelta, che viene sottoposta ad hashing e memorizzata. Non resta che inviare loro un link per verificare il loro indirizzo email.

Nel nostro caso non si registrano, quindi non fornire una password. Qual è il modo più sicuro per procedere?

Questa risposta suggerisce di inviare loro un link a una pagina in cui possono vedere la loro password, ma non sono sicuro che abbia dei vantaggi rispetto inviandoli a una pagina in cui possono inserire la propria password. In realtà, penso che quest'ultimo suggerimento sia migliore, come se la password fosse già stata impostata, la pagina web può informarli che la password è stata impostata, e se questa non era loro, contattare immediatamente gli amministratori.

Quale sarebbe il modo migliore per informare un nuovo utente della propria password, dal punto di vista della sicurezza?

A proposito, non c'è differenza nell'invio per posta di un collegamento unico o di una password iniziale una tantum, qualunque cosa sia più semplice da implementare.Entrambi faranno affidamento sulla sicurezza della posta elettronica che è debole ma un modello di fiducia comune.Quindi, a meno che tu non abbia informazioni di contatto alternative o una chiave di crittografia degli utenti, devi seguirle.Assicurati che possano avvisarti se trovano che la cosa occasionale non funziona (perché qualcun altro l'ha usata)
Perché avere una password.Perché non utilizzare accessi senza password utilizzando collegamenti una tantum a tempo limitato inviati tramite posta elettronica.
Non è la stessa cosa, ma quello che facciamo sul nostro sito che è tra solo su invito e pubblico è: l'utente si registra con nome utente, password ed e-mail, approviamo manualmente l'account dell'utente (o lo cancelliamo), l'utente riceve un'e-mail per verificare la propria e-mail,e quando verificano la loro posta elettronica, possono accedere immediatamente al loro account con la password che hanno impostato.
Il metodo ** più sicuro ** è * contatto personale *.
@eckes Non sono d'accordo.Sì, la posta elettronica è l'anello debole comune.Ma ci sono persone che incollano la password iniziale in un file casuale non crittografato sul proprio disco rigido perché la password iniziale generata sembra loro più sicura di qualsiasi cosa avrebbero inventato
Vuoi il modo più sicuro effettivo o il modo più sicuro che sia ragionevolmente pratico e conveniente?Ad esempio, se il tuo CTO visita personalmente ogni utente per comunicare loro la password faccia a faccia, è molto sicuro ma molto poco pratico.
@marstato bene prima di tutto questo sarebbe probabilmente molto più sicuro quindi avere "password" come password, ma sto parlando di una password iniziale che deve essere modificata al primo accesso.
@Sentinel no, non è b / s l'email è molto debole e ci sono molte alternative, tuttavia nella maggior parte degli scenari l'email è l'unico modello di fiducia praticabile
@MikeScott puoi chiedere alle risorse umane di iscrivere i dipendenti e dare loro il loro badge / smartcard.Ma per l'e-commerce i canali di comunicazione pubblica sono l'ancora di fiducia con cui hai a che fare (spesso non ti interessa chi sia, purché sia sempre lo stesso accesso)
Nove risposte:
#1
+206
David Waters
2019-06-24 03:42:37 UTC
view on stackexchange narkive permalink

La migliore pratica in questo caso è inviare loro un collegamento a una pagina in cui possono impostare la propria password.

È necessario assicurarsi che dopo aver utilizzato questo collegamento per la registrazione, il collegamento non possa essere utilizzato per il controllo dell'account. Un modo per ottenere ciò è includere un token monouso limitato nel tempo nell'URL.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/95423/discussion-on-answer-by-david-waters-whats-the-safest-way-to-inform-a-nuovo utente).
-1 Questa risposta è piuttosto concisa."La migliore pratica è X" ... ok, ma perché ?!Questa risposta è abbastanza inutile nella sua forma attuale.
Qual è il vantaggio di un collegamento una tantum a una pagina di registrazione rispetto a una password temporanea che ti costringe a cambiarla quando effettui l'accesso?
Il vantaggio (secondo i commenti sulla risposta di User3399) sembra essere UX: se hai intenzione di fornire una password temporanea all'utente, dovresti anche forzare l'utente a cambiarla immediatamente.Ma allora perché includere il passaggio aggiuntivo di dare loro una password temporanea?Perché non fornire loro un collegamento per impostare la password?Inoltre, quest'ultimo è più semplice da [email protected] potrebbe valere la pena modificare la tua risposta per indicare questo (o qualunque cosa tu consideri il vantaggio, cioè perché è la migliore pratica).
@bob Si prega di leggere la discussione che è stata [spostata in chat] (https://chat.stackexchange.com/rooms/95423/discussion-on-answer-by-david-waters-whats-the-safest-way-to-inform-un-nuovo-utente), questo è già uscito :).Non è necessario fornire una password temporanea, idealmente si invierebbe un collegamento tramite e-mail che genera una password permanente dopo l'interazione dell'utente (per assicurarsi che non sia un controllo di collegamento).Ma sì, in ogni caso, la risposta dovrebbe essere modificata per indicare il ragionamento.
@Luc Abbastanza giusto - mi dispiace;ha le dita pruriginose e non ha pensato di guardare prima la chat.Grazie!
#2
+52
Samuel Philipp
2019-06-24 04:50:20 UTC
view on stackexchange narkive permalink

Dovresti semplicemente inviare ai nuovi utenti creati un collegamento in cui possono impostare la propria password. Ma considera i seguenti pensieri per prevenire abusi, perché le e-mail vengono inviate in testo normale:

  • assicurati che il collegamento possa essere utilizzato solo una volta (quindi solo se l'utente non ha ancora una password)
  • potrebbe impostare una data fino a quando la password deve essere impostata, altrimenti devono richiedere un nuovo collegamento
  • generazione di collegamenti casuali, quindi sarà (quasi) impossibile indovinare il collegamento per un'e-mail
  • aggiungi un altro passaggio di verifica (ad es. richiedi loro di inserire l'email e / o la data di nascita)
Sono d'accordo con il passaggio aggiuntivo della verifica, ma non ne farei un'e-mail o un compleanno.Entrambe sono generalmente considerate informazioni pubbliche che possono essere facilmente trovate o generalmente sono facilmente condivise su varie piattaforme di social media.Idealmente vuoi qualcosa che possa essere verificato automaticamente ma non facilmente dataminato, anche se non ho idea di cosa possa essere.
@Nzall dipende dal sito Web e dalle esigenze di sicurezza, ma se un utente inserisce la carta di credito, il suo nome potrebbe essere convalidato in questo modo.
Non utilizzare la convalida della carta di credito;molte persone hanno nomi che non corrispondono al nome sulla carta di credito per una serie di motivi (account congiunto, in corso di modifica del nome, problemi con la localizzazione di caratteri non romani, ecc.) e non tutti lo hanno nemmenouna carta di credito.
@GrantGarrison Perché mai uno dovrebbe consegnare i dati della carta di credito a qualsiasi pagina a meno che non si tratti di elaborare un acquisto?Che urla tentativo di phishing.
A seconda del provider di posta elettronica dell'utente, è anche possibile impedire almeno lo snooping * intermedio *, ad es.se ti connetti a Gmail sulla porta 587 e verifichi il loro certificato SSL, puoi essere ragionevolmente certo che solo l'utente finale sarà in grado di leggere l'email.
@FrankHopkins questo avrebbe davvero bisogno di essere un sito Web molto sicuro di cui non solo le persone si fidavano, ma dovevano determinare l'identità indipendentemente da cosa.Probabilmente la più piccola frazione di siti web potrebbe usarlo, ma funzionerebbe.
@GrantGarrison Le persone * non dovrebbero * fidarsi di un sito Web che richiede informazioni di pagamento quando non acquistano nulla, quindi un sito di cui le persone si fidano non può utilizzare le informazioni della carta di credito per verificare l'identità.
#3
+7
user3399
2019-06-24 12:51:40 UTC
view on stackexchange narkive permalink

Dalla mia esperienza, di solito è fatto in due modi.

Un modo è già stato descritto da David Waters, quindi non ne parlerò.

L'altro modo è inviare loro una password monouso, che dovrà cambiare in un determinato periodo di tempo (di solito una finestra di 48 ore).

Con questo metodo, devi assicurarti che ricevano una password casuale che è sufficientemente protetto da non essere forzato, ed è unico e non può essere riutilizzato.

Una volta che l'utente si connette utilizzando questa password, il sito web dovrebbe reindirizzarlo verso una pagina dove può scegliere una password di sua scelta .

Se invii al nuovo utente un link con un lungo token randomizzato che può essere aperto solo una volta, un limite di tempo non è realmente necessario.Ho creato un sistema del genere per una grande società di hosting per cui ho lavorato alcuni anni fa ed è stato integrato nel loro sistema di supporto in modo da poter generare una nuova password, il token generato e l'email con l'URL generata e inviata premendo unpulsante.
Da una prospettiva UX, credo che questa soluzione sia peggiore.Se mi verrà richiesto di cambiare la password dopo il primo accesso, qual è il punto?Fammi solo impostare una password direttamente, invece di dover copiare e incollare (o digitare) una password temporanea e * quindi * impostarne una nuova.(Ogni volta che è possibile).
@Marc.2377 Se il sistema richiede comunque modifiche regolari delle password, è lo stesso processo di una normale modifica della password dopo X periodo di tempo, e in tal caso è una procedura che un utente già conosce.Lo preferirei leggermente rispetto a qualche nuovo processo da una prospettiva UX e fortemente da una prospettiva tecnica per essere in grado di riutilizzare gran parte del processo / codice esistente.Ma se un tale processo non è presente, sarei con te.
@P.Goetterup Il limite di tempo impedisce l'accesso dannoso nei casi in cui l'utente originale ignora la posta e "se ne dimentica", ma a un certo punto un intruso ottiene l'accesso al suo account di posta dove trova la posta e può ancora utilizzare il link di ripristino.Con un limite di tempo questa espansione dell'accesso dell'intruso non è possibile.Certo, potrebbe non essere un grosso problema, ma in alcuni casi può fare la differenza tra una semplice perdita di alcune vecchie comunicazioni di un ex dipendente e una violazione del database principale dei clienti, dello strumento di gestione finanziaria ecc. Pp.
@P.Goetterup quindi se è necessario dipende davvero dai requisiti di sicurezza.Che non fosse nel tuo caso, non implica che non lo sia in tutti gli altri casi.Sebbene, scontato, la domanda di OP - e il fatto che debba chiedere qui - rendano probabile (si spera ^^) che il sistema di OP non abbia requisiti di sicurezza così elevati.
#4
+3
TJK
2019-06-24 19:17:01 UTC
view on stackexchange narkive permalink

Chiedi ai tuoi utenti di eseguire una prima autenticazione tramite un provider OpenID o Oauth, come Google, Microsoft, Amazon ecc., per verificare la loro identità. Ciò evita qualsiasi problema di sicurezza relativo all'invio di una password tramite posta elettronica all'utente.

Ci si potrebbe chiedere perché qualcuno dovrebbe avere anche un nome utente / password se utilizzerà OpenID o OAuth.
@fluffy e viceversa, se l'utente sceglie di utilizzare e-mail / password per evitare qualsiasi soluzione SSO / OpenID pubblica, riderà come un maniaco quando avrà completato alcuni passaggi di registrazione e quindi gli verrà chiesto di accedere tramite uno di questi provider ^^
@fluffy ci sono molti casi in cui i fornitori hanno avuto interruzioni o sono andati via.Soprattutto se consenti a fornitori esterni, devi almeno offrire un recupero da quello.Ma sì, dipende dalla profondità della tua offerta di servizi se vuoi stare lontano dalla gestione dell'account o dipendere dagli altri.
#5
+2
SQB
2019-06-26 14:55:47 UTC
view on stackexchange narkive permalink

Quindi gli utenti hanno un account con un indirizzo e-mail associato, ma non hanno impostato la propria password. Questa è esattamente la stessa situazione di quando hanno impostato ma dimenticato la password.

Quindi implementare una procedura di "password dimenticata" che consenta a un utente di richiedere un collegamento via e-mail per impostare una nuova password. Quindi chiedi ai tuoi utenti di utilizzare questa procedura per impostare la password la prima volta che utilizzano il loro account. Puoi impostare le loro password su una stringa generata in modo casuale quando crei i loro account.

Ciò ti consente di creare i loro account quando vuoi, senza dover generare un URL una tantum o in scadenza quindi . Se non utilizzano mai il proprio account, la password rimane quella stringa generata in modo casuale, che dovrebbe essere sufficientemente sicura contro i tentativi di forzatura.

#6
+1
CDRohling
2019-06-24 15:27:51 UTC
view on stackexchange narkive permalink

Dal mio punto di vista la posta elettronica è un canale di comunicazione utilizzato comunemente. È generalmente considerato sicuro, il che potrebbe essere vero se tutti impostassero le cose come utilizzare le connessioni SSL / TLS per POP3 / IMAP o SMTP. In realtà, non tutte le persone sanno a cosa servono queste tecniche e si limitano ad andare avanti senza la sicurezza dei trasporti e quindi configurano male il loro sistema. Allora come superare questo problema?

Direi che ci sarà un modo più sicuro per fornire un account al tuo cliente. Pensa al tuo telefono. Non c'è bisogno di configurarlo e funziona. Quindi non ci sarà il problema dell'errata configurazione. Quindi pensiamoci un po '. So che anche il token SMS e le chiamate non sono così sicure, ma è un po 'più difficile ricevere un SMS da un altro telefono reindirizzato al telefono degli hacker. Allora perché non utilizzare il numero di telefono per inviare loro una password una tantum che usano su una pagina di configurazione e completare la registrazione? Direi che sarà più sicuro che usare le e-mail.

Comunque se vuoi usare le e-mail non imposterò la password per l'utente e la invierei a loro. E ho alcuni motivi per pensare al motivo per cui non dovresti farlo in questo modo e lasciare che impostino la password da soli:

  • Se invii una password alcuni utenti potrebbero pensare che tu la conservi senza hash e puoi vederlo in modo che non si fidino di te, anche se non è vero.
  • Alcuni utenti non cambiano la password e la lasciano come quella inviata.
  • Se il cliente ha lasciato la password quella originale e qualcuno ha accesso agli altri account di posta o ai messaggi di posta del mittente, ha ottenuto la sua password.

Per questo motivo vorrei semplicemente inviare un link dove possono creare autonomamente una password.

Io, per esempio, sono molto riluttante a dare il mio numero di telefono a qualche sito web.È un'informazione di identificazione personale che è un identificatore personale troppo affidabile e molto facile da abusare per molestie o truffe quando cade nelle mani sbagliate.Se il tuo servizio richiede che ti fornisca il mio numero di telefono, non lo userò.
@Philipp Sì, anch'io lo sto facendo in questo modo, ma se voglio un servizio da un'azienda, devo fornirlo normalmente.Penso che il problema sia che non sappiamo quale servizio fornisce l'azienda.Se è una piattaforma di social media non gli darò il mio numero, ma cosa succede se si tratta di un servizio di hosting e hanno bisogno di contattarmi un giorno?E poiché ha affermato che hanno bisogno degli amministratori per impostare tutto, non può essere un servizio normale.
Lavoravo con diverse società di hosting e non ne ho mai parlato al telefono.Tutte le comunicazioni con loro avvengono solitamente tramite e-mail.Il motivo per cui chiedono un numero di telefono è perché è un altro pezzo di PII che possono utilizzare per rintracciarti se non paghi le bollette di hosting.
@Philipp Capisco il tuo punto di vista ma a volte non c'è altro modo.Se vuoi un servizio devi fornire il numero.Altrimenti non puoi ottenerlo da loro.Penso che un normale cliente lo capirà e non abbia problemi con questa pratica.Comunque, la domanda era come fornire la password nel modo più sicuro e questa era la mia idea.Se va bene o no, deve pensarci da solo.Ma grazie per il tuo contributo amico!
Concordo sul fatto che, a meno che non conosciamo i dettagli del servizio, non vi è alcun motivo per rifiutare l'autenticazione a due fattori.Inoltre, essere riluttanti a inviare informazioni telefoniche è una questione di fiducia più che di sicurezza delle informazioni per quanto riguarda questa domanda
Un numero di telefono non è un'autenticazione a due fattori.Il tuo _phone_ è un secondo fattore (fisico), ma il numero è solo un altro dato proprio come un'e-mail o una password.Non è possibile accedere a un'app di autenticazione adeguatamente protetta sul telefono senza l'accesso al telefono.Ma i tuoi messaggi / chiamate in arrivo possono essere reindirizzati rapidamente e facilmente da un ingegnere sociale medio che ne inserisce uno su un lavoratore con salario minimo che (giustamente) non si preoccupa personalmente della tua sicurezza.Ancora peggio, questa non è password + codice 2FA, è solo la password iniziale.Non c'è un secondo fattore qui in entrambi i casi.
Penso che ci manchi l'argomento principale.Non c'è idea con 2FA.Solo il canale di comunicazione dovrebbe essere cambiato nel mio pensiero.
#7
+1
Fabby
2019-06-26 03:01:40 UTC
view on stackexchange narkive permalink

Il metodo più utilizzato è inviare all'utente un collegamento per creare la propria password.

Se tuttavia ciò non è pratico (ad es. perché non hai sviluppato questa parte del sito) e desideri comunque invitare l'utente seduto accanto a te fornendo la prima password manualmente , utilizza un segreto una tantum.

Ci sono molti servizi là fuori, ma https://onetimesecret.com è facile da ricordare.

Non dimenticare di dirgli di avvisarti se ha già letto il loro segreto (ad esempio, l'FSB o la NSA hanno già effettuato l'accesso al loro account) ;-)”

Per favore fai clic qui per il segreto devi accedere al nostro servizio solo su invito.

Se ricevi il seguente avviso:

Segreto sconosciuto

Non è mai esistito o è già stato visualizzato .

Contattaci immediatamente al +00800 IVEBEENHAD

Sfortunatamente, molti programmi antivirus leggeranno le e-mail, invalidando così i flussi di lavoro di visualizzazione una tantum.D'altra parte un token USE una tantum per creare una password è sicuro.Se un'agenzia governativa infrange regolarmente la legge leggendo e-mail casuali, a meno che non abbia completato il flusso di lavoro per te, non conoscerà la password.
@gburton ha letto le email * e `OTTIENI` il collegamento HTTP al loro interno? * Per favore [ping me in chat] (https://chat.stackexchange.com/rooms/151/the-dmz) per elaborare come non ho mai sentito parlare diQuella.
Non ho tempo, ma so che è Norton a farlo.IIRC è una caratteristica relativamente comune del software antivirus.Se ci pensi, ha senso, soprattutto se offrono protezione dal phishing e-mail.Ho dovuto giudicare il software di rig per aggirare questo problema quando 300 utenti per un client non potevano reimpostare le loro password.
Ti credo sulla parola * ora ... * **; -) ** @gburton
#8
  0
Steve Gazzo
2019-06-24 19:31:28 UTC
view on stackexchange narkive permalink

Invia un collegamento per impostare la propria password con un token monouso generato in modo casuale. Quello che stai facendo ora viola un paio di principi di sicurezza:

1) Gli amministratori del sito non dovrebbero conoscere le password degli utenti

2) Le password non dovrebbero mai essere inviate in chiaro

Garantire che il token sia generato in modo casuale impedirà a un utente malintenzionato di forzare i possibili token e quindi di impostare la password da solo. Il fatto che gli utenti impostino la propria password elimina la necessità di un canale di distribuzione sicuro. Suggerirei anche un limite di tempo sul token, dopodiché ne dovrà essere generato uno nuovo. Ciò eviterà la situazione in cui gli utenti che non impostano la password possono avere il loro token indovinato e il loro account violato.

"Questo eviterà la situazione in cui gli utenti che non impostano la password possono avere il loro token indovinato e il loro account violato".quindi usa un segno lungo, lungo.mettere un limite di tempo in realtà non aggiunge alcun valore di sicurezza IMO.
Un token difficile da indovinare è difficile da indovinare, ma un limite di tempo significa anche che un token compromesso non può essere utilizzato.Un token davvero lungo e difficile da indovinare che è compromesso è ancora un problema di sicurezza.Tuttavia, avrei dovuto essere più pulito riguardo allo scenario di compromesso nella mia risposta.
#9
  0
bobuhito
2019-06-25 23:17:44 UTC
view on stackexchange narkive permalink

Vorrei inviare la stessa email (da [email protected]) a tutti (l'unica differenza tra le email è un lungo codice account # generato automaticamente che non può essere forzato):

  Un nuovo conto di trading # 3298889119019881 è disponibile per te. Per attivarlo, per favore: 1) Rispondi a questa email con le parole "Accetto con il suffisso X della password" 2) Quindi, accedi a https://InvitedTrading.com using username = <your email> and password = <3298889119019881 + private details + X> <private details> is a string of first name, last name, birthdate, and social security number Ego312671976 numero 123456789, con X = f76djisuh Devi quindi cambiare la tua password e puoi cambiare il tuo nome utente se lo desideri Oppure, non fare nulla e tutto verrà cancellato in 48 ore.Se non ti fidi di https://InvitedTrading.com o hai qualche motivo per d o dubito che dovrebbero già conoscere i tuoi dettagli privati ​​sopra, per favore non fare nulla.  
Essendo qualcuno che deve sviluppare un gatekeeper per una comunità di persone che ci si aspetta abbiano un certo livello di conoscenza tecnica, posso assicurarti che la UX su questo confonderebbe * molte * persone che non sono brave con i computer o conL'inglese (e quindi farebbe sì che molti utenti non si registrino), sarebbe visto come phishing.
Sono d'accordo, la procedura deve essere perfezionata e forse standardizzata.Solo coprendo tutti i possibili controlli per l'autenticazione "un fattore più fattore personale".


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...