The Definitive Guide to-formulieren gebaseerde authenticatie van websites

stemmen
4k

-Form-gebaseerde authenticatie voor websites

Wij zijn van mening dat stack overflow een bron voor zeer specifieke technische vragen, maar ook voor algemene richtlijnen over hoe om variaties op veel voorkomende problemen op te lossen niet alleen zou moeten zijn. Formulier gebaseerde authenticatie voor websites moet een boete onderwerp voor een dergelijk experiment zijn.

Het moet omvatten onderwerpen zoals:

  • Hoe om in te loggen
  • Hoe om uit te loggen
  • Hoe ingelogd blijven
  • Het beheren van cookies (inclusief aanbevolen instellingen)
  • SSL / HTTPS-encryptie
  • Hoe om wachtwoorden op te slaan
  • Met behulp van geheime vragen
  • Vergeten gebruikersnaam en / of wachtwoord vergeten functionaliteit
  • Het gebruik van nonces om te voorkomen dat cross-site request vervalsingen (CSRF)
  • OpenID
  • checkbox Remember me
  • Browser automatisch aanvullen van gebruikersnamen en wachtwoorden
  • Secret URL's (openbare URL beschermd door digest)
  • Controleren wachtwoordsterkte
  • E-mail validatie
  • en nog veel meer over de vorm gebaseerde authenticatie ...

Het moet niet omvatten dingen zoals:

  • Rollen en autorisatie
  • HTTP Basic Authentication

U kunt ons helpen door:

  1. suggereren subonderwerpen
  2. Het indienen van goede artikelen over dit onderwerp
  3. Bewerken van de officiële antwoord
De vraag is gesteld op 02/08/2008 om 20:51
bron van user
In andere talen...                            


12 antwoorden

stemmen
382

definitieve artikel

Het verzenden van de geloofsbrieven

De enige praktische manier om referenties veilig verzenden 100% is met behulp van SSL . JavaScript gebruiken om het wachtwoord hash is niet veilig. Voorkomende valkuilen voor client-side wachtwoord hashing:

  • Als de verbinding tussen de client en server is niet versleuteld, alles wat je doet is kwetsbaar voor man-in-the-middle-aanvallen . Een aanvaller kan het inkomende javascript om de hashing breken of stuur alle referenties naar hun server te vervangen, konden ze naar klant reacties luisteren en zich voordoen als de gebruiker perfect, is etc. etc. SSL met vertrouwde Certificate Authorities ontworpen om MitM aanvallen te voorkomen.
  • De gehashte wachtwoord ontvangen door de server is minder veilig als je geen extra, redundante werkzaamheden op de server doen.

Er is een andere veilige methode genaamd SRP , maar het is gepatenteerd (hoewel het vrije licentie ) en er zijn weinig goede implementaties beschikbaar.

Het opslaan van wachtwoorden

Do not ever wachtwoorden als platte tekst in de database. Zelfs niet als je niet de zorg over de veiligheid van uw eigen site. Neem aan dat sommige van uw gebruikers het wachtwoord van hun online bankrekening te hergebruiken. Dus, bewaar de gehashte wachtwoord, en gooi het origineel. En zorg ervoor dat het wachtwoord niet te zien in de toegang logs of applicatie logs. OWASP adviseert het gebruik van Argon2 als uw eerste keuze voor nieuwe toepassingen. Als dit niet beschikbaar is, moet PBKDF2 of scrypt plaats daarvan worden gebruikt. En tenslotte als geen van de bovenstaande beschikbaar zijn, gebruiken bcrypt.

Hashes door zelf ook onzeker. Bijvoorbeeld, identieke wachtwoorden betekenen identieke hashes - dit maakt hash opzoektabellen een effectieve manier om het kraken veel wachtwoorden tegelijk. In plaats daarvan slaan de gezouten hash. Een zout een tekenreeks toegevoegd aan het wachtwoord vóór hashing - via een andere (willekeurige) zout per gebruiker. Het zout is een publieke waarde, zodat u ze kunt opslaan met de hash in de database. Zie hier voor meer informatie hierover.

Dit betekent dat u niet de gebruiker kan sturen hun vergeten wachtwoorden (omdat je alleen de hash). Laat het wachtwoord van de gebruiker niet opnieuw in te stellen, tenzij u de gebruiker zijn geverifieerd (gebruikers moeten aantonen dat zij in staat zijn om e-mails verzonden naar de opgeslagen (en gevalideerde) e-mail adres te lezen.)

Veiligheidsvragen

Veiligheid vragen zijn onzeker - vermijd het gebruik ervan. Waarom? Alles wat een beveiligingsvraag doet, een wachtwoord doet het beter. Lees DEEL III: het gebruik van geheime vragen in @Jens Roland antwoord hier in deze wiki.

Session cookies

Nadat de gebruiker zich aanmeldt, de server stuurt de gebruiker een sessie cookie. De server kan de gebruikersnaam of id van het cookie te halen, maar niemand anders kan zo'n cookie te genereren (TODO uitleggen mechanismen).

Cookies kunnen worden gekaapt : ze zijn zo veilig als de rest van de machine van de klant en andere vormen van communicatie. Ze kunnen worden gelezen van schijf, snoof in het netwerkverkeer, opgetild door een cross-site scripting-aanval, phishing vanuit een vergiftigde DNS, zodat de klant hun cookies stuurt naar de verkeerde servers. Laat permanente cookies niet te sturen. Cookies moeten vervallen aan het einde van de client sessie (browser te sluiten of het verlaten van uw domein).

Als u wilt dat uw gebruikers autologin, kunt u een blijvende cookie te stellen, maar het moet onderscheiden worden van een full-sessie cookie. U kunt een extra vlag die de gebruiker automatisch aangemeld, en moet om in te loggen voor echt voor de gevoelige operaties in te stellen. Dit is populair bij shopping sites die willen u te voorzien van een naadloze, gepersonaliseerde shopping ervaring, maar toch bescherming van uw financiële gegevens. Bijvoorbeeld, wanneer je terugkeert naar Amazon te bezoeken, ze tonen u een pagina die eruit ziet als je ingelogd bent, maar als je naar een bestelling te plaatsen (of wijzigen van uw afleveradres, credit card etc.), ze je vragen om te bevestigen uw wachtwoord.

