Enkele suggesties:

Stel het wachtwoord van de gebruiker niet opnieuw in totdat het is bevestigd. Stel het wachtwoord van de gebruiker niet onmiddellijk opnieuw in. Stel het pas opnieuw in als de gebruiker op een bevestigingslink klikt die naar zijn vooraf geregistreerde e-mailadres is verzonden.

Een CAPTCHA vereist. Wanneer een gebruiker vraagt ​​om zijn wachtwoord opnieuw in te stellen, forceer hem dan om een ​​CAPTCHA op te lossen voordat u verder gaat. Dit is bedoeld om te voorkomen dat geautomatiseerde tools veel gebruikers verdriet proberen te bezorgen, en de gebruiker te dwingen te bewijzen dat ze een mens zijn (geen robot).

Willekeurig. De beperkte tijd URL voor het opnieuw instellen van een wachtwoord moet een willekeurig, niet te raden onderdeel bevatten. Zorg ervoor dat u willekeurigheid van cryptokwaliteit gebruikt. De uitvoer van / dev / urandom of System.Security.Cryptography.RNGCryptoServiceProvider zou een goede keuze zijn. De uitvoer van rand () of random () of System.Random is niet willekeurig genoeg en zou een slechte keuze zijn. Een GUID of tijdstempel is niet willekeurig genoeg en zou geen goede keuze zijn.

Voeg een tijdslimiet toe. De bevestigingslink voor het opnieuw instellen moet na een redelijke tijd verlopen: bijvoorbeeld 24 uur . De link mag slechts één keer bruikbaar zijn en moet onmiddellijk vervallen zodra deze wordt gebruikt.

Voeg een verklarende tekst toe aan de e-mail. Misschien wilt u wat verklarende tekst toevoegen aan de e-mail, om uit te leggen waarom de e-mail is verzonden, voor het geval iemand een reset aanvraagt ​​voor een account dat niet van jou is. U kunt tekst toevoegen zoals "Iemand heeft gevraagd om het wachtwoord opnieuw in te stellen voor uw account gebruikersnaam op site . Als u dit verzoek heeft gedaan, klikt u hier om uw wachtwoord te wijzigen. Als u heeft dit verzoek niet gedaan, klik hier om het verzoek te annuleren. "

Stuur een e-mail nadat het wachtwoord opnieuw is ingesteld. Zodra het wachtwoord is gereset, stuurt u een e-mail naar de gebruiker naar laat hen weten dat het wachtwoord is gewijzigd. Voeg het nieuwe wachtwoord niet toe aan die e-mail.

Annuleringen controleren. U kunt overwegen wat logica op te nemen om te controleren hoe vaak gebruikers op de annuleringslink klikken om aan te geven dat ze geen reset hebben aangevraagd. Als dit boven een bepaalde drempel uitkomt, kan het handig zijn om een ​​waarschuwing te sturen naar de netbeheerders. Ook als een annuleringslink voor een bepaald verzoek wordt bezocht nadat de bevestigingslink is bezocht, is dat een mogelijke indicatie van een aanval op die gebruiker - misschien wilt u op dat moment actie ondernemen, bijvoorbeeld ongeldig maken het wachtwoord van de gebruiker en vereisen dat ze hun wachtwoord opnieuw instellen. (Dit is een verdediging tegen de volgende aanval: de aanvaller krijgt toegang tot de mailbox van de gebruiker, vraagt ​​vervolgens om het wachtwoord op uw site te resetten en bezoekt vervolgens de bevestigingslink. Als de aanvaller deze e-mails niet uit de inbox van de gebruiker verwijdert, wanneer de echte gebruiker zijn e-mail leest, kan hij op de annuleringslink klikken, waardoor u een indicatie krijgt van mogelijke problemen.)

Gebruik HTTPS. De link moet https gebruiken (niet http :), ter bescherming tegen verschillende aanvallen (bijv. Firesheep-aanvallen op gebruikers die op internet surfen vanuit een internetcafé).

