Ett ensamt lösenord kan inte nödvändigtvis verifieras av sig självt. I synnerhet om servern gör saker ordentligt lagrar den inte själva lösenorden utan utdata från en lösenordshashfunktion beräknad över lösenordet. En lösenordshash-funktion (i motsats till enbart hash-funktion) innehåller några extra funktioner, inklusive ett salt (av mycket goda säkerhetsrelaterade skäl). För att verifiera ett lösenord krävs sedan kunskap om motsvarande salt. Eftersom saltet är instansspecifikt (poängen med saltet är att distinkta användare har sina egna salter) krävs användaridentiteten (användaridentiteten används som en indexeringsnyckel för saltet).

För det första skulle servern inte veta om lösenordet ensam matchade några konton.

I ett säkert system saltas lösenorden och hashas sedan.

I en förenklad demo, antar att jag hade tre användare:

  Användarnamn Lösenordbob foobaralice foobarmaggie foobar  

När dessa lösenord är inställda tillsätts ett salt och en hash genereras:

  Användarnamn salt värde till hash hash resultbob ABCDEF ABCDEFfoobar 778f9aab91717e420e447d7e4cdd84f1alice 123456 123456foobar 17e9191daecc5b8be26779209769b275maggie ZXCVBN ZXCVBNfoobar 527cb07b112559cf9c1aff19d28074fa  

som du kan se, är syftet med salt som det inte finns två lösenord lagras samma, även om lösenordet kan matcha. Detta är ett viktigt säkerhetssteg att ta för att förhindra att regnbågstabeller används i en extraherad lösenordslista.

Detta gör det omöjligt att avgöra vilket konto som loggas in på grundval av enbart lösenordet, eftersom saltet till användningen är inte känd. Detta beror på att användarnamn används som en nyckel för uppslaget, och utan att det ges till servern kan lösenordet som anges i steg ett inte matchas utan att försöka varje hash i användartabellen förrän en matchning hittas. På ett korrekt konfigurerat system skulle detta vara för långsamt eftersom du använder en långsam algoritm (se fotnot).

Det skulle också vara en massiv säkerhetsinformationsläcka om systemet berättar att ditt lösenord håller på används av en annan.

_{Exemplet ovan är endast avsett att illustrera och använder MD5. Använd aldrig MD5 för att hash lösenord - använd bcrypt, scrypt eller pbkdf2.}

Frågar du inte i princip "Finns det någon anledning att vi inte har offentliga lösenord och privata användarnamn?"

De är båda bara textsträngar. Din idé att genomdriva unika lösenord är egentligen bara att säga att användarnamn är unika. Etiketten du applicerar på en textruta spelar ingen roll. Vi kallar strängen som är privat ett lösenord och den unika ett användarnamn eller användar-ID eftersom det är unikt.

Säkerhetsmässigt och tittar på det i normal ordning för inloggning / lösenord : Om du krävde att båda skulle vara unika, skulle du öppna en attack mot databasen, för varje kontrollerat lösenord skulle kontrolleras mot alla användare i databasen eftersom du har krävt att dina lösenord ska vara unika . Så båda unika fungerar inte. Båda icke-unika fungerar inte eftersom du inte vet vilket konto som nås. Så det lämnar bara en unik sträng. Om du skapar en enda unik textsträng kan du lika gärna göra den till en offentlig datablad och kontrollera det först (och vi kallar dessa data Login / ID / Användarnamn).

Låt oss föreställa oss en analogi ...

Jag är en budbärare som skickas av min kung för att leverera ett meddelande till ett visst slott i Slottdalen. Jag vet hur slottet jag vill gå till ser ut och jag fick en lösenfras för att berätta för vakten så att jag kunde släppas in i slottet.

Jag har två alternativ för hur man gör detta:

1. Som du utan tvekan förväntar dig är det konventionella sättet att göra detta att åka till slottet som jag skickades till och sedan berätta för lösenfrasen som ska släppas in. Detta används först min offentliga information (slottet, synligt för alla som vill titta på det) för att logga in med min privata information (lösenfrasen).

2. Men det finns en omvänd väg att gör det här. Jag kan få ett horn och ropa min lösenfras över hela dalen för allmänheten att lyssna på. Eftersom slottet som jag tänker besöka har hört min lösenfras (tillsammans med alla andra slott och de potentiellt skadliga invånarna i dalen), bör slottet jag besöker veta att förvänta mig.

   Jag fortsätter sedan till häst till rätt slott och åka över dess öppna vindbrygga. Men de skulle släppa in någon genom denna öppna vindbro! Nu när min privata information har delats med världen kan vem som helst åka mellan slotten och gå in i den med den öppna porten.

   Om jag inte är här för att skrika detta i ett horn, dalbo kunde stå på toppen av en kulle med sitt eget horn och skrika gnisslande över dalen tills de hör dammet av en vindbrygga öppnas; de vet att de gissade en lösenfras korrekt, de måste helt enkelt åka mellan slottet tills de hittar en som är öppen.

