Autentificazione à dui fattori
Tuttu ciò chì leghje in legatu à l'identificazione basatu annantu à u fattu chì u dumandante sà. Sapi u so indirizzu email, sapi cumu accede à ellu (vale à dì cunnosce a so password di email), è cunnosce e risposte à e dumande di sicurezza.
"A cunniscenza" hè cunsideratu un fattore di autentificazione; dui altri fattori cumuni sò ciò chì avete, per esempiu, un dispusitivu fisicu, è quale sìcum'è impronte digitali o a retina di l'ochju.
In a maiò parte di i casi, a realizazione di l'identificazione biologica ùn hè micca fattibile, soprattuttu quandu parlemu di a sicurità di l'applicazioni web, cusì cù l'autentificazione di dui fattori (autentificazione di dui fattori, 2FA), u sicondu attributu hè generalmente utilizatu - "ciò chì avete". Una variazione populari di stu secondu fattore hè un token fisicu, per esempiu, :
U token fisicu hè spessu usatu per l'autentificazione in VPN corporativi è servizii finanziarii. Per autentificà à u serviziu, avete bisognu di utilizà una password è un codice nantu à un token (chì cambia spessu) in cumminazione cù un PIN. In teoria, per identificà un attaccu, deve cunnosce a password, avè un token, è ancu cunnosce u PIN di u token. In un scenariu di resettore di password, a password stessu hè apparentemente scunnisciutu, ma u pussessu di u token pò esse usatu per pruvà a pruprietà di u contu. Di sicuru, cum'è cù qualsiasi implementazione di sicurità, , ma di sicuru eleva a barriera à l'entrata.
Unu di i prublemi principali di stu approcciu hè u costu è a logistica di implementazione; Parlemu di trasmette i dispositi fisichi à ogni cliente è di insignà u novu prucessu. Inoltre, l'utilizatori anu bisognu di avè un dispositivu cun elli, chì ùn hè micca sempre u casu cù un token fisicu. Un'altra opzione hè di implementà un secondu fattore di autentificazione cù SMS, chì in u casu di 2FA pò serve cum'è cunferma chì a persona chì esegue u prucessu di resettore hà u telefuninu di u pruprietariu di u contu. Eccu cumu fà Google:
Avete ancu bisognu di attivà , ma questu significa chì a prossima volta chì resettate a vostra password, u vostru telefuninu puderia diventà un secondu fattore d'autentificazione. Lasciatemi dimustrà questu cù u mo esempiu. iPhone per ragioni chì prestu diventeranu chjare:
Dopu avè identificatu l'indirizzu email di u contu, Google determina chì 2FA hè stata attivata è pudemu resettate u contu utilizendu a verificazione, chì hè mandata via SMS à u telefuninu di u pruprietariu di u contu:
Avà avemu bisognu di selezziunà u principiu di u prucessu di resettore:
Questa azione manda un email à l'indirizzu registratu:
Questu email cuntene l'URL di reset:
Quandu accede à l'URL di reset, un SMS hè mandatu è u situ web dumanda:
Eccu l'SMS:
Dopu avè digitatu in u navigatore, simu di ritornu in u territoriu classicu di resettore di password:
Questu prubabilmente sona un pocu verbose, è hè, ma a forma cunfirma chì a persona chì esegue u resettore hà accessu à l'indirizzu email è u telefuninu mobile di u titulare di u contu. Ma pò esse nove volte più sicura ch'è resettate a vostra password solu per email. Tuttavia, ci sò prublemi ...
U prublema hè ligata à i smartphones. U dispusitivu mostratu quì sottu pò certificà solu un fattore di autentificazione - pò riceve SMS, ma micca email:
Tuttavia, stu dispusitivu pò riceve SMS и riceve e-mail di resettore di password:
U prublema hè chì cunsideremu email cum'è u primu fattore di autentificazione, è SMS (o ancu una applicazione di generazione di token) cum'è u sicondu, ma oghje sò cumminati in un dispositivu. Di sicuru, questu significa chì, se qualcunu ghjunghje à u vostru smartphone, allora tutta sta cunvenzione vene à u fattu chì simu torna à u listessu canali di novu; stu secondu fattore "ciò chì avete" significa chì avete ancu u primu fattore. È tuttu hè prutettu da un unicu PIN di quattru cifre ... se u telefunu hà un PIN in tuttu. и era bluccatu.
Iè, a funzione 2FA di Google certamente furnisce una prutezzione supplementaria, ma ùn hè micca infallibile, è certamente ùn dipende micca di dui canali completamente autonomi.
Resettate per nome d'utilizatore versus resettate per indirizzu email
Devo permette solu reset per indirizzu email? O duveria chì l'utilizatore pò esse resettatu ancu per nome? U prublema cù resetting per nome d'utilizatore hè chì ùn ci hè micca manera di avvisà l'utilizatore di un nome d'utilizatore invalidu, senza divulgà chì qualchissia altru puderia avè un contu cù quellu nome. In a sezione precedente, un reset di e-mail hà assicuratu chì u dirittu pruprietariu di quellu email riceve sempre feedback senza divulgà publicamente a so esistenza in u sistema. Questu ùn pò micca esse fattu cù solu u nome d'utilizatore.
Allora a risposta corta hè: email solu. Se pruvate à resettate solu cù u nome d'utilizatore, allora ci saranu casi induve l'utilizatore si dumandarà ciò chì hè accadutu, o vi divulgarà l'esistenza di cunti. Iè, hè solu un nome d'utilizatore, micca un indirizzu email, è iè, qualcunu pò sceglie qualsiasi nome d'utilizatore (dispunibule), ma ci hè ancu una bona chance chì vi sia indirettamente revelatu i pruprietarii di u contu per via di a tendenza di l'utilizatori à riutilizà u nome.
Allora chì succede quandu qualchissia scurda u so nome d'utilizatore? Assumindu chì u nome d'utilizatore ùn hè micca immediatamente un indirizzu email (chì hè spessu u casu), u prucessu hè simile à cumu principia un resettore di password - entre in un indirizzu email, è dopu mandà un missaghju à questu indirizzu senza divulgà a so esistenza. A sola diferenza hè chì sta volta u missaghju cuntene solu u nome d'utilizatore è micca l'URL di resettore di password. O questu, o l'email dicerà chì ùn ci hè micca un contu per questu indirizzu.
Verificazione d'identità è precisione di l'indirizzi email
Un aspettu chjave di resetting password, è forse ancu da l'aspettu chjave hè di verificà l'identità di a persona chì prova di resette. Hè veramente u pruprietariu legittimu di u contu, o hè qualcunu chì prova di pirate in questu o causanu inconvenienti à u pruprietariu?
Ovviamente, l'email hè u canali di verificazione d'identità più còmuda è più cumuni. Ùn hè micca infallibile, è ci sò parechji casi induve solu esse capace di riceve mail à l'indirizzu di u pruprietariu di u contu ùn hè micca abbastanza se un altu gradu di cunfidenza in l'identificazione hè necessariu (chì hè per quessa 2FA hè utilizatu), ma hè quasi sempre u puntu di partenza, prucessu di reset.
Se l'e-mail hà da ghjucà un rolu in furnisce a fiducia, u primu passu hè di assicurà chì l'indirizzu email hè veramente currettu. Se qualchissia hà fattu un sbagliu cù u simbulu, allora, ovviamente, u reset ùn principia micca. U prucessu di verificazione di e-mail à u mumentu di a registrazione hè un modu affidabile per verificà a correttezza di l'indirizzu. Tutti l'avemu vistu in azzione: quandu vi registrate, avete mandatu un email cù un URL unicu per cliccà, chì cunfirma chì site u veru pruprietariu di quellu contu email. Ùn esse capace di login finu à chì stu prucessu hè cumpletu assicura chì ci hè motivazione per verificà l'indirizzu.
Cum'è u casu cù parechji altri aspetti di a sicurità, stu mudellu reduce l'usabilità in cambiu di furnisce un gradu aumentatu di sicurità relative à a fiducia in l'identità di l'utilizatore. Questu pò esse accettabile per un situ induve l'utilizatore valuta assai a registrazione è aghjunghjenu cun piacè un altru passu in u prucessu (servizii pagati, banca, etc.), ma tali cose ponu respingere l'utilizatore s'ellu percepisce u contu cum'è "unu- tempu" è usa, per esempiu, cum'è un mezzu per cummentà un postu.
Identificazione di quale hà iniziatu u prucessu di reset
Claramente, ci sò ragioni per aduprà a funzione di resettore maliziosamente, è l'attaccanti ponu aduprà in parechje manere. Un truccu simplice chì pudemu aduprà per aiutà à verificà l'origine di una dumanda (questu truccu di solitu opere) hè un aghjuntu à a lettera cù una pruposta per resettate l'indirizzu IP di u richiedente. Fornisce u destinatariu qualchi infurmazione per identificà a fonte di a dumanda.
Eccu un esempiu da a funzione di reset chì aghju attualmente custruendu in ASafaWeb:
U ligame "truvà più" porta l'utilizatori à u situ , dendu infurmazioni cum'è u locu è l'urganizazione di u richiedente di u reset:
Di sicuru, qualchissia chì vole ammuccià a so identità hà parechje manere di offuscà u so veru indirizzu IP, ma questu hè un modu cunvene per aghjunghje l'identificazione parziale di u richiedente, è in più In certi casi, questu vi darà una bona idea di quale compie a dumanda di resettore di password.
Notificazione di cambiamentu di email
Stu postu hè permeatu cù un tema - cumunicazione; dì à u pruprietariu di u contu quant'è pussibule di ciò chì succede à ogni passu di u prucessu, senza revelà nunda chì puderia esse usatu cù intenzione maliziosa. U listessu s'applica à a situazione induve a password hà cambiatu veramente - avvisà u pruprietariu!
I mutivi di cambià a password ponu esse duie fonti:
- Cambia password dopu à login perchè l'utilizatore vole una nova password
- Resetta a password senza login perchè l'utilizatore l'hà scurdatu
Mentre chì questu post hè soprattuttu di resetting, a notificazione di u primu riduce u risicu di qualcunu cambià a password senza a cunniscenza di u dirittu pruprietariu. Cumu pò accade questu? Un scenariu assai cumuni hè di ottene a password di u pruprietariu legittimu (password reutilizata filtrata da una altra fonte, password ottenuta da keylogging, password faciule d'invintà, etc.), dopu chì l'attaccante decide di cambià, cusì bluccà u pruprietariu. Senza notificazione per email, u veru pruprietariu ùn serà micca cunnisciutu di u cambiamentu di password.
Di sicuru, in l'eventu di un resettore di password, u pruprietariu duveria avè digià iniziatu u prucessu stessu (o sguassate l'attrezzi di verificazione d'identificazione descritti sopra), cusì cambiendu. ùn deve micca vene cum'è una sorpresa per ellu, però, a cunferma di e-mail serà un feedback pusitivu è una verificazione supplementaria. Inoltre, furnisce unità cù u scenariu descrittu sopra.
Oh, è in casu ùn hè micca ovvi ancu - ùn mandate micca una nova password per mail! Puderia fà ride à certi, ma :
Logs, logs, logs and some more logs
A funzione di resettore di password hè attrattiva per l'attaccanti: un attaccu vole sia accede à u contu d'una altra persona, o solu causanu inconvenienti à u pruprietariu di u contu / sistema. Parechje di e pratiche descritte sopra riducenu a probabilità di abusu, ma ùn impediscenu micca, è certamente ùn impediscenu micca a ghjente di pruvà à utilizà una funzione in modu imprevisu.
Per a rilevazione di comportamenti maliziusi, u logging hè una pratica assolutamente inestimabile, è vogliu dì Logging assai detallatu. Capture tentativi di login falluti, resetting password, cambiendu password (vale à dì quandu l'utilizatore hè digià login) è quasi tuttu ciò chì pò aiutà à capisce ciò chì succede; questu serà assai utile in u futuru. Fix in i logs ancu individuali parte prucessu, per esempiu, una bona funzione di resettore deve include l'iniziu di un resettore via un situ web (catturandu a dumanda di resettore è i tentativi di login cù un nome d'utilizatore o email incorrecte), catturà una visita à un situ web à l'URL di resettore (inclusi i tentativi di utilizà un URL incorrectu). token), è dopu logu u successu o fallimentu di a risposta à a quistione di sicurità.
Quandu parlu di logging, vogliu dì micca solu di arregistrà u fattu chì una pagina hè stata caricata, ma ancu di cullà quant'è più infurmazione pussibule, s'ellu ùn hè micca cunfidenziale. ragazzi, per piacè ùn logate micca e password! I logs anu bisognu di registrà l'identità di l'utilizatore autorizatu (serà autorizatu s'ellu cambiamenti password esistente o pruvate à resettate password di qualcunu altru dopu à login), qualsiasi nome d'utilizatore o indirizzi email chì prova, più ogni token di reset chì prova d'utilizà. Ma vale ancu a pena di logu cose cum'è l'indirizzi IP è, se pussibule, ancu dumandà intestazioni. Questu permette di ricreà micca solu chì l'utilizatore (o attaccante) prova di fà, ma ancu chì ellu hè cusì.
Delegazione di rispunsabilità à altri artisti
Se pensate chì tuttu questu rapprisenta una grande quantità di travagliu, ùn site micca solu. In fatti, custruisce un sistema affidabile per travaglià cù cunti ùn hè micca un compitu faciule. Ùn hè micca chì hè difficiule tecnicamente, hè solu chì hà assai caratteristiche. Ùn si tratta micca solu di resetting, ci hè un prucessu tutale di firmà, almacenà e password in modu sicuru, gestisce parechji tentativi di login cattivi, è cetara è cetara. Eppuru in più di quessa, ci vole à fà assai di più.
Oghje, ci sò parechji venditori di terzu chì sò felici di piglià u dulore da ellu è astrattu tuttu in un serviziu amministratu. Questi servizii includenu OpenID, OAuth, è ancu Facebook. Certi pirsuni (OpenID hà veramente assai successu in Stack Overflow), ma altri .
Senza dubbitu, un serviziu cum'è OpenID risolve assai prublemi di sviluppatori, ma hè ancu sicuru chì aghjunghje novi. Hanu qualchì rolu ? Iè, ma hè chjaru chì ùn avemu micca vistu usu massiu di i servizii di i fornituri di serviziu di autentificazione. I banche, e compagnie aeree, è ancu i magazzini implementanu tutti u so propiu mecanismu di autentificazione, è ci sò ovviamente ragioni assai boni per questu.
Reset maliciosa
Un aspettu impurtante di ognunu di l'esempii sopra hè chì a vecchia password hè cunsiderata solu inutilità dopu à cunfirmà l'identità di u pruprietariu di u contu. Questu hè impurtante perchè se u contu puderia esse resettatu à cuntrolli d'identità, questu furnisce l'uppurtunità per ogni tipu d'attività maliciosa.
Eccu un esempiu: qualcunu offre nantu à un situ d'asta, è versu a fine di u prucessu di licitazione, bluccanu i cuncurrenti inizendu un prucessu di reset, sguassendu cusì da l'offerta. Ovviamente, se una funzione di reset mal pensata pò esse abusata, pò purtà à risultati negativi seri. Hè da nutà chì u bloccu di cunti cù tentativi di login invalidu hè una situazione simili, ma questu hè un tema per un altru postu.
Cumu l'aghju dettu sopra, se dà l'utilizatori anonimi a capacità di resettate a password di qualsiasi contu solu per sapè u so indirizzu email, allora questu hè una situazione pronta per un attaccu di denegazione di serviziu. Pò esse micca quellu , chì avemu usatu per parlà, ma ùn ci hè micca un modu più veloce per bluccà l'accessu à un contu chè cù una funzione di reset di password mal pensata.
U ligame più debule
Da u puntu di vista di prutezzione di un cuntu unicu, tuttu ciò chì hè scrittu sopra hè grande, ma avete sempre bisognu di mantene in mente l'ecosistema chì circundanu u contu chì prutegge. Lasciami dà un esempiu:
ASafaWeb hè ospitatu nantu à un serviziu maravigghiusu furnitu da AppHarbor. U prucessu di resetting un contu di hosting hè u seguitu:
Stage 1:
Stage 2:
Stage 3:
Stage 4:
Dopu avè lettu tutte l'infurmazioni previ, hè digià faciule per capiscenu chì aspetti in un mondu ideale avemu implementatu un pocu sfarente. In ogni casu, ciò chì dicu quì hè chì s'e aghju publicatu un situ cum'è ASafaWeb nantu à AppHarbor, è poi vene cun grandi dumande è risposte di sicurezza, aghjunghje un secondu fattore di autentificazione, è fate tuttu ciò chì hè in modu di e regule, chì ùn cambia micca. u fattu chì u ligame più debule in tuttu u prucessu hà da pudè rompe tuttu. Se qualchissia s'autentifica in AppHarbor cù a mo infurmazione, allora puderà cambià a password per qualsiasi contu ASafaWeb à quellu chì hà bisognu!
U puntu hè chì a forza di una implementazione di sicurezza deve esse cunsiderata holisticamente: i minaccii anu da esse modellati in ogni puntu di ingressu in u sistema, ancu s'ellu hè un prucessu superficiale cum'è login in AppHarbor. Questu duverebbe dà una bona idea di quantu sforzu aghju bisognu di mette in u prucessu di resettore di password ASafaWeb.
Mettendu tuttu inseme
Questu post cuntene assai infurmazioni, cusì vogliu cuncentrallu in un schema visuale simplice:
Ricurdativi chì duvete fà u logu più detallatu di ognuna di sti articuli. Eccu, hè simplice !
Risultati
U mo post pare esse cumpletu, ma ci hè assai materiale supplementu chì aghju pudia includenu in questu, ma hà decisu micca per a brevità: u rolu di un indirizzu email di salvezza, a situazione in quale perdi l'accessu à l'email assuciatu cù u vostru contu (per esempiu, abbandunà u vostru travagliu), etc. Comu dissi prima, a funzione di resettore ùn hè micca cusì complicata, solu ci sò parechji punti di vista diffirenti.
Ancu s'è u reset ùn hè micca cusì complicatu, hè spessu implementatu in modu incorrectu. Sopra avemu vistu un coppiu di esempi induve l'implementazione pò portanu à prublemi, è ci sò assai più casi induve u resetten sbagliatu veramente causatu prublemi. Ricertamenti hè stata chì . Questu hè un risultatu negativu seriu!
Allora fate attenzione cù e vostre funzioni di reset, in parechji punti, è quandu si cuncepisce una funzione, ùn toglie micca u vostru cappellu neru perchè ci hè una bona probabilità chì qualcunu l'hà purtatu!
I diritti di publicità
VDSina offre à pocu costu cù un pagamentu di ogni ghjornu, ogni servitore hè cunnessu à un canale Internet di 500 Mbps è hè prutettu da attacchi DDoS gratuitamente!
Source: www.habr.com
