Üksikut parooli ei pruugi iseenesest kontrollida. Täpsemalt, kui server teeb asju korralikult, siis ei salvesta see paroole ise, vaid parooli arvutatud parooli räsimisfunktsiooni väljundit. Parooli räsimisfunktsioon (erinevalt pelgalt räsifunktsioonist) sisaldab mõningaid lisafunktsioone, sealhulgas soola (väga headel turvalisusega seotud põhjustel). Parooli kontrollimiseks on vaja teada vastavat soola. Kuna sool on eksemplarispetsiifiline (soola mõte on see, et erinevatel kasutajatel on oma soolad), on vajalik kasutaja identiteet (soola indekseerimisvõtmena kasutatakse kasutajatunnust).

Ühest küljest ei tea server, kas ainult parool ühildub mõne kontoga.

Turvalises süsteemis soolatakse paroolid ja seejärel räsitakse.

Lihtsustatud demo korral Oletame, et mul oli kolm kasutajat:

  kasutajanimi Passwordbob foobaralice foobarmaggie foobar  

Kui need paroolid on määratud, lisatakse sool ja genereeritakse räsi:

  Kasutajanimi Salt väärtus et hash resultbob ABCDEF ABCDEFfoobar 778f9aab91717e420e447d7e4cdd84f1alice 123456 123456foobar 17e9191daecc5b8be26779209769b275maggie ZXCVBN ZXCVBNfoobar 527cb07b112559cf9c1aff19d28074fa  

Nagu näete, eesmärk soola on see, et kaks paroole salvestatakse samamoodi, kuigi parool võib sobida. See on oluline turvasamm, et vältida vikerkaarte tabelite kasutamist ekstraktitud parooliloendis.

See muudab võimatuks kindlaks teha, millisele kontole logitakse ainult parooli alusel, sest sool kasutamine pole teada. Seda seetõttu, et kasutajanime kasutatakse otsingu võtmena ja ilma seda serverile edastamata ei saa esimeses etapis sisestatud parooli sobitada ilma kasutaja tabelis iga räsi proovimata, kuni vaste on leitud. Korralikult konfigureeritud süsteemis oleks see liiga aeglane, kuna kasutate aeglast algoritmi (vt joonealust märkust).

Samuti oleks see tohutu turvateabe leke, kui süsteem ütleks teile, et teie parooli kasutatakse mida teine ​​kasutab.

_{Ülaltoodud näide on ainult illustratiivne ja kasutab MD5. Ärge kunagi kasutage MD5 paroolide räsimiseks - kasutage bcrypt, scrypt või pbkdf2.}

Kas te põhimõtteliselt ei küsi: "Kas meil on mingeid põhjuseid, miks meil pole avalikke paroole ja privaatseid kasutajanimesid?"

Need mõlemad on lihtsalt tekstistringid. Teie idee unikaalsete paroolide kasutuselevõtuks ütleb tõesti, et kasutajanimed on kordumatud. Tekstikastile kleebitav silt ei oma tähtsust. Kutsume privaatset stringi parooliks ja kordumatut kasutajanimeks või kasutajatunnuseks kuna see on ainulaadne.

Turvaliselt ja vaadates seda tavalises sisselogimise / parooli järjekorras : Kui vajate, et mõlemad oleksid ainulaadsed, avaksite andmebaasi rünnaku, sest iga kontrollitud parooli kontrollitakse kõigi andmebaasis olevate kasutajate suhtes kuna olete nõudnud, et teie paroolid oleksid ainulaadsed . Nii et mõlemad unikaalsed ei tööta. Mõlemad unikaalsed ei tööta, kuna te ei tea, millisele kontole juurde pääsete. Nii et jääb vaid üks ainulaadne string. Kui teete ühe ainulaadse tekstistringi, võib sama hästi teha selle avalikuks andmeteks ja kontrollida seda kõigepealt (ja me nimetame neid andmeid Logi sisse / ID / Kasutajanimi).

Kujutame ette analoogiat ...

Olen sõnumitooja, kelle mu kuningas saatis teatavaks kindluse losside orus lossis. Ma tean, milline näeb välja loss, kuhu ma minna tahan, ja mulle anti parool, mis tuli valvurile öelda, et mind saaks lossi lasta.

Mul on kaks võimalust, kuidas seda teha:

1. Nagu te kahtlemata arvate, on selleks tavapärane viis sõita lossi, kuhu mind saadeti, ja seejärel öelda neile sissepääsuparool. Seda kasutatakse kõigepealt minu avalik teave (loss, nähtav kõigile, kes seda vaadata tahavad), et sisse logida minu privaatsete andmetega (parool).

2. Kuid on ka vastupidine viis tee seda. Võin saada sarve ja karjuda oma parooli kogu orus, et avalikkus seda kuulaks. Kuna kindlus, mida kavatsen külastada, on kuulnud minu parooli (koos kõigi teiste losside ja potentsiaalselt alatute oru elanikega), peaks minu külastatav loss mind teadma.

   Seejärel jätkan hobusega õige lossi juurde ja sõitke üle selle avatud tõstesilla. Kuid nad laseksid kõik selle avatud tõstesilla kaudu sisse! Nüüd, kui minu privaatset teavet on maailmale jagatud, saavad kõik losside vahel sõita ja siseneda avatud väravaga majja.

   Kui ma pole siin, et seda ise sarveks karjuda, siis oru elanikud võisid seista oma sarvega mäe otsas ja hüüdsid üle oru kolinat, kuni kuulsid tõstesilla avanemist; teades, et nad arvasid parooli õigesti, peavad nad lihtsalt losside vahel sõitma, kuni leiavad selle lahti.

