Die definitiewe gids tot vormgebaseerde webwerf-verifikasie [gesluit]

StackOverflow https://stackoverflow.com/questions/549

Vra

Vormgebaseerde verifikasie vir webwerwe

Ons glo dat Stack Overflow nie net 'n hulpbron vir baie spesifieke tegniese vrae moet wees nie, maar ook vir algemene riglyne oor hoe om variasies op algemene probleme op te los."Vormgebaseerde verifikasie vir webwerwe" behoort 'n goeie onderwerp vir so 'n eksperiment te wees.

Dit moet onderwerpe insluit soos:

  • Hoe om aan te meld
  • Hoe om uit te meld
  • Hoe om aangemeld te bly
  • Bestuur webkoekies (insluitend aanbevole instellings)
  • SSL/HTTPS-enkripsie
  • Hoe om wagwoorde te stoor
  • Gebruik geheime vrae
  • Vergete gebruikersnaam/wagwoord funksionaliteit
  • Gebruik van nonsies om te verhoed kruis-werf versoek vervalsings (CSRF)
  • OpenID
  • "Onthou my" merkblokkie
  • Blaaier-outovoltooiing van gebruikersname en wagwoorde
  • Geheime URL's (publiek URL beskerm deur vertering)
  • Kontroleer tans wagwoordsterkte
  • E-pos bekragtiging
  • en nog baie meer oor vormgebaseerde verifikasie...

Dit moet nie dinge soos:

  • Rolle en magtiging
  • HTTP basiese verifikasie

Help ons asseblief deur:

  1. Stel subonderwerpe voor
  2. Die indiening van goeie artikels oor hierdie onderwerp
  3. Redigeer die amptelike antwoord
Was dit nuttig?

Oplossing

DEEL I:Hoe om aan te meld

Ons sal aanvaar dat jy reeds weet hoe om 'n login+wagwoord HTML-vorm te bou wat die waardes na 'n skrif aan die bedienerkant plaas vir verifikasie.Die afdelings hieronder sal handel oor patrone vir goeie praktiese bekragtiging, en hoe om die mees algemene sekuriteitslaggate te vermy.

Na HTTPS of nie na HTTPS nie?

Tensy die verbinding reeds veilig is (dit wil sê, deur HTTPS deur SSL/TLS getonnel is), sal jou aanmeldvormwaardes in duidelike teks gestuur word, wat toelaat dat enigiemand wat die lyn tussen blaaier en webbediener afluister, aanmeldings kan lees soos hulle verbygaan deur.Hierdie tipe afluister word gereeld deur regerings gedoen, maar oor die algemeen sal ons nie 'besit' drade aanspreek anders as om dit te sê:As jy enigiets belangrik beskerm, gebruik HTTPS.

In wese die enigste prakties manier om te beskerm teen afluistering/pakkiesnuffel tydens aanmelding is deur HTTPS of 'n ander sertifikaat-gebaseerde enkripsieskema te gebruik (byvoorbeeld, TLS) of 'n bewese en getoetste uitdaging-reaksie-skema (byvoorbeeld die Diffie-Hellman-gebaseerde SRP). Enige ander metode kan maklik omseil word deur 'n afluisterende aanvaller.

Natuurlik, as jy bereid is om 'n bietjie onprakties te raak, kan jy ook een of ander vorm van twee-faktor-verifikasieskema gebruik (bv.die Google Authenticator-toepassing, 'n fisiese 'koue oorlogstyl'-kodeboek, of 'n RSA-sleutelgenerator-dongle).As dit korrek toegepas word, kan dit werk selfs met 'n onversekerde verbinding, maar dit is moeilik om te dink dat 'n ontwikkelaar bereid sou wees om twee-faktor-bekragtiging te implementeer, maar nie SSL nie.

(Moenie) Rol jou eie JavaScript-enkripsie/hashing

Gegewe die nie-nul-koste en waargenome tegniese probleme om 'n SSL-sertifikaat op u webwerf op te stel, is sommige ontwikkelaars in die versoeking om hul eie hashing- of enkripsieskemas in die blaaier te gebruik om te verhoed dat duidelike teks-aanmeldings oor 'n onversekerde draad gestuur word.

Alhoewel dit 'n edele gedagte is, is dit in wese nutteloos (en kan 'n sekuriteitsfout) tensy dit gekombineer word met een van die bogenoemde - dit wil sê, óf die lyn met sterk enkripsie beveilig óf 'n beproefde uitdaging-reaksie-meganisme gebruik (as jy nie weet wat dit is nie, weet net dat dit een is van die moeilikste om te bewys, die moeilikste om te ontwerp en die moeilikste om konsepte in digitale sekuriteit te implementeer).

Terwyl dit waar is dat die wagwoord hashing Kan wees effektief teen wagwoord openbaarmaking, dit is kwesbaar vir herhalingsaanvalle, Man-In-The-Middle-aanvalle / kapings (as 'n aanvaller 'n paar grepe in jou onversekerde HTML-bladsy kan inspuit voordat dit jou blaaier bereik, kan hulle eenvoudig kommentaar lewer oor die hashing in die JavaScript), of brute-force aanvalle (aangesien jy die aanvaller beide gebruikersnaam, sout en gehashte wagwoord gee).

CAPTCHAS teen die mensdom

CAPTCHA is bedoel om een ​​spesifieke kategorie van aanval te stuit:outomatiese woordeboek / brute krag proef-en-fout met geen menslike operateur.Daar is geen twyfel dat dit 'n werklike bedreiging is nie, maar daar is maniere om dit naatloos te hanteer wat nie 'n CAPTCHA vereis nie, spesifiek behoorlik ontwerpte bediener-kant-aanmelding-beperkingskemas - ons sal dit later bespreek.

Weet dat CAPTCHA-implementerings nie eenders geskep word nie;hulle is dikwels nie menslik oplosbaar nie, die meeste van hulle is eintlik ondoeltreffend teen bots, almal van hulle is oneffektief teen goedkoop derdewêreldarbeid (volgens OWASP, die huidige sweetshop-koers is $12 per 500 toetse), en sommige implementerings kan tegnies onwettig wees in sommige lande (sien OWASP Authentication Cheat Sheet).As jy 'n CAPTCHA moet gebruik, gebruik Google s'n reCAPTCHA, aangesien dit per definisie OCR-hard is (aangesien dit reeds OCR-verkeerd geklassifiseerde boekskanderings gebruik) en baie hard probeer om gebruikersvriendelik te wees.