Financiële websites zoals banken en credit cards, aan de andere kant, alleen gevoelige gegevens en mogen niet toestaan ​​dat auto-login of een lage-security-modus.

Lijst van externe middelen

antwoordde op 02/08/2008 om 21:40
bron van user

stemmen
3k

DEEL I: Hoe om in te loggen

We gaan ervan uit dat je al weet hoe je een login + wachtwoord HTML-formulier op te bouwen welke functies de waarden om een ​​script op de server voor verificatie. De secties hieronder zal zich bezighouden met patronen voor geluid praktische Auth, en hoe u de meest voorkomende security valkuilen te vermijden.

HTTPS of niet HTTPS?

Tenzij de verbinding is al beveiligd (dat wil zeggen, getunneld door middel van HTTPS met SSL / TLS), zal uw login formulier waarden worden verzonden in leesbare tekst, die het mogelijk maakt iedereen afluisteren op de lijn tussen de browser en de webserver in staat om logins te lezen als ze passeren zullen zijn door. Dit soort aftappen wordt routinematig uitgevoerd door regeringen, maar in het algemeen zullen we niet 'eigendom' draden anders dan om dit te zeggen aan te pakken: Als je iets belangrijks beschermen, HTTPS.

In wezen is de enige praktische manier om te beschermen tegen afluisteren / packet sniffing tijdens het inloggen is het gebruik van HTTPS of een ander op basis van certificaten encryptie regeling (bijvoorbeeld TLS ) of een beproefde en geteste challenge-response-regeling (bijvoorbeeld de Diffie-Hellman gebaseerde SRP). Elke andere methode kan eenvoudig worden omzeild door een afluisteren aanvaller.

Natuurlijk, als je bereid bent een beetje onpraktisch om te krijgen, kun je ook een bepaalde vorm van twee-factor authenticatie-regeling (bijvoorbeeld de Google Authenticator-app, een fysieke 'koude oorlog style' codeboek, of een RSA key generator dongle) in dienst. Indien correct toegepast, kan dit zelfs werken met een onbeveiligde verbinding, maar het is moeilijk voor te stellen dat een dev bereid zijn om uit te voeren twee-factor authenticatie, maar niet SSL zou zijn.

(Niet) Roll-your-own JavaScript encryptie / hashing

Gezien de niet-nul kosten en ervaren technische problemen bij het opzetten van een SSL-certificaat op uw website, zijn sommige ontwikkelaars geneigd om hun eigen in-browser hashing of encryptie regelingen rollen om te voorkomen dat het passeren van cleartext logins via een onbeveiligde draad.

Hoewel dit een edele gedachte is het in wezen nutteloos is (en kan worden lek ) indien het wordt gecombineerd met één van de bovengenoemde - dat wil zeggen, ofwel het vastzetten van de lijn met sterke versleuteling of met een beproefde en geteste challenge-response mechanisme (als je niet weet wat dat is, weet alleen dat het een van de meest moeilijk te bewijzen, het meest moeilijk te ontwerpen, en moeilijkste om concepten in digitale beveiliging uit te voeren).

Hoewel het waar is dat de hash het wachtwoord kan effectief zijn tegen wachtwoord openbaarmaking , is het kwetsbaar voor aanvallen af te spelen, man-in-the-middle-aanvallen / kapingen (als een aanvaller een paar bytes kan injecteren in uw ongedekte HTML-pagina voordat het uw bereikt browser, kunnen ze gewoon commentaar uit de hashing in de JavaScript), of brute-force aanvallen (aangezien u de aanvaller zowel gebruikersnaam, zout overhandigen en hashed wachtwoord).

CAPTCHA's tegen de menselijkheid

CAPTCHA's zijn bedoeld om een specifieke categorie van de aanval te dwarsbomen: geautomatiseerde woordenboek / brute kracht trial-and-error zonder menselijke operator. Er is geen twijfel dat dit een reële bedreiging, maar er zijn manieren van omgaan met het naadloos die niet beschikt over een CAPTCHA nodig, in het bijzonder goed ontworpen serverside login smoren's - we zullen later bespreken die.

Weet dat CAPTCHA implementaties zijn niet gelijk geschapen; ze zijn vaak niet menselijk-oplosbaar zijn, de meeste van hen zijn eigenlijk niet effectief tegen bots, alle van hen zijn niet effectief tegen goedkope derdewereld-arbeid (volgens OWASP , het huidige sweatshop tarief is $ 12 per 500 tests), en sommige implementaties kunnen zijn technisch gezien illegaal in sommige landen (zie OWASP Authentication Cheat Sheet ). Als u een CAPTCHA moet gebruiken, gebruik maken van Google's reCAPTCHA , omdat het OCR-hard per definitie (sinds het gebruik van al OCR-onjuist geclassificeerd boek scans) en probeert heel hard om gebruiksvriendelijk zijn.

Persoonlijk ben ik geneigd om captcha's vervelend te vinden, en gebruik ze alleen als laatste redmiddel wanneer een gebruiker heeft nagelaten een aantal keren en smoren vertragingen in te loggen worden maxxed uit. Dit zal zelden genoeg gebeuren aanvaardbaar te zijn, en het versterkt het systeem als geheel.

Het opslaan van wachtwoorden / verifiëren van logins

Dit kan uiteindelijk algemeen bekend beschouwd, na al het opzienbarende hacks en gebruikersgegevens lekken hebben we gezien in de afgelopen jaren, maar het moet gezegd worden: geen wachtwoorden in leesbare tekst op te slaan in uw database. Gebruiker databases worden regelmatig gehackt, uitgelekt of verzameld via SQL-injectie, en als je het opslaan van rauwe, plaintext wachtwoorden, dat is meteen game over voor uw login veiligheid.