Log deze bewerkingen. Ik raad aan om al dergelijke verzoeken te loggen. Naast het loggen van de gebruikersnaam van de gebruiker, wil je misschien het IP-adres van de client die om een ​​reset-link heeft gevraagd, per e-mail naar de gebruiker sturen, evenals het IP-adres van de client die de reset-link heeft bezocht.

Meer lezen. Misschien wil je ook de uitstekende blogpost van Troy Hunt lezen, Alles wat je ooit wilde weten over het bouwen van een veilige functie voor het opnieuw instellen van wachtwoorden. Met dank aan @coryT voor een link naar deze bron.

Ten slotte overweeg authenticatie zonder wachtwoord. Wachtwoorden hebben veel problemen als authenticatiemechanisme, en u zou andere methoden kunnen overwegen om gebruikers te authenticeren, zoals het opslaan van een veilige permanente cookie op hun computer met een niet te raden geheim om ze te authenticeren. Op deze manier is er geen wachtwoord om te vergeten en kan de gebruiker geen phishing krijgen, hoewel u een gebruiker wel een manier moet bieden om toegang te verlenen vanaf een nieuwe machine of een nieuwe browser (mogelijk via e-mail naar de pre- geregistreerd e-mailadres). Dit enquêtedocument bevat een uitstekend overzicht van veel alternatieve verificatiemethoden en hun sterke en zwakke punten.

Troy Hunt heeft een heel mooie beschrijving van deze exacte vraag. Alles wat je ooit wilde weten over het bouwen van een veilige functie voor het opnieuw instellen van wachtwoorden

OK, dus uw vraag is: hoe moet u het proces voor wachtwoord- / accountherstel structureren? Dat hangt af van waarvoor u wilt optimaliseren: probleemloze gebruikerservaring of goede beveiliging.

Als u een goede beveiliging wilt:

• Tijdens het aanmelden moet de gebruiker zijn e-mailadres invoeren.

• Tijdens het aanmelden moet de gebruiker een secundair kanaal invoeren voor authenticatie: mobiel telefoonnummer of uitdagingsvraag &-antwoord (bijv. " wat is de meisjesnaam van je moeder "of beter).

• Tijdens het herstel krijgt je systeem eerst een ruwe identiteitsverificatie door middel van het bovenstaande secundaire kanaal - de uitdaging vraag, of door een code naar de mobiele telefoon of iets dergelijks te sms'en.

• Wanneer de eerste identiteitscontrole hierboven is voltooid, stuurt het systeem een ​​e-mail voor het opnieuw instellen van het wachtwoord alleen naar het eerder ingevoerde e-mailadres . Dit is een aanvullende, belangrijke maatregel om f.x. exploits van het type Sarah Palin.

• De e-mail mag geen een nieuw wachtwoord of iets dergelijks bevatten. Het moet een klikbare link bevatten naar een HTTPS-gecodeerde webpagina op uw site die a) aan het account is gekoppeld via een niet-radenbare geheime waarde in de URL, b) is in de tijd beperkt, dus het accountherstel werkt slechts x uur nadat het werd aangevraagd, c) biedt de eindgebruiker een manier om een ​​ nieuw wachtwoord aan te maken.

• Zorg voor een goede logboekregistratie bij alle accountresettransacties, en laat een mens deze daadwerkelijk controleren en handelen als ze verdacht lijken (kijk in de serverlogboeken voor de IP-adressen fx, veel verzoeken komen van hetzelfde IP-adres, zijn er gevallen waarin een gebruiker wachtwoorden probeert te resetten uit een ander land dan dat van de geregistreerde accounteigenaar, enz.).

U kunt deze complexiteit ook helemaal omzeilen: het is nog pril, maar OAuth / OpenID / inloggen via Facebook, Google enz. verwijdert deze complexiteit volledig uit uw systemen, maar met een misschien minder gevestigde bruikbaarheid.

