Onlangs had ik de tijd om opnieuw na te denken over hoe de functie voor veilig wachtwoord resetten zou moeten werken, vooral toen ik deze functionaliteit integreerde in , en daarna, toen ik hielp om iets soortgelijks voor een andere persoon te doen. In het tweede geval wilde ik hem een link geven naar de canonieke bron met alle details voor een veilige implementatie van de resetfunctie. Het probleem is echter dat zo'n bron niet bestaat, althans niet eentje die alles beschrijft wat ik belangrijk vind. Daarom besloot ik het zelf te schrijven.
Zie je, de wereld van vergeten wachtwoorden is eigenlijk behoorlijk mysterieus. Er zijn veel verschillende, volkomen acceptabele standpunten en een aantal behoorlijk gevaarlijke. Het is waarschijnlijk dat je als eindgebruiker vaak met elk van hen te maken hebt gehad; daarom zal ik proberen deze voorbeelden te gebruiken om te laten zien wie alles goed doet en wie niet, en waar je je op moet concentreren voor de juiste implementatie van de functie in je applicatie.
Wachtwoordopslag: hashing, versleuteling en (oh!) platte tekst
We kunnen niet bespreken wat te doen met vergeten wachtwoorden voordat we de opslagmethode bespreken. In de database worden wachtwoorden opgeslagen in een van de drie hoofdvormen:
- Platte tekst. Er is een kolom met het wachtwoord dat in gewone tekst is opgeslagen.
- Versleuteld. Meestal met behulp van symmetrische versleuteling (één sleutel wordt zowel voor versleuteling als ontsleuteling gebruikt), en de versleutelde wachtwoorden worden ook in één kolom opgeslagen.
- Gehasht. Een eenzijdig proces (een wachtwoord kan worden gehasht, maar niet worden ontsleuteld); het wachtwoord, hoop ik, wordt vergezeld door een zout, en elk bevindt zich in zijn eigen kolom.
Laten we meteen het eenvoudigste probleem aanpakken: sla nooit wachtwoorden op in platte tekst! Nooit. Eén enkele kwetsbaarheid voor , één ondoordacht gemaakte back-up of een van de tientallen andere eenvoudige fouten — en dat is het, game over, al je wachtwoorden — dat wil zeggen, excuses, de wachtwoorden van al je klanten worden openbaar bezit. Dit betekent uiteraard een enorme kans dat openbaar bezit wordt. van al hun accounts in andere systemen. En dat zal jouw schuld zijn.
Versleuteling is beter, maar heeft zijn zwakke plekken. Het probleem met versleuteling ligt in de ontcijfering; je kunt die gek uitziende cijfers nemen en ze terugzetten in platte tekst, en als dat gebeurt, komen we weer terecht in een situatie met leesbare wachtwoorden. Hoe gebeurt dit? Een kleine fout kan binnendringen in de code die zich bezighoudt met deontcijfering van het wachtwoord, waardoor het publiek toegankelijk wordt — dat is een manier. Hackers krijgen toegang tot de machine waarop de versleutelde gegevens zijn opgeslagen — dat is een tweede manier. Een andere manier is weer dat een back-up van de database wordt gestolen en iemand ook de versleutelingssleutel krijgt, die vaak zeer onbetrouwbaar wordt opgeslagen.
En dat brengt ons bij hashing. Het idee van hashing is dat het eenrichtingsverkeer is; de enige manier om het door de gebruiker ingevoerde wachtwoord te vergelijken met de gehashte versie is door het ingevoerde te hashen en deze met elkaar te vergelijken. Om aanvallen met hulpmiddelen zoals 'regenboogtabellen' te voorkomen, voegen we willekeurigheid aan het proces toe met een salt (voor de volledigheid, lees mijn over cryptografische opslag). Uiteindelijk, bij correcte implementatie, kunnen we met een grote mate van zekerheid stellen dat gehashte wachtwoorden nooit meer platte tekst zullen worden (ik zal de voordelen van verschillende hash-algoritmen in een andere post bespreken).
Een kort argument over hashing en versleuteling: de enige reden waarom je ooit een wachtwoord zou willen versleutelen in plaats van te hashen, is als je het wachtwoord in platte tekst wilt zien, en dat zou je nooit moeten willen, tenminste niet in de situatie van een standaardwebsite. Als je dat nodig hebt, doe je hoogstwaarschijnlijk iets verkeerd!
Let op!
Iets verderop in de post bevindt zich een gedeelte van een screenshot van de pornografische website AlotPorn. Het is netjes bijgesneden, en er is niets te zien dat je niet op het strand zou kunnen zien, maar als dit toch problemen kan veroorzaken, scroll dan niet verder naar beneden.
Reset altijd je wachtwoord, nooit dit herinneren
Is je ooit gevraagd om een functie te creëren voor herinnering Wachtwoord? Stap even terug en overweeg dit verzoek vanuit een ander perspectief: waarom is deze 'herinnering' nodig? Omdat de gebruiker zijn wachtwoord is vergeten. Wat willen we eigenlijk doen? Hem helpen weer in te loggen.
Ik begrijp dat het woord 'herinnering' (vaak) in de spreektaal wordt gebruikt, maar eigenlijk proberen we de gebruiker veilig weer online te helpen.Omdat we veiligheid nodig hebben, zijn er twee redenen waarom een herinnering (d.w.z. het toezenden van het wachtwoord aan de gebruiker) niet geschikt is:
- E-mail is een onveilige kanaal. Net zoals we niets vertrouwelijks via HTTP zouden versturen (we zouden HTTPS gebruiken), moeten we ook niets via e-mail versturen, omdat de transportlaag onveilig is. Eigenlijk is dit veel erger dan het gewoon verzenden van informatie via een onbeschermd transportprotocol, omdat e-mail vaak op opslagmedia wordt bewaard, toegankelijk is voor systeembeheerders, doorgestuurd en verspreid wordt, en toegankelijk is voor malware, enzovoort. Onversleutelde e-mail is een extreem onveilig kanaal.
- Je zou in ieder geval geen toegang tot het wachtwoord moeten hebben. Lees het bovenstaande gedeelte over opslag opnieuw — je moet een hash van het wachtwoord hebben (met een goede stevige zout), dat wil zeggen dat je op geen enkele manier het wachtwoord zou moeten kunnen uitlezen en het per e-mail versturen.
Laat me het probleem demonstreren aan de hand van het voorbeeld : Hier is een typische inlogpagina:
Het is duidelijk dat het eerste probleem is dat de inlogpagina niet via HTTPS wordt geladen, maar de site biedt ook nog de optie om het wachtwoord te versturen ('Send Password'). Mogelijk is dit een voorbeeld van de eerder genoemde spreektaaltoepassing van deze term, dus laten we nog een stap verder gaan en kijken wat er gebeurt:
Het ziet er helaas niet veel beter uit; e-mail bevestigt het bestaan van het probleem:
Dit vertelt ons twee belangrijke aspecten van usoutdoor.com:
- De site hash't wachtwoorden niet. In het beste geval zijn ze versleuteld, maar het is zeer waarschijnlijk dat ze in platte tekst worden opgeslagen; er is geen bewijs dat het anders is.
- De site verstuurt een langdurig wachtwoord (we kunnen het steeds weer gebruiken) via een onveilig kanaal.
Als we dit hebben begrepen, moeten we controleren of het resetproces veilig wordt uitgevoerd. Eerst moeten we ervoor zorgen dat de verzoeker het recht heeft om de reset uit te voeren. Met andere woorden, we hebben een identificatiecontrole nodig; laten we kijken wat er gebeurt wanneer de identiteit wordt bevestigd zonder vooraf te verifiëren of de verzoeker daadwerkelijk de eigenaar van de account is.
De vermelding van gebruikersnamen en de impact op anonimiteit
Dit probleem wordt beter visueel geïllustreerd. Probleem:
Zie je? Let op het bericht 'There is no user registered with this email address' ('Er is geen gebruiker geregistreerd met dit e-mailadres'). Het probleem doet zich duidelijk voor als zo'n site bevestigt aanwezigheid dat er een geregistreerde gebruiker is met dat e-mailadres. Bingo - je hebt zojuist de porno-fetisj van je man/bas/buurtbewoner ontdekt!
Natuurlijk is porno een vrij canoniek voorbeeld van het belang van privacy, maar het gevaar van het koppelen van een identiteit aan een bepaalde website is veel breder dan de bovengenoemde potentieel ongemakkelijke situatie. Een van de gevaren is sociale manipulatie; als een aanvaller in staat is om een persoon aan een service te koppelen, zal hij informatie hebben die hij kan beginnen te gebruiken. Bijvoorbeeld, hij kan contact opnemen met de persoon, zich voordoend als een vertegenwoordiger van de website, en om meer informatie vragen in een poging om .
Dergelijke praktijken brengen ook het gevaar van 'gebruikersnaamvermelding' met zich mee, waarbij de aanwezigheid van een hele verzameling gebruikersnamen of e-mailadressen op een website kan worden gecontroleerd met eenvoudige groepsverzoeken en het bestuderen van de antwoorden daarop. Heb je een lijst met e-mailadressen van alle medewerkers en een paar minuten om een script te schrijven? Dan zie je wat het probleem is!
Wat is de alternatieve oplossing? Eigenlijk is die vrij eenvoudig en geweldig gerealiseerd op :
Hier onthult Entropay totaal niets over het bestaan van een e-mailadres in hun systeem aan iemand die dit adres niet bezit. Als je bezit met dit adres en het bestaat niet in het systeem, dan ontvangt u een soortgelijke e-mail:
Natuurlijk zijn er aanvaardbare situaties waarin iemand denkt, dat hij zich heeft geregistreerd op de website. maar dat is niet het geval, of hij heeft dit gedaan met een ander e-mailadres. Het bovenstaande voorbeeld gaat goed om met beide situaties. Het is duidelijk, als het adres overeenkomt, ontvangt u een e-mail waarin het wachtwoord opnieuw kan worden ingesteld.
De finesse van de gekozen Entropay-oplossing is dat de identificatie wordt gecontroleerd via e-mail nog voordat online verificatie plaatsvindt. Sommige sites vragen gebruikers om een antwoord op een geheime vraag (meer hierover hieronder) tot over hoe het resetproces kan beginnen; echter, het probleem hierbij is dat men op de vraag moet antwoorden terwijl men een soort identificatie moet geven (e-mail of gebruikersnaam), waardoor het bijna onmogelijk wordt om intuïtief op de vraag te antwoorden zonder het bestaan van een anoniem gebruikersaccount te onthullen.
Bij deze aanpak is er een kleine daling in gebruiksvriendelijkheid, omdat er bij het proberen een niet-bestaand account opnieuw in te stellen geen directe feedback is. Natuurlijk is dat de hele zin van het versturen van een e-mail, maar vanuit het perspectief van de daadwerkelijke eindgebruiker, als hij een verkeerd adres invoert, zal hij dit voor het eerst ontdekken bij het ontvangen van de e-mail. Dit kan enige spanning veroorzaken, maar het is een kleine prijs voor zo'n zeldzaam proces.
Een andere opmerking, iets afgedwaald van het onderwerp: de inloghulpfuncties die de juistheid van de gebruikersnaam of het e-mailadres onthullen, hebben hetzelfde probleem. Geef altijd een antwoord aan de gebruiker met de mededeling "De combinatie van gebruikersnaam en wachtwoord is ongeldig", in plaats van expliciet te bevestigen dat de identificatie-informatie bestaat (bijvoorbeeld "de gebruikersnaam is juist, maar het wachtwoord is verkeerd ingevoerd").
Wachtwoordreset-e-mail versus het verzenden van een reset-URL
Het volgende concept dat we moeten bespreken, betreft de manier van het resetten van wachtwoorden. Er zijn twee populaire oplossingen:
- Een nieuw wachtwoord genereren op de server en dit per e-mail versturen
- Een e-mail sturen met een unieke URL die het resetproces vereenvoudigt
Ondanks , het eerste punt moet je nooit gebruiken. Het probleem ermee is dat dit betekent dat er een opgeslagen wachtwoord, waar je op elk moment naar terug kunt keren en het opnieuw kunt gebruiken; het is verzonden via een onveilige verbinding en blijft in je inbox. Er is een kans dat de inbox synchroniseert met mobiele apparaten en e-mailclients, en het kan bovendien online worden opgeslagen in de webmailservice gedurende lange tijd. Het idee is dat de mailbox niet kan worden beschouwd als een betrouwbare methode voor langdurige opslag..
Maar naast dit heeft het eerste punt nog een ernstig probleem — het vereenvoudigt maximaal de blokkering van accounts met kwade bedoelingen. Als ik het e-mailadres weet van degene die een account heeft op de website, kan ik het op elk moment blokkeren door simpelweg hun wachtwoord te resetten; dit is een denial-of-service aanval, gepresenteerd op een gouden schoteltje! Daarom moet de reset alleen worden uitgevoerd na succesvolle verificatie van wie het vraagt.
Wanneer we het hebben over de reset-URL, dan verwijzen we naar een website-adres dat uniek is voor dit specifieke resetproces.Natuurlijk moet deze willekeurig zijn, niet gemakkelijk te raden en geen externe links naar het account bevatten die de reset vergemakkelijken. Bijvoorbeeld, de reset-URL mag niet gewoon een pad zijn zoals "Reset/?username=JohnSmith".
We willen een unieke token creëren die via e-mail kan worden verzonden als een reset-URL, en vervolgens deze vergelijken met de record op de server die aan het gebruikersaccount is gekoppeld, om zo te bevestigen dat de eigenaar van het account inderdaad dezelfde persoon is die het wachtwoord probeert te resetten. Bijvoorbeeld, de token kan eruitzien als "3ce7854015cd38c862cb9e14a1ae552b" en worden opgeslagen in een tabel samen met de gebruikers-ID, die de reset uitvoert, en de tijd van token-generatie (hieronder meer over). Bij het verzenden van de e-mail bevat deze een URL zoals "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", en wanneer de gebruiker deze laadt, controleert de pagina het bestaan van de token, waarna de gebruikersinformatie wordt bevestigd en de wijziging van het wachtwoord wordt toegestaan.
Natuurlijk, aangezien het hierboven beschreven proces (hopelijk) de gebruiker in staat stelt een nieuw wachtwoord te maken, moet de URL over HTTPS worden geladen. Nee, deze URL met token moet het transportbeveiligingsniveau gebruiken, zodat de invoerformulieren voor het nieuwe wachtwoord niet aangevallen kunnen worden door en het door de gebruiker aangemaakte wachtwoord moet via een beveiligde verbinding worden verzonden.
Voor de reset-URL moet ook een tijdslimiet voor het token worden toegevoegd, zodat het resetproces binnen een bepaalde tijd kan worden uitgevoerd, bijvoorbeeld binnen een uur. Dit garandeert dat het tijdsvenster voor de reset minimaal is, zodat degene die deze reset-URL heeft ontvangen, alleen binnen dit zeer kleine venster kan handelen. Uiteraard kan een aanvaller het resetproces opnieuw starten, maar hij zal een nieuwe unieke reset-URL moeten verkrijgen.
Ten slotte moeten we ervoor zorgen dat dit proces eenmalig is. Na de voltooiing van het resetproces moet het token worden verwijderd, zodat de reset-URL niet langer actief is. Het vorige punt is belangrijk, zodat een aanvaller een zeer klein venster heeft waarin hij de reset-URL kan manipuleren. Bovendien, uiteraard, is het token na een succesvolle reset niet meer nodig.
Sommige van deze stappen kunnen overbodig lijken, maar ze belemmeren de gebruiksvriendelijkheid totaal niet en hebben we echt verhogen de veiligheid, hoewel dit in situaties is die, hopelijk, zeldzaam zullen zijn. In 99% van de gevallen zal de gebruiker de reset binnen een zeer kort tijdsbestek uitvoeren en zal hij het wachtwoord niet snel opnieuw willen resetten.
De rol van CAPTCHA,
O, CAPTCHA, het beschermingsmiddel dat we allemaal zo graag haten! In feite is CAPTCHA een middel tot identificatie — bent u een mens of een robot (of een geautomatiseerd script). Het idee is om te voorkomen dat formulieren automatisch worden verzonden, wat uiteraard, kan kan worden gebruikt als een poging om de bescherming te doorbreken. In de context van wachtwoordresets betekent CAPTCHA dat de resetfunctie niet kan worden gekraakt door brute kracht, om vervolgens de gebruiker te spammen of om te proberen het bestaan van accounts te bepalen (wat uiteraard onmogelijk zal zijn als u de tips uit het verificatiegedeelte heeft opgevolgd).
Natuurlijk is CAPTCHA op zichzelf niet perfect; er zijn talloze gevallen van softwarematige "hack" en het behalen van voldoende succespercentages (60-70%). Daarnaast is er een oplossing die in mijn post over , waarbij je mensen een fractie van een cent kunt betalen om elke CAPTCHA op te lossen en een succespercentage van 94% te behalen. Dit betekent dat het kwetsbaar is, maar (lichtjes) de toegangsdrempel verhoogt.
Laten we eens kijken naar een voorbeeld van PayPal:
In dit geval kan het resetproces gewoon niet beginnen totdat de CAPTCHA is opgelost, dus theoretisch is het automatiseren van het proces onmogelijk. Theoretisch.
Echter, voor de meeste webapplicaties zou dit overkill zijn en het vertegenwoordigt absoluut een vermindering van de gebruiksvriendelijkheid — mensen houden gewoon niet van CAPTCHA! Bovendien is CAPTCHA zoiets waarmee je eenvoudig kunt terugkomen wanneer dat nodig is. Als de service begint te worden aangevallen (hier komt logging van pas, maar daar later meer over), dan is het heel eenvoudig om CAPTCHA toe te voegen.
Geheime vragen en antwoorden
Bij alle besproken methoden konden we het wachtwoord resetten door alleen toegang te hebben tot het e-mailadres. Ik zeg "alleen", maar natuurlijk is het illegaal om toegang te krijgen tot een ander iemands e-mailaccount. moet dat kan een ingewikkeld proces zijn. Echter, .
Eigenlijk dient de bovenstaande link over het hacken van Sarah Palin's account op Yahoo! twee doelen; ten eerste illustreert het hoe gemakkelijk het is om (sommige) e-mailaccounts te hacken, en ten tweede toont het aan hoe slechte geheime vragen kwaadwillig kunnen worden gebruikt. Maar daar komen we later op terug.
Het probleem met het resetten van wachtwoorden dat volledig afhankelijk is van e-mail is dat de integriteit van het account van de site waarvan je het wachtwoord probeert te resetten, volledig afhankelijk wordt van de integriteit van het e-mailaccount. Iedereen die toegang heeft tot je e-mail, heeft toegang tot elk account dat je kunt resetten door simpelweg een e-mail te ontvangen.Voor zulke accounts is e-mail de "sleutel tot alle deuren" van je online leven.
Een van de manieren om dit risico te verminderen, is door het implementeren van het patroon van een geheime vraag en antwoord. Zonder twijfel heb je ze al gezien: je kiest een vraag waarvan alleen jij het antwoord weet, waarna deze je wordt voorgelegd bij het resetten van je wachtwoord. moeten Dit geeft vertrouwen dat de persoon die probeert het wachtwoord opnieuw in te stellen daadwerkelijk de eigenaar van het account is.
Laten we terugkomen op Sarah Palin: de fout was dat de antwoorden op haar geheime vraag/vragen gemakkelijk konden worden gevonden. Vooral wanneer je zo'n belangrijke publieke figuur bent, is informatie zoals de meisjesnaam van je moeder, je onderwijsachtergrond of waar iemand in het verleden heeft gewoond, niet zo geheim. Sterker nog, het grootste deel kan door vrijwel iedereen worden gevonden. Dat was ook het geval met Sarah:
Hacker David Kernell kreeg toegang tot het account van Palin door details over haar biografie, zoals haar universiteit en geboortedatum, te vinden en vervolgens de functie voor het herstellen van vergeten wachtwoorden van Yahoo! te gebruiken.
In de eerste plaats is dit een ontwerpfout van Yahoo! — door zulke eenvoudige vragen te stellen, heeft het bedrijf in wezen de waarde van de geheime vraag gesaboteerd, en dus de bescherming van zijn systeem. Natuurlijk is het altijd moeilijker om een wachtwoord voor een e-mailaccount opnieuw in te stellen, aangezien je de eigendom ervan niet kunt bevestigen door de eigenaar een e-mail te sturen (zonder een tweede adres), maar gelukkig zijn er tegenwoordig niet veel manieren om een dergelijk systeem te creëren.
Laten we terugkomen op de geheime vragen — er is een optie om de gebruiker de mogelijkheid te geven om hun eigen vragen te creëren. Het probleem is dat dit resulteert in vreselijk voor de hand liggende vragen:
Welke kleur heeft de lucht?
Vragen waardoor mensen zich ongemakkelijk voelen, wanneer voor identificatie de geheime vraag gebruikt wordt door een persoon (bijvoorbeeld in een callcenter):
Met wie heb ik gekust met Kerstmis?
Of openlijk domme vragen:
Hoe schrijf je 'wachtwoord'?
Als het gaat om geheime vragen, moeten gebruikers beschermd worden tegen zichzelf! Met andere woorden, de geheime vraag moet door de site zelf worden bepaald, en nog beter, een reeks van geheime vragen moeten beschikbaar zijn waaruit de gebruiker kan kiezen. En niet alleen kiezen; idealiter zou de gebruiker twee of meer geheime vragen moeten kunnen kiezen éénop het moment van registratie van het account. в момент регистрации аккаунта, die vervolgens als tweede identificatiekanaal zullen worden gebruikt. Het hebben van meerdere vragen verhoogt de betrouwbaarheid van het verificatieproces en biedt de mogelijkheid om enige willekeurigheid toe te voegen (niet altijd dezelfde vraag te tonen), plus het zorgt voor enige redundantie voor het geval de echte gebruiker zijn wachtwoord is vergeten.
Wat maakt een goede beveiligingsvraag? Dit wordt beïnvloed door verschillende factoren:
- Het moet zijn kort — de vraag moet duidelijk en ondubbelzinnig zijn.
- Het antwoord moet zijn concreet — we willen geen vraag waarbij één persoon verschillend kan antwoorden.
- Mogelijke antwoorden moeten zijn divers — een vraag naar iemands favoriete kleur biedt een zeer klein subset van mogelijke antwoorden.
- Zoeken het antwoord moet moeilijk zijn — als het antwoord gemakkelijk te vinden is elk （denk aan mensen in hoge posities), dan is het slecht.
- Het antwoord moet zijn constant in de tijd — als je naar iemands favoriete film vraagt, kan het antwoord over een jaar anders zijn.
Zoals het gaat, bestaat er een website die gewijd is aan goede vragen, genaamd . Sommige vragen lijken heel goed, andere slagen niet voor sommige van de hierboven beschreven tests, vooral de 'zoekgemak' test.
Laat me laten zien hoe beveiligingsvragen zijn geïmplementeerd bij PayPal en in het bijzonder welke inspanningen de site levert om te verifiëren. Boven hebben we de startpagina van het proces (met CAPTCHA) gezien, en hier laten we zien wat er gebeurt nadat je je e-mailadres invoert en de CAPTCHA oplost:
Daarna ontvangt de gebruiker een dergelijke e-mail:
Tot nu toe is alles vrij standaard, maar dit is wat er achter deze reset-URL schuilgaat:
Dus, beveiligingsvragen komen in het spel. In feite maakt PayPal het ook mogelijk om een wachtwoord te resetten door het creditcardnummer te bevestigen, waardoor er een extra kanaal is waartoe veel sites geen toegang hebben. Ik kan mijn wachtwoord gewoon niet wijzigen zonder te antwoorden op beide beveiligingsvragen (of zonder het kaartnummer te weten). Zelfs als iemand mijn e-mailaccount hackt, kan hij het wachtwoord van mijn PayPal-account niet resetten zonder iets meer persoonlijke informatie over mij te kennen. Welke informatie? Dit zijn de opties voor beveiligingsvragen die PayPal aanbiedt:
De vraag over de school en het ziekenhuis kan enigszins dubieus zijn qua eenvoud van zoeken, maar de anderen zijn niet zo slecht. Echter, voor een verhoogde veiligheid vereist PayPal aanvullende identificatie voor wijzigingen de antwoorden op geheime vragen:
PayPal is een vrij utopisch voorbeeld van veilige wachtwoordreset: het implementeert CAPTCHA om het risico op brute-force-aanvallen te verlagen, vereist twee geheime vragen en vraagt vervolgens nog een volledig andere vorm van identificatie alleen voor het wijzigen van antwoorden - en dit gaat nadat de gebruiker al is ingelogd. Uiteraard was dit precies wat we verwachten van PayPal; het is een financiële organisatie die met grote bedragen geld werkt. Dit betekent niet dat elke wachtwoordreset deze stappen moet volgen - in de meeste gevallen is het overkill - maar het is een goed voorbeeld voor gevallen waarin veiligheid een serieuze zaak is.
Het gemak van het systeem van geheime vragen is dat als je het niet meteen hebt geïmplementeerd, je het later kunt toevoegen als dat het veiligheidsniveau van de bron vereist. Een goed voorbeeld hiervan is Apple, dat deze mechanismen pas recent heeft geïmplementeerd [artikel schreef in 2012]. Toen ik eenmaal begon met het bijwerken van de app op de iPad, zag ik de volgende prompt:
Toen zag ik een scherm waarop ik verschillende paren geheime vragen en antwoorden kon selecteren, evenals een reddings-e-mailadres:
Wat betreft PayPal, de vragen zijn vooraf gekozen en sommige zijn eigenlijk best goed:
Elk van de drie paren vragen en antwoorden vertegenwoordigt een aparte set mogelijke vragen, dus er zijn voldoende manieren om het account te configureren.
Een ander aspect dat moet worden overwogen met betrekking tot het beantwoorden van de geheime vraag, is opslag. Het hebben van gewone tekst in de database vertegenwoordigt bijna dezelfde bedreigingen als in het geval van een wachtwoord, namelijk - het onthullen van de database onthult onmiddellijk de waarde en brengt niet alleen de applicatie, maar ook potentieel volstrekt andere applicaties in gevaar die dezelfde geheime vragen gebruiken (het is weer ). Een van de opties is veilige hashing (een robuust algoritme en cryptografisch willekeurige salt), maar in tegenstelling tot de meeste gevallen van wachtwoordopslag, kan hier een valide reden zijn voor de zichtbaarheid van het antwoord als platte tekst. Een typisch scenario is identiteitsverificatie door een live operator via de telefoon. Uiteraard is hashing in dit geval ook van toepassing (de operator kan eenvoudigweg het door de klant genoemde antwoord invoeren), maar in het slechtste geval moet het geheime antwoord op een bepaald niveau van cryptografische opslag zijn, zelfs als het gewoon symmetrische encryptie is. Laten we samenvatten: behandel geheimen als geheimen!
En een laatste aspect van geheime vragen en antwoorden is dat ze kwetsbaarder zijn voor sociale engineering. Proberen rechtstreeks het wachtwoord van iemand anders zijn account te achterhalen is één ding, maar een gesprek beginnen over zijn opleiding (een populaire geheime vraag) is iets heel anders. In werkelijkheid kun je heel goed met iemand praten over veel aspecten van zijn leven die een geheime vraag kunnen zijn, zonder argwaan te wekken. Uiteraard is de essentie van de geheime vraag dat deze verband houdt met iemands levenservaring, waardoor deze memorabel is, en dat is precies het probleem — mensen houden ervan om over hun levenservaring te vertellen! Hier valt niet veel aan te doen, behalve het kiezen van zulke opties voor geheime vragen, zodat ze met minder kans kunnen worden achterhaald door sociale engineering.
[Vervolg volgt.]
Adverteervermelding
VDSina biedt betrouwbare , elke server is aangesloten op een internetkanaal van 500 Megabit en gratis beschermd tegen DDoS-aanvallen!
Bron: habr.com