Esimene võimalus on see, kuidas seda tavaliselt tehakse. Pole mingit põhjust seda konventsiooni muuta. Alternatiiv on võimalik, kuid kõigepealt jagades oma privaatset teavet, on teil enne avaliku teabega autentimist, st igasse lossi sõitmist või kogu avalikkuse proovimist, palju lihtsam ära arvata kõigi korraga parool. konto nimed. Kuna selles orus on tuhandeid losse või on veebisaidil kontosid, arvab keegi tõenäoliselt lihtsa parooli ära ja siis on palju lihtsam seda lihtsalt ühildada mõne tuhande lossi või avaliku konto nimega.

Google ei lase teil turvalisuse huvides kõigepealt oma e-posti sisestada. Selle peate sisestama oma e-posti aadressi / kasutajanime, nii et kui logite sisse töö- või haridusdomeeni, mis soovib saada SSO / SAML-i jaoks oma sihtlehte

Kui küsite kõigepealt parooli, peate mõnes olekus kasutajanime ootamise ajal säilitama väärtuse "saladus". Veebirakenduse puhul peate tavaliselt selle salvestusruumi mingil viisil tegema, et uus protsess saaks väärtust lugeda, kuna kasutajanimi tuleks sisse teise taotluse korral. See suurendab paroolistringi avalikustamise võimaluse akent nii aja kui ka andmete juurde jõudmise võimaluste osas.

Kui küsite kõigepealt kasutajanime, tuleb paroolikinnitus kasutada soolatud räsimist. (või mitte) saab parooli viivitamatuks kinnitamiseks juba juurdepääsu kõigele vajalikule ja süsteemil peab olema parool ise minimaalseks ajaks saadaval. Parim on, kui tundlikud andmed oleksid saadaval võimalikult vähe aega.

Ja see on tavapärane. Kõigepealt parooli küsides koolitate kasutajaid parooli kogemata mujale kasutajanimeväljadele sisestama, mille tulemuseks on tõenäoliselt logide kaudu avaldamine.

Ärge tehke seda. :)

Lisamiseks; rakenduse arendamisel otsustatakse tuvastamise vs autentimise / kinnitamise mehhanism. Identifitseerimine on 1: palju , kontrollimine / autentimine on 1: 1

  1: 1 - vaste ühele eelnevalt valitud tulemuste komplektile; 1: palju - sobib kõigi DB-s leiduvate tulemustega  

Kasutajanimed nagu gmail on ainulaadsed. See ei ole kõigi rakenduste jaoks kohustuslik, kuid see muudab verifitseerimisalgoritmi elu vastupidiseks identifitseerimisalgoritmile kindlasti lihtsamaks.

Kaaluge populaarse kasutajanime ja seejärel parooli autentimist gmaili jaoks:

1. sisestage kasutajanimi;

   gmail ühtib ainulaadse kasutajanimega kõik ülejäänud kordumatud kasutajanimed; Jah sobib, sisestage parool; Vastet pole, juurdepääsu pole.

2. Sisestage parool.

   gmail sobib lihtsalt 1 kasutajanimega 1 ükskõik millises vormingus salvestatud parooliga; Vastet pole, autentimine nurjus. Jah, sobi, pääse oma meilidele juurde.

Päris sirgjooneline IMHO.

Teise poole võtmine, tuvastamine (1: palju), sobitamisprotsess gmail oleks selline:

1. sisestage parool; ja nagu @SilverlightFox selgelt osutas, võib paljudel kontodel olla sama parool.

     sobitusalgoritm sobib parooliga KÕIKI gmaili andmebaasis registreeritud kasutajanimedega.  

   Liiga konservatiivne tulemuste komplekt võib olla 10 kasutajanime.

2. Sisestage kasutajanimi;

Kas kasutajanimed on unikaalsed või võivad olla samad, otsustab, kui palju rohkem aega autentimisprotsess kestab ja mitu vastet leitakse. Kui sobib rohkem kui 1, peame rakendama kolmeastmelise sisselogimise autentimise.

Kaheastmeline autentimine muudab arendaja ja algoritmi elu lihtsamaks.

Google'i ja enamiku jagatud autentimise seadistuste korral kasutab süsteem põhimõtteliselt kasutaja ID-d, et tuvastada seotud risk ja määrata sobiv sisselogimisprotsess, mida see peaks kasutaja jaoks käivitama.

Juhul enamikus neist olukordadest on inimese sisestatud kasutajatunnus vaid üks sisend, mida kaalutakse. Koos sellega edastatakse riskide kindlaksmääramise mootorile (enamikus pankades) palju muud teavet (näiteks IP-aadress, kust te juurde pääsete, seade, mida kasutaja kasutab - koos kasutaja ID-ga on loodud ja edastatud seadme allkiri). kuid ei pruugi alati kasutada), mis võib pakkuda soovitatud sisselogimisprotsessi. Lisaks sellele kontrollib süsteem kasutajaga seotud sisselogimispoliitikat (st kas sellel on näiteks lubatud mitmeteguriline funktsioon). Lõpliku kindlakstegemise põhjal võite enamasti saada lihtsalt lihtsa parooliekraani, kuid mõnel juhul võidakse teil paluda minna mitme autentimise protsessi (nt telefonipõhine OTP jne).