Recentment vaig tenir temps per pensar de nou en com hauria de funcionar una funció de restabliment de contrasenya segura, primer quan estava creant aquesta funcionalitat en , i després quan va ajudar una altra persona a fer alguna cosa semblant. En el segon cas, volia donar-li un enllaç a un recurs canònic amb tots els detalls de com implementar de manera segura la funció de reinici. Tanmateix, el problema és que aquest recurs no existeix, almenys no un que descrigui tot el que em sembla important. Així que vaig decidir escriure-ho jo mateix.
Ja veus, el món de les contrasenyes oblidades és en realitat força misteriós. Hi ha molts punts de vista diferents, completament acceptables i molts de força perillosos. És probable que t'hagis trobat amb cadascun d'ells moltes vegades com a usuari final; així que intentaré utilitzar aquests exemples per mostrar qui ho fa bé, qui no i en què us heu de centrar per aconseguir la funció correctament a la vostra aplicació.
Emmagatzematge de contrasenyes: hash, xifratge i text sense format
No podem discutir què fer amb les contrasenyes oblidades abans de parlar de com emmagatzemar-les. Les contrasenyes s'emmagatzemen a la base de dades en un dels tres tipus principals:
- Text senzill. Hi ha una columna de contrasenya, que s'emmagatzema en forma de text senzill.
- Encriptat. Normalment s'utilitza xifratge simètric (s'utilitza una clau tant per al xifratge com per al desxifrat), i les contrasenyes xifrades també s'emmagatzemen a la mateixa columna.
- Triturat. Procés unidireccional (la contrasenya es pot eliminar, però no es pot eliminar); contrasenya, M'agradaria esperar, seguida d'una sal, i cadascuna a la seva columna.
Anem directament a la pregunta més senzilla: No emmagatzemeu mai les contrasenyes en text sense format! Mai. Una sola vulnerabilitat a , una còpia de seguretat descuidada o una de les desenes d'altres errors senzills, i això és tot, gameover, totes les teves contrasenyes, és a dir, ho sento, contrasenyes de tots els vostres clients passarà a ser de domini públic. Per descomptat, això significaria una gran probabilitat que això de tots els seus comptes en altres sistemes. I serà culpa teva.
El xifratge és millor, però té els seus punts febles. El problema amb el xifratge és el desxifrat; podem agafar aquests xifratges d'aspecte boig i tornar-los a convertir en text sense format i, quan això succeeix, tornem a la situació de la contrasenya llegible pels humans. Com passa això? Hi ha un petit defecte al codi que desxifra la contrasenya, fent-la disponible públicament: aquesta és una manera. Els pirates informàtics accedeixen a la màquina on s'emmagatzemen les dades xifrades: aquest és el segon mètode. Una altra manera, de nou, és robar la còpia de seguretat de la base de dades i algú també obté la clau de xifratge, que sovint s'emmagatzema de manera molt insegura.
I això ens porta al hashing. La idea darrere del hashing és que és unidireccional; l'única manera de comparar la contrasenya introduïda per l'usuari amb la seva versió hash és fent hash l'entrada i comparar-les. Per evitar atacs d'eines com les taules de l'arc de Sant Martí, salpegem el procés amb aleatorietat (llegiu el meu sobre l'emmagatzematge criptogràfic). En última instància, si s'implementa correctament, podem estar segurs que les contrasenyes hash mai tornaran a ser text sense format (parlaré dels avantatges dels diferents algorismes de hash en una altra publicació).
Un breu argument sobre l'encriptació i l'encriptació: l'única raó per la qual haureu de xifrar una contrasenya en lloc d'haver-hi hash és quan necessiteu veure la contrasenya en text sense format i mai hauríeu de voler això, almenys en una situació de lloc web estàndard. Si ho necessiteu, és molt probable que feu alguna cosa malament!
Atenció!
A continuació, al text de la publicació, hi ha part d'una captura de pantalla del lloc web pornogràfic AlotPorn. Està ben retallat, de manera que no hi ha res que no pugueu veure a la platja, però si encara és probable que us provoqui algun problema, no us desplaceu cap avall.
Reinicieu sempre la vostra contrasenya mai no li recordis
Alguna vegada us han demanat que creeu una funció recordatoris contrasenya? Fes un pas enrere i pensa en aquesta petició al revés: per què cal aquest "recordatori"? Perquè l'usuari ha oblidat la contrasenya. Què volem fer realment? Ajudeu-lo a iniciar sessió de nou.
M'adono que la paraula "recordatori" s'utilitza (sovint) en un sentit col·loquial, però el que realment estem intentant és ajudar l'usuari a estar en línia de manera segura. Com que necessitem seguretat, hi ha dues raons per les quals un recordatori (és a dir, enviar a l'usuari la seva contrasenya) no és adequat:
- El correu electrònic és un canal insegur. De la mateixa manera que no enviaríem res sensible per HTTP (utilitzaríem HTTPS), no hauríem d'enviar res sensible per correu electrònic perquè la seva capa de transport és insegura. De fet, això és molt pitjor que simplement enviar informació mitjançant un protocol de transport insegur, perquè el correu sovint s'emmagatzema en un dispositiu d'emmagatzematge, accessible per als administradors del sistema, reenviat i distribuït, accessible per programari maliciós, etc. El correu electrònic sense xifrar és un canal extremadament insegur.
- De totes maneres, no hauríeu de tenir accés a la contrasenya. Torneu a llegir la secció anterior sobre emmagatzematge: hauríeu de tenir un hash de la contrasenya (amb una bona sal forta), és a dir, no hauríeu de poder extreure la contrasenya de cap manera i enviar-la per correu.
Permeteu-me demostrar el problema amb un exemple : Aquí teniu una pàgina d'inici de sessió típica:
Òbviament, el primer problema és que la pàgina d'inici de sessió no es carrega a través d'HTTPS, però el lloc també us demana que envieu una contrasenya ("Envia la contrasenya"). Aquest pot ser un exemple de l'ús col·loquial del terme esmentat anteriorment, així que anem un pas més enllà i veiem què passa:
No es veu molt millor, malauradament; i un correu electrònic confirma que hi ha un problema:
Això ens explica dos aspectes importants d'usoutdoor.com:
- El lloc no fa hash contrasenyes. En el millor dels casos, estan xifrats, però és probable que s'emmagatzemin en text sense format; No veiem cap prova del contrari.
- El lloc envia una contrasenya a llarg termini (podem tornar i utilitzar-la una i altra vegada) a través d'un canal no segur.
Amb això fora del camí, hem de comprovar si el procés de restabliment es fa de manera segura. El primer pas per fer-ho és assegurar-se que el sol·licitant té dret a realitzar el restabliment. En altres paraules, abans d'això necessitem una comprovació d'identitat; fem una ullada a què passa quan es verifica una identitat sense comprovar abans que el sol·licitant és realment el propietari del compte.
Llista de noms d'usuari i el seu impacte en l'anonimat
Aquest problema s'il·lustra millor visualment. Problema:
Veus? Preste atenció al missatge "No hi ha cap usuari registrat amb aquesta adreça de correu electrònic". El problema, òbviament, sorgeix si un lloc així ho confirma disponibilitat usuari registrat amb aquesta adreça de correu electrònic. Bingo: acabes de descobrir el fetitxe porno del teu marit/cap/veí!
Per descomptat, el porno és un exemple bastant icònic de la importància de la privadesa, però els perills d'associar una persona amb un lloc web específic són molt més amplis que la situació potencialment incòmode descrita anteriorment. Un perill és l'enginyeria social; Si l'atacant pot emparellar una persona amb el servei, llavors tindrà informació que pot començar a utilitzar. Per exemple, pot contactar amb una persona que es fa passar com a representant d'un lloc web i sol·licita informació addicional per intentar comprometre's .
Aquestes pràctiques també augmenten el perill d'"enumeració de noms d'usuari", per la qual cosa es pot verificar l'existència d'una col·lecció sencera de noms d'usuari o adreces de correu electrònic en un lloc web simplement realitzant consultes de grup i examinant les respostes a aquestes. Tens una llista d'adreces de correu electrònic de tots els empleats i uns minuts per escriure un guió? Llavors veuràs quin és el problema!
Quina és l'alternativa? De fet, és bastant senzill i s'implementa de manera meravellosa :
Aquí Entropay no revela absolutament res sobre l'existència d'una adreça de correu electrònic al seu sistema a algú que no és propietari d'aquesta adreça... Si tu propi aquesta adreça i no existeix al sistema, llavors rebreu un correu electrònic com aquest:
Per descomptat, hi pot haver situacions acceptables en què algú pensaque us heu registrat al lloc web. però aquest no és el cas, o ho vaig fer des d'una adreça de correu electrònic diferent. L'exemple mostrat anteriorment gestiona bé ambdues situacions. Òbviament, si l'adreça coincideix, rebràs un correu electrònic perquè sigui més fàcil restablir la teva contrasenya.
La subtilesa de la solució escollida per Entropay és que la verificació d'identificació es realitza segons correu electrònic abans de qualsevol verificació en línia. Alguns llocs demanen als usuaris la resposta a una pregunta de seguretat (més informació a continuació) до com pot començar el restabliment; tanmateix, el problema és que heu de respondre la pregunta mentre proporcioneu alguna forma d'identificació (correu electrònic o nom d'usuari), cosa que fa gairebé impossible respondre de manera intuïtiva sense revelar l'existència del compte de l'usuari anònim.
Amb aquest plantejament hi ha petit disminució de la usabilitat perquè si intenteu restablir un compte que no existeix, no hi ha cap comentari immediat. Per descomptat, aquest és l'objectiu d'enviar un correu electrònic, però des de la perspectiva d'un usuari final real, si introdueix l'adreça incorrecta, només ho sabrà per primera vegada quan rebi el correu electrònic. Això pot causar certa tensió per part seva, però aquest és un petit preu a pagar per un procés tan rar.
Una altra nota, una mica fora del tema: les funcions d'assistència d'inici de sessió que mostren si un nom d'usuari o una adreça de correu electrònic són correctes tenen el mateix problema. Respon sempre a l'usuari amb un missatge "La teva combinació de nom d'usuari i contrasenya no és vàlida" en lloc de confirmar explícitament l'existència de les credencials (per exemple, "el nom d'usuari és correcte, però la contrasenya és incorrecta").
Enviament de la contrasenya de restabliment versus enviament de l'URL de restabliment
El següent concepte que hem de parlar és com restablir la contrasenya. Hi ha dues solucions populars:
- Generar una nova contrasenya al servidor i enviar-la per correu electrònic
- Envieu un correu electrònic amb un URL únic per facilitar el procés de restabliment
Malgrat , el primer punt no s'ha d'utilitzar mai. El problema d'això és que vol dir que hi ha contrasenya emmagatzemada, que podeu tornar i utilitzar de nou en qualsevol moment; s'ha enviat per un canal insegur i es manté a la teva safata d'entrada. El més probable és que les safates d'entrada es sincronitzin entre els dispositius mòbils i el client de correu electrònic, a més que es puguin emmagatzemar en línia al servei de correu electrònic web durant molt de temps. La qüestió és que una bústia no es pot considerar un mitjà fiable d'emmagatzematge a llarg termini.
Però a més d'això, el primer punt té un altre problema greu: això simplifica el màxim possible bloquejar un compte amb intenció maliciosa. Si conec l'adreça de correu electrònic d'algú que té un compte en un lloc web, puc bloquejar-lo en qualsevol moment simplement restablint la seva contrasenya; Aquest és un atac de denegació de servei servit en un plat de plata! És per això que el restabliment només s'ha de realitzar després de la verificació correcta dels drets del sol·licitant.
Quan parlem d'una URL de restabliment, ens referim a l'adreça d'un lloc web que és únic per a aquest cas particular del procés de restabliment. Per descomptat, hauria de ser aleatori, no hauria de ser fàcil d'endevinar i no hauria de contenir cap enllaç extern al compte que faciliti el restabliment. Per exemple, l'URL de restabliment no hauria de ser simplement un camí com "Restablir/?username=JohnSmith".
Volem crear un testimoni únic que es pugui enviar per correu com a URL de restabliment i, a continuació, comparar-lo amb el registre del servidor del compte de l'usuari, confirmant així que el propietari del compte és, de fet, la mateixa persona que intenta restablir la contrasenya . Per exemple, el testimoni podria ser "3ce7854015cd38c862cb9e14a1ae552b" i emmagatzemat en una taula juntament amb l'ID de l'usuari que realitza el restabliment i l'hora en què es va generar el testimoni (més informació a continuació). Quan s'envia el correu electrònic, conté una URL com “Restablir/?id=3ce7854015cd38c862cb9e14a1ae552b”, i quan l'usuari el descarrega, la pàgina demana l'existència del testimoni, després del qual confirma la informació de l'usuari i permet que la contrasenya sigui canviat.
Per descomptat, com que el procés anterior (esperem) permet a l'usuari crear una nova contrasenya, hem d'assegurar-nos que l'URL es carregui mitjançant HTTPS. No, , aquest URL del testimoni ha d'utilitzar la seguretat de la capa de transport perquè no es pugui atacar el nou formulari de contrasenya i la contrasenya creada per l'usuari es va transmetre mitjançant una connexió segura.
També per a l'URL de restabliment, cal afegir un límit de temps de testimoni perquè el procés de restabliment es pugui completar en un interval determinat, per exemple, en una hora. Això garanteix que la finestra de temps de restabliment es redueixi al mínim perquè el destinatari de l'URL de restabliment només pugui actuar dins d'aquesta finestra molt petita. Per descomptat, l'atacant pot tornar a iniciar el procés de restabliment, però haurà d'obtenir un altre URL de restabliment únic.
Finalment, hem de garantir que aquest procés és d'un sol ús. Un cop finalitzat el procés de restabliment, s'ha d'eliminar el testimoni perquè l'URL de restabliment ja no funcioni. El punt anterior és necessari per garantir que l'atacant tingui una finestra molt petita durant la qual pot manipular l'URL de restabliment. A més, per descomptat, una vegada que el restabliment es fa correctament, el testimoni ja no és necessari.
Alguns d'aquests passos poden semblar excessivament redundants, però no interfereixen amb la usabilitat i de fet millorar la seguretat, encara que en situacions que esperem siguin rares. En el 99% dels casos, l'usuari habilitarà el restabliment en un període de temps molt curt i no tornarà a restablir la contrasenya en un futur proper.
Paper del CAPTCHA
Oh, CAPTCHA, la funció de seguretat que a tots ens agrada odiar! De fet, CAPTCHA no és tant una eina de protecció sinó una eina d'identificació, tant si sou una persona com un robot (o un script automatitzat). El seu propòsit és evitar l'enviament automàtic de formularis, que, per descomptat, llauna servir com a intent de trencar la seguretat. En el context de la restabliment de contrasenyes, CAPTCHA significa que la funció de restabliment no es pot forçar de manera bruta ni per enviar correu brossa a l'usuari ni per intentar determinar l'existència de comptes (cosa que, per descomptat, no serà possible si seguiu els consells de la secció sobre verificació d'identitats).
Per descomptat, el CAPTCHA en si no és perfecte; Hi ha molts precedents de "pirateria" de programari i d'aconseguint taxes d'èxit suficients (60-70%). A més, hi ha una solució que es mostra a la meva publicació sobre , on pots pagar a la gent fraccions d'un cèntim per resoldre cada CAPTCHA i aconseguir una taxa d'èxit del 94%. És a dir, és vulnerable, però eleva (lleugerament) la barrera d'entrada.
Fem una ullada a l'exemple de PayPal:
En aquest cas, el procés de restabliment simplement no pot començar fins que no es resolgui el CAPTCHA, per tant en teoria és impossible automatitzar el procés. En teoria.
Tanmateix, per a la majoria d'aplicacions web això serà excessiu i tota la raó representa una disminució de la usabilitat: a la gent no li agrada CAPTCHA! A més, CAPTCHA és una cosa a la qual podeu tornar fàcilment si cal. Si el servei comença a ser atacat (aquí és on el registre és útil, però en parlarem més endavant), afegir un CAPTCHA no podria ser més fàcil.
Preguntes i respostes secretes
Amb tots els mètodes que vam considerar, vam poder restablir la contrasenya només tenint accés al compte de correu electrònic. Dic "només", però, per descomptat, és il·legal accedir al compte de correu electrònic d'una altra persona. hauria ser un procés complex. malgrat això .
De fet, l'enllaç anterior sobre la pirateria de Yahoo! de Sarah Palin! té dos propòsits; en primer lloc, il·lustra com de fàcil és piratejar (alguns) comptes de correu electrònic i, en segon lloc, mostra com es poden utilitzar preguntes de seguretat dolentes amb intenció maliciosa. Però més endavant hi tornarem.
El problema amb els restabliments de contrasenyes XNUMX% basats en correu electrònic és que la integritat del compte del lloc que intenteu restablir depèn al XNUMX% de la integritat del compte de correu electrònic. Qualsevol persona que tingui accés al teu correu electrònic té accés a qualsevol compte que es pugui restablir simplement rebent un correu electrònic. Per a aquests comptes, el correu electrònic és la "clau de totes les portes" de la vostra vida en línia.
Una manera de reduir aquest risc és implementar un patró de preguntes i respostes de seguretat. Sens dubte, ja els has vist: tria una pregunta que només tu puguis respondre tenir Coneixeu la resposta i, després, quan reinicieu la contrasenya, se us demanarà. Això afegeix la confiança que la persona que intenta el restabliment és realment el propietari del compte.
Tornem a Sarah Palin: l'error va ser que es podien trobar fàcilment les respostes a la seva pregunta/preguntes de seguretat. Sobretot quan sou una figura pública tan important, la informació sobre el nom de soltera de la vostra mare, la història educativa o on podria haver viscut algú en el passat no és tan secret. De fet, la majoria la pot trobar gairebé qualsevol persona. Això és el que va passar amb la Sara:
El pirata informàtic David Kernell va obtenir accés al compte de Palin trobant detalls sobre els seus antecedents, com ara la seva universitat i la data de naixement, i després utilitzant la funció de recuperació de contrasenya oblidada de Yahoo!.
En primer lloc, es tracta d'un error de disseny per part de Yahoo! — En especificar preguntes tan senzilles, l'empresa va sabotejar essencialment el valor de la qüestió de seguretat i, per tant, la protecció del seu sistema. Per descomptat, restablir les contrasenyes d'un compte de correu electrònic sempre és més difícil, ja que no podeu demostrar la propietat enviant un correu electrònic al propietari (sense tenir una segona adreça), però, afortunadament, avui dia no hi ha molts usos per crear aquest sistema.
Tornem a les preguntes de seguretat: hi ha una opció per permetre que l'usuari creï les seves pròpies preguntes. El problema és que això donarà lloc a preguntes terriblement òbvies:
De quin color és el cel?
Preguntes que fan que les persones se sentin incòmodes quan s'utilitza una pregunta de seguretat per identificar-se persona (per exemple, en un centre de trucades):
Amb qui vaig dormir per Nadal?
O preguntes francament estúpides:
Com s'escriu "contrasenya"?
Quan es tracta de preguntes de seguretat, els usuaris s'han de salvar d'ells mateixos! En altres paraules, la pregunta de seguretat l'hauria de determinar el mateix lloc, o millor encara, plantejada sèrie preguntes de seguretat entre les quals l'usuari pot triar. I no és fàcil triar 01:00; idealment, l'usuari hauria de seleccionar dues o més preguntes de seguretat en el moment del registre del compte, que després s'utilitzarà com a segon canal d'identificació. Tenir diverses preguntes augmenta la confiança en el procés de verificació i també ofereix l'oportunitat d'afegir aleatorietat (no sempre mostra la mateixa pregunta), a més proporciona una mica de redundància en cas que l'usuari real hagi oblidat la contrasenya.
Quina és una bona pregunta de seguretat? Això està influenciat per diversos factors:
- Deu ser-ho breu — la pregunta ha de ser clara i sense ambigüitats.
- La resposta ha de ser específics — No necessitem una pregunta que una persona pugui respondre de manera diferent
- Les possibles respostes haurien de ser diversa - preguntar sobre el color preferit d'algú produeix un subconjunt molt petit de possibles respostes
- Cercar la resposta ha de ser complexa, si la resposta es pot trobar fàcilment qualsevol (recordeu-vos de la gent en alts càrrecs), llavors és dolent
- La resposta ha de ser permanent amb el temps: si preguntes la pel·lícula preferida d'algú, un any després la resposta pot ser diferent
Com passa, hi ha un lloc web dedicat a fer bones preguntes anomenat . Algunes de les preguntes semblen força bones, d'altres no superen algunes de les proves descrites anteriorment, especialment la prova de "facilitat de cerca".
Permeteu-me demostrar com PayPal implementa les preguntes de seguretat i, en particular, l'esforç que fa el lloc en l'autenticació. Més amunt hem vist la pàgina per iniciar el procés (amb un CAPTCHA), i aquí us mostrarem què passa després d'introduir la vostra adreça de correu electrònic i resoldre el CAPTCHA:
Com a resultat, l'usuari rep la següent carta:
Fins ara, tot és bastant normal, però aquí teniu el que s'amaga darrere d'aquest URL de restabliment:
Per tant, entren en joc les preguntes de seguretat. De fet, PayPal també us permet restablir la vostra contrasenya verificant el vostre número de targeta de crèdit, de manera que hi ha un canal addicional al qual molts llocs no tenen accés. Simplement no puc canviar la meva contrasenya sense respondre tots dos pregunta de seguretat (o no saber el número de la targeta). Fins i tot si algú em segrestés el correu electrònic, no podria restablir la contrasenya del meu compte de PayPal tret que conegués una mica més d'informació personal sobre mi. Quina informació? Aquestes són les opcions de preguntes de seguretat que ofereix PayPal:
La qüestió de l'escola i l'hospital pot ser una mica dubtosa pel que fa a la facilitat de cerca, però les altres no estan gens malament. Tanmateix, per millorar la seguretat, PayPal requereix una identificació addicional per canvis respostes a preguntes de seguretat:
PayPal és un exemple bastant utòpic de restabliment de contrasenyes segurs: implementa un CAPTCHA per reduir el perill d'atacs de força bruta, requereix dues preguntes de seguretat i després requereix un altre tipus d'identificació completament diferent només per canviar les respostes, i això després de l'usuari. ja ha iniciat la sessió. Per descomptat, això és exactament el que nosaltres esperat de PayPal; és una entitat financera que tracta grans sumes de diners. Això no vol dir que cada restabliment de la contrasenya hagi de seguir aquests passos, la majoria de vegades és excessiu, però és un bon exemple per als casos en què la seguretat és un negoci seriós.
La comoditat del sistema de preguntes de seguretat és que si no l'heu implementat immediatament, podeu afegir-lo més endavant si el nivell de protecció dels recursos ho requereix. Un bon exemple d'això és Apple, que fa poc que va implementar aquest mecanisme [article escrit el 2012]. Un cop vaig començar a actualitzar l'aplicació al meu iPad, vaig veure la següent sol·licitud:
Aleshores vaig veure una pantalla on podia seleccionar diversos parells de preguntes i respostes de seguretat, així com una adreça de correu electrònic de rescat:
Pel que fa a PayPal, les preguntes estan preseleccionades i algunes d'elles són força bones:
Cadascun dels tres parells pregunta/resposta representa un conjunt diferent de possibles preguntes, de manera que hi ha moltes maneres de configurar un compte.
Un altre aspecte a tenir en compte per respondre a la vostra pregunta de seguretat és l'emmagatzematge. Tenir una base de dades de text sense format a la base de dades suposa gairebé les mateixes amenaces que una contrasenya, és a dir, que exposar la base de dades de manera instantània revela el valor i posa no només en risc l'aplicació, sinó també aplicacions potencialment completament diferents que utilitzen les mateixes preguntes de seguretat (de nou. ). Una opció és el hashing segur (un algorisme fort i una sal criptogràficament aleatòria), però a diferència de la majoria dels casos d'emmagatzematge de contrasenyes, pot haver-hi una bona raó perquè la resposta sigui visible com a text sense format. Un escenari típic és la verificació d'identitat per part d'un operador telefònic en directe. Per descomptat, el hashing també és aplicable en aquest cas (l'operador simplement pot introduir la resposta anomenada pel client), però en el pitjor dels casos, la resposta secreta s'ha de localitzar en algun nivell d'emmagatzematge criptogràfic, encara que només sigui xifratge simètric. . Resumeix: tracta els secrets com si fossin secrets!
Un últim aspecte de les preguntes i respostes de seguretat és que són més vulnerables a l'enginyeria social. Intentar extreure directament la contrasenya al compte d'una altra persona és una cosa, però iniciar una conversa sobre la seva formació (una pregunta de seguretat popular) és completament diferent. De fet, pots comunicar-te molt bé amb algú sobre molts aspectes de la seva vida que poden plantejar una pregunta secreta sense despertar sospita. Per descomptat, el punt mateix d'una pregunta de seguretat és que es relaciona amb l'experiència de vida d'algú, de manera que és memorable, i aquí és on rau el problema: a la gent li encanta parlar de les seves experiències vitals! Hi ha poc que podeu fer al respecte, només si trieu aquestes opcions de preguntes de seguretat perquè ho siguin menys probablement podria ser retirat per l'enginyeria social.
[Continuarà.]Sobre els drets de publicitat
VDSina ofereix fiables , cada servidor està connectat a un canal d'Internet de 500 Megabits i està protegit d'atacs DDoS de manera gratuïta!
Font: www.habr.com