Hai pouco tiven tempo para pensar de novo sobre como debería funcionar unha función de restablecemento de contrasinal segura, primeiro cando estaba a construír esta funcionalidade en , e despois cando axudou a outra persoa a facer algo semellante. No segundo caso, quería darlle unha ligazón a un recurso canónico con todos os detalles de como implementar de forma segura a función de reinicio. Porén, o problema é que tal recurso non existe, polo menos non que describa todo o que me parece importante. Así que decidín escribilo eu.
Xa vedes, o mundo dos contrasinais esquecidos é en realidade bastante misterioso. Hai moitos puntos de vista diferentes, completamente aceptables e moitos bastante perigosos. É probable que te atopes con cada un deles moitas veces como usuario final; así que tentarei usar estes exemplos para mostrar quen o fai ben, quen non e en que debes centrarte para que a función sexa correcta na túa aplicación.
Almacenamento de contrasinal: hash, cifrado e (¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡)
Non podemos discutir que facer cos contrasinais esquecidos antes de discutir como almacenalos. Os contrasinais almacénanse na base de datos nun dos tres tipos principais:
- Texto sinxelo. Hai unha columna de contrasinal, que se almacena en forma de texto plano.
- Cifrado. Normalmente úsase cifrado simétrico (utilízase unha chave tanto para o cifrado como para o descifrado), e os contrasinais cifrados tamén se almacenan na mesma columna.
- Triturado. Proceso unidireccional (o contrasinal pódese eliminar, pero non se pode eliminar); contrasinal, Gustaríame esperar, seguido dun sal, e cada un está na súa propia columna.
Imos directamente á pregunta máis sinxela: Nunca almacene os contrasinais en texto plano! Nunca. Unha única vulnerabilidade a , unha copia de seguranza descoidada ou unha das decenas de erros simples - e iso é todo, gameover, todos os teus contrasinais - é dicir, perdón, contrasinais de todos os seus clientes pasará a ser de dominio público. Por suposto, isto significaría unha enorme probabilidade de que de todas as súas contas noutros sistemas. E será culpa túa.
O cifrado é mellor, pero ten os seus puntos débiles. O problema co cifrado é o descifrado; podemos tomar estes cifrados de aspecto tolo e convertelos de novo en texto simple, e cando isto ocorra volvemos á situación de contrasinal lexible por humanos. Como ocorre isto? Un pequeno fallo entra no código que descifra o contrasinal, facéndoo dispoñible publicamente - este é un xeito. Os piratas informáticos acceden á máquina na que se almacenan datos cifrados: este é o segundo método. Outra forma, de novo, é roubar a copia de seguridade da base de datos e alguén tamén obtén a clave de cifrado, que moitas veces se almacena de forma moi insegura.
E isto lévanos ao hashing. A idea detrás do hash é que é unidireccional; a única forma de comparar o contrasinal introducido polo usuario coa súa versión hash é hash a entrada e comparalas. Para evitar ataques de ferramentas como as táboas do arco da vella, salgamos o proceso con aleatoriedade (le meu sobre o almacenamento criptográfico). En definitiva, se se implementan correctamente, podemos estar seguros de que os contrasinais hash nunca volverán a converterse en texto simple (falarei sobre os beneficios dos diferentes algoritmos de hash noutra publicación).
Un argumento rápido sobre o hash fronte ao cifrado: a única razón pola que necesitarías cifrar un contrasinal en vez de hash é cando necesitas ver o contrasinal en texto simple e nunca deberías querer isto, polo menos nunha situación de sitio web estándar. Se necesitas isto, é probable que esteas facendo algo mal!
Atención!
Abaixo no texto da publicación hai parte dunha captura de pantalla do sitio web pornográfico AlotPorn. Está ben recortado polo que non hai nada que non poidas ver na praia, pero se aínda é probable que cause algún problema, non te despraces cara abaixo.
Restablece sempre o teu contrasinal nunca non llo recordes
Pedíronche algunha vez que crees unha función recordatorios contrasinal? Da un paso atrás e pensa nesta solicitude ao revés: por que é necesario este "recordatorio"? Porque o usuario esqueceu o contrasinal. Que queremos facer realmente? Axúdao a iniciar sesión de novo.
Eu entendo que a palabra "recordatorio" úsase (moitas veces) nun sentido coloquial, pero o que realmente estamos intentando é axudar ao usuario a estar en liña de novo. Dado que necesitamos seguridade, hai dúas razóns polas que un recordatorio (é dicir, enviar ao usuario o seu contrasinal) non é apropiado:
- O correo electrónico é unha canle insegura. Do mesmo xeito que non enviariamos nada sensible a través de HTTP (usamos HTTPS), non debemos enviar nada sensible por correo electrónico porque a súa capa de transporte é insegura. De feito, isto é moito peor que simplemente enviar información a través dun protocolo de transporte inseguro, porque o correo adoita almacenarse nun dispositivo de almacenamento, accesible para os administradores do sistema, reenviado e distribuído, accesible para malware, etc. O correo electrónico sen cifrar é unha canle moi insegura.
- De todos os xeitos, non deberías ter acceso ao contrasinal. Volve ler a sección anterior sobre almacenamento: deberías ter un hash do contrasinal (cunha boa sal forte), o que significa que non deberías poder extraer o contrasinal de ningún xeito e envialo por correo.
Déixeme demostrar o problema cun exemplo : Aquí está unha páxina de inicio de sesión típica:
Obviamente, o primeiro problema é que a páxina de inicio de sesión non se carga a través de HTTPS, pero o sitio tamén che pide que envíes un contrasinal ("Enviar contrasinal"). Este pode ser un exemplo do uso coloquial do termo mencionado anteriormente, así que imos dar un paso máis e ver que pasa:
Non se ve moito mellor, por desgraza; e un correo electrónico confirma que hai un problema:
Isto indícanos dous aspectos importantes de usoutdoor.com:
- O sitio non usa hash contrasinais. Ao mellor, están cifrados, pero é probable que estean almacenados en texto plano; Non vemos ningunha evidencia que indique o contrario.
- O sitio envía un contrasinal a longo prazo (podemos volver e usalo unha e outra vez) a través dunha canle non segura.
Con isto fóra do camiño, necesitamos comprobar se o proceso de restablecemento se realiza de forma segura. O primeiro paso para facelo é asegurarse de que o solicitante ten dereito a realizar o restablecemento. Noutras palabras, antes necesitamos un control de identidade; vexamos o que ocorre cando se verifica unha identidade sen antes comprobar que o solicitante é realmente o propietario da conta.
Lista de nomes de usuario e o seu impacto no anonimato
Este problema é mellor ilustrado visualmente. Problema:
ves? Preste atención á mensaxe "Non hai ningún usuario rexistrado con este enderezo de correo electrónico". O problema, obviamente, xorde se tal sitio confirma dispoñibilidade usuario rexistrado con tal enderezo de correo electrónico. Bingo: acabas de descubrir o fetiche porno do teu marido/xefe/veciño!
Por suposto, a pornografía é un exemplo bastante emblemático da importancia da privacidade, pero os perigos de asociar unha identidade cun sitio web específico son moito máis amplos que a situación potencialmente incómoda descrita anteriormente. Un perigo é a enxeñería social; Se o atacante pode facer coincidir unha persoa co servizo, entón terá información que pode comezar a utilizar. Por exemplo, pode contactar cunha persoa que se fai pasar por representante dun sitio web e solicitar información adicional para tentar comprometerse .
Tales prácticas tamén aumentan o perigo da "enumeración de nomes de usuario", pola cal se pode verificar a existencia dunha colección completa de nomes de usuario ou enderezos de correo electrónico nun sitio web simplemente realizando consultas de grupo e examinando as respostas a elas. Tes unha lista de enderezos de correo electrónico de todos os empregados e uns minutos para escribir un guión? Entón xa ves cal é o problema!
Cal é a alternativa? De feito, é bastante sinxelo e está moi ben implementado :
Aquí Entropay non revela absolutamente nada sobre a existencia dun enderezo de correo electrónico no seu sistema a alguén que non posúe este enderezo... Se propio este enderezo e non existe no sistema, entón recibirás un correo electrónico como este:
Por suposto, pode haber situacións aceptables nas que alguén pensaque se rexistrou na páxina web. pero este non é o caso, ou fíxeno desde un enderezo de correo electrónico diferente. O exemplo mostrado arriba manexa ben ambas situacións. Obviamente, se o enderezo coincide, recibirás un correo electrónico facilitando o restablecemento do teu contrasinal.
A sutileza da solución escollida por Entropay é que a verificación da identificación realízase segundo correo electrónico antes de calquera verificación en liña. Algúns sitios piden aos usuarios a resposta a unha pregunta de seguranza (máis información a continuación) para como pode comezar o reset; non obstante, o problema con isto é que tes que responder á pregunta mentres proporcionas algún tipo de identificación (correo electrónico ou nome de usuario), o que fai case imposible responder intuitivamente sen revelar a existencia da conta do usuario anónimo.
Con este enfoque hai pequeno diminuíu a usabilidade porque se tentas restablecer unha conta que non existe, non hai comentarios inmediatos. Por suposto, ese é todo o punto de enviar un correo electrónico, pero desde a perspectiva dun usuario final real, se introduce o enderezo incorrecto, só saberá por primeira vez cando recibe o correo electrónico. Isto pode causar certa tensión pola súa parte, pero este é un pequeno prezo a pagar por un proceso tan raro.
Outra nota, un pouco fóra do tema: as funcións de asistencia ao inicio de sesión que revelan se un nome de usuario ou enderezo de correo electrónico é correcto teñen o mesmo problema. Responda sempre ao usuario cunha mensaxe "A túa combinación de nome de usuario e contrasinal non é válida" en lugar de confirmar explícitamente a existencia das credenciais (por exemplo, "o nome de usuario é correcto, pero o contrasinal é incorrecto").
Enviar contrasinal de restablecemento vs envío de URL de restablecemento
O seguinte concepto que debemos discutir é como restablecer o teu contrasinal. Hai dúas solucións populares:
- Xerando un novo contrasinal no servidor e enviándoo por correo electrónico
- Envía un correo electrónico cun URL único para facilitar o proceso de restablecemento
A pesar de , o primeiro punto nunca debe utilizarse. O problema con isto é que significa que hai contrasinal almacenado, ao que podes volver e utilizar de novo en calquera momento; enviouse por unha canle insegura e permanece na túa caixa de entrada. É probable que as caixas de entrada se sincronicen entre os dispositivos móbiles e o cliente de correo electrónico, ademais de que estean almacenadas en liña no servizo de correo electrónico web durante moito tempo. A cuestión é que unha caixa de correo non pode considerarse un medio fiable de almacenamento a longo prazo.
Pero ademais disto, o primeiro punto ten outro problema grave: iso simplifica o máximo posible bloquear unha conta con intención maliciosa. Se coñezo o enderezo de correo electrónico de alguén que posúe unha conta nun sitio web, podo bloquealo en calquera momento simplemente restablecendo o seu contrasinal; Este é un ataque de denegación de servizo servido nunha bandexa de prata! É por iso que o restablecemento só se debe realizar despois da verificación exitosa dos dereitos do solicitante sobre el.
Cando falamos dun URL de restablecemento, queremos dicir o enderezo dun sitio web que é exclusivo para este caso particular del proceso de reinicio. Por suposto, debe ser aleatorio, non debe ser fácil de adiviñar e non debe conter ligazóns externas á conta que faciliten o restablecemento. Por exemplo, o URL de restablecemento non debe ser simplemente un camiño como "Reiniciar/?username=JohnSmith".
Queremos crear un token único que se poida enviar por correo como URL de restablecemento e, a continuación, comparalo co rexistro do servidor da conta do usuario, confirmando así que o propietario da conta é, de feito, a mesma persoa que está tentando restablecer o contrasinal . Por exemplo, un token podería ser "3ce7854015cd38c862cb9e14a1ae552b" e almacenarse nunha táboa xunto co ID do usuario que realizou o restablecemento e a hora en que se xerou o token (máis información a continuación). Cando se envía o correo electrónico, contén un URL como “Reiniciar/?id=3ce7854015cd38c862cb9e14a1ae552b”, e cando o usuario o descarga, a páxina solicita a existencia do token, despois de que confirma a información do usuario e permítelle cambiar o contrasinal.
Por suposto, xa que o proceso anterior (con sorte) permite ao usuario crear un novo contrasinal, debemos asegurarnos de que o URL se cargue a través de HTTPS. Non, , este URL do token debe utilizar a seguranza da capa de transporte para que non se poida atacar o novo formulario de contrasinal e o contrasinal creado polo usuario foi transmitido a través dunha conexión segura.
Tamén para o URL de restablecemento cómpre engadir un límite de tempo de token para que o proceso de restablecemento poida completarse nun determinado intervalo, por exemplo, nunha hora. Isto garante que a xanela de tempo de restablecemento se manteña ao mínimo para que o destinatario do URL de restablecemento só poida actuar dentro desa ventá moi pequena. Por suposto, o atacante pode iniciar de novo o proceso de restablecemento, pero terá que obter outro URL de restablecemento único.
Finalmente, debemos asegurarnos de que este proceso sexa desbotable. Unha vez que se complete o proceso de restablecemento, o token debe eliminarse para que o URL de restablecemento xa non funcione. O punto anterior é necesario para asegurarse de que o atacante teña unha ventá moi pequena durante a cal pode manipular o URL de restablecemento. Ademais, por suposto, unha vez que o restablecemento teña éxito, o token xa non é necesario.
Algúns destes pasos poden parecer excesivamente redundantes, pero non interfiren coa usabilidade e de feito mellorar a seguridade, aínda que en situacións que esperamos sexan raras. No 99% dos casos, o usuario activará o restablecemento nun período de tempo moi curto e non volverá a restablecer o contrasinal nun futuro próximo.
Papel do CAPTCHA
¡Oh, CAPTCHA, a función de seguridade que a todos nos gusta odiar! De feito, CAPTCHA non é tanto unha ferramenta de protección como unha ferramenta de identificación, xa sexa unha persoa ou un robot (ou un script automatizado). A súa finalidade é evitar o envío automático de formularios que, por suposto, lata ser usado como un intento de romper a seguridade. No contexto do restablecemento do contrasinal, CAPTCHA significa que a función de restablecemento non pode ser forzada de xeito bruto nin para enviar spam ao usuario nin para tentar determinar a existencia de contas (o que, por suposto, non será posible se seguiu os consellos da sección sobre verificación de identidades).
Por suposto, o propio CAPTCHA non é perfecto; Existen moitos precedentes para o seu software "piratear" e acadar taxas de éxito suficientes (60-70%). Ademais, hai unha solución que se mostra na miña publicación sobre , onde podes pagar á xente fraccións dun céntimo para resolver cada CAPTCHA e acadar unha taxa de éxito do 94%. É dicir, é vulnerable, pero eleva (lixeiramente) a barreira de entrada.
Vexamos o exemplo de PayPal:
Neste caso, o proceso de restablecemento simplemente non pode comezar ata que se resolva o CAPTCHA, polo que en teoría é imposible automatizar o proceso. En teoría.
Non obstante, para a maioría das aplicacións web isto será excesivo e absolutamente seguro representa unha diminución da usabilidade - á xente simplemente non lle gusta o CAPTCHA! Ademais, o CAPTCHA é algo ao que podes volver facilmente se é necesario. Se o servizo comeza a sufrir un ataque (aquí é onde o rexistro é útil, pero máis sobre iso máis tarde), engadir un CAPTCHA non podería ser máis sinxelo.
Preguntas e respostas secretas
Con todos os métodos que consideramos, puidemos restablecer o contrasinal só tendo acceso á conta de correo electrónico. Digo "só", pero, por suposto, é ilegal acceder á conta de correo electrónico doutra persoa. debería ser un proceso complexo. Porén .
De feito, a ligazón anterior sobre o hackeo do Yahoo! de Sarah Palin! serve para dous propósitos; en primeiro lugar, ilustra o fácil que é piratear (algunhas) contas de correo electrónico e, en segundo lugar, mostra como se poden usar preguntas de seguranza malas con intención maliciosa. Pero sobre isto volveremos máis tarde.
O problema co restablecemento do contrasinal XNUMX% baseado no correo electrónico é que a integridade da conta do sitio que estás tentando restablecer depende ao XNUMX% da integridade da conta de correo electrónico. Calquera persoa que teña acceso ao teu correo electrónico ten acceso a calquera conta que se poida restablecer con só recibir un correo electrónico. Para tales contas, o correo electrónico é a "chave de todas as portas" da túa vida en liña.
Unha forma de reducir este risco é implementar un patrón de preguntas e respostas de seguridade. Sen dúbida xa as viches: escolle unha pregunta que só ti poidas responder debería sabe a resposta e, a continuación, cando restablezas o teu contrasinal, pediráselle. Isto engade a confianza de que a persoa que intenta o restablecemento é realmente o propietario da conta.
Volver a Sarah Palin: o erro foi que as respostas ás súas preguntas/preguntas de seguridade se podían atopar facilmente. Especialmente cando es unha figura pública tan importante, a información sobre o apelido de solteira da túa nai, o historial educativo ou onde alguén puido vivir no pasado non é tan segredo. De feito, case calquera pode atopar a maioría. Isto é o que lle pasou a Sarah:
O hacker David Kernell accedeu á conta de Palin ao atopar detalles sobre os seus antecedentes, como a súa universidade e a súa data de nacemento, e despois mediante a función de recuperación do contrasinal esquecido de Yahoo!.
En primeiro lugar, este é un erro de deseño por parte de Yahoo! — ao especificar preguntas tan sinxelas, a empresa saboteou esencialmente o valor da cuestión de seguridade e, polo tanto, a protección do seu sistema. Por suposto, restablecer os contrasinais dunha conta de correo electrónico sempre é máis difícil xa que non se pode demostrar a propiedade enviando un correo electrónico ao propietario (sen ter un segundo enderezo), pero afortunadamente non hai moitos usos para crear un sistema deste tipo hoxe en día.
Volvamos ás preguntas de seguridade: hai unha opción para permitir que o usuario cree as súas propias preguntas. O problema é que isto dará lugar a preguntas terriblemente obvias:
De que cor é o ceo?
Preguntas que incomodan ás persoas cando se utiliza unha pregunta de seguridade para identificar persoa (por exemplo, nun centro de chamadas):
Con quen durmín no Nadal?
Ou preguntas francamente estúpidas:
Como se escribe "contrasinal"?
Cando se trata de preguntas de seguridade, os usuarios teñen que salvarse de si mesmos. Noutras palabras, a pregunta de seguridade debe ser determinada polo propio sitio, ou mellor aínda, preguntada serie preguntas de seguridade entre as que o usuario pode escoller. E non é doado escoller un; o ideal é que o usuario seleccione dúas ou máis preguntas de seguridade no momento do rexistro da conta, que despois se utilizará como segunda canle de identificación. Ter varias preguntas aumenta a confianza no proceso de verificación e tamén ofrece a posibilidade de engadir aleatoriedade (non sempre mostra a mesma pregunta), ademais proporciona un pouco de redundancia no caso de que o usuario real esqueza o contrasinal.
Cal é unha boa pregunta de seguridade? Isto está influenciado por varios factores:
- Debe ser breve - a pregunta debe ser clara e inequívoca.
- A resposta debe ser específico - Non necesitamos unha pregunta que unha persoa poida responder de forma diferente
- As posibles respostas deberían ser diversas - preguntar pola cor favorita de alguén obtén un pequeno subconxunto de posibles respostas
- Procurar a resposta debe ser complexa, se a resposta se pode atopar facilmente calquera (lembra xente en altos cargos), entón é malo
- A resposta debe ser permanente a tempo: se preguntas a película favorita de alguén, un ano despois a resposta pode ser diferente
Polo que ocorre, hai un sitio web dedicado a facer boas preguntas chamado . Algunhas das preguntas parecen bastante boas, outras non superan algunhas das probas descritas anteriormente, especialmente a proba de "facilidade de busca".
Permítanme demostrar como PayPal implementa as preguntas de seguridade e, en particular, o esforzo que fai o sitio na autenticación. Arriba vimos a páxina para iniciar o proceso (cun CAPTCHA), e aquí mostraremos o que ocorre despois de que introduza o seu enderezo de correo electrónico e resolva o CAPTCHA:
Como resultado, o usuario recibe a seguinte carta:
Ata agora todo é bastante normal, pero aquí está o que se esconde detrás deste URL de restablecemento:
Entón, as preguntas de seguridade entran en xogo. De feito, PayPal tamén che permite restablecer o teu contrasinal verificando o teu número de tarxeta de crédito, polo que hai unha canle adicional á que moitos sitios non teñen acceso. Non podo cambiar o meu contrasinal sen responder ambas pregunta de seguridade (ou non saber o número da tarxeta). Aínda que alguén secuestrase o meu correo electrónico, non podería restablecer o contrasinal da miña conta de PayPal a menos que soubese un pouco máis de información persoal sobre min. Que información? Aquí están as opcións de preguntas de seguridade que ofrece PayPal:
A cuestión da escola e do hospital pode ser un pouco dudosa en canto á facilidade de busca, pero as outras non son tan malas. Non obstante, para mellorar a seguridade, PayPal require unha identificación adicional para cambios respostas ás preguntas de seguridade:
PayPal é un exemplo bastante utópico de restablecemento de contrasinais seguro: implementa un CAPTCHA para reducir o perigo de ataques de forza bruta, require dúas preguntas de seguridade e, a continuación, require outro tipo de identificación completamente diferente só para cambiar as respostas, e isto despois do usuario. xa se iniciou sesión. Por suposto, isto é exactamente o que nós esperado de PayPal; é unha entidade financeira que se ocupa de grandes cantidades de diñeiro. Isto non significa que cada restablecemento de contrasinal teña que seguir estes pasos, a maioría das veces é excesivo, pero é un bo exemplo para os casos nos que a seguridade é un asunto serio.
A conveniencia do sistema de preguntas de seguridade é que, se non o implementou de inmediato, pode engadilo máis tarde se o nivel de protección dos recursos o require. Un bo exemplo diso é Apple, que só recentemente implementou este mecanismo [artigo escrito en 2012]. Unha vez que comecei a actualizar a aplicación no meu iPad, vin a seguinte solicitude:
Entón vin unha pantalla na que podía seleccionar varios pares de preguntas e respostas de seguridade, así como un enderezo de correo electrónico de rescate:
En canto a PayPal, as preguntas están preseleccionadas e algunhas delas son bastante boas:
Cada un dos tres pares pregunta/resposta representa un conxunto diferente de posibles preguntas, polo que hai moitas formas de configurar unha conta.
Outro aspecto a ter en conta para responder á túa pregunta de seguridade é o almacenamento. Ter unha base de datos de texto simple na base de datos supón case as mesmas ameazas que un contrasinal, é dicir, que expor a base de datos revela ao instante o valor e pon en risco non só a aplicación, senón tamén aplicacións potencialmente completamente diferentes que usan as mesmas preguntas de seguridade (aí de novo ). Unha opción é o hash seguro (un algoritmo forte e unha sal criptográficamente aleatoria), pero a diferenza da maioría dos casos de almacenamento de contrasinais, pode haber unha boa razón para que a resposta sexa visible como texto simple. Un escenario típico é a verificación de identidade por parte dun operador de telefonía en directo. Por suposto, o hash tamén é aplicable neste caso (o operador pode simplemente introducir a resposta nomeada polo cliente), pero no peor dos casos, a resposta secreta debe situarse nalgún nivel de almacenamento criptográfico, aínda que sexa só cifrado simétrico. . Resume: trata os segredos como segredos!
Un aspecto final das preguntas e respostas de seguridade é que son máis vulnerables á enxeñería social. Tentar extraer directamente o contrasinal da conta doutra persoa é unha cousa, pero comezar unha conversación sobre a súa formación (unha pregunta de seguridade popular) é completamente diferente. De feito, podes comunicarte moi ben con alguén sobre moitos aspectos da súa vida que poden plantexar unha pregunta secreta sen espertar sospeitas. Por suposto, o propio punto dunha pregunta de seguridade é que se relaciona coa experiencia de vida de alguén, polo que é memorable, e aí está o problema. á xente encántalle falar das súas experiencias vitais! Pouco podes facer respecto diso, só se escollas tales opcións de preguntas de seguridade para que o sexan menos probablemente podería ser retirado pola enxeñería social.
[Continuará.]Sobre os dereitos da publicidade
VDSina ofrece fiables , cada servidor está conectado a unha canle de Internet de 500 Megabits e está protexido de ataques DDoS de balde!
Fonte: www.habr.com