Dus als je het wachtwoord niet kunt opslaan, hoe ga je controleren of de login + wachtwoord combinatie Geplaatst van het login formulier juist zijn? Het antwoord wordt via een hashing sleutelafleidingsbericht functie . Wanneer een nieuwe gebruiker wordt gemaakt of een wachtwoord is veranderd, het wachtwoord neemt u en voer het uit door middel van een KDF, zoals Argon2, bcrypt, scrypt of PBKDF2, het draaien van de leesbare tekst wachtwoord ( "correcthorsebatterystaple") in een lange, willekeurige uitziende koord , dat is een stuk veiliger op te slaan in uw database. Om een login te controleren, u dezelfde hash-functie uitvoeren op het ingevoerde wachtwoord, dit keer passeren in het zout en vergelijk de resulterende hash string naar de opgeslagen in uw database waarde. Argon2, bcrypt en scrypt slaan van het zout met de hash reeds. Check dit artikel op sec.stackexchange voor meer gedetailleerde informatie.

De reden dat een zout wordt gebruikt is omdat hashing op zich is niet voldoende - je wilt een zogenaamde 'zout' toe te voegen aan de hash te beschermen tegen rainbow tables . Zout voorkomt effectief twee wachtwoorden die exact overeenkomen worden opgeslagen als dezelfde hash-waarde, waardoor alle symbolen worden afgetast in een run als een aanvaller het wachtwoord raden aanval wordt uitgevoerd.

Een cryptografische hash mag niet worden gebruikt voor de opslag van wachtwoorden, omdat de gebruiker geselecteerde wachtwoorden zijn niet sterk genoeg is (dat wil zeggen meestal niet bevatten genoeg entropie) en een wachtwoord raden aanval zou in een relatief korte tijd kan worden voltooid door een aanvaller met toegang tot de hashes. Dit is de reden waarom een KDF wordt gebruikt - deze effectief "Rek de key" wat betekent dat elk wachtwoord te raden een aanvaller maakt impliceert iteratie de hash-algoritme meerdere keren, bijvoorbeeld 10.000 keer, waardoor het wachtwoord van de aanvaller te raden 10.000 keer langzamer.

Session data - "U bent aangemeld als Spiderman69"

Zodra de server de login en het wachtwoord tegen uw gebruikersdatabase heeft geverifieerd en vond een wedstrijd, het systeem moet een manier om te onthouden dat de browser is geauthenticeerd. Dit moet altijd alleen worden opgeslagen server side in de sessie data.

Als je niet bekend bent met data van de sessie zijn, hier is hoe het werkt: Een enkel willekeurig gegenereerde reeks wordt opgeslagen in een verlopende cookie en wordt gebruikt om een ​​verzameling van gegevens verwijzen - de sessie data - die is opgeslagen op de server. Als u gebruik maakt van een MVC framework, is dit ongetwijfeld al afgehandeld.

Als het mogelijk is, zorg ervoor dat de sessie-cookie heeft de veilige en HTTP Alleen vlaggen instellen wanneer naar de browser. De HttpOnly vlag enige bescherming tegen het cookie wordt gelezen door een XSS-aanval. De beveiligde vlag zorgt ervoor dat het cookie alleen wordt teruggestuurd via HTTPS, en daarom beschermt tegen netwerk snuiven aanvallen. De waarde van de cookie mag niet voorspelbaar zijn. Wanneer een cookie te verwijzen naar een niet-bestaande sessie wordt gepresenteerd, moet de waarde ervan onmiddellijk worden vervangen om te voorkomen dat fixatie sessie .

DEEL II: How To aangemeld blijven - de beruchte "Remember Me" checkbox

Persistent Inloggen Cookies ( "onthoud mij" functionaliteit) zijn een gevarenzone bevindt; aan de ene kant, ze zijn volledig even veilig als conventionele logins wanneer gebruikers weten hoe om te gaan; en aan de andere kant zijn ze een enorm gevaar voor de veiligheid in de handen van onzorgvuldig gebruikers, die ze kunnen gebruiken op openbare computers en vergeet uit te loggen, en die niet weten welke browser cookies zijn en hoe om ze te verwijderen.

Persoonlijk vind ik aanhoudende logins voor de websites die ik bezoek op een regelmatige basis, maar ik weet hoe ze veilig te behandelen. Als u positief dat uw gebruikers weten hetzelfde zijn, kunt u aanhoudende logins gebruiken met een rein geweten. Zo niet - nou ja, dan kunt u zich abonneren op de filosofie dat gebruikers die onzorgvuldig met hun inloggegevens bracht het op zich als ze gehackt. Het is niet alsof we naar de huizen van onze gebruikers en scheur al die facepalm-inducerende Post-it notities met wachtwoorden zij hebben met aan de rand van hun monitoren, hetzij.

Natuurlijk kunnen sommige systemen niet veroorloven om het even welke accounts gehackt; voor dergelijke systemen, is er geen manier waarop je kan rechtvaardigen welke persistente logins.