Det första alternativet är hur det vanligtvis görs. Det finns ingen anledning att ändra den konventionen. Alternativet är möjligt, men genom att dela din privata information först gör du det mycket lättare att gissa lösenordet för alla på en gång innan du autentiserar med offentlig information, dvs åker till varje slott eller försöker hela allmänheten kontonamn. Med tusentals slott i den här dalen eller konton på en webbplats är det troligt att någon gissar ett enkelt lösenord och då är det mycket lättare att helt enkelt matcha det med ett av få tusen slott eller offentliga kontonamn.

Google behöver inte ange din e-post först av säkerhetsskäl. Du måste ange ditt e-post / användarnamn så om du loggar in på en arbets- eller utbildningsdomän som vill ha en egen målsida för SSO / SAML

Om du först ber om lösenordet måste du behålla det "hemliga" värdet i något tillstånd medan du väntar på användarnamnet. Med en webbapp skulle du vanligtvis behöva göra den lagringen på något sätt så att en ny process kan läsa värdet, eftersom användarnamnet skulle komma in på en andra begäran. Det ökar möjligheten för lösenordssträngen att avslöjas, både när det gäller tid och när det gäller sätt att komma till data.

Genom att först fråga användarnamnet, lösenordsverifiering som använder saltad hashing (eller inte) kan redan ha tillgång till allt som krävs för att verifiera lösenordet omedelbart, och systemet behöver bara ha lösenordet tillgängligt under en minimal tid. Det är i allmänhet bäst att ha känslig data tillgänglig så kort tid som möjligt.

Och det är konventionen. Genom att först be om lösenord kommer du att träna användare att av misstag skriva sitt lösenord i användarnamnfält någon annanstans, vilket troligen kommer att avslöjas genom loggar.

Gör inte det. :)

För att lägga till; mekanismen för identifiering vs autentisering / verifiering bestäms när applikationen utvecklas. Identifiering är 1: många , verifiering / autentisering är 1: 1

  1: 1 - matcha mot en för vald resultatuppsättning; 1: många - matchar mot alla resultat i DB  

Användarnamn som gmail är unika. Detta är inte obligatoriskt för alla applikationer, men det gör livet lättare för verifieringsalgoritmen i motsats till identifieringsalgoritmen.

Tänk på det populära användarnamnet och sedan autentisering av lösenord för gmail:

1. ange användarnamnet;

   gmail matchar det unika användarnamnet och alla andra unika användarnamn; Ja matcha, ange lösenord; Ingen matchning, ingen åtkomst.

2. Ange lösenord.

   gmail matchar bara 1 användarnamn med 1 lösenord lagrat i vilket format som helst; Ingen matchning, autentisering misslyckades. Ja matcha, få tillgång till din post.

Ganska enkelt IMHO.

Tar den andra sidan, identifiering (1: många), matchningsprocessen av gmail skulle vara så här:

1. ange lösenord; och som @SilverlightFox tydligt indikerar kan många konton ha samma lösenord.

     matchande algoritm matchar lösenordet till ALLA användarnamn registrerade i gmail-databasen.  

   En för konservativ resultatuppsättning kan vara tio användarnamn.

2. Ange användarnamn;

Huruvida användarnamnen är unika eller kan vara desamma, avgör hur mycket mer tid som autentiseringsprocessen kommer att köras och hur många matchningar som hittas. Om fler än 1 matchar måste vi implementera inloggningsautentisering i tre steg.

Tvåstegsautentisering gör livet enklare för utvecklaren och algoritmen.

I händelse av google och större delen av inställningen för delad autentisering använder systemet i princip användar-id för att identifiera risken och bestämma lämplig inloggningsprocess som den ska köras för användaren.

Om i de flesta av dessa situationer är användar-ID som anges av person bara en ingång som övervägs. Tillsammans med den skickas en hel del annan information (som IP-adress där du kommer åt, enhet som användaren använder - det finns en enhetssignatur som genereras och skickas tillsammans med användar-id) till en riskbestämningsmotor (i de flesta bankerna men kan inte alltid användas) vilket kan ge en föreslagen inloggningsprocess. Utöver det kontrollerar systemet inloggningspolicyn som är associerad med användaren (dvs. om det till exempel har flera faktorer aktiverat). Baserat på slutgiltig bestämning kan du för det mesta bara få en enkel lösenordsskärm men i vissa fall kan du bli ombedd att gå till flera autentiseringsprocesser (t.ex. telefonbaserad OTP, etc.).