Elke plaats die je een wachtwoord kan sturen, betekent dat ze het wachtwoord niet hashen, maar opslaan waar het op de een of andere manier kan worden ontsleuteld tot 'leesbare tekst'. Dit op zichzelf is slecht.

Waarschijnlijk niet "meest" veilig, maar veiliger zou zijn om:

Na wachtwoordverzoek een wachtwoordherstellink naar de gebruiker te sturen met ingesloten GUID. De sessie in de GUID verloopt over, hmm, uur of zo.

Een andere die al dan niet geschikt is voor uw toepassing, maar die wordt gebruikt in toepassingen voor internetbankieren en dergelijke, is om de helft van de resetcode per sms naar een geregistreerde mobiele telefoon te verzenden. Vanuit het perspectief van een aanvaller is dit een complete PITA, aangezien er een aantal kanalen moet worden gecompromitteerd om te breken.

De veiligste manier om een ​​wachtwoordreset uit te voeren, is door een grote willekeurige unieke eenmalige reset-token te genereren, met een vervaldatum, gekoppeld aan de gebruikers-ID. Het token moet in de database worden gehasht, aangezien een aanvaller met SQL-toegang het kan gebruiken om willekeurige gebruikerswachtwoorden opnieuw in te stellen.

Er moet een reset-link naar het e-mailadres worden gestuurd dat het reset-token bevat. Wanneer de gebruiker op de link klikt, moet de hash van het token in de database worden gevonden en moet de vervaldatum worden geverifieerd als in de toekomst. Als aan deze voorwaarden is voldaan, moet de gebruiker een scherm te zien krijgen waarop hij een nieuw wachtwoord kan typen.

Dit hele proces moet worden uitgevoerd via SSL, anders een aanvaller kan de URL opsnuiven en het wachtwoord resetten voordat de gebruiker het doet.

Een paar andere tips:

1. Geheime vragen een kleine ergernis voor aanvallers en een grote ergernis voor gebruikers. Vermijd ze volledig.
2. Stel de gebruiker voor met een menselijke verificatie-uitdaging (bijv. Een CAPTCHA) voordat het wachtwoord opnieuw wordt ingesteld. Dit voorkomt geautomatiseerde resetverzoeken.
3. Controleer of het IP-adres dat de reset uitvoert, het IP-adres is dat eerder met succes op het account is ingelogd. Is dit niet het geval, vraag dan wat meer details over het account / de gebruiker, bijv. aanmaakjaar van account, geboortedatum, eerste adresregel.
4. Voeg een link 'Ik heb niet om deze e-mail gevraagd' toe, zodat gebruikers foutieve verzoeken voor wachtwoordherstel kunnen rapporteren.
ol >

2-factor authenticatie via sms! 1 je kent de klant en zijn gsm-nummer, sms hem een ​​unieke code om toe te voegen aan de website om te valideren dat hij het is :)

Maak er een paar stappen van. Bijvoorbeeld zoiets als dit:

1. Gebruiker is zijn wachtwoord vergeten. Hij klikt op de knop "Ik ben mijn wachtwoord vergeten, stuur me een e-mail wat ik nu moet doen" (knoplabel kan verschillen;))
2. Je server stuurt hem een ​​link www.uwdomein.com/lostpassword?param_1 = x; param_2 = y
3. Hij klikt op de link en kan zelf een nieuw wachtwoord aanmaken
4. Hij klikt op verzenden. Alles klaar. Iedereen tevreden

Een en enige vangst is in punt 3). X- en Y-waarden moeten willekeurig en onvoorspelbaar zijn en aan dit ene specifieke account zijn gekoppeld. Ze mogen ook slechts voor eenmalig worden gebruikt en moeten na een korte tijd (24 uur?) Oud worden. Sla beide waarden op in een speciale tabel met de bijbehorende kolommen:

  | some_id | user_id | X | Y | expire_time  

Als een gebruiker de juiste link probeert te gebruiken, controleer dan of de vervaltijd niet gehaald is en zo niet, laat hem dan het wachtwoord wijzigen.