Als je besluit om hardnekkige login cookies uit te voeren, dit is hoe je het doet:

  1. Ten eerste, enige tijd duren om te lezen artikel Paragon Initiative over het onderwerp. Je moet een heleboel elementen goed te krijgen, en het artikel doet een groot werk uit te leggen elk.

  2. En alleen maar om een van de meest voorkomende valkuilen herhalen, NIET in uw database Bewaar de aanmeldingssleutels COOKIE (TOKEN) slechts een hash van IT! De login token is Password Equivalent, dus als een aanvaller kregen hun handen op je database, konden ze de tokens gebruiken om in te loggen op een rekening, net alsof ze waren cleartext login-wachtwoord combinaties. Gebruik daarom hashing (volgens https://security.stackexchange.com/a/63438/5002 een zwakke hash prima hiertoe doen) bij opslag aanmeldingssleutels tokens.

DEEL III: Het gebruik van geheime vraag?

Niet uit te voeren 'geheime vragen' . De functie 'geheime vragen' is een security anti-patroon. Lees het papier uit koppeling nummer 4 van de must-read lijst. U kunt Sarah Palin vragen over die ene, na haar Yahoo! e-mail account gehackt tijdens een vorige presidentiële campagne, omdat het antwoord op haar geheime vraag was ... "Wasilla High School"!

Zelfs met de gebruiker opgegeven vragen, is het zeer waarschijnlijk dat de meeste gebruikers ofwel zullen kiezen:

  • Een 'standaard' geheime vraag als de meisjesnaam van de moeder of favoriete huisdier

  • Een eenvoudig stukje trivia dat iedereen kon tillen uit hun blog, LinkedIn profiel, of soortgelijke

  • Elke vraag die is makkelijker te beantwoorden dan hun wachtwoord te raden. Die voor elke fatsoenlijke wachtwoord, is elke vraag die u zich kunt voorstellen

Tot slot, veiligheid vragen inherent onveilig zijn in vrijwel al hun vormen en variaties, en mag niet worden gebruikt in een methode voor identiteitscontrole voor welke reden dan ook.

De ware reden waarom de beveiliging vragen bestaan, zelfs in het wild is dat ze gemakkelijk de kosten van een paar support calls te redden van gebruikers die geen toegang hebben tot hun e-mail naar een reactivering code te krijgen. Dit ten koste van de veiligheid en de reputatie van Sarah Palin. De moeite waard? Waarschijnlijk niet.

DEEL IV: Wachtwoord vergeten functionaliteit

Ik heb al gezegd waarom je moet nooit gebruik van beveiligingsvragen voor het afhandelen vergeten / verloren wachtwoorden van gebruikers; het spreekt ook vanzelf dat je nooit moet een e-mail gebruikers hun daadwerkelijke wachtwoorden. Er zijn ten minste twee meer al te veel voorkomende valkuilen te vermijden in dit gebied:

  1. Do not reset een vergeten wachtwoord om een automatisch gegenereerde sterk wachtwoord - zoals wachtwoorden zijn notoir moeilijk te onthouden, wat betekent dat de gebruiker moet ofwel wijzigen of schrijf het op - laten we zeggen, op een heldere gele Post-It op het puntje van hun monitor. In plaats van het instellen van een nieuw wachtwoord, laat het gebruikers kies een nieuw meteen - en dat is wat ze willen toch doen.

  2. Hash altijd het verloren wachtwoord code / token in de database. OPNIEUW , deze code is een ander voorbeeld van een wachtwoord Equivalent, dus het moet worden gehashed in het geval een aanvaller kregen hun handen op je database. Wanneer een verloren wachtwoord code wordt gevraagd, stuur het leesbare code om het e-mailadres van de gebruiker, hash dan, sla je de hash in de database - en gooi het origineel . Net zoals een wachtwoord of een hardnekkige login token.

Een laatste opmerking: altijd voor zorgen dat de interface voor het invoeren van de 'verloren wachtwoord code' is minstens zo veilig als uw login formulier zelf, of een aanvaller gewoon dit gebruiken om toegang plaats te krijgen. Zorg ervoor dat u genereert heel lang 'verloren wachtwoord codes' (bijvoorbeeld 16 hoofdlettergevoelig alfanumerieke tekens) is een goed begin, maar overwegen om dezelfde smoren regeling die je doet voor het login formulier zelf.

DEEL V: Het controleren van wachtwoord Sterkte

Ten eerste, wil je dit kleine artikel voor een reality check te lezen: De 500 meest voorkomende wachtwoorden

Oke, dus misschien is de lijst is niet de canonieke lijst van de meest voorkomende wachtwoorden op elk systeem waar ooit , maar het is een goede indicatie van hoe slecht de mensen zullen hun wachtwoorden kiezen wanneer er geen afgedwongen beleid op zijn plaats. Plus, de lijst ziet er angstaanjagend dicht bij huis als je het vergelijken met openbaar beschikbare analyses van recent gestolen wachtwoorden.

Dus: Met geen minimum wachtwoord sterkte-eisen, 2% van de gebruikers gebruik maken van een van de top 20 meest voorkomende wachtwoorden. Betekenis: als een aanvaller krijgt slechts 20 pogingen wordt 1 op de 50 accounts op uw website te kraken zijn.

Tegenwerken dit vereist het berekenen van de entropie van een wachtwoord en het toepassen van een drempel. Het National Institute of Standards and Technology (NIST) Special Publication 800-63 heeft een aantal zeer goede suggesties. Dat, in combinatie met een woordenboek en toetsenbord analyse (bijvoorbeeld 'qwertyuiop' een slecht wachtwoord), kan 99% van slecht gekozen wachtwoorden wijzen op een niveau van 18 bits entropie. Gewoon het berekenen wachtwoord kracht en het tonen van een visuele kracht meter om een gebruiker is goed, maar onvoldoende. Tenzij het wordt afgedwongen, zal veel gebruikers die het meest waarschijnlijk negeren.

En voor een verfrissende kijk op gebruiksvriendelijkheid van high-entropie wachtwoorden, Randall Munroe wachtwoord Sterkte xkcd wordt sterk aanbevolen.

DEEL VI: Much More - Of: Het voorkomen van Rapid-Fire Inloggen Pogingen

Ten eerste, neem een kijkje op de nummers: Password Recovery Snelheden - Hoe lang zal uw wachtwoord opstaan

Als u niet de tijd om te kijken door de tabellen in dat verband hebben, hier is de lijst van hen:

  1. Het kost vrijwel geen tijd om een zwak wachtwoord te kraken, zelfs als je het bent kraken met een telraam

  2. Het duurt vrijwel geen tijd om een alfanumeriek 9-karakter wachtwoord te kraken, als het hoofdlettergevoelig

  3. Het kost vrijwel geen tijd om een ingewikkelde, symbolen-and-letters-and-nummers, upper-en kleine letters wachtwoord te kraken, als het minder dan 8 tekens lang (een desktop PC kan de hele keyspace doorzoeken maximaal 7 tekens in een kwestie van dagen of zelfs uren)

  4. Het zou echter wel eens een buitensporige hoeveelheid tijd om zelfs een 6-karakter wachtwoord te kraken, als je beperkt waren tot één poging per seconde!

Dus wat kunnen we leren van deze nummers? Nou, veel, maar we kunnen richten op het belangrijkste onderdeel: het feit dat het voorkomen van grote aantallen snelvuur achtereenvolgende inlogpogingen (dat wil zeggen het. Brute force attack) is echt niet zo moeilijk. Maar voorkomen dat het juist is niet zo eenvoudig als het lijkt.

Over het algemeen heb je drie keuzes die alle effectief tegen brute-force aanvallen zijn (en dictionary-aanvallen, maar omdat je al gebruik van een sterke wachtwoorden beleid, moeten ze niet een probleem te zijn) :

  • Presenteer een CAPTCHA na N mislukte pogingen (vervelend als de hel en vaak inefficiënte - maar ik ben mezelf hier te herhalen)

  • Vergrendelen accounts en die e-mail verificatie na N mislukte pogingen (dit is een DoS -aanval staat te gebeuren)

  • En tot slot, login smoren : dat wil zeggen, het instellen van een tijdsvertraging tussen de pogingen na N mislukte pogingen (ja, DoS-aanvallen zijn nog steeds mogelijk, maar in ieder geval zijn ze veel minder waarschijnlijk en een stuk ingewikkelder te trekken).

Best practice # 1: Een korte tijd vertraging die toeneemt met het aantal mislukte pogingen, zoals:

  • 1 mislukte poging = geen vertraging
  • 2 mislukte pogingen = 2 sec delay
  • 3 mislukte pogingen = 4 sec vertraging
  • 4 mislukte pogingen = 8 sec vertraging
  • 5 mislukte pogingen = 16 sec delay
  • enz.

DoS aanvallen van deze regeling zou zeer onpraktisch zijn, aangezien de resulterende lockout tijd is iets groter dan de som van de vorige blokkeertijden.

Ter verduidelijking: De vertraging is niet een vertraging alvorens terug te keren de reactie op de browser. Het is meer als een time-out of refractaire periode waarin inloggen pogingen om een specifieke rekening of van een specifiek IP-adres zal niet worden geaccepteerd of helemaal niet geëvalueerd. Dat wil zeggen, zal de juiste referenties niet terugkeren in een succesvolle login, en onjuiste geloofsbrieven zal niet leiden tot een vertraging toename.

Best practice # 2: Een middellang tijdvertraging die ingaat na N mislukte pogingen, zoals:

  • 1-4 mislukte pogingen = geen vertraging
  • 5 mislukte pogingen = 15-30 min delay

DoS aanvallen van deze regeling zou heel onpraktisch, maar zeker uitvoerbaar zijn. Ook kan het van belang zijn om op te merken dat een dergelijke langdurige vertraging erg vervelend voor een legitieme gebruiker kan zijn. Vergeetachtig gebruikers zullen je een hekel.

Best practice # 3: De combinatie van de twee benaderingen - ofwel een vaste, korte tijd vertraging die ingaat na N mislukte pogingen, zoals:

  • 1-4 mislukte pogingen = geen vertraging
  • 5+ mislukte pogingen = 20 sec delay

Of, een toenemende vertraging met een vaste bovengrens, zoals:

  • 1 mislukte poging = vertraging van 5 sec
  • 2 mislukte pogingen = 15 sec delay
  • 3+ mislukte pogingen = 45 sec delay

Deze laatste regeling werd genomen uit de OWASP best-practices suggesties (link 1 van de must-read lijst), en moet worden beschouwd als de beste praktijken, ook al is het weliswaar aan de restrictieve kant.

Als vuistregel geldt echter, zou ik zeggen: hoe sterker je wachtwoord beleid is, hoe minder je hoeft te bug gebruikers met vertragingen. Als je sterk (hoofdlettergevoelig alphanumerics + benodigde cijfers en symbolen) 9+ karakter wachtwoorden vereisen, kan je de gebruikers geven 2-4 onvertraagde wachtwoord pogingen voordat het activeren van de smoren.

DoS aanvallen van deze laatste login smoren regeling zou zijn erg onpraktisch. En als een final touch, altijd toestaan persistent (cookie) logins (en / of een CAPTCHA-geverifieerde login formulier) te passeren, zodat legitieme gebruikers zullen niet eens worden uitgesteld terwijl de aanval aan de gang is . Op die manier, het zeer onpraktisch DoS-aanval wordt een uiterst onpraktisch aanval.

Daarnaast is het zinvol om meer agressieve throttling doen op admin accounts, want dat zijn de meest aantrekkelijke instappunten

DEEL VII: Distributed Brute force aanvallen

Net als een terzijde, zullen meer geavanceerde aanvallers proberen om login smoren omzeilen door 'het verspreiden van hun activiteiten':

  • Het verspreiden van de pogingen op een botnet om te voorkomen dat het IP-adres markeren

  • In plaats van het kiezen van een gebruiker en het proberen van de 50.000 meest voorkomende wachtwoorden (wat ze niet kunnen, vanwege onze smoren), zullen zij de meest voorkomende wachtwoord kiezen en probeer het tegen 50.000 gebruikers in plaats daarvan. Op die manier, niet alleen hebben zij rond maximum-pogingen maatregelen, zoals CAPTCHA's en login smoren, hun kans op succes neemt toe, omdat de nummer 1 meest voorkomende wachtwoord is veel waarschijnlijker dan nummer 49,995

  • Tussenruimte de login aanvragen voor elke gebruikersaccount, laten we zeggen, 30 seconden uit elkaar, te sluipen onder de radar

Hier, zou de beste praktijk te loggen het aantal mislukte logins, het hele systeem , en het gebruik van een lopend gemiddelde van bad-login frequentie van uw site als basis voor een bovengrens die u vervolgens op te leggen aan alle gebruikers.

Te abstract? Laat ik het anders:

Stel dat uw site is een gemiddelde van 120 slechte logins per dag had de afgelopen 3 maanden. Met behulp van die (voortschrijdend gemiddelde), kan het systeem de globale limiet ingesteld op 3 keer dat - ie. 360 mislukte pogingen gedurende 24 uur. Dan, als het totale aantal mislukte pogingen in alle accounts dat getal hoger is dan binnen een dag (of zelfs beter, het toezicht op de snelheid van de versnelling en trekker op een berekende drempel), activeert het hele systeem login smoren - dat wil zeggen korte vertragingen voor alle gebruikers (nog steeds, met uitzondering van de cookie-logins en / of back-up CAPTCHA logins).

Ik postte ook een vraag met meer details en een echt goede discussie over hoe om lastige pitfals voorkomen in het afweren van gedistribueerde brute force attacks

DEEL VIII: Two-Factor Authentication and Authentication Providers

Geloofsbrieven gevaar kan worden gebracht, hetzij door exploits, wachtwoorden opgeschreven en verloren, laptops met sleutels worden gestolen, of gebruikers die logins in phishing-sites. Aanmeldingen kan verder worden beschermd met dubbele authenticatie, die buiten de band factoren zoals eenmalige codes ontvangen van een telefoontje, sms, app of dongle. Verschillende providers bieden twee-factor authenticatie-diensten.

Verificatie kan volledig worden gedelegeerd aan een single-sign-on service, waar een andere provider verzorgt het verzamelen van referenties. Dit duwt het probleem aan een vertrouwde derde partij. Google en Twitter bieden beide standaarden gebaseerde SSO-services, terwijl Facebook biedt een vergelijkbare eigen oplossing.

Must-read LINKS over Web Authentication

  1. OWASP Guide To Authentication / OWASP Authentication Cheat Sheet
  2. Do's en Don'ts van Clientverificatie op het web (zeer leesbaar MIT research paper)
  3. Wikipedia: cookie
  4. Personal kennisvragen voor fallback authenticatie: Veiligheid vragen in het tijdperk van Facebook (zeer leesbaar Berkeley research paper)
antwoordde op 25/01/2009 om 12:27
bron van user

stemmen
146

Ten eerste, een sterke waarschuwing dat dit antwoord is niet de beste pasvorm voor de exacte deze vraag. Het zou zeker niet de top antwoord!

Ik zal doorgaan met vermelding van Mozilla's voorgesteld BrowserID (of misschien beter gezegd, de geverifieerde e-Protocol ) in de geest van het vinden van een upgrade naar een betere aanpak van authenticatie in de toekomst.

Ik doe het samen te vatten op deze manier:

  1. Mozilla is een non-profit met waarden die goed aansluiten bij het vinden van goede oplossingen voor dit probleem.
  2. De realiteit van vandaag is dat de meeste websites maken gebruik van vorm gebaseerde authenticatie
  3. -Vorm-gebaseerde authenticatie heeft een groot nadeel, dat is een verhoogd risico op phishing . Gebruikers worden gevraagd om gevoelige informatie in te voeren in een gebied gecontroleerd door een externe entiteit, in plaats van een gebied dat wordt bestuurd door de User Agent (browser).
  4. Aangezien browsers impliciet vertrouwen (het hele idee van een User Agent is om te handelen in naam van de gebruiker), kunnen ze helpen bij het verbeteren van deze situatie.
  5. De primaire kracht tegenhouden van vooruitgang hier is inzet impasse . Er moeten oplossingen worden ontleed in stappen die sommige incrementele voordeel op hun eigen te bieden.
  6. De eenvoudigste decentrale methode voor het uitdrukken van identiteit die in de internet-infrastructuur wordt gebouwd is de domeinnaam.
  7. Als een tweede niveau van het uitdrukken identiteit, elk domein beheert haar eigen set van de rekeningen.
  8. Het formulier “-account @domein” is beknopt en ondersteund door een groot aantal protocollen en URI's. Een dergelijke identificatie is, uiteraard, meest universeel erkend als een e-mailadres.
  9. E-mail providers zijn al de de-facto primaire identiteit providers online. Huidig ​​wachtwoord reset stromen meestal laat je de controle over een account als u kunt aantonen dat u bijbehorende e-mailadres van dat account te controleren.
  10. De geverifieerde e-Protocol werd voorgesteld om een ​​veilige methode te verschaffen, gebaseerd op public key cryptografie, voor het stroomlijnen van het proces van blijkt te zijn domein B dat u een account op het domein A.
  11. Voor browsers die niet ondersteunen de Verified Email Protocol (op dit moment allemaal), Mozilla biedt een shim die het protocol in client-side JavaScript-code implementeert.
  12. Voor e-mail diensten die geen ondersteuning voor de geverifieerde e-protocol, het protocol maakt derden op te treden als een betrouwbare tussenpersoon, beweren dat ze eigendom van een account van een gebruiker heeft geverifieerd. Het is niet wenselijk om een ​​groot aantal van deze derde partijen; Deze functie is echter alleen bedoeld om een ​​upgrade pad mogelijk te maken, en het is veel voorkeur dat e-mailservices deze beweringen zelf.
  13. Mozilla biedt hun eigen dienst te treden als zodanig een betrouwbare derde partij. Service Providers (dat wil zeggen, Vertrouwende Partijen) de uitvoering van het Verified Email protocol kan ervoor kiezen om Mozilla's beweringen of niet vertrouwt. Mozilla's dienst gebruikers verifieert eigendom van een account met behulp van de conventionele middelen van het verzenden van een e-mail met een bevestiging link.
  14. Service Providers kunnen natuurlijk, bieden dit protocol als een optie in aanvulling op een andere methode (s) van authenticatie ze zouden willen aanbieden.
  15. Een groot gebruikersinterface voordeel wordt hier aangevraagd, is het “identity selector”. Wanneer een gebruiker een site bezoekt en ervoor kiest om te verifiëren, hun browser toont ze een selectie van e-mailadressen ( “persoonlijke”, “werk”, “politiek activisme”, etc.) ze kunnen gebruiken om zich te identificeren op de site.
  16. Een ander groot gebruikersinterface uitkering wordt gezocht in het kader van deze inspanning is het helpen van de browser meer informatie over de sessie van de gebruiker te weten - wie ze zijn aangemeld als op dit moment, in de eerste plaats - dus het kan weergeven dat in de browser Chrome.
  17. Vanwege het gedistribueerde karakter van dit systeem is het lock-in vermijdt grote sites zoals Facebook, Twitter, Google, etc. Elk individu kan zelf hun eigen domein en daarom fungeren als hun eigen identiteit provider.

Dit is niet strikt “-vorm-gebaseerde authenticatie voor websites”. Maar het is een poging om de overgang van de huidige norm van vorm gebaseerde authenticatie om iets veiliger:-browser ondersteund authenticatie.

antwoordde op 08/08/2011 om 16:32
bron van user

stemmen
71

Ik denk niet dat het bovenstaande antwoord is "verkeerd", maar er zijn grote delen van authenticatie die niet worden aangeraakt (of liever de nadruk op "how to cookie-sessies uit te voeren", niet over "welke opties beschikbaar zijn en wat zijn de handel offs".

Mijn voorgestelde bewerkingen / antwoorden

  • Het probleem ligt meer in het instellen van een account dan in wachtwoordcontrole.
  • Het gebruik van twee factor authenitication is veel veiliger dan slimmer middel van wachtwoordencryptie
  • Probeer niet om de uitvoering van uw eigen login formulier of database opslaan van wachtwoorden, tenzij de gegevens worden opgeslagen is waardeloos op aanmaken van een account en zelf opgewekte (dat wil zeggen, web 2.0 stijl, zoals Facebook, Flickr , enz.)

    1. Digest Authentication is een op standaarden gebaseerde aanpak gesteund in alle belangrijke browsers en servers, die geen wachtwoord stuurt zelfs via een beveiligd kanaal.

Dit vermijdt elke noodzaak om "sessies" of cookies als de browser zelf zal opnieuw versleutelen de communicatie elke keer te hebben. Het is de meest "lichtgewicht" benadering van de ontwikkeling.

Maar ik dit niet aanraden, met uitzondering van openbare, lage waarde diensten. Dit is een probleem met sommige van de andere antwoorden hierboven - probeer niet een re-implementeren van server-side authetication mechanismen - dit probleem is opgelost en wordt ondersteund door de meeste grote browsers. Gebruiken geen cookies. Laat niets in uw eigen handgerolde database op te slaan. Vraag het maar aan, per verzoek, indien het verzoek wordt autheticated. Al het andere moet worden ondersteund door de configuratie en third-party vertrouwde software.

So ...

Ten eerste zijn we verwarren de initiële creatie van een account (met een wachtwoord) met de re-controle van het wachtwoord later. Als ik Flickr en het creëren van uw site voor de eerste keer, de nieuwe gebruiker toegang heeft tot de waarde nul (blanco webruimte). Ik heb echt niet schelen als de persoon die het account is liegen over hun naam. Als ik ben het creëren van een rekening van het ziekenhuis intranet / extranet, de waarde ligt in alle medische dossiers, en dus ik heb de zorg over de identiteit (*) van de maker van het account.

Dit is het heel erg hard deel. De enige fatsoenlijke oplossing is een web van vertrouwen. Zo wordt u lid van het ziekenhuis als arts. U maakt een webpagina ergens gehost met uw foto, uw paspoortnummer en een publieke sleutel, en hash ze allemaal met de private sleutel. U bezoekt vervolgens het ziekenhuis en de systeembeheerder kijkt naar uw paspoort, ziet als de foto overeenkomt met u, en vervolgens hashes de webpagina / foto hash met het ziekenhuis private sleutel. Vanaf nu kunnen we veilig sleutels en tokens te wisselen. Zoals iedereen die het ziekenhuis vertrouwt (er is de geheime saus BTW). De systeembeheerder kan u ook een RSA dongle of andere twee-factor authenticatie.

Maar dit is een heel gedoe, en niet erg web 2.0. Echter, het is de enige veilige manier om nieuwe accounts die toegang tot waardevolle informatie die niet zelf gecreëerd hebben te maken.

  1. Kerberos en SPNEGO - single sign on mechanismen met een vertrouwde derde partij - in principe de gebruiker verifieert tegen een vertrouwde derde partij. (NB dit is op geen enkele wijze het niet te vertrouwen OAuth )

  2. SRP - soort van slimme wachtwoordauthenticatie zonder een trusted third party. Maar hier krijgen we in het rijk van "het is veiliger om twee-factor authenticatie gebruiken, zelfs als dat duurder"

  3. SSL client side - geven de klanten een publieke sleutel certificaat (ondersteuning in alle belangrijke browsers - maar roept vragen op client security).

Op het einde is het een afweging - wat is de kostprijs van een inbreuk op de beveiliging versus de kosten van de uitvoering beter te beveiligen benaderingen. Op een dag, kunnen we zien een goede PKI algemeen aanvaard en dus geen eigen gerold authenticatie-formulieren en databases. Op een dag...

antwoordde op 08/08/2011 om 17:29
bron van user

stemmen
48

Toen hashing, geen gebruik maken van snelle hash algoritmen, zoals MD5 (veel hardware implementaties bestaan). Gebruik iets als SHA-512. Voor wachtwoorden, langzamer hashes zijn beter.

Hoe sneller je kunt hashes te creëren, kan het sneller enige brute kracht checker werken. Langzamer hashes zal dus vertragen brute dwingen. Een langzame hash algoritme zal brute maken dwingen onpraktisch voor langere wachtwoorden (8 cijfers +)

antwoordde op 09/08/2011 om 00:07
bron van user

stemmen
120

Ik dacht dat ik zou deze oplossing die ik heb gevonden om samen te werken prima te delen.

Ik noem het de Dummy Field (hoewel ik dit niet hebben uitgevonden dus vraag me niet krediet).

In het kort: je moet alleen maar om dit in te voegen in <form>en controleer of het aan leeg bij het valideren van zijn:

<input type="text" name="email" style="display:none" />

De truc is om een bot te laten denken dat het heeft om gegevens in te voegen in een verplicht veld, dat is waarom ik de ingang "e-mail" genoemd. Als u al een veld met de naam e-mail die u gebruikt moet je proberen het benoemen van de dummy-veld iets anders als "bedrijf", "telefoon" of "e-mailadres". Kies gewoon iets wat je weet dat je niet nodig hebt en wat klinkt als iets wat mensen normaal zou vinden logisch om in te vullen in een webformulier. Nu verbergt het inputveld met behulp van CSS en JavaScript / jQuery - wat het beste past bij je - gewoon niet zet de ingang typeaan hiddenof anders de bot zal niet vallen voor het.

Wanneer u het valideren van het formulier (client of server side) controleren of uw dummy veld is ingevuld om te bepalen of het was te sturen door een mens of een bot.

Voorbeeld:

In het geval van een mens: De gebruiker zal niet de dummy-veld (in mijn geval de naam "e-mail") en zal niet proberen om het te vullen. Dus de waarde van de dummy veld moet nog steeds leeg zijn wanneer het formulier is verstuurd.

In het geval van een bot: De bot zal een veld waarvan het type is te zien texten een naam email(of wat het ook is dat je het heet) en zal logischerwijs proberen om het te vullen met de juiste gegevens. Het maakt niet uit of je het invulformulier gestyled met een aantal mooie CSS, web-ontwikkelaars doen het de hele tijd. Wat de waarde in het dummy-veld is, weten we niet zo lang als het is groter dan de zorg 0karakters.

Ik gebruikte deze methode op een gastenboek in combinatie met CAPTCHA , en ik heb sindsdien niet meer gezien een enkele spam-bericht. Ik had een CAPTCHA-enige oplossing eerder gebruikt, maar uiteindelijk resulteerde in ongeveer vijf spam berichten per uur. Het toevoegen van de dummy-veld in het formulier is gestopt (althans tot nu toe) van alle spam wordt weergegeven.

Ik denk dat dit kan ook prima gebruikt worden met een login / authenticatie vorm.

Waarschuwing : Natuurlijk is deze methode niet 100% waterdicht zijn. Bots kunnen worden geprogrammeerd om invoervelden met de stijl negeren display:nonetoegepast. Je hebt ook te denken over mensen die een vorm van automatische aanvulling gebruiken (zoals de meeste browsers hebben een ingebouwde!) Om automatisch te vullen alle formuliervelden voor hen. Ze kunnen net zo goed pick-up een dummy-veld.

U kunt dit ook variëren een beetje bij het verlaten van het dummy-veld zichtbaar, maar buiten de grenzen van het scherm, maar dit is helemaal aan jou.

Wees creatief!

antwoordde op 22/05/2012 om 13:11
bron van user

stemmen
46

Een goed artikel over realistische wachtwoord sterkte schatting:

Dropbox Tech Blog »Blog Archive» zxcvbn: realistische wachtwoordsterkte schatting

antwoordde op 08/11/2012 om 12:15
bron van user

stemmen
41

Mijn favoriete regel met betrekking tot systemen authenticatie: gebruik wachtwoorden, wachtwoorden. Makkelijk te onthouden, moeilijk te kraken. Meer info: Coding Horror: Wachtwoorden vs. wachtzinnen

antwoordde op 24/11/2012 om 22:15
bron van user

stemmen
10

Ik zou graag een zeer belangrijke reactie toe te voegen:

  • "In een zakelijke, intra- net setting," de meeste, zo niet alle van de voorgaande mogelijk niet van toepassing!

Veel bedrijven zetten "intern gebruik" websites die, effectief, "corporate applicaties" die toevallig te zijn uitgevoerd door middel van URL's. Deze URL's kunnen (zogenaamd ...) alleen worden opgelost binnen "het bedrijf het interne netwerk." (Dat netwerk omvat op magische wijze alle VPN-connected 'road warriors.')

Wanneer een gebruiker plichtsgetrouw verbonden met dit netwerk, hun identiteit ( "authentificatie") is [reeds ...] "definitief bekend," zoals toestemming ( "vergunning") om bepaalde dingen ... zoals doen. .. "om toegang te krijgen tot deze website."

Deze "authenticatie + autorisatie" service kan worden geleverd door verschillende technologieën, zoals LDAP (Microsoft OpenDirectory) , of Kerberos.

Vanuit uw point-of-view, je gewoon weet dat dit: dat iedereen die rechtmatig wind-up op uw website moet . "Token" vergezeld gaan van [een milieu-variabele magische bevattende ...] een ( Dwz Het ontbreken van een dergelijk token moet onmiddellijk redenen 404 Not Found.)

De waarde van de token heeft geen zin om u, maar, mocht dat nodig zijn, "passende middelen bestaan", waaraan uw web-site kan "[gezag] vraag dan iemand die weet (LDAP ... enz.)" Over elke en elke ( !) vraag die je kan hebben. Met andere woorden, hoeft u niet zelf maken van elke "home-grown logica." In plaats daarvan, u informeren van de Autoriteit en volledig vertrouwen de uitspraak.

Uh huh ... het is nogal een mentale-switch van het "wild-en-wollig Internet."

antwoordde op 29/04/2015 om 01:06
bron van user

stemmen
20

Ik wil graag een suggestie die ik heb gebruikt toevoegen, op basis van de verdediging in de diepte. U hoeft niet naar dezelfde authenticatie en authenticatie systeem voor de admins als reguliere gebruikers. U kunt een aparte login formulier op een aparte url uitvoeren aparte code voor verzoeken die hoge privileges toe te kennen te hebben. Dit kan men keuzes die een totale pijn aan regelmatige gebruikers zou zijn te maken. Een van die die ik heb gebruikt is om daadwerkelijk scramble de login-URL voor toegang admin en e-mail de beheerder de nieuwe URL. Stopt elke brute force attack meteen als uw nieuwe URL willekeurig moeilijk (zeer lange willekeurige reeks) kunnen zijn, maar enige ongemak je admin gebruiker wordt naar aanleiding van een link in hun e-mail. De aanvaller weet niet meer waar te zelfs post aan.

antwoordde op 18/07/2015 om 01:18
bron van user

stemmen
12

Ik dont't weten of het het beste was om deze vraag te beantwoorden als een antwoord of een reactie. Ik koos voor de eerste optie.

Ten aanzien van de Poing DEEL IV: Wachtwoord vergeten Functionaliteit in het eerste antwoord, zou ik een punt over Timing Attacks te maken.

In de Onthoud uw wachtwoord vormen, kan een aanvaller mogelijk een controle op een volledige lijst van e-mails en op te sporen die zijn geregistreerd in het systeem (zie onderstaande link).

Ten aanzien van de Vergeten wachtwoord formulier, zou ik willen toevoegen dat het een goed idee om tijden tussen succesvolle en unsucessful queries gelijk met enige vertraging functie.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

antwoordde op 16/08/2015 om 17:31
bron van user

stemmen
5

Gebruik OpenID Connect of -gebruiker beheerde Access .

Als niets is efficiënter dan het helemaal niet te doen.

antwoordde op 10/08/2016 om 13:27
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more