Ik had onlangs tijd om opnieuw na te denken over hoe de functie voor het veilig opnieuw instellen van wachtwoorden zou moeten werken, eerst toen ik de functionaliteit inbouwde , en toen hij hielp iets vergelijkbaars met een andere persoon te doen. In het tweede geval wilde ik hem een link geven naar de canonieke bron met alle details van de veilige implementatie van de reset-functie. Het probleem is echter dat een dergelijke bron niet bestaat, althans niet een die alles beschrijft wat mij belangrijk lijkt. Daarom besloot ik het zelf te schrijven.
Zie je, de wereld van vergeten wachtwoorden is eigenlijk behoorlijk mysterieus. Er zijn veel verschillende, volkomen aanvaardbare standpunten en een heleboel nogal gevaarlijke. De kans is groot dat u ze als eindgebruiker al vele malen bent tegengekomen; dus ik zal proberen deze voorbeelden te gebruiken om te laten zien wie het goed doet en wie niet, en waar u zich op moet concentreren om een functie op de juiste manier in uw toepassing te implementeren.
Wachtwoordopslag: hashing, encryptie en (oh!) platte tekst
We kunnen niet bespreken wat we met vergeten wachtwoorden moeten doen voordat we bespreken hoe ze worden opgeslagen. Wachtwoorden worden in een van de volgende drie hoofdtypen in de database opgeslagen:
- Platte tekst. Er is een kolom met een wachtwoord, die in platte tekst is opgeslagen.
- gecodeerd. Meestal wordt gebruik gemaakt van symmetrische codering (er wordt één sleutel gebruikt voor zowel codering als decodering), en gecodeerde wachtwoorden worden ook in dezelfde kolom opgeslagen.
- gehasht. Eenrichtingsproces (wachtwoord kan worden gehasht maar niet gedehashed); wachtwoord, hopelijk, gevolgd door een zout, en elk staat in zijn eigen kolom.
Laten we meteen de eenvoudigste vraag beantwoorden: bewaar wachtwoorden nooit in platte tekst! Nooit. Eén enkele kwetsbaarheid , een onzorgvuldig gemaakte reservekopie of een van de tientallen andere simpele fouten - en dat is alles, game-over, al je wachtwoorden - dat wil zeggen, sorry, wachtwoorden voor al uw klanten publiek bezit zal worden. Dit betekent natuurlijk een grote kans dat van al hun accounts in andere systemen. En het zal jouw schuld zijn.
Encryptie is beter, maar heeft zijn zwakke punten. Het probleem van encryptie zit in de decryptie; we kunnen deze gek uitziende cijfers nemen en ze terug naar platte tekst converteren, en als dat gebeurt, zijn we terug bij de situatie met leesbare wachtwoorden. Hoe gebeurde dit? Er komt een klein foutje in de code die het wachtwoord decodeert, waardoor het publiekelijk beschikbaar wordt - dit is één manier. Hackers verkrijgen toegang tot de machine waarop de gecodeerde gegevens zijn opgeslagen - dit is de tweede manier. Een andere manier is wederom om de back-up van de database te stelen, en iemand krijgt ook de coderingssleutel, die vaak erg onveilig wordt opgeslagen.
En dat brengt ons bij hashing. Het idee achter hashen is dat het op één manier gebeurt; de enige manier om het door de gebruiker ingevoerde wachtwoord te vergelijken met de gehashte versie is door het ingevoerde wachtwoord te hashen en te vergelijken. Om aanvallen met tools zoals regenboogtabellen te voorkomen, gebruiken we salt om willekeur aan het proces toe te voegen (voor het volledige beeld, lees mijn over cryptografische opslag). Uiteindelijk kunnen we er, als ze correct worden geïmplementeerd, veilig van uitgaan dat gehashte wachtwoorden nooit meer platte tekst zullen worden (ik zal de voordelen van verschillende hash-algoritmen in een ander bericht bespreken).
Snel argument over hashing en encryptie: de enige reden dat u ooit een wachtwoord zult moeten coderen in plaats van hashen, is wanneer u het wachtwoord in platte tekst moet zien in plaats van je zou het nooit moeten willen, tenminste in de situatie van een standaardwebsite. Als je dit nodig hebt, doe je hoogstwaarschijnlijk iets verkeerd!
Waarschuwing!
Iets verderop in de tekst van het bericht staat een deel van een screenshot van de pornografische website AlotPorn. Het is netjes bijgesneden, dus er is niets dat niet te zien is op het strand, maar als dat toch problemen oplevert, scroll dan niet naar beneden.
Reset altijd uw wachtwoord nooit herinner hem er niet aan
Is u ooit gevraagd een functie te maken herinneringen wachtwoord? Doe een stap terug en denk in omgekeerde volgorde over dit verzoek na: waarom is deze “herinnering” nodig? Omdat de gebruiker het wachtwoord is vergeten. Wat willen we echt doen? Help hem opnieuw in te loggen.
Ik begrijp dat het woord 'herinnering' (vaak) in de volksmond wordt gebruikt, maar wat we eigenlijk proberen te doen is Help de gebruiker veilig weer online te zijn. Omdat we beveiliging nodig hebben, zijn er twee redenen waarom een herinnering (d.w.z. het sturen van het wachtwoord aan de gebruiker) niet gepast is:
- E-mail is een onveilig kanaal. Net zoals we niets vertrouwelijks via HTTP zouden verzenden (we zouden HTTPS gebruiken), zouden we niets via e-mail moeten verzenden omdat de transportlaag ervan onveilig is. In feite is dit veel erger dan het eenvoudigweg verzenden van informatie via een onveilig transportprotocol, omdat e-mail vaak op de schijf wordt opgeslagen, beschikbaar is voor systeembeheerders, wordt doorgestuurd en gedistribueerd, beschikbaar is voor malware, enzovoort. Niet-versleutelde e-mail is een uiterst onveilig kanaal.
- U zou sowieso geen toegang tot het wachtwoord moeten hebben. Herlees het vorige gedeelte over opslag - u moet een hash van het wachtwoord hebben (met een goede, sterke salt), wat betekent dat u op geen enkele manier het wachtwoord kunt extraheren en opsturen.
Laat ik het probleem met een voorbeeld demonstreren : Hier is een typische inlogpagina:
Het eerste probleem is uiteraard dat de inlogpagina niet via HTTPS laadt, maar de site biedt ook aan om een wachtwoord te sturen ("Wachtwoord verzenden"). Misschien is dit een voorbeeld van het informele gebruik van de hierboven genoemde term, dus laten we nog een stap verder gaan en kijken wat er gebeurt:
Het ziet er helaas niet veel beter uit; en de e-mail bevestigt dat er een probleem is:
Dit vertelt ons over twee belangrijke aspecten van usoutdoor.com:
- De site hasht geen wachtwoorden. In het beste geval zijn ze gecodeerd, maar het is waarschijnlijk dat ze in platte tekst zijn opgeslagen; Wij zien geen bewijs van het tegendeel.
- De site verzendt een langetermijnwachtwoord (we kunnen teruggaan en het steeds opnieuw gebruiken) via een onveilig kanaal.
Nu dat uit de weg is, moeten we controleren of het resetproces op een veilige manier wordt uitgevoerd. De eerste stap om dit te doen is ervoor te zorgen dat de aanvrager het recht heeft om de reset uit te voeren. Met andere woorden: daarvoor hebben we een identiteitscontrole nodig; Laten we eens kijken wat er gebeurt als een identiteit wordt geverifieerd zonder eerst te verifiëren dat de aanvrager inderdaad de eigenaar van het account is.
Opsomming van gebruikersnamen en de impact ervan op de anonimiteit
Dit probleem kan het beste visueel worden geïllustreerd. Probleem:
Zien? Let op de melding "Er is geen gebruiker geregistreerd met dit e-mailadres". Het probleem ontstaat uiteraard als een vergelijkbare site dit bevestigt наличие geregistreerd met een dergelijk e-mailadres van de gebruiker. Bingo - je hebt zojuist de pornofetisj van je man/baas/buurman ontdekt!
Natuurlijk is porno een tamelijk canoniek voorbeeld van het belang van privacy, maar de gevaren van het koppelen aan een bepaalde website zijn veel groter dan de potentieel gênante situatie die hierboven wordt beschreven. Eén gevaar is social engineering; als een aanvaller een persoon aan een dienst kan koppelen, beschikt hij over informatie die hij kan gaan gebruiken. Hij kan bijvoorbeeld contact opnemen met een persoon die zich voordoet als vertegenwoordiger van een website en om aanvullende informatie vragen in een poging dat te doen .
Dergelijke praktijken brengen ook het gevaar met zich mee van "gebruikersnaamopsomming", waarbij het mogelijk is om het bestaan van een hele verzameling gebruikersnamen of e-mailadressen op een website te controleren door middel van eenvoudige bulkquery's en het onderzoeken van de antwoorden daarop. Heeft u een lijst met de e-mailadressen van alle medewerkers en een paar minuten om een script te schrijven? Dan zie je wat het probleem is!
Wat is het alternatief? In feite is het vrij eenvoudig en opmerkelijk geïmplementeerd :
Hier onthult Entropay helemaal niets over het bestaan van een e-mailadres in haar systeem. aan iemand die niet de eigenaar is van dit adres... als jij eigen adres en het bestaat niet in het systeem, u ontvangt een e-mail als deze:
Natuurlijk zijn er acceptabele situaties waarin iemand denktdie zich op de website heeft geregistreerd. maar dit is niet het geval, of gebeurde vanaf een ander mailadres. Het bovenstaande voorbeeld behandelt beide situaties met succes. Als het adres overeenkomt, ontvangt u uiteraard een e-mail waarmee u eenvoudig uw wachtwoord opnieuw kunt instellen.
De subtiliteit van de door Entropay gekozen oplossing is dat identiteitsverificatie wordt uitgevoerd door e-mail voorafgaand aan enige online controle. Sommige sites vragen gebruikers om het antwoord op een beveiligingsvraag (meer hierover hieronder) naar hoe de reset kan beginnen; Het probleem hiermee is echter dat je de vraag moet beantwoorden terwijl je een of andere vorm van identificatie (e-mailadres of gebruikersnaam) moet opgeven, waardoor het vrijwel onmogelijk is om intuïtief te antwoorden zonder het bestaan van een anonieme gebruikersaccount te onthullen.
Met deze aanpak, daar klein afname van de bruikbaarheid, omdat er bij een poging om een niet-bestaand account te resetten geen onmiddellijke feedback is. Dit is natuurlijk het hele punt van het verzenden van een e-mail, maar vanuit het perspectief van de echte eindgebruiker zal hij, als hij het verkeerde adres invoert, dit pas voor het eerst weten wanneer hij de brief ontvangt. Dit kan enige spanning van zijn kant veroorzaken, maar dit is een kleine prijs voor zo'n zeldzaam proces.
Nog een enigszins off-topic opmerking: inloghulpfuncties die de juiste gebruikersnaam of het juiste e-mailadres onthullen, hebben hetzelfde probleem. Reageer altijd op de gebruiker met het bericht "Uw gebruikersnaam en wachtwoordcombinatie is ongeldig", in plaats van expliciet het bestaan van de identiteitsgegevens te bevestigen (bijvoorbeeld: "de gebruikersnaam is correct, maar het wachtwoord is onjuist").
Een resetwachtwoord verzenden versus een reset-URL verzenden
Het volgende concept dat we moeten bespreken heeft te maken met de methode voor het opnieuw instellen van het wachtwoord. Er zijn twee populaire oplossingen:
- Een nieuw wachtwoord genereren op de server en dit per e-mail verzenden
- Een e-mail verzenden met een unieke URL om het resetproces te vereenvoudigen
Niettegenstaande , mag het eerste punt nooit worden gebruikt. Zijn probleem is dat het betekent hebben opgeslagen wachtwoord, waarnaar u op elk moment kunt terugkeren en opnieuw kunt gebruiken; het is verzonden via een onveilig kanaal en blijft in uw inbox staan. Er is een kans dat inboxen worden gesynchroniseerd met mobiele apparaten en e-mailclient, en dat ze heel lang online kunnen worden bewaard in een webgebaseerde e-mailservice. Het punt is dat de brievenbus kan niet worden beschouwd als een betrouwbaar middel voor langdurige opslag.
Maar daarnaast heeft de eerste paragraaf nog een ernstig probleem: deze vereenvoudigt zoveel mogelijk accountblokkering met kwade bedoelingen. Als ik het e-mailadres ken van iemand die een account op een website heeft, kan ik hem op elk moment blokkeren door simpelweg zijn wachtwoord opnieuw in te stellen; het is een denial-of-service-aanval op een presenteerblaadje! Daarom mag de reset alleen worden uitgevoerd na een succesvolle controle bij de aanvrager op de rechten erop.
Als we het hebben over de reset-URL, bedoelen we het websiteadres, namelijk uniek voor dit specifieke geval van het resetproces. Uiteraard moet het willekeurig zijn, mag het niet gemakkelijk te raden zijn en mag het geen externe verwijzingen naar het account bevatten waardoor het gemakkelijk kan worden gereset. De reset-URL mag bijvoorbeeld niet zomaar een pad zijn, zoals 'Reset/?gebruikersnaam=JohnSmith'.
We willen een uniek token maken dat kan worden gemaild als een reset-URL en vervolgens kan worden vergeleken met het serverrecord van het gebruikersaccount, waardoor wordt geverifieerd dat de accounteigenaar inderdaad dezelfde persoon is die probeert het wachtwoord opnieuw in te stellen. Een token kan er bijvoorbeeld uitzien als "3ce7854015cd38c862cb9e14a1ae552b" en in een tabel worden opgeslagen, samen met het opnieuw ingestelde gebruikers-ID en de tijd voor het genereren van het token (daarover later meer). Wanneer de e-mail wordt verzonden, bevat deze een URL zoals "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", en wanneer de gebruiker deze laadt, vraagt de pagina om het bestaan van het token, bevestigt vervolgens de gegevens van de gebruiker en staat toe dat het wachtwoord wordt gewijzigd.
Omdat het bovenstaande proces de gebruiker (hopelijk) in staat stelt een nieuw wachtwoord aan te maken, moeten we er natuurlijk voor zorgen dat de URL via HTTPS wordt geladen. Nee, , moet deze URL met het token transportlaagbeveiliging gebruiken, zodat het nieuwe wachtwoordinvoerformulier niet kan worden aangevallen en het door de gebruiker aangemaakte wachtwoord werd via een beveiligde verbinding verzonden.
Ook moet u voor de reset-URL een tokentijdslimiet toevoegen, zodat het resetproces binnen een bepaald interval, bijvoorbeeld binnen een uur, kan worden voltooid. Dit zorgt ervoor dat het resettijdvenster zo kort mogelijk wordt gehouden, zodat de ontvanger van deze reset-URL alleen binnen dit zeer kleine venster kan handelen. Uiteraard kan een aanvaller het resetproces opnieuw starten, maar hij zal dan een andere unieke reset-URL moeten krijgen.
Ten slotte moeten we ervoor zorgen dat dit proces wegwerpbaar is. Zodra het resetproces is voltooid, moet het token worden verwijderd, zodat de reset-URL niet langer geldig is. Het vorige punt is nodig zodat de aanvaller een heel klein venster heeft waarin hij de reset-URL kan manipuleren. Bovendien is het token na de succesvolle voltooiing van de reset uiteraard niet langer nodig.
Sommige van deze stappen lijken misschien overbodig, maar ze belemmeren de bruikbaarheid niet in feite de veiligheid te verbeteren, zij het in situaties waarvan we hopen dat ze zeldzaam zullen zijn. In 99% van de gevallen zal de gebruiker de reset binnen zeer korte tijd inschakelen en zal hij het wachtwoord in de nabije toekomst niet opnieuw resetten.
Rol van CAPTCHA
Oh, CAPTCHA, de beveiligingsmaatregel die we allemaal graag haten! In feite is CAPTCHA niet zozeer een beschermingsmiddel als wel identificatie: je bent een persoon of een robot (of een geautomatiseerd script). Het doel ervan is om automatische formulierinzendingen te voorkomen, wat uiteraard kan worden gebruikt als een poging om de bescherming te verbreken. In de context van het opnieuw instellen van wachtwoorden betekent CAPTCHA dat de resetfunctie niet bruut kan worden geforceerd om de gebruiker te spammen of te proberen het bestaan van accounts vast te stellen (wat uiteraard niet mogelijk zou zijn als u de tips in het gedeelte over identiteit verificatie).
CAPTCHA zelf is natuurlijk niet perfect; er zijn veel precedenten waarin het programmatisch wordt "gehackt" en voldoende succespercentages behaalt (60-70%). Er staat ook een oplossing in mijn bericht over , waar je mensen fracties van een cent kunt betalen om elke CAPTCHA op te lossen en een succespercentage van 94% te behalen. Dat wil zeggen: het is kwetsbaar, maar verhoogt (enigszins) de toetredingsdrempel.
Laten we een PayPal-voorbeeld bekijken:
In dit geval kan het resetproces eenvoudigweg niet starten voordat de CAPTCHA is opgelost theoretisch het is onmogelijk om het proces te automatiseren. In theorie.
Voor de meeste webapplicaties zal dit echter overdreven zijn helemaal gelijk vertegenwoordigt een afname van de bruikbaarheid - mensen houden gewoon niet van CAPTCHA's! Daarnaast is CAPTCHA zo’n ding waar je indien nodig gemakkelijk naar terug kunt keren. Als de service wordt aangevallen (loggen is hier handig, maar daarover later meer), dan kan het toevoegen van een CAPTCHA niet eenvoudiger.
Geheime vragen en antwoorden
Met alle methoden die we hebben bekeken, konden we het wachtwoord opnieuw instellen, gewoon door toegang te hebben tot het e-mailaccount. Ik zeg "gewoon", maar natuurlijk illegaal toegang verkrijgen tot het e-mailaccount van iemand anders moet een complex proces zijn. Echter .
In feite is de bovenstaande link over Sarah Palin's Yahoo! dient twee doelen; ten eerste illustreert het hoe gemakkelijk het is om (sommige) e-mailaccounts te hacken, en ten tweede laat het zien hoe slechte geheime vragen kwaadwillig kunnen worden gebruikt. Maar we komen hier later op terug.
Het probleem met het opnieuw instellen van wachtwoorden die XNUMX% e-mailafhankelijk zijn, is dat de accountintegriteit van de site die u probeert te resetten XNUMX% afhankelijk wordt van de integriteit van het e-mailaccount. Iedereen die toegang heeft tot uw e-mail heeft toegang tot elk account dat kan worden gereset door simpelweg een e-mail te ontvangen. Voor dergelijke accounts is e-mail de "sleutel tot alle deuren" van uw online leven.
Eén manier om dit risico te beperken is het implementeren van een beveiligingsvraag- en antwoordpatroon. Je hebt ze ongetwijfeld al gezien: kies een vraag die alleen jij hebt hebben weet het antwoord, waarna u hierom wordt gevraagd wanneer u uw wachtwoord opnieuw instelt. Dit draagt bij aan het vertrouwen dat de persoon die probeert te resetten inderdaad de eigenaar van het account is.
Terug naar Sarah Palin: de fout was dat de antwoorden op haar geheime vraag/vragen gemakkelijk te vinden waren. Vooral als je zo'n grote publieke figuur bent, is informatie over de meisjesnaam van je moeder, de schoolgeschiedenis of waar iemand in het verleden heeft gewoond niet zo geheim. In feite kan het meeste ervan door vrijwel iedereen worden gevonden. Dit is wat er met Sara gebeurde.
Hacker David Kernell kreeg toegang tot Palins account door haar achtergrondgegevens te vinden, zoals haar middelbare school en geboortedatum, en vervolgens de functie voor het herstellen van wachtwoorden voor verloren accounts van Yahoo! te gebruiken.
Dit is in de eerste plaats een ontwerpfout van Yahoo! - Door zulke eenvoudige vragen te specificeren saboteerde het bedrijf in wezen de waarde van de geheime vraag, en daarmee de bescherming van zijn systeem. Natuurlijk is het opnieuw instellen van wachtwoorden voor een e-mailaccount altijd lastiger, omdat je het eigendom ervan niet kunt verifiëren door de eigenaar te e-mailen (zonder dat je een tweede adres hebt), maar gelukkig zijn er tegenwoordig niet veel toepassingen voor zo'n systeem.
Terug naar geheime vragen - er is een optie waarmee de gebruiker zijn eigen vragen kan maken. Het probleem is dat het resultaat vreselijk voor de hand liggende vragen zullen zijn:
Welke kleur is de lucht?
Vragen die mensen in een ongemakkelijke positie brengen wanneer een beveiligingsvraag een geheime vraag gebruikt om zich te identificeren человек (bijvoorbeeld in een callcenter):
Met wie heb ik met Kerstmis geslapen?
Of eerlijk gezegd domme vragen:
Hoe spel je "wachtwoord"?
Als het om beveiligingsvragen gaat, moeten gebruikers van zichzelf worden gered! Met andere woorden: de geheime vraag moet de site zelf bepalen, of beter nog, stellen serie beveiligingsvragen waaruit de gebruiker kan kiezen. En kies niet zomaar een; Idealiter zou de gebruiker twee of meer beveiligingsvragen moeten selecteren op het moment van accountregistratie, dat vervolgens als tweede identificatiekanaal zal worden gebruikt. Het hebben van meerdere vragen verhoogt het vertrouwen in het verificatieproces, maakt willekeur mogelijk (niet altijd dezelfde vraag) en biedt een beetje redundantie voor het geval de echte gebruiker het wachtwoord is vergeten.
Wat zou een goede beveiligingsvraag moeten zijn? Verschillende factoren zijn hierop van invloed:
- Het zou moeten zijn kort De vraag moet duidelijk en ondubbelzinnig zijn.
- Het antwoord moet zijn: specifiek — we hebben geen vraag nodig die één persoon op verschillende manieren kan beantwoorden
- Mogelijke antwoorden zouden moeten zijn gevarieerd Als je iemands favoriete kleur vraagt, krijg je maar een heel klein deel van de mogelijke antwoorden.
- zoeken het antwoord moet complex zijn - als het antwoord gemakkelijk te vinden is een (denk aan mensen in een hoge positie), dan is hij slecht
- Het antwoord moet zijn: permanent na verloop van tijd - als je iemands favoriete film vraagt, kan het antwoord een jaar later anders zijn
Toevallig bestaat er een website gewijd aan goede vragen . Sommige vragen lijken redelijk goed te zijn, andere slagen niet voor sommige van de hierboven beschreven tests, met name voor de 'makkelijk te vinden'-test.
Ik zal u laten zien hoe beveiligingsvragen in PayPal worden geïmplementeerd en, in het bijzonder, hoeveel moeite de site aan identificatie besteedt. We hebben de startpagina van het proces (met CAPTCHA) hierboven gezien, en hier laten we zien wat er gebeurt nadat u uw e-mailadres invoert en de CAPTCHA oplost:
Als gevolg hiervan ontvangt de gebruiker de volgende e-mail:
Tot nu toe zo normaal, maar dit is wat er achter deze reset-URL zit:
Er spelen dus geheime vragen. Met PayPal kunt u zelfs uw wachtwoord opnieuw instellen door uw creditcardnummer te verifiëren, zodat er een extra kanaal is waar veel sites geen toegang toe hebben. Ik kan mijn wachtwoord alleen niet wijzigen zonder te antwoorden beide geheime vraag (of het kaartnummer niet kennen). Zelfs als iemand mijn e-mail kaapt, kunnen ze het wachtwoord van hun PayPal-account niet opnieuw instellen, tenzij ze wat meer persoonlijke informatie over mij weten. Welke informatie? Dit zijn de opties voor beveiligingsvragen die PayPal biedt:
De vraag over school en ziekenhuis is misschien een beetje dubieus als het gaat om het zoekgemak, maar de andere zijn niet zo slecht. Om de veiligheid te verbeteren heeft PayPal echter aanvullende identificatie nodig veranderingen antwoorden op beveiligingsvragen:
PayPal is een nogal utopisch voorbeeld van een veilige wachtwoordreset: het implementeert een CAPTCHA om het risico op brute kracht te verminderen, vereist twee beveiligingsvragen en vereist vervolgens nog een ander soort totaal andere identiteit om de antwoorden te wijzigen - en dat is achter de gebruiker aan. heeft zich al aangemeld. Dit is natuurlijk precies wat wij doen verwacht zou van PayPal zijn; het is een financiële instelling die met grote sommen geld omgaat. Dit betekent niet dat elke wachtwoordreset deze stappen moet volgen (in de meeste gevallen is dit overdreven), maar het is een goed voorbeeld voor gevallen waarin beveiliging een serieuze zaak is.
Het gemak van het beveiligingsvragensysteem is dat als u het niet meteen heeft geïmplementeerd, u het later kunt toevoegen als het beschermingsniveau van de bron dit vereist. Een goed voorbeeld hiervan is Apple, dat dit mechanisme pas onlangs heeft geïmplementeerd. [artikel geschreven in 2012]. Toen ik begon met het updaten van de applicatie op de iPad, zag ik het volgende verzoek:
Toen zag ik een scherm waarin ik meerdere paren beveiligingsvragen en -antwoorden kon selecteren, evenals een reddings-e-mailadres:
Wat PayPal betreft, de vragen zijn vooraf geselecteerd en sommige zijn eigenlijk best goed:
Elk van de drie paren vragen en antwoorden vertegenwoordigt een andere reeks mogelijke vragen, dus er zijn tal van manieren om een account te configureren.
Een ander aspect waarmee rekening moet worden gehouden bij het antwoord op de beveiligingsvraag is opslag. Platte tekst in de database brengt vrijwel dezelfde bedreigingen met zich mee als in het geval van een wachtwoord, namelijk het blootleggen van de database onthult onmiddellijk de waarde en brengt niet alleen de applicatie in gevaar, maar mogelijk ook compleet andere applicaties die dezelfde beveiligingsvragen gebruiken (dit is opnieuw ). Eén optie is veilige hashing (sterk algoritme en cryptografisch willekeurig zout), maar in tegenstelling tot de meeste gevallen van wachtwoordopslag kan er een goede reden zijn dat het antwoord als platte tekst verschijnt. Een typisch scenario is identiteitsverificatie door een live telefoonoperator. Natuurlijk is hashen in dit geval ook van toepassing (de operator kan eenvoudigweg het door de cliënt genoemde antwoord invoeren), maar in het ergste geval moet het geheime antwoord zich op een bepaald niveau van cryptografische opslag bevinden, ook al is het slechts symmetrische codering. Samenvatten: behandel geheimen als geheimen!
En het laatste aspect van geheime vragen en antwoorden is dat ze kwetsbaarder zijn voor social engineering. Proberen rechtstreeks om het wachtwoord voor het account van iemand anders te vragen is één ding, maar een gesprek beginnen over zijn opleiding (een populaire geheime vraag) is heel iets anders. In feite is het heel goed mogelijk dat u met iemand communiceert over vele aspecten van zijn leven die een geheime vraag kunnen vormen, en zonder argwaan te wekken. De essentie van een geheime vraag is natuurlijk dat deze verband houdt met iemands levenservaring, zodat deze wordt onthouden, en dit is waar het probleem ligt: mensen praten graag over hun levenservaringen! U kunt hier niet veel aan doen, tenzij u de opties voor beveiligingsvragen kiest minder waarschijnlijk door social engineering worden teruggetrokken.
[Wordt vervolgd.]Als advertentie
VDSina biedt betrouwbaar Elke server is verbonden met een internetkanaal van 500 Mbps en is gratis beschermd tegen DDoS-aanvallen!
Bron: www.habr.com