Persoonlik is ek geneig om CAPTCHAS irriterend te vind, en gebruik dit slegs as 'n laaste uitweg wanneer 'n gebruiker 'n aantal kere versuim het om aan te meld en versnellingsvertragings uitgeput is.Dit sal selde genoeg gebeur om aanvaarbaar te wees, en dit versterk die stelsel as geheel.

Stoor wagwoorde / Verifieer aanmeldings

Dit kan uiteindelik algemene kennis wees na al die hoogs-gepubliseerde hacks en gebruikersdatalekkasies wat ons die afgelope jare gesien het, maar dit moet gesê word:Moenie wagwoorde in duidelike teks in jou databasis stoor nie.Gebruikersdatabasisse word gereeld deur SQL-inspuiting gekap, uitgelek of ingesamel, en as jy rou, gewone tekswagwoorde stoor, is dit onmiddellik afgehandel vir jou aanmeldveiligheid.

So as jy nie die wagwoord kan stoor nie, hoe kontroleer jy dat die aanteken+wagwoordkombinasie wat vanaf die aanmeldvorm geplaas is, korrek is?Die antwoord is hashing met behulp van a sleutel afleidingsfunksie.Wanneer 'n nuwe gebruiker geskep of 'n wagwoord verander word, neem jy die wagwoord en hardloop dit deur 'n KDF, soos Argon2, bcrypt, scrypt of PBKDF2, en verander die duidelike teks wagwoord ("correcthorsebatterystaple") in 'n lang, ewekansige string , wat baie veiliger is om in jou databasis te stoor.Om 'n aanmelding te verifieer, voer jy dieselfde hash-funksie op die ingevoerde wagwoord uit, en gee hierdie keer die sout in en vergelyk die gevolglike hash-string met die waarde wat in jou databasis gestoor is.Argon2, bcrypt en scrypt stoor die sout reeds met die hash.Kyk hierna artikel op sec.stackexchange vir meer gedetailleerde inligting.

Die rede waarom 'n sout gebruik word, is dat hashing op sigself nie voldoende is nie -- jy sal 'n sogenaamde 'sout' wil byvoeg om die hash teen reënboog tafels.'n Sout verhoed effektief dat twee wagwoorde wat presies ooreenstem, as dieselfde hash-waarde gestoor word, wat verhoed dat die hele databasis in een keer geskandeer word as 'n aanvaller 'n wagwoordraai-aanval uitvoer.

’n Kriptografiese hash moet nie vir wagwoordberging gebruik word nie omdat gebruiker-geselekteerde wagwoorde nie sterk genoeg is nie (d.w.s.bevat gewoonlik nie genoeg entropie nie) en 'n wagwoordraai-aanval kan binne 'n relatief kort tyd voltooi word deur 'n aanvaller met toegang tot die hashes.Dit is hoekom KDF's gebruik word - dit is effektief "rek die sleutel", wat beteken dat elke wagwoordraai wat 'n aanvaller maak, veelvuldige herhalings van die hash-algoritme veroorsaak, byvoorbeeld 10 000 keer, wat veroorsaak dat die aanvaller die wagwoord 10 000 keer stadiger raai.

Sessiedata - "Jy is aangemeld as Spiderman69"

Sodra die bediener die login en wagwoord teen jou gebruikersdatabasis geverifieer het en 'n passing gevind het, het die stelsel 'n manier nodig om te onthou dat die blaaier geverifieer is.Hierdie feit moet slegs bedienerkant in die sessiedata gestoor word.

As jy nie vertroud is met sessiedata nie, werk dit so:'n Enkele willekeurig gegenereerde string word in 'n koekie wat verval, gestoor en gebruik om 'n versameling data te verwys - die sessiedata - wat op die bediener gestoor word.As jy 'n MVC-raamwerk gebruik, word dit ongetwyfeld reeds hanteer.

Indien enigsins moontlik, maak seker dat die sessiekoekie die veilige en HTTP Only-vlae het wat gestel is wanneer dit na die blaaier gestuur word.Die HttpOnly-vlag bied 'n mate van beskerming teen die koekie wat deur XSS-aanval gelees word.Die veilige vlag verseker dat die koekie slegs via HTTPS teruggestuur word, en beskerm dus teen netwerksnuffelaanvalle.Die waarde van die koekie behoort nie voorspelbaar te wees nie.Waar 'n koekie wat na 'n nie-bestaande sessie verwys, aangebied word, moet die waarde daarvan onmiddellik vervang word om te voorkom sessie fiksasie.

DEEL II:Hoe om aangemeld te bly - Die berugte "Onthou my"-merkblokkie

Aanhoudende aanmeldkoekies ("onthou my"-funksie) is 'n gevaarsone;aan die een kant is hulle heeltemal so veilig soos konvensionele aanmeldings wanneer gebruikers verstaan ​​hoe om dit te hanteer;en aan die ander kant is dit 'n enorme sekuriteitsrisiko in die hande van sorgelose gebruikers, wat dit dalk op publieke rekenaars gebruik en vergeet om uit te meld, en wat dalk nie weet wat blaaierkoekies is of hoe om dit uit te vee nie.

Persoonlik hou ek van volgehoue ​​aanmeldings vir die webwerwe wat ek gereeld besoek, maar ek weet hoe om dit veilig te hanteer.As jy seker is dat jou gebruikers dieselfde weet, kan jy volgehoue ​​aanmeldings met 'n skoon gewete gebruik.Indien nie - wel, dan kan jy inteken op die filosofie dat gebruikers wat onverskillig is met hul aanmeldbewyse dit oor hulself gebring het as hulle gekap word.Dit is ook nie asof ons na ons gebruikers se huise gaan en al daardie gesigpalm-inducerende Post-It-notas met wagwoorde wat hulle op die rand van hul monitors in lyn het, afskeur nie.

Natuurlik kan sommige stelsels nie bekostig om te hê nie enige rekeninge gekap;vir sulke stelsels, is daar geen manier waarop jy kan regverdig om aanhoudende aanmeldings te hê nie.

As jy besluit om aanhoudende aanmeldkoekies te implementeer, is dit hoe jy dit doen:

  1. Neem eers tyd om te lees Paragon Initiative se artikel op die onderwerp.Jy sal 'n klomp elemente reg moet kry, en die artikel verduidelik elkeen uitstekend.

  2. En net om een ​​van die mees algemene slaggate te herhaal, MOENIE DIE VOLHARDIGE AANMELDKOEKIE (TOKEN) IN JOU DATABASIS BOOR NIE, SLEGS 'N HASH DAARVAN! Die aanmeldtoken is Wagwoordekwivalent, so as 'n aanvaller jou databasis in die hande kry, kan hulle die tekens gebruik om by enige rekening aan te meld, net asof dit duidelike teksaanmelding-wagwoordkombinasies is.Gebruik daarom hashing (volgens https://security.stackexchange.com/a/63438/5002 'n swak hash sal goed werk vir hierdie doel) wanneer aanhoudende aanmeldtokens gestoor word.

DEEL III:Gebruik geheime vrae

Moenie 'geheime vrae' implementeer nie.Die 'geheime vrae'-kenmerk is 'n sekuriteit-teenpatroon.Lees die vraestel vanaf skakel nommer 4 van die MOET-LEES lys.Jy kan Sarah Palin oor daardie een vra, na haar Yahoo!e-posrekening is tydens 'n vorige presidensiële veldtog gekap omdat die antwoord op haar sekuriteitsvraag was..."Hoërskool Wasilla"!

Selfs met gebruiker-gespesifiseerde vrae, is dit hoogs waarskynlik dat die meeste gebruikers een van die volgende sal kies:

  • 'n 'Standaard' geheime vraag soos ma se nooiensvan of gunsteling troeteldier

  • 'n Eenvoudige stukkie trivia wat enigiemand van hul blog, LinkedIn-profiel of soortgelyke kan optel

  • Enige vraag wat makliker is om te beantwoord as om hul wagwoord te raai.Wat, vir enige ordentlike wagwoord, elke vraag is wat jy jou kan voorstel

Ten slotte, sekuriteitsvrae is inherent onseker in feitlik al hul vorme en variasies, en moet om enige rede nie in 'n stawingskema gebruik word nie.

Die ware rede waarom sekuriteitsvrae selfs in die natuur bestaan, is dat dit gerieflik die koste van 'n paar ondersteuningsoproepe bespaar van gebruikers wat nie toegang tot hul e-pos het nie om by 'n heraktiveringskode uit te kom.Dit ten koste van sekuriteit en Sarah Palin se reputasie.Die moeite werd?Waarskynlik nie.

DEEL IV:Vergete wagwoord funksionaliteit

Ek het reeds genoem hoekom jy moet gebruik nooit sekuriteitsvrae nie vir die hantering van vergete/verlore gebruikerwagwoorde;dit spreek ook vanself dat jy nooit gebruikers hul werklike wagwoorde moet e-pos nie.Daar is ten minste twee meer al te algemene slaggate om te vermy in hierdie veld:

  1. Moenie herstel 'n vergete wagwoord vir 'n outo-gegenereerde sterk wagwoord - sulke wagwoorde is berug moeilik om te onthou, wat beteken dat die gebruiker dit óf moet verander óf dit moet neerskryf - sê, op 'n heldergeel Post-It op die rand van hul monitor.In plaas daarvan om 'n nuwe wagwoord in te stel, laat gebruikers net dadelik 'n nuwe een kies - dit is in elk geval wat hulle wil doen.('n Uitsondering hierop kan wees as die gebruikers universeel 'n wagwoordbestuurder gebruik om wagwoorde te stoor/bestuur wat normaalweg onmoontlik sou wees om te onthou sonder om dit neer te skryf).

  2. Hash altyd die verlore wagwoordkode/token in die databasis. WEER, is hierdie kode nog 'n voorbeeld van 'n wagwoord-ekwivalent, so dit MOET gehash word ingeval 'n aanvaller jou databasis in die hande kry.Wanneer 'n verlore wagwoordkode versoek word, stuur die gewone tekskode na die gebruiker se e-posadres, hash dit dan, stoor die hash in jou databasis -- en gooi die oorspronklike weg.Net soos 'n wagwoord of 'n aanhoudende aanmeldteken.

'n Laaste nota:maak altyd seker dat jou koppelvlak vir die invoer van die 'verlore wagwoordkode' minstens so veilig is soos jou aanmeldvorm self, of 'n aanvaller sal dit bloot gebruik om eerder toegang te verkry.Om seker te maak dat jy baie lang 'verlore wagwoordkodes' genereer (byvoorbeeld, 16 hooflettersensitiewe alfanumeriese karakters) is 'n goeie begin, maar oorweeg dit om dieselfde versperringskema by te voeg as wat jy vir die aanmeldvorm self doen.

DEEL V:Kontroleer wagwoordsterkte

Eerstens wil jy hierdie klein artikel lees vir 'n realiteitskontrole: Die 500 mees algemene wagwoorde

Goed, so miskien is die lys nie die kanoniek lys van mees algemene wagwoorde op enige stelsel enige plek ooit, maar dit is 'n goeie aanduiding van hoe swak mense hul wagwoorde sal kies wanneer daar geen afgedwingde beleid in plek is nie.Boonop lyk die lys skrikwekkend naby die huis as jy dit vergelyk met publieke beskikbare ontledings van onlangs gesteelde wagwoorde.

Dus:Met geen minimum wagwoordsterktevereistes nie, gebruik 2% van gebruikers een van die top 20 mees algemene wagwoorde.Betekenis:as 'n aanvaller net 20 pogings kry, sal 1 uit 50 rekeninge op jou webwerf kraakbaar wees.

Om dit te stuit, vereis die berekening van die entropie van 'n wagwoord en dan die toepassing van 'n drempel.Die Nasionale Instituut vir Standaarde en Tegnologie (NIST) Spesiale publikasie 800-63 het 'n stel baie goeie voorstelle.Dit, wanneer dit gekombineer word met 'n woordeboek- en sleutelborduitlegontleding (byvoorbeeld, 'qwertyuiop' is 'n slegte wagwoord), kan verwerp 99% van alle swak geselekteerde wagwoorde op 'n vlak van 18 stukkies entropie.Bereken eenvoudig wagwoordsterkte en wat 'n visuele sterktemeter toon vir 'n gebruiker is goed, maar onvoldoende.Tensy dit afgedwing word, sal baie gebruikers dit heel waarskynlik ignoreer.

En vir 'n verfrissende aanpak van gebruikersvriendelikheid van hoë-entropie wagwoorde, Randall Munroe's Wagwoordsterkte xkcd word sterk aanbeveel.

Gebruik Troy Hunt's Is ek Pwned API om gebruikers se wagwoorde te kontroleer teen wagwoorde wat in die gedrang kom in openbare data-oortredings.

DEEL VI:Baie meer - Of:Voorkom vinnige-vuur-aanmeldingspogings

Kyk eers na die getalle: Wagwoordherstelspoed - Hoe lank sal jou wagwoord bly staan

As jy nie die tyd het om deur die tabelle in daardie skakel te kyk nie, hier is die lys van hulle:

  1. Dit neem feitlik geen tyd nie om 'n swak wagwoord te kraak, selfs al kraak jy dit met 'n abakus

  2. Dit neem feitlik geen tyd nie om 'n alfanumeriese 9-karakter wagwoord te kraak as dit is geval onsensitiewe

  3. Dit neem feitlik geen tyd nie om 'n ingewikkelde, simbole-en-letters-en-syfers, hoof- en kleinletters wagwoord te kraak as dit minder as 8 karakters lank ('n rekenaarrekenaar kan die hele sleutelspasie tot 7 karakters binne 'n kwessie van dae of selfs ure deursoek)

  4. Dit sal egter 'n buitensporige hoeveelheid tyd neem om selfs 'n 6-karakter wagwoord te kraak, as jy beperk was tot een poging per sekonde!

So wat kan ons uit hierdie getalle leer?Wel, baie, maar ons kan op die belangrikste deel fokus:die feit dat die voorkoming van groot getalle vinnige-vuur opeenvolgende aanmeldpogings (bv.die brute krag aanval) is regtig nie so moeilik nie.Maar om dit te voorkom reg is nie so maklik soos dit lyk nie.

Oor die algemeen het jy drie keuses wat almal effektief is teen brute-force aanvalle (en woordeboekaanvalle, maar aangesien jy reeds 'n sterk wagwoordbeleid gebruik, behoort dit nie 'n probleem te wees nie):

  • Bied a CAPTCHA na N mislukte pogings (irriterend soos die hel en dikwels ondoeltreffend -- maar ek herhaal myself hier)

  • Sluit rekeninge en wat e-posverifikasie vereis na N mislukte pogings (dit is 'n DoS aanval wat wag om te gebeur)

  • En uiteindelik, login smoor:dit wil sê, die stel van 'n tydsvertraging tussen pogings na N mislukte pogings (ja, DoS-aanvalle is steeds moontlik, maar dit is ten minste baie minder waarskynlik en baie meer ingewikkeld om af te haal).

Beste praktyk #1: 'n Kort tydsvertraging wat toeneem met die aantal mislukte pogings, soos:

  • 1 mislukte poging = geen vertraging nie
  • 2 mislukte pogings = 2 sekondes vertraging
  • 3 mislukte pogings = 4 sekondes vertraging
  • 4 mislukte pogings = 8 sekondes vertraging
  • 5 mislukte pogings = 16 sekondes vertraging
  • ens.

DoS om hierdie skema aan te val sou baie onprakties wees, aangesien die gevolglike uitsluitingstyd effens groter is as die som van die vorige uitsluittye.

Om te verduidelik:Die vertraging is nie 'n vertraging voordat die antwoord na die blaaier teruggestuur word.Dit is meer soos 'n time-out of refractaire tydperk waartydens aanmeldpogings by 'n spesifieke rekening of vanaf 'n spesifieke IP-adres glad nie aanvaar of geëvalueer sal word nie.Dit wil sê, korrekte geloofsbriewe sal nie terugkeer in 'n suksesvolle aanmelding nie, en verkeerde geloofsbriewe sal nie 'n vertragingsverhoging veroorsaak nie.

Beste praktyk #2: 'n Middellange tydsvertraging wat in werking tree na N mislukte pogings, soos:

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

DoS om hierdie skema aan te val sou redelik onprakties wees, maar beslis uitvoerbaar.Dit kan ook relevant wees om daarop te let dat so 'n lang vertraging baie irriterend kan wees vir 'n wettige gebruiker.Vergeetige gebruikers sal nie van jou hou nie.

Beste praktyk #3: Die kombinasie van die twee benaderings - óf 'n vaste, kort tydsvertraging wat in werking tree na N mislukte pogings, soos:

  • 1-4 mislukte pogings = geen vertraging
  • 5+ mislukte pogings = 20 sekondes vertraging

Of, 'n toenemende vertraging met 'n vaste boonste grens, soos:

  • 1 mislukte poging = 5 sekondes vertraging
  • 2 mislukte pogings = 15 sekondes vertraging
  • 3+ mislukte pogings = 45 sekondes vertraging

Hierdie finale skema is geneem uit die OWASP beste praktykvoorstelle (skakel 1 van die MOET-LEES lys) en moet as beste praktyk beskou word, selfs al is dit weliswaar aan die beperkende kant.

As 'n duimreël sou ek egter sê:hoe sterker jou wagwoordbeleid is, hoe minder hoef jy gebruikers met vertragings te fouteer.As jy sterk (hooflettersensitiewe alfanumeriese + vereiste nommers en simbole) 9+ karakter wagwoorde benodig, kan jy die gebruikers 2-4 nie-vertraagde wagwoordpogings gee voordat die versnelling geaktiveer word.

DoS wat hierdie finale login-versnellingskema aanval, sou wees baie onprakties.En as 'n finale aanraking, laat altyd aanhoudende (koekie) aanmeldings (en/of 'n CAPTCHA-geverifieerde aanmeldvorm) deur, sodat wettige gebruikers nie eers vertraag sal word nie terwyl die aanval aan die gang is.Op dié manier word die baie onpraktiese DoS-aanval 'n uiters onpraktiese aanval.

Boonop is dit sinvol om meer aggressiewe versperring op admin-rekeninge te doen, aangesien dit die aantreklikste toegangspunte is

DEEL VII:Verspreide Brute Force-aanvalle

Net tersyde, sal meer gevorderde aanvallers probeer om aanmeldversperring te omseil deur 'hul aktiwiteite te versprei':

  • Versprei die pogings op 'n botnet om IP-adresvlag te voorkom

  • Eerder as om een ​​gebruiker te kies en die 50.000 mees algemene wagwoorde te probeer (wat hulle nie kan nie, as gevolg van ons verswakking), sal hulle DIE mees algemene wagwoord kies en dit eerder teen 50.000 gebruikers probeer.Op hierdie manier kom hulle nie net om maksimum-pogingsmaatreëls soos CAPTCHA's en login throttling nie, hul kans op sukses verhoog ook, aangesien die nommer 1 mees algemene wagwoord baie meer waarskynlik is as nommer 49.995

  • Spasieer die aanmeldversoeke vir elke gebruikersrekening, sê, 30 sekondes uitmekaar, om onder die radar te sluip

Hier sou die beste praktyk wees aanteken van die aantal mislukte aanmeldings, stelselwyd, en gebruik 'n lopende gemiddelde van jou werf se slegte aanmeldfrekwensie as basis vir 'n boonste limiet wat jy dan op alle gebruikers oplê.

Te abstrak?Laat ek herformuleer:

Gestel jou werf het die afgelope 3 maande gemiddeld 120 slegte aanmeldings per dag gehad.Deur dit (lopende gemiddelde) te gebruik, kan jou stelsel die globale limiet op 3 keer stel stel -- dws.360 mislukte pogings oor 'n tydperk van 24 uur.Dan, as die totale aantal mislukte pogings oor alle rekeninge daardie getal binne een dag oorskry (of selfs beter, monitor die tempo van versnelling en sneller op 'n berekende drempel), aktiveer dit stelselwye aanmeldversnelling - wat kort vertragings vir ALLE gebruikers beteken (steeds, met die uitsondering van koekie-aanmeldings en/of rugsteun-CAPTCHA-aanmeldings).

Ek het ook 'n vraag geplaas met meer besonderhede en 'n baie goeie bespreking van hoe om moeilike slaggate te vermy om verspreide brute krag aanvalle af te weer

DEEL VIII:Twee-faktor-verifikasie- en verifikasieverskaffers

Geloofsbriewe kan gekompromitteer word, hetsy deur uitbuiting, wagwoorde wat neergeskryf en verloor word, skootrekenaars met sleutels wat gesteel word, of gebruikers wat aanmeldings by uitvissingwebwerwe invoer.Aanmeldings kan verder beskerm word met twee-faktor-verifikasie, wat buite-band-faktore gebruik soos enkelgebruikkodes wat van 'n telefoonoproep, SMS-boodskap, toepassing of dongle ontvang word.Verskeie verskaffers bied twee-faktor stawing dienste.

Stawing kan heeltemal gedelegeer word na 'n enkelaanmelding-diens, waar 'n ander verskaffer die insameling van geloofsbriewe hanteer.Dit stoot die probleem na 'n betroubare derde party.Google en Twitter bied albei standaardgebaseerde SSO-dienste, terwyl Facebook 'n soortgelyke eie oplossing bied.

MOET-LEES SKAKELS Oor webverifikasie

  1. OWASP-gids tot verifikasie / OWASP Authentication Cheat Sheet
  2. Moets en moenies van kliëntverifikasie op die web (baie leesbare MIT-navorsingsartikel)
  3. Wikipedia:HTTP-koekie
  4. Persoonlike kennisvrae vir terugvalstawing:Sekuriteitsvrae in die era van Facebook (baie leesbare Berkeley-navorsingsartikel)

Ander wenke

Bepaalde artikel

Stuur geloofsbriewe

Die enigste praktiese manier om geloofsbriewe 100% veilig te stuur, is deur gebruik te maak SSL.Dit is nie veilig om JavaScript te gebruik om die wagwoord te hash nie.Algemene slaggate vir kliënt-kant wagwoord hashing:

  • As die verbinding tussen die kliënt en bediener ongeënkripteer is, is alles wat jy doen kwesbaar vir man-in-die-middel-aanvalle.'n Aanvaller kan die inkomende javascript vervang om die hashing te breek of alle geloofsbriewe na hul bediener te stuur, hulle kan na kliëntantwoorde luister en die gebruikers perfek naboots, ens.ens.SSL met betroubare sertifikaatowerhede is ontwerp om MitM-aanvalle te voorkom.
  • Die hashed wagwoord wat deur die bediener ontvang is, is minder veilig as jy nie bykomende, oortollige werk op die bediener doen nie.

Daar is nog 'n veilige metode genoem SRP, maar dit is gepatenteer (alhoewel dit is vrylik gelisensieer) en daar is min goeie implementerings beskikbaar.

Stoor wagwoorde

Moet nooit wagwoorde as gewone teks in die databasis stoor nie.Selfs nie as jy nie omgee vir die sekuriteit van jou eie webwerf nie.Aanvaar dat sommige van jou gebruikers die wagwoord van hul aanlyn bankrekening sal hergebruik.Stoor dus die gehashte wagwoord en gooi die oorspronklike weg.En maak seker dat die wagwoord nie in toegangsloglêers of toepassinglogboeke verskyn nie.OWASP beveel die gebruik van Argon2 aan as jou eerste keuse vir nuwe toepassings.As dit nie beskikbaar is nie, moet PBKDF2 of scrypt eerder gebruik word.En laastens as nie een van die bogenoemde beskikbaar is nie, gebruik bcrypt.

Hashes op sigself is ook onseker.Byvoorbeeld, identiese wagwoorde beteken identiese hashes - dit maak hash-opsoektabelle 'n effektiewe manier om baie wagwoorde gelyktydig te kraak.Stoor eerder die gesoute hasj.'n Sout is 'n string wat aan die wagwoord gevoeg word voor hashing - gebruik 'n ander (ewekansige) sout per gebruiker.Die sout is 'n publieke waarde, so jy kan dit saam met die hash in die databasis stoor.Sien hier vir meer hieroor.

Dit beteken dat jy nie die gebruiker hul vergete wagwoorde kan stuur nie (omdat jy net die hash het).Moenie die gebruiker se wagwoord terugstel tensy jy die gebruiker geverifieer het nie (gebruikers moet bewys dat hulle e-posse kan lees wat na die gestoorde (en gevalideerde) e-posadres gestuur is.)

Sekuriteitsvrae

Sekuriteitsvrae is onseker - vermy om dit te gebruik.Hoekom?Enigiets wat 'n sekuriteitsvraag doen, doen 'n wagwoord beter.Lees DEEL III:Gebruik geheime vrae in @Jens Roland antwoord hier in hierdie wiki.

Sessiekoekies

Nadat die gebruiker aangemeld het, stuur die bediener vir die gebruiker 'n sessiekoekie.Die bediener kan die gebruikersnaam of ID van die koekie afhaal, maar niemand anders kan so 'n koekie genereer nie (TODO verduidelik meganismes).

Koekies kan gekaap word:hulle is net so veilig soos die res van die kliënt se masjien en ander kommunikasie.Hulle kan vanaf skyf gelees word, in netwerkverkeer gesnuif word, opgehef word deur 'n kruis-werf script-aanval, uitvissing vanaf 'n vergiftigde DNS sodat die kliënt hul koekies na die verkeerde bedieners stuur.Moenie aanhoudende koekies stuur nie.Webkoekies behoort aan die einde van die kliëntsessie te verval (blaaier sluit of verlaat jou domein).

As jy jou gebruikers outolog wil aanmeld, kan jy 'n aanhoudende koekie stel, maar dit moet onderskei word van 'n volsessie-koekie.Jy kan 'n bykomende vlag stel wat die gebruiker outomaties aangemeld het, en vir sensitiewe bedrywighede moet aanmeld.Dit is gewild onder inkopiewebwerwe wat jou 'n naatlose, persoonlike inkopie-ervaring wil bied, maar steeds jou finansiële besonderhede wil beskerm.Byvoorbeeld, wanneer jy terugkeer om Amazon te besoek, wys hulle vir jou 'n bladsy wat lyk of jy aangemeld is, maar wanneer jy 'n bestelling gaan plaas (of jou afleweringsadres, kredietkaart ens. verander), vra hulle jou om te bevestig jou wagwoord.

Finansiële webwerwe soos banke en kredietkaarte, aan die ander kant, het net sensitiewe data en behoort nie outo-aanmelding of 'n lae-sekuriteitmodus toe te laat nie.

Lys van eksterne hulpbronne

Eerstens, 'n sterk waarskuwing dat hierdie antwoord nie die beste pas vir hierdie presiese vraag nie.Dit behoort beslis nie die top antwoord te wees nie!

Ek sal voortgaan en Mozilla se voorgestelde noem Blaaier-ID (of dalk meer presies, die Geverifieerde e-posprotokol) in die gees om 'n opgraderingspad te vind na beter benaderings tot verifikasie in die toekoms.

Ek sal dit so opsom:

  1. Mozilla is 'n niewinsorganisasie met waardes wat goed aansluit by die vind van goeie oplossings vir hierdie probleem.
  2. Die realiteit vandag is dat die meeste webwerwe vormgebaseerde verifikasie gebruik
  3. Vormgebaseerde verifikasie het 'n groot nadeel, wat 'n groter risiko van uitvissing.Gebruikers word gevra om sensitiewe inligting in 'n area in te voer wat deur 'n afgeleë entiteit beheer word, eerder as 'n area wat deur hul gebruikersagent (blaaier) beheer word.
  4. Aangesien blaaiers implisiet vertrou word (die hele idee van 'n gebruikersagent is om namens die gebruiker op te tree), kan hulle help om hierdie situasie te verbeter.
  5. Die primêre krag wat vordering hier terughou, is ontplooiing dooiepunt.Oplossings moet ontbind word in stappe wat op hul eie 'n mate van inkrementele voordeel bied.
  6. Die eenvoudigste gedesentraliseerde metode om 'n identiteit uit te druk wat in die internetinfrastruktuur ingebou is, is die domeinnaam.
  7. As 'n tweede vlak om identiteit uit te druk, bestuur elke domein sy eie stel rekeninge.
  8. Die vorm "rekening@domein" is bondig en ondersteun deur 'n wye reeks protokolle en URI-skemas.So 'n identifiseerder word natuurlik mees universeel erken as 'n e-posadres.
  9. E-posverskaffers is reeds die de facto primêre identiteitsverskaffers aanlyn.Huidige wagwoordterugstellingvloeie laat jou gewoonlik beheer oor 'n rekening neem as jy kan bewys dat jy daardie rekening se geassosieerde e-posadres beheer.
  10. Die Verified Email Protocol is voorgestel om 'n veilige metode, gebaseer op publieke sleutel kriptografie, te verskaf om die proses te stroomlyn om aan domein B te bewys dat jy 'n rekening op domein A het.
  11. Vir blaaiers wat nie die Verified Email Protocol ondersteun nie (tans almal), verskaf Mozilla 'n shim wat die protokol in kliënt-kant JavaScript-kode implementeer.
  12. Vir e-posdienste wat nie die Verified Email Protocol ondersteun nie, laat die protokol derde partye toe om as 'n betroubare tussenganger op te tree, wat beweer dat hulle 'n gebruiker se eienaarskap van 'n rekening geverifieer het.Dit is nie wenslik om 'n groot aantal sulke derde partye te hê nie;hierdie vermoë is slegs bedoel om 'n opgraderingspad toe te laat, en dit word baie verkies dat e-posdienste self hierdie stellings verskaf.
  13. Mozilla bied hul eie diens om soos so 'n betroubare derde party op te tree.Diensverskaffers (dit wil sê Vertroue Partye) wat die Verified Email Protocol implementeer, kan kies om Mozilla se bewerings te vertrou of nie.Mozilla se diens verifieer gebruikers se rekeningeienaarskap deur gebruik te maak van die konvensionele manier om 'n e-pos met 'n bevestigingskakel te stuur.
  14. Diensverskaffers kan natuurlik hierdie protokol as 'n opsie aanbied bykomend tot enige ander metode(s) van verifikasie wat hulle dalk wil aanbied.
  15. 'n Groot gebruikerskoppelvlakvoordeel wat hier gesoek word, is die "identiteitkieser".Wanneer 'n gebruiker 'n webwerf besoek en kies om te staaf, wys hul blaaier vir hulle 'n seleksie van e-posadresse ("persoonlik", "werk", "politieke aktivisme", ens.) wat hulle kan gebruik om hulself aan die webwerf te identifiseer.
  16. Nog 'n groot gebruikerskoppelvlakvoordeel wat as deel van hierdie poging gesoek word, is om die blaaier te help om meer oor die gebruiker se sessie te weet – hoofsaaklik as wie hulle tans aangemeld is – so dit kan dit in die blaaier-chroom vertoon.
  17. As gevolg van die verspreide aard van hierdie stelsel, vermy dit insluiting by groot webwerwe soos Facebook, Twitter, Google, ens.Enige individu kan hul eie domein besit en dus as hul eie identiteitsverskaffer optree.

Dit is nie streng "vorm-gebaseerde verifikasie vir webwerwe" nie.Maar dit is 'n poging om van die huidige norm van vormgebaseerde verifikasie na iets veiliger oor te gaan:blaaier-ondersteunde verifikasie.

Ek het net gedink ek sal hierdie oplossing deel wat ek gevind het dat dit goed werk.

Ek noem dit die Dummy Field (alhoewel ek dit nie uitgevind het nie, moenie my krediet gee nie).

In kort:jy moet dit net in jou <form> en maak seker dat dit leeg is by wanneer dit bekragtig word:

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

Die truuk is om 'n bot te flous om te dink dat dit data in 'n vereiste veld moet invoeg, daarom het ek die invoer "e-pos" genoem.As jy reeds 'n veld genaamd e-pos het wat jy gebruik, moet jy probeer om die dummy-veld iets anders te noem soos "maatskappy", "foon" of "e-posadres".Kies net iets wat jy weet jy nie nodig het nie en wat klink soos iets wat mense normaalweg logies sal vind om in 'n webvorm in te vul.Versteek nou die input veld met CSS of JavaScript/jQuery - wat ook al die beste by jou pas - net moenie stel die invoer in type aan hidden anders sal die bot nie daarvoor val nie.

Wanneer jy die vorm valideer (óf kliënt- of bedienerkant), kyk of jou dummy-veld ingevul is om te bepaal of dit deur 'n mens of 'n bot gestuur is.

Voorbeeld:

In die geval van 'n mens:Die gebruiker sal nie die dummy-veld sien nie (in my geval genaamd "e-pos") en sal nie probeer om dit in te vul nie.Die waarde van die dummy-veld behoort dus steeds leeg te wees wanneer die vorm gestuur is.

In die geval van 'n bot: Die bot sal 'n veld sien wie se tipe is text en 'n naam email (of wat dit ook al is wat jy dit genoem het) en sal logies probeer om dit met toepaslike data te vul.Dit gee nie om as jy die invoervorm met 'n paar fancy CSS gestileer het nie, webontwikkelaars doen dit heeltyd.Wat ook al die waarde in die dummy-veld is, ons gee nie om nie solank dit groter is as 0 karakters.

Ek het hierdie metode op 'n gasteboek gebruik in kombinasie met CAPTCHA, en ek het sedertdien nog nie 'n enkele strooiposplasing gesien nie.Ek het voorheen slegs 'n CAPTCHA-oplossing gebruik, maar uiteindelik het dit elke uur ongeveer vyf strooiposplasings tot gevolg gehad.Die byvoeging van die dummy-veld in die vorm het gestop (ten minste tot nou toe) al die strooipos om te verskyn.

Ek glo dit kan ook net goed gebruik word met 'n aanmeld-/verifikasievorm.

Waarskuwing:Natuurlik is hierdie metode nie 100% onfeilbaar nie.Bots kan geprogrammeer word om invoervelde met die styl te ignoreer display:none daarop toegepas.Jy moet ook dink aan mense wat een of ander vorm van outo-voltooiing gebruik (soos die meeste blaaiers ingebou het!) om alle vormvelde vir hulle outomaties in te vul.Hulle kan net sowel 'n dummy veld optel.

Jy kan dit ook 'n bietjie verander deur die dummy-veld sigbaar te laat, maar buite die grense van die skerm, maar dit is heeltemal aan jou.

Wees kreatief!

Ek dink nie die antwoord hierbo is "verkeerd" nie, maar daar is groot areas van verifikasie wat nie aangeraak word nie (of eerder die klem is op "hoe om koekiesessies te implementeer", nie op "watter opsies is beskikbaar en wat is die handel" -afs".

My voorgestelde wysigings/antwoorde is

  • Die probleem lê meer in rekeningopstelling as in wagwoordkontrolering.
  • Die gebruik van twee-faktor-verifikasie is baie veiliger as meer slim maniere van wagwoordenkripsie

  • Moenie probeer om u eie aanmeldvorm of databasisberging van wagwoorde te implementeer nie, tensy die data wat gestoor word, waarloos is by die skepping van rekening en selfgegenereer is (dit wil sê Web 2.0-styl soos Facebook, Flickr, ens.)

    1. Digest Authentication is 'n standaardgebaseerde benadering wat in alle groot blaaiers en bedieners ondersteun word, wat nie 'n wagwoord selfs oor 'n veilige kanaal sal stuur nie.

Dit vermy enige behoefte om "sessies" of koekies te hê, aangesien die blaaier self die kommunikasie elke keer sal herenkripteer.Dit is die mees "liggewig" ontwikkelingsbenadering.

Ek beveel dit egter nie aan nie, behalwe vir openbare, lae-waarde dienste.Dit is 'n probleem met sommige van die ander antwoorde hierbo - moenie 'n her-implementeer bediener-kant stawing meganismes probeer - hierdie probleem is opgelos en word ondersteun deur die meeste groot blaaiers.Moenie koekies gebruik nie.Moenie iets in jou eie handgerolde databasis stoor nie.Vra net, per versoek, as die versoek geverifieer is.Alles anders moet ondersteun word deur konfigurasie en derdeparty-betroubare sagteware.

So...

Eerstens verwar ons die aanvanklike skepping van 'n rekening (met 'n wagwoord) met die herkontrolering van die wagwoord daarna.As ek Flickr is en jou webwerf vir die eerste keer skep, het die nuwe gebruiker toegang tot nulwaarde (leë webruimte).Ek gee regtig nie om of die persoon wat die rekening skep oor hul naam lieg nie.As ek 'n rekening van die hospitaal se intranet/ekstranet skep, lê die waarde in al die mediese rekords, en so ek doen gee om oor die identiteit (*) van die rekeningskepper.

Dit is die baie baie moeilike deel.Die enigste ordentlike oplossing is 'n web van vertroue.Jy sluit byvoorbeeld as dokter by die hospitaal aan.Jy skep 'n webblad wat iewers gehuisves word met jou foto, jou paspoortnommer en 'n publieke sleutel, en hash hulle almal met die private sleutel.Jy besoek dan die hospitaal en die stelseladministrateur kyk na jou paspoort, kyk of die foto by jou pas, en hashes dan die webblad/foto-hash met die hospitaal se private sleutel.Van nou af kan ons sleutels en tokens veilig uitruil.Soos enige iemand wat die hospitaal vertrou (daar is die geheime sous BTW).Die stelseladministrateur kan jou ook 'n RSA dongle of ander twee-faktor-verifikasie.

Maar dit is 'n baie van 'n gesukkel, en nie baie web 2.0.Dit is egter die enigste veilige manier om nuwe rekeninge te skep wat toegang het tot waardevolle inligting wat nie self geskep is nie.

  1. Kerberos en SPNEGO - enkelaanmeldingmeganismes met 'n betroubare derde party - basies verifieer die gebruiker teen 'n betroubare derde party.(LW dit is nie op enige manier die nie te vertrou nie OAuth)

  2. SRP - soort van slim wagwoordverifikasie sonder 'n betroubare derde party.Maar hier kom ons in die gebied van "dit is veiliger om twee-faktor-verifikasie te gebruik, selfs al is dit duurder"

  3. SSL kliënt kant - gee die kliënte 'n publieke sleutel sertifikaat (ondersteuning in alle groot blaaiers - maar stel vrae oor kliënt masjien sekuriteit).

Op die ou end is dit 'n kompromis - wat is die koste van 'n sekuriteitskending teenoor die koste van die implementering van veiliger benaderings.Eendag sien ons dalk 'n behoorlike PKI wyd aanvaar en dus nie meer eie gerolde verifikasievorms en databasisse nie.Eendag...

Wanneer jy hash, moenie vinnige hash-algoritmes soos MD5 gebruik nie (baie hardeware-implementasies bestaan).Gebruik iets soos SHA-512.Vir wagwoorde is stadiger hashes beter.

Hoe vinniger jy hashes kan skep, hoe vinniger kan enige brute force checker werk.Stadiger hashes sal dus brute forsering vertraag.'n Stadige hash-algoritme sal brute forsering onprakties maak vir langer wagwoorde (8 syfers +)

'n Goeie artikel oor realistiese wagwoordsterkteskatting is:

Dropbox Tech Blog » Blog Argief » zxcvbn:realistiese wagwoordsterkteskatting

My gunsteling reël met betrekking tot verifikasiestelsels:gebruik wagwoordfrases, nie wagwoorde nie.Maklik om te onthou, moeilik om te kraak.Meer inligting: Koder gruwel:Wagwoorde vs.Slaagfrases

Ek wil graag een voorstel byvoeg wat ek gebruik het, gebaseer op verdediging in diepte.Jy hoef nie dieselfde bekragtiging-en-verifikasiestelsel vir admins as gewone gebruikers te hê nie.Jy kan 'n aparte aanmeldvorm op 'n aparte url hê wat aparte kode uitvoer vir versoeke wat hoë voorregte sal verleen.Hierdie een kan keuses maak wat 'n totale pyn vir gereelde gebruikers sal wees.Een so wat ek gebruik het, is om eintlik die aanmeld-URL vir admin-toegang deurmekaar te maak en die nuwe URL aan die admin te e-pos.Stop enige brute force-aanval dadelik aangesien jou nuwe URL arbitrêr moeilik kan wees (baie lang ewekansige string), maar jou admin gebruiker se enigste ongerief is om 'n skakel in hul e-pos te volg.Die aanvaller weet nie meer waarheen om eers te POST nie.

Ek weet nie of dit die beste was om dit as 'n antwoord of as 'n opmerking te beantwoord nie.Ek het die eerste opsie gekies.

Oor die poing DEEL IV:Vergete wagwoord funksionaliteit in die eerste antwoord sal ek 'n punt maak oor tydsberekening van aanvalle.

In die Onthou jou wagwoord vorms, kan 'n aanvaller moontlik 'n volledige lys e-posse nagaan en opspoor wat op die stelsel geregistreer is (sien skakel hieronder).

Met betrekking tot die Vergete Wagwoord-vorm, wil ek byvoeg dat dit 'n goeie idee is om gelyke tye tussen suksesvolle en onsuksesvolle navrae met een of ander vertragingsfunksie.

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

Ek wil graag een baie belangrike opmerking byvoeg:-

  • "In 'n korporatiewe, intra- netto-instelling," kan die meeste, indien nie al, die voorafgaande nie van toepassing wees nie!

Baie korporasies ontplooi "slegs interne gebruik" webwerwe wat effektief "korporatiewe toepassings" is wat toevallig deur URL's geïmplementeer is.Hierdie URL's kan (vermoedelik ...) slegs opgelos word binne "die maatskappy se interne netwerk." (Watter netwerk sluit op magiese wyse alle VPN-gekoppelde 'padkrygers' in.)

Wanneer 'n gebruiker pligsgetrou aan die voorgenoemde netwerk gekoppel is, hul identiteit ("stawing") is [reeds ...] "afdoende bekend," soos hulle toestemming is ("magtiging") om sekere dinge te doen ...soos ..."om toegang tot hierdie webwerf te kry."

Hierdie "verifikasie + magtiging" diens kan verskaf word deur verskeie verskillende tegnologieë, soos LDAP (Microsoft OpenDirectory), of Kerberos.

Vanuit jou oogpunt weet jy eenvoudig dit:daardie enigiemand wat wettiglik op jou webwerf beland moet vergesel word van ['n omgewing-veranderlike op 'n magiese manier ...] 'n "teken." (d.w.s. Die afwesigheid van so 'n teken moet onmiddellike redes wees 404 Not Found.)

Die waarde van die teken maak geen sin vir jou nie, maar, sou die behoefte ontstaan, "bestaan ​​toepaslike middele" waardeur jou webwerf "[gesaghebbend] iemand kan vra wat weet (LDAP...ens.)" oor enige en elke (!) vraag wat jy mag hê.Met ander woorde, jy doen nie maak gebruik van enige 'Tuis-gekweekte logika.' In plaas daarvan vra u die gesag en vertrou dit implisiet die uitspraak daarvan.

Uh huh ...dit is nogal 'n verstandelike skakelaar van die "wild-en-wolle internet."

Gebruik OpenID Connect of Gebruikerbestuurde toegang.

Aangesien niks meer doeltreffend is as om dit glad nie te doen nie.

Gelisensieer onder: CC-BY-SA met toeskrywing
Nie verbonde aan StackOverflow
scroll top