Den definitive guiden til skjemabasert nettsted autentisering

stemmer
5k

Skjemabasert autentisering for nettsteder

Vi tror at Stack Overflow bør ikke bare være en ressurs for svært spesifikke tekniske spørsmål, men også for generelle retningslinjer for hvordan å løse variasjoner på vanlige problemer. Skjema basert autentisering for nettsteder skal være en fin tema for et slikt eksperiment.

Den bør inneholde emner som:

  • Hvordan logge inn
  • Hvordan logge ut
  • Hvordan forbli pålogget
  • Håndtere informasjonskapsler (inkludert anbefalte innstillinger)
  • SSL / HTTPS-kryptering
  • Hvordan du lagre passord
  • Ved hjelp av hemmelige spørsmål
  • Glemt brukernavn / passord funksjonalitet
  • Bruk av nonces å hindre forespørsler mellom forfalskninger (CSRF)
  • OpenID
  • Husk meg boksen
  • Browser autofullføring av brukernavn og passord
  • Secret URLer (offentlig URL beskyttet av digest)
  • Sjekker passord styrke
  • E-post validering
  • og mye mer om skjemabasert autentisering ...

Det bør ikke inkludere ting som:

  • Roller og autorisasjon
  • HTTP enkel godkjenning

Hjelp oss ved å:

  1. tyder delemner
  2. Sende gode artikler om dette emnet
  3. Redigere offisielt svar
Publisert på 02/08/2008 klokken 19:51
kilden bruker
På andre språk...                            


12 svar

stemmer
3k

DEL I: Hvordan logge inn

Vi vil anta at du allerede vet hvordan å bygge en innlogging + passord HTML-skjema hvilke innlegg verdiene til et skript på serversiden for godkjenning. Avsnittene nedenfor vil håndtere mønstre for lyd praktisk auth, og hvordan du kan unngå de vanligste sikkerhetsfallgruver.

Til HTTPS eller ikke HTTPS?

Med mindre tilkoblingen er allerede sikker (som er tunell gjennom HTTPS med SSL / TLS), vil påloggings form verdier sendes i klartekst, som lar hvem som helst tyvlytting på linjen mellom nettleser og webserver vil være i stand til å lese pålogginger som de passerer gjennom. Denne typen telefonavlytting gjøres rutinemessig av regjeringer, men generelt vil vi ikke ta 'eies' andre ledninger enn å si dette: Hvis du beskytter noe viktig, bruker HTTPS.

Kort sagt, er den eneste praktiske til måte beskytte mot avlytting / pakkekontroll under innlogging er ved hjelp av HTTPS eller annet sertifikat-baserte krypteringsordning (for eksempel TLS ) eller en utprøvd og testet challenge-response skjema (for eksempel det Diffie-Hellman -basert SRP). Enhver annen metode kan lett omgås av en avlytting angriper.

Selvfølgelig, hvis du er villig til å få litt upraktisk, du kan også bruke noen form for to-faktor autentisering ordningen (for eksempel Google Authenticator app, en fysisk 'kald krig-stil' kodebok, eller en RSA nøkkel generator dongle). Hvis brukt riktig, kan dette fungere selv med en usikret tilkobling, men det er vanskelig å forestille seg at en dev ville være villig til å gjennomføre to-faktor autentisering, men ikke SSL.

(Ikke) Roll-din-egen Javascript-kryptering / hashing

Gitt den ikke-null kostnader og oppfattes tekniske problemer med å sette opp et SSL-sertifikat på nettstedet ditt, er noen utviklere fristet til å rulle sine egne i nettleseren hashing eller kryptering ordninger for å unngå passerer klartekst innlogginger over en usikret wire.

Selv om dette er en edel tanke, er det essensielt ubrukelig (og kan være et sikkerhetshull ) med mindre den er kombinert med en av de ovennevnte - det vil si, enten festing av ledningen sammen med sterk kryptering eller ved hjelp av en utprøvd og testet challenge-response mekanisme (hvis du ikke vet hva det er, bare vet at det er en av de vanskeligste å bevise, mest vanskelig å utforme, og mest vanskelig å implementere begreper i digital sikkerhet).

Mens det er sant at hashing passord kan være effektiv mot passord avsløring , er den sårbar for å spille angrep, man-in-the-middle angrep / flykapringer (hvis en angriper kan injisere noen bytes inn i usikret HTML-side før den når nettleser, kan de bare kommentere ut hashing i Javascript), eller brute-force angrep (siden du overlate den angriper både brukernavn, salt og hashet passord).

CAPTCHA mot menneskeheten

CAPTCHA er ment å hindre en bestemt kategori av angrep: automatisert ordbok / brute force prøving og feiling uten menneskelig operatør. Det er ingen tvil om at dette er en reell trussel, men det finnes måter å håndtere det sømløst som ikke krever en CAPTCHA, spesielt riktig utformet Server innlogging strupe ordninger - vi vil diskutere de senere.

Vet at CAPTCHA implementeringer er ikke skapt like, de ofte ikke er menneske-løsbar, de fleste av dem er faktisk ineffektive mot bots, alle av dem er ineffektive mot billig tredje verden arbeidskraft (i henhold til OWASP , er den nåværende sweat sats $ 12 per 500 tester), og noen implementeringer kan være teknisk ulovlig i enkelte land (se OWASP Authentication Cheat Sheet ). Hvis du må bruke en CAPTCHA, bruke Googles reCAPTCHA , siden det er OCR-hard per definisjon (siden det allerede bruker OCR-misclassified bok skanner) og prøver veldig hardt å være brukervennlig.

Personlig pleier jeg å finne captchas irriterende, og bare benyttes som en siste utvei når en bruker har unnlatt å logge inn flere ganger og strupe forsinkelser er maxxed ut. Dette vil skje sjelden nok til å være akseptabelt, og det styrker systemet som helhet.

Lagring av passord / verifisering innlogginger

Dette kan til slutt være felles kunnskap etter at alle de svært omtalte hacks og brukerdatalekkasjer vi har sett de siste årene, men det må sies: Ikke lagre passord i klartekst i databasen. Brukerdatabaser blir rutinemessig hacket, lekket eller sanket gjennom SQL-injeksjon, og hvis du lagrer rå, klartekst passord, er at instant game over for påloggings sikkerhet.

Så hvis du ikke kan lagre passordet, Hvordan sjekker du at innlogging + passord kombinasjon postet fra innloggingsskjemaet er riktig? Svaret er hashing ved hjelp av en nøkkel avledning funksjon . Når en ny bruker opprettes eller et passord er endret, ta deg passordet og kjøre det gjennom en KDF som Argon2, bcrypt, scrypt eller PBKDF2, snu klartekst passord ( "correcthorsebatterystaple") inn i en lang, tilfeldig utseende streng , som er mye tryggere å lagre i databasen. For å bekrefte en pålogging, kan du kjøre den samme hash-funksjonen på det angitte passordet, denne gangen bestått i salt og sammenligne den resulterende hash strengen til i din database verdi. Argon2, bcrypt og scrypt butikk saltet med hash allerede. Sjekk ut denne artikkelen på sec.stackexchange for mer detaljert informasjon.

Grunnen til et salt blir brukt er fordi hashing i seg selv er ikke nok - vil du ønsker å legge til et såkalt 'salt' for å beskytte hash mot regnbuen . Et salt forhindrer effektivt to passord som nøyaktig tilsvarer fra å bli lagret som den samme hash-verdi som forhindrer at hele databasen som skannes i en sikt hvis en angriper utfører en passordgjetting angrep.

En kryptografisk hash bør ikke brukes til lagring av passord fordi bruker valgt passord er ikke sterk nok (dvs. vanligvis ikke inneholder nok entropi) og et passord gjette angrep kan være ferdig i løpet av relativt kort tid av en angriper med tilgang til hashes. Det er derfor en KDF brukes - disse effektivt "strekke nøkkel" som betyr at alle passord gjette en angriper gjør innebærer itera de hashing algoritmen flere ganger, for eksempel 10.000 ganger, slik at angriperens passordgjetting 10.000 ganger tregere.

Sesjonsdata - "Du er logget inn som Spiderman69"

Når serveren har verifisert brukernavn og passord mot brukerdatabasen og fant en kamp, ​​må systemet en måte å huske at nettleseren har blitt godkjent. Dette faktum bør bare noen gang bli lagret tjenersiden i sesjonsdata.

Hvis du er ukjent med sesjonsdata, her er hvordan det fungerer: En enkelt tilfeldig generert strengen er lagret i en utløper cookie og brukes til å referere til en samling av data - økten data - som er lagret på serveren. Hvis du bruker en MVC rammeverk, er dette utvilsomt håndtert allerede.

Hvis det overhodet er mulig, sørge for at øktinformasjonskapsel har sikre og HTTP Kun flagg satt når de sendes til nettleseren. Den kun http flagget gir en viss beskyttelse mot cookie blir lest av en XSS-angrep. Den sikre flagget sikrer at kapselen blir bare sendt tilbake via HTTPS, og dermed beskytter mot nettverks sniffing angrep. Verdien av cookie bør ikke være forutsigbar. Når en cookie som refererer til en ikke-eksisterende sesjon er presentert, skal verdien erstattes umiddelbart for å hindre sesjon fiksering .

DEL II: Hvordan forbli logget inn - The Infamous "Husk meg" boksen

Vedvarende Logg Cookies ( "husk meg" funksjonalitet) er et faresonen; på den ene siden, de er helt like sikker som vanlige pålogginger når brukere forstår hvordan man skal håndtere dem, og på den annen side, er de en enorm sikkerhetsrisiko i hendene på skjødesløse brukere, som kan bruke dem på offentlige datamaskiner og glemmer å logge ut, og som kanskje ikke vet hvilken nettleser cookies er eller hvordan du sletter dem.

Personlig liker jeg vedvarende pålogginger for de nettstedene jeg besøker med jevne mellomrom, men jeg vet hvordan man skal håndtere dem trygt. Hvis du er positivt at brukerne vet det samme, kan du bruke vedvarende pålogginger med en ren samvittighet. Hvis ikke - vel, så du kan abonnere på filosofien at brukere som er uforsiktig med sine påloggingsinformasjon brakte det på seg hvis de blir hacket. Det er ikke som vi går til vår brukerens hus og rive av alle de facepalm-induserende Post-it lapper med passord de har stilt opp på kanten av sine skjermer, heller.

Selvfølgelig kan noen systemer ikke råd til å ha noen kontoer hacket; for slike systemer, er det ingen måte du kan rettferdiggjøre å ha vedvarende innlogginger.

Hvis du bestemmer deg for å gjennomføre vedvarende logg cookies, dette er hvordan du gjør det:

  1. Først, ta litt tid til å lese Paragon Initiative artikkel om emnet. Du trenger å få en haug med elementer riktige, og artikkelen gjør en god jobb med å forklare hver.

  2. Og bare for å gjenta en av de vanligste fallgruvene, Ikke oppbevar vedvarende LOGG INN (symbol) i database, bare en hash av det! Innloggings token er Password tilsvarende, så hvis en angriper fikk kloa i databasen, kan de bruke symboler for å logge på en konto, akkurat som om de var klartekst login-passord kombinasjoner. Derfor bruker hashing (i henhold til https://security.stackexchange.com/a/63438/5002 en svak hash vil gjøre det bra for dette formål) ved lagring vedvarende innloggings symboler.

DEL III: Bruk av Secret Spørsmål

Ikke implementere 'hemmelige spørsmål' . Den 'hemmelige spørsmål' funksjonen er en sikkerhets anti-mønster. Les artikkelen fra linken nummer fire fra må-lese-listen. Du kan spørre Sarah Palin om at etter hennes Yahoo! e-postkonto ble hacket i løpet av en tidligere presidentkampanje fordi svaret på hennes sikkerhet spørsmålet var ... "Wasilla High School"!

Selv med brukerdefinerte spørsmål, er det svært sannsynlig at de fleste brukere vil velge enten:

  • En 'standard' hemmelige spørsmål som mors pikenavn eller favoritt kjæledyr

  • Et enkelt stykke trivia som noen kunne løfte fra sin blogg, Linkedin-profil, eller lignende

  • Eventuelle spørsmål som er lettere å svare på enn å gjette passordet sitt. Som for enhver anstendig passord, er alle spørsmål du kan tenke deg

I konklusjonen, sikkerhetsspørsmål er iboende usikre på nesten alle sine former og varianter, og bør ikke være ansatt i en autentiseringsordning eller annen grunn.

Den egentlige årsaken til at sikkerhetsspørsmål engang eksisterer i naturen er at de praktisk spare kostnadene av noen få støttesamtaler fra brukere som ikke har tilgang til e-posten sin for å få til en reaktive kode. Dette på bekostning av sikkerhet og Sarah Palin omdømme. Verdt det? Sannsynligvis ikke.

DEL IV: Glemt passord Funksjonalitet

Jeg har allerede nevnt at du bør aldri bruke sikkerhetsspørsmål for håndtering av glemte / tapte brukerpassord; det også går uten å si at du aldri skal sende en e-postbrukere deres faktiske passord. Det er minst to mer altfor vanlige fallgruvene å unngå i dette feltet:

  1. Ikke tilbakestille et glemt passord til en autogenerert sterkt passord - slike passord er notorisk vanskelig å huske, noe som betyr at brukeren må endre det eller skrive det ned - si, på en lys gul post-it på kanten av skjermen sin. I stedet for å sette et nytt passord, bare la brukerne velge en ny en med en gang - som er hva de ønsker å gjøre uansett. (Et unntak kan være hvis brukerne er universelt ved hjelp av et passord manager for å lagre / administrere passord som normalt ville være umulig å huske uten å skrive det ned).

  2. Alltid hash den tapte passord kode / token i databasen. IGJEN , er denne koden et annet eksempel på et passord Equivalent, så det må være hashed i tilfelle en angriper fikk kloa i databasen. Når en tapt passord kode er forespurt, sender klartekst kode til brukerens e-postadresse, så hasj det, lagre hash i databasen - og kaste bort den opprinnelige . Akkurat som et passord eller en vedvarende innlogging token.

Et siste notat: alltid sørge for at grensesnittet for å legge inn den 'tapte passord kode' er minst like sikker som innloggingsskjemaet selv, eller en angriper vil bare bruke dette for å få tilgang stedet. Sørge for at du generere svært lang 'tapt passord koder' (for eksempel 16 store og små bokstaver alfanumeriske tegn) er en god start, men vurdere å legge den samme strupe ordningen som du gjør for login form selv.

DEL V: Kontroll Passordstyrke

Først vil du ønsker å lese denne lille artikkelen for en reality check: De 500 mest vanlige passord

Ok, så kanskje listen er ikke den kanoniske listen over mest vanlige passord på ethvert system hvor som helst noensinne , men det er en god indikasjon på hvor dårlig folk vil velge sine passord når det ikke er håndhevet policy på plass. Plus, listen ser skremmende nær hjemmet når du sammenligner det å offentlig tilgjengelige analyser av nylig stjålne passord.

Så: Med ingen minimums passord styrkekravene, 2% av brukerne bruker en av de beste 20 mest vanlige passord. Betydning: hvis en angriper får bare 20 forsøk, vil en i 50 kontoer på nettstedet ditt være crackable.

Ødela dette krever beregning av entropien et passord og deretter bruke en terskel. The National Institute of Standards and Technology (NIST) Special Publication 800-63 har et sett med veldig gode forslag. Som i kombinasjon med en ordbok og tastaturoppsett Analyse (for eksempel 'QWERTYUIOP' er en dårlig passord), kan forkaste 99% av alle dårlig valgte passord ved et nivå på 18 biter av entropi. Bare beregning passord styrke og viser en visuell styrkemåleren til en bruker er bra, men ikke nok. Med mindre det håndheves, vil mange brukere mest sannsynlig ignorere det.

Og for en forfriskende vri på brukervennlighet av høy entropi passord, Randall Munroe sin Passordstyrke XKCD er sterkt anbefalt.

DEL VI: Mye mer - Eller: Forebygging av Rapid-Fire påloggingsforsøk

Først ta en titt på tallene: Passord Recovery hastigheter - Hvor lenge vil passordet stå opp

Hvis du ikke har tid til å se gjennom tabellene i denne linken, her er listen over dem:

  1. Det tar nesten ingen tid å knekke et svakt passord, selv om du sprekker det med en kuleramme

  2. Det tar nesten ingen tid å knekke et alfanumerisk 9-tegns passord, hvis det er små bokstaver

  3. Det tar nesten ingen tid å knekke en intrikat, symboler-og-brev-og-tall, øvre-and-små bokstaver passord, hvis det er mindre enn 8 tegn (en stasjonær PC kan søke i hele KEYSPACE opp til 7 tegn i en løpet av noen dager eller timer)

  4. Det vil imidlertid ta uforholdsmessig lang tid å knekke enda en 6-tegns passord, hvis du var begrenset til ett forsøk per sekund!

Så hva kan vi lære av disse tallene? Vel, mange, men vi kan fokusere på den viktigste delen: det faktum at å forebygge et stort antall raske brann påfølgende påloggingsforsøk (dvs. Brute force angrep) er egentlig ikke så vanskelig. Men hindrer det riktig er ikke så lett som det virker.

Generelt sett, har du tre valg som er alle effektive mot brute-force angrep (og ordbok angrep, men siden du allerede ansette en sterk passord politikk, bør de ikke være et problem) :

  • Presentere en CAPTCHA etter N mislykkede forsøk (irriterende som faen, og ofte ineffektive - men jeg gjentar meg selv her)

  • Låsing kontoer og krever e-postbekreftelse etter N mislykkede forsøk (dette er et DoS angrep venter på å skje)

  • Og til slutt, innlogging struping : det vil si å sette en tidsforsinkelse mellom forsøk etter N mislykkede forsøk (ja, DoS angrep er fortsatt mulig, men minst de er langt mindre sannsynlig, og mye mer komplisert å trekke av).

Beste praksis # 1: En kort tidsforsinkelse som øker med antallet mislykkede forsøk, som:

  • En mislykket forsøk = ingen forsinkelse
  • 2 mislykkede forsøk = 2 sek forsinkelse
  • 3 forsøk = 4 sek forsinkelse
  • 4 mislykkede forsøk = 8 sek forsinkelse
  • 5 mislykkede forsøk = 16 sek forsinkelse
  • etc.

DoS angrep denne ordningen ville være svært upraktisk, siden den resulterende lockout tid er litt større enn summen av de tidligere lockout ganger.

For å klargjøre: Forsinkelsen er ikke en forsinkelse før retur responsen til nettleseren. Det er mer som en timeout eller ildfast perioden som innloggingsforsøk til en bestemt konto eller fra en bestemt IP-adresse vil ikke bli akseptert eller vurdert i det hele tatt. Det vil si, riktige legitimasjon vil ikke gå tilbake på en vellykket pålogging, og feil legitimasjon vil ikke utløse en forsinkelse økning.

Beste praksis # 2: En middels lang tidsforsinkelse som trer i kraft etter at N mislykkede forsøk, som:

  • 1-4 mislykkede forsøk = ingen forsinkelse
  • 5 mislykkede forsøk = 15-30 min forsinkelse

DoS angrep denne ordningen ville være ganske upraktisk, men absolutt gjennomførbart. Dessuten kan det være relevant å merke seg at en så lang forsinkelse kan være veldig irriterende for en legitim bruker. Glemsom brukere vil mislike deg.

Beste praksis # 3: Ved å kombinere de to tilnærminger - enten en fast, kort tidsforsinkelse som trer i kraft etter at N mislykkede forsøk, som:

  • 1-4 mislykkede forsøk = ingen forsinkelse
  • 5+ mislykkede forsøk = 20 sek forsinkelse

Eller, en økende forsinkelse med en fast øvre grense, som:

  • En mislykket forsøk = 5 sek forsinkelse
  • 2 mislykkede forsøk = 15 sek forsinkelse
  • 3+ mislykkede forsøk = 45 sek forsinkelse

Denne endelige ordningen ble tatt fra OWASP best-practices forslag (koblingen en fra må-lese-listen), og bør vurderes beste praksis, selv om det er riktignok på den restriktive side.

Som en tommelfingerregel derimot, ville jeg si: jo sterkere ditt passord policy er, jo mindre du har å feil brukere med forsinkelser. Hvis du trenger sterke (case-sensitive alfanumeriske tegn + nødvendige tall og symboler) 9 + tegnet passord, kan du gi brukerne 2-4 uten forsinkelse passordforsøk før du aktiverer struping.

DoS angrep denne siste innlogging struping ordningen ville være svært upraktisk. Og som en siste touch, alltid gi vedvarende (cookie) innlogginger (og / eller en CAPTCHA-verifisert login form) til å passere gjennom, så legitime brukere vil ikke engang bli forsinket mens angrepet pågår . På den måten blir det veldig upraktisk DoS angrep en svært upraktisk angrep.

I tillegg er det fornuftig å gjøre mer aggressive struping på admin kontoer, siden de er de mest attraktive inngangspunkter

DEL VII: Distributed brute force angrep

Akkurat som en side, vil mer avanserte angripere prøver å omgå innlogging struping av 'spre sine aktiviteter':

  • Distribuere forsøk på et botnet for å hindre IP-adresse flagging

  • Snarere enn å plukke en bruker og prøver de 50.000 mest vanlige passord (som de ikke kan, på grunn av vår struping), vil de velge den mest vanlige passord og prøve det mot 50.000 brukere i stedet. På den måten, ikke bare gjøre de får rundt maks-forsøk tiltak som CAPTCHA og innlogging struping, sjansen for suksess øker også, siden nummer 1 vanligste passord er langt mer sannsynlig enn nummer 49,995

  • Avstand påloggingsforespørsler for hver brukerkonto, sier 30 sekunder fra hverandre, å snike seg under radaren

Her ville det beste praksis skal logge antallet mislykkede pålogginger, hele systemet , og bruke et løpende gjennomsnitt av nettstedets bad-login frekvens som grunnlag for en øvre grense som du deretter pålegge alle brukere.

For abstrakt? La meg omformulere:

Si nettstedet har hatt et gjennomsnitt på 120 dårlige innlogginger per dag i løpet av de siste 3 månedene. Med bruk av denne (løpende gjennomsnitt), kan systemet sette den globale grensen til 3 ganger - det vil si. 360 mislykkede forsøk over en 24 timers periode. Da, hvis det totale antallet mislykkede forsøk på tvers av alle regnskap overstiger dette tallet innen en dag (eller enda bedre, overvåke frekvensen av akselerasjon og utløser på en beregnet terskel), aktiverer den systemomfattende login struping - noe som betyr korte forsinkelser for alle brukere (fortsatt, med unntak av kapselen logikk og / eller sikkerhets CAPTCHA innlogginger).

Jeg har også postet et spørsmål med flere detaljer og en virkelig god diskusjon om hvordan man skal unngå vanskelige pitfals i hamlet opp distribuerte brute force angrep

DEL VIII: To-faktor autentisering og autentisering Providers

Legitimasjon kan bli svekket, enten ved utnytter, passord blir skrevet ned og tapt, bærbare datamaskiner med nøkler blir stjålet, eller brukere legge inn innlogginger til phishing-nettsteder. Innlogginger kan beskyttes ytterligere med to-faktor autentisering, som bruker out-of-band faktorer som engangskoder som mottas fra en telefonsamtale, SMS-melding, en app eller dongelen. Flere leverandører tilbyr to-faktor autentiseringstjenester.

Autentisering kan være helt delegert til en single-sign-on-tjenesten, hvor en annen leverandør håndterer samle legitimasjon. Dette skyver problemet til en betrodd tredjepart. Google og Twitter begge gir standardbaserte SSO tjenester, mens Facebook gir en lignende proprietær løsning.

Må leses linker om Web Authentication

  1. OWASP Guide til autentisering / OWASP autentisering Cheat Sheet
  2. Dos and don'ts av klientgodkjenning på nettet (veldig lesbar MIT forskning papir)
  3. Wikipedia: HTTP cookie
  4. Personlige kunnskapsspørsmål for fallback-godkjenning: Sikkerhet spørsmål i æra av Facebook (veldig lesbar Berkeley forskning papir)
Svarte 25/01/2009 kl. 11:27
kilden bruker

stemmer
390

definitive Artikkel

sende legitimasjon

Den eneste praktiske måten å sende legitimasjon 100% sikkert er ved hjelp av SSL . Bruker Javascript til hasj passordet er ikke trygt. Vanligste fallgruvene for klientsiden passord hashing:

  • Hvis forbindelsen mellom klienten og serveren er ukryptert, alt du gjør er sårbar for man-in-the-middle-angrep . En angriper kan erstatte den innkommende script for å bryte hashing eller sende alle legitimasjon til deres server, kan de lytte til kundens svar og utgi brukerne perfekt, er etc. etc. SSL med troverdige sertifiseringsinstanser utformet for å hindre MITM angrep.
  • Den hashet passord mottatt av serveren er mindre sikker hvis du ikke gjør ekstra, overflødig arbeid på serveren.

Det er en annen sikker metode som kalles SRP , men det er patentert (selv om det er fritt lisensiert ), og det er få gode implementeringer tilgjengelig.

lagring av passord

Ikke noen gang lagre passord som klartekst i databasen. Ikke selv om du ikke bryr seg om sikkerheten til ditt eget nettsted. Anta at noen av brukerne vil bruke passordet til sin nettbank. Så, lagre hashet passord, og kaste bort originalen. Og sørg for at passordet ikke vises i tilgangslogger eller applikasjonslogger. OWASP anbefaler bruk av Argon2 som førstevalget for nye applikasjoner. Hvis dette ikke er tilgjengelig, bør PBKDF2 eller scrypt brukes i stedet. Og til slutt hvis ingen av de ovennevnte er tilgjengelig, bruker bcrypt.

Hashes av seg selv er også usikre. For eksempel identiske passord bety identiske hashes - dette gjør hash oppslagstabeller en effektiv måte å knekke mange passord samtidig. I stedet lagre saltet hash. Et salt er en streng legges til passord før hashing - bruke en annen (tilfeldig) salt per bruker. Saltet er en offentlig verdi, slik at du kan lagre dem med hasj i databasen. Se her for mer om dette.

Det betyr at du ikke kan sende brukeren deres glemte passord (fordi du bare har hash). Ikke nullstill brukerens passord hvis du ikke har godkjent brukeren (brukere må bevise at de er i stand til å lese e-post som sendes til lagret (og validert) e-postadresse.)

Sikkerhetsspørsmål

Sikkerhetsspørsmål er usikre - unngå å bruke dem. Hvorfor? Noe et sikkerhetsspørsmål gjør, gjør et passord bedre. Les DEL III: Ved hjelp av hemmelige spørsmål i @Jens Roland svarer her i denne wikien.

session cookies

Når brukeren logger inn, sender serveren brukeren en session cookie. Serveren kan hente brukernavn eller id fra cookie, men ingen andre kan generere en slik informasjonskapsel (TODO forklare mekanismene).

Cookies kan bli kapret : de er bare så sikker som resten av kundens maskin og annen kommunikasjon. De kan leses fra disken, snuste i nettverkstrafikken, løftet av en cross-site scripting angrep, bli utsatt for svindel fra en forgiftet DNS slik at kunden sender sine cookies til feil servere. Ikke send vedvarende informasjonskapsler. Cookies bør utløper ved slutten av klientøkt (leseren lukker eller forlate ditt domene).

Hvis du ønsker å Autologin brukerne, kan du angi en vedvarende informasjonskapsel, men det bør være forskjellig fra en full-session cookie. Du kan sette et ekstra flagg som brukeren har automatisk logget inn, og må logge inn på ordentlig for sensitive operasjoner. Dette er populært blant nettbutikker som ønsker å gi deg en sømløs, personlig shopping opplevelse, men likevel beskytte dine finansielle detaljer. For eksempel, når du kommer tilbake for å besøke Amazon, de viser deg en side som ser ut som du er logget inn, men når du går inn en ordre (eller endre leveringsadresse, kredittkort etc.), de ber deg om å bekrefte ditt passord.

Finansielle nettsider som banker og kredittkort, på den annen side, bare har sensitive data, og bør ikke la auto-login eller en lav-sikkerhetsmodus.

Liste over eksterne ressurser

Svarte 02/08/2008 kl. 20:40
kilden bruker

stemmer
146

Først en sterk påminnelse at dette svaret er ikke den beste passform for akkurat dette spørsmålet. Det bør definitivt ikke være toppen svaret!

Jeg vil gå videre og nevner Mozillas forslag BrowserID (eller kanskje mer presist, Verified Email Protocol ) i ånden av å finne en oppgradering til bedre tilnærminger til godkjenning i fremtiden.

Jeg vil oppsummere det slik:

  1. Mozilla er en nonprofit med verdier som er i tråd godt med å finne gode løsninger på dette problemet.
  2. Realiteten i dag er at de fleste nettsteder bruker skjemabasert autentisering
  3. Skjemabasert autentisering har en stor ulempe, som er økt risiko for phishing . Brukere blir bedt om å oppgi sensitiv informasjon i et område kontrollert av en ekstern enhet, snarere enn et område kontrollert av deres User Agent (nettleser).
  4. Siden nettlesere er klarert implisitt (hele ideen om en brukeragent er å handle på vegne av bruker), kan de bidra til å forbedre denne situasjonen.
  5. Den primære kraft som holder tilbake fremgangen her er utplassering vranglås . Løsninger må deles opp i tiltak som gir noen inkrementell fordel på egenhånd.
  6. Den enkleste desentralisert metode for å uttrykke identitet som er bygget inn i Internett-infrastrukturen er domenenavnet.
  7. Som et annet nivå for å uttrykke identitet, forvalter hvert domene sitt eget sett med kontoer.
  8. Skjemaet “konto @domene” er kortfattet og støttes av et bredt spekter av protokoller og URI ordninger. En slik identifikator er selvfølgelig mest universelt anerkjent som en e-postadresse.
  9. E-postleverandører er allerede de-facto primære identitetsleverandører på nettet. Nåværende tilbakestilling av passord flyter vanligvis lar deg ta kontroll over en konto hvis du kan bevise at du kontrollerer at kontoen er knyttet e-postadresse.
  10. Verified Email protokollen ble foreslått å gi en sikker metode, basert på offentlig nøkkel kryptografi, for å effektivisere prosessen med å bevise for domene B som du har en konto på domenet A.
  11. For nettlesere som ikke støtter bekreftet e-protokollen (for tiden alle av dem), gir Mozilla et mellomlegg som implementerer protokollen i klientsiden Javascript-kode.
  12. For e-posttjenester som ikke støtter Verified Email protokollen tillater protokollen tredjeparter til å fungere som en betrodd mellommann, hevde at de har bekreftet en brukers eierskap til en konto. Det er ikke ønskelig å ha et stort antall slike tredjeparter; denne evnen er kun ment å gi en oppgradering, og det er mye foretrukket at e-posttjenester tilbyr disse påstandene selv.
  13. Mozilla har sin egen tjeneste for å fungere som en pålitelig tredjepart. Service Providers (det vil si Stole partene) som gjennomfører bekreftet e-protokollen kan velge å stole på Mozillas påstander eller ikke. Mozillas tjeneste bekrefter brukerens konto eierskap ved hjelp av konvensjonelle midler for å sende en e-post med en bekreftelseslink.
  14. Tjenesteleverandører kan selvsagt tilby denne protokollen som et alternativ i tillegg til noen annen metode (r) for autentisering de kanskje ønsker å tilby.
  15. En stor brukergrensesnitt fordel søkes her er “identitet velgeren”. Når en bruker besøker et nettsted, og velger å autentisere viser nettleseren dem et utvalg av e-postadresser ( “personlig”, “arbeid”, “politisk aktivisme”, osv) de kan bruke til å identifisere seg på kurset.
  16. En annen stor brukergrensesnitt fordel søkes som en del av dette arbeidet er å hjelpe leseren vite mer om brukerens session - hvem de er logget på som i dag, først og fremst - så det kan vise at nettleseren Chrome.
  17. På grunn av den distribuerte natur dette systemet unngår det lock-in til store nettsteder som Facebook, Twitter, Google, etc. Alle kan eie sin egen domene og dermed opptre som sin egen identitet leverandøren.

Dette er strengt tatt ikke “skjemabasert autentisering for nettsteder”. Men det er et forsøk på å gå over fra dagens norm av skjemabasert autentisering til noe mer sikker: nettleser-støttede godkjenning.

Svarte 08/08/2011 kl. 15:32
kilden bruker

stemmer
120

Jeg tenkte jeg skulle dele denne løsningen som jeg fant ut til å fungere helt fint.

Jeg kaller det Dummy Feltet (selv om jeg ikke har oppfunnet dette så ikke kreditere meg).

Kort sagt: du må bare sette dette inn i <form>og se etter det å være tom på når validering:

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

Trikset er å lure en bot til å tro det har å sette inn data i et obligatorisk felt, det er derfor jeg heter input "email". Hvis du allerede har et felt som heter e-post som du bruker bør du prøve å navngi dummy feltet noe annet som "selskap", "telefon" eller "e-postadresse". Bare velg noe du vet du ikke trenger og hva høres ut som noe folk ville vanligvis finner logisk å fylle inn i et webskjema. Nå skjule inputfeltet ved hjelp av CSS eller Javascript / jQuery - uansett hva som passer deg best - bare ikke sette inn typetil hiddenellers boten vil ikke falle for det.

Når du validere form (enten klient eller server side) sjekke om din dummy feltet er fylt for å fastslå om det var sending av et menneske eller en bot.

Eksempel:

I tilfelle av et menneske: Brukeren vil ikke se dummy-feltet (i mitt tilfelle heter "e") og vil ikke prøve å fylle den. Så verdien av dummy feltet skal fortsatt være tom når har blitt sende skjemaet.

I tilfelle av en bot: Boten vil se et felt som type er textog et navn email(eller hva det er du kalte det) og vil logisk forsøke å fylle det med passende data. Den bryr seg ikke om du stylet input skjema med noen fancy CSS, web-utviklere gjør det hele tiden. Uansett hva verdien i dummy feltet er, bryr vi oss ikke så lenge det er større enn 0tegn.

Jeg brukte denne metoden på en gjestebok i kombinasjon med CAPTCHA , og jeg har ikke sett en eneste spam innlegget siden. Jeg hadde brukt en CAPTCHA-eneste løsningen før, men til slutt det resulterte i omtrent fem spam innlegg hver time. Legge til dummy-feltet i form har stoppet (minst til nå) all spam vises.

Jeg tror dette kan også brukes helt fint med en login / autentisering form.

Advarsel : Selvfølgelig denne metoden er ikke 100% idiotsikker. Roboter kan programmeres til å ignorere inputfelt med stilen display:nonebrukes til det. Du må også tenke på folk som bruker noen form for auto-fullføring (som de fleste nettlesere har innebygd!) Til auto-fill alle feltene for dem. De kan like gjerne plukke opp en dummy-feltet.

Du kan også variere dette opp litt ved å la dummy feltet synlig, men utenfor grensene av skjermen, men dette er helt opp til deg.

Vær kreativ!

Svarte 22/05/2012 kl. 12:11
kilden bruker

stemmer
71

Jeg tror ikke de ovennevnte svaret er "feil", men det er store områder av godkjenning som ikke er berørt (eller snarere det legges vekt på "hvordan å implementere cookie økter", ikke på "hva alternativene er tilgjengelige og hva er handelen offs".

Mine foreslåtte endringer / svarene er

  • Problemet ligger mer i kontooppsett enn i passordkontroll.
  • Bruken av to faktor authenitication er mye sikrere enn mer smarte hjelp av passordkryptering
  • Ikke prøv å implementere din egen påloggingsskjema eller database lagring av passord, med mindre dataene blir lagret er verdiløs ved opprettelse av konto og egenprodusert (det vil si web 2.0 stil som Facebook, Flickr , etc.)

    1. Digest Authentication er en standardbasert tilnærming støttes i alle de store nettlesere og servere, som ikke vil sende et passord selv over en sikker kanal.

Dette unngår noe behov for å ha "sessions" eller informasjonskapsler som selve nettleseren vil re-kryptere kommunikasjonen hver gang. Det er den mest "lette" utvikling tilnærming.

Men jeg anbefaler ikke dette, med unntak av offentlige, lav verdi tjenester. Dette er et problem med noen av de andre svarene ovenfor - ikke prøv en re-implementere server-side authetication mekanismer - dette problemet er løst, og støttes av de fleste store nettleserne. Ikke bruk cookies. Ikke oppbevar noe i din egen håndrullet database. Bare spør, etter ønske, dersom forespørselen er autheticated. Alt annet bør støttes av konfigurasjon og tredjeparts klarert programvare.

Så ...

Først blir vi forvirrende den innledende opprettelse av en konto (med et passord) med gjen kontroll av passordet senere. Hvis jeg er Flickr og lage nettstedet ditt for første gang, har den nye brukeren tilgang til null verdi (blank webhotell). Jeg virkelig ikke bryr seg om personen oppretter kontoen lyver om deres navn. Hvis jeg oppretter en konto på sykehusets intranett / ekstranett, ligger verdien i alle medisinske poster, og så jeg ikke bryr seg om identitet (*) av kontoen skaperen.

Dette er veldig vanskelig del. Den eneste anstendig løsning er et nett av tillit. For eksempel, bli med deg på sykehuset som lege. Du oppretter en nettside vert for et sted med bildet ditt, din passnummer og en offentlig nøkkel, og hash dem alle med den private nøkkelen. Du kan deretter besøke sykehuset og systemadministratoren ser på passet ditt, ser om bildet passer deg, og deretter hashes nettsiden / bilde hash med sykehuset private nøkkel. Fra nå av kan vi sikkert utveksle nøkler og symboler. Som kan noen som stoler på sykehuset (det er hemmeligheten saus BTW). Systemadministrator kan også gi deg en RSA dongle eller annen to-faktor autentisering.

Men dette er en mye stress, og ikke veldig web 2.0. Men det er den eneste sikre måten å opprette nye kontoer som har tilgang til verdifull informasjon som ikke er selvlagde.

  1. Kerberos og SPNEGO - enkel pålogging på mekanismer med en betrodd tredjepart - i utgangspunktet brukeren verifiserer mot en betrodd tredjepart. (NB dette er ikke på noen måte ikke til å stole OAuth )

  2. SRP - slags smart passord autentisering uten en pålitelig tredjepart. Men her vi får inn i verdener av "det er tryggere å bruke to-faktor autentisering, selv om det er dyrere"

  3. SSL klientsiden - gi kundene en offentlig nøkkel sertifikat (støtte i alle de store nettleserne - men reiser spørsmål i løpet av klientmaskinen sikkerhet).

Til slutt er det en tradeoff - hva er kostnaden for et sikkerhetsbrudd vs kostnaden ved å implementere sikrere metoder. En dag, kan vi se en skikkelig PKI allment akseptert og så ikke mer egen rullet autentiserings skjemaer og databaser. En dag...

Svarte 08/08/2011 kl. 16:29
kilden bruker

stemmer
48

Når hashing, ikke bruk raske hash algoritmer som MD5 (mange hardware implementeringer finnes). Bruk noe som SHA-512. For passord, tregere hashes er bedre.

Jo raskere du kan lage hashes, jo raskere kan noen brute force kontrolløren fungere. Langsommere hashes vil derfor bremse brute tvinge. En langsom hash algoritme vil gjøre brute tvinge upraktisk for lengre passord (8 siffer +)

Svarte 08/08/2011 kl. 23:07
kilden bruker

stemmer
46

En god artikkel om realistisk passord styrke estimering er:

Dropbox Tech Blog »Blog Archive» zxcvbn: realistisk passord styrke estimering

Svarte 08/11/2012 kl. 11:15
kilden bruker

stemmer
41

Min favoritt regel i forhold til autentiseringssystemer: Bruk passfraser, ikke passord. Lett å huske, vanskelig å knekke. Mer info: Coding Horror: Passord vs. Pass fraser

Svarte 24/11/2012 kl. 21:15
kilden bruker

stemmer
20

Jeg vil gjerne legge til ett forslag jeg har brukt, basert på forsvar i dybden. Du trenger ikke å ha samme auth & auth system for administratorer som vanlige brukere. Du kan ha en egen login form på en egen url utføre egen kode for forespørsler som vil gi høye privilegier. Dette kan man gjøre valg som ville være en total smerte for vanlige brukere. En slik som jeg har brukt er å faktisk rykke innloggings URL for admin-tilgang og e-post til admin den nye nettadressen. Stopper noen brute force angrep med en gang som den nye nettadressen kan være vilkårlig vanskelig (svært lang tilfeldig streng), men admin brukerens eneste ulempen er å følge en lenke i e-posten. Angriperen ikke lenger vet hvor du selv legge inn til.

Svarte 18/07/2015 kl. 01:18
kilden bruker

stemmer
12

Jeg dont't vet om det var best å svare på dette som et svar eller som en kommentar. Jeg valgte det første alternativet.

Når det gjelder Poing DEL IV: Glemt passord Funksjonalitet i det første svaret, ville jeg gjøre et punkt om angrep timing.

I de Husk passordet ditt former, kan en angriper potensielt sjekke en fullstendig liste over e-post og oppdage som er registrert i systemet (se lenke nedenfor).

Når det gjelder Glemt passord Form, vil jeg legge til at det er en god idé å tilsvare ganger mellom vellykkede og unsucessful spørsmål med en viss forsinkelse funksjon.

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

Svarte 16/08/2015 kl. 17:31
kilden bruker

stemmer
10

Jeg vil gjerne legge til en svært viktige kommentaren:

  • "I en corporate, intra- nett innstilling," de fleste om ikke alle av de ovennevnte kan ikke søke!

Mange selskaper distribuere "internt bruk" nettsteder som er effektivt, "bedriftens applikasjoner" som tilfeldigvis har blitt implementert gjennom nettadresser. Disse nettadressene kan (visstnok ...) bare løses innenfor "selskapets interne nettverket." (Som nettverket omfatter magisk all VPN-tilkoblet 'veien krigere'.)

Når en bruker er dutifully bart forbundet med den foran nevnte nettverk, deres identitet ( "authentication") er [allerede ...] "endelig kjent," som er deres tillatelse ( "autorisasjon") for å gjøre visse ting ... som. .. "for å få tilgang til dette nettstedet."

Denne "autentisering + autorisasjon" service kan leveres av flere ulike teknologier, for eksempel LDAP (Microsoft OpenDirectory) , eller Kerberos.

Fra point-of-view, du bare vet dette: at alle som legitimt vind opp mot ditt nettsted "token" følges av [et miljø variabel magisk inneholder ...] en ( Dvs. Fraværet av en slik token må være umiddelbare grunnlag for 404 Not Found).

Token verdi gir ingen mening for deg, men hvis behovet skulle oppstå, "egnede midler finnes" der din web-site kan "[autoritativt] spør noen som vet (LDAP ... osv)" om noen og enhver ( !) spørsmål som du måtte ha. Med andre ord trenger du ikke benytte deg av noen "hjemmesnekrede logikk." I stedet spørre deg om myndighet og implisitt stole på sin dom.

Uh huh ... det er ganske en mental-bryteren fra "vill-and-ullen Internett."

Svarte 29/04/2015 kl. 01:06
kilden bruker

stemmer
5

Bruk OpenID Connect eller brukerstyrte tilgang .

Så ingenting er mer effektivt enn å ikke gjøre det i det hele tatt.

Svarte 10/08/2016 kl. 13:27
kilden bruker

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