Systemet som beskrivs i frågan är faktiskt svagare än att bara kräva ett enda lösenord med längden A + B + C, eftersom det tillåter en klass av attacker som inte kan användas mot enstaka lösenord:

Säg att din kombination av tre lösenord är EFG . En angripare kan skicka lösenorden ABCDEFG , vilket gör fem attacker ( ABC , BCD , CDE , DEF och EFG ) till priset av två. Den allmänna termen för detta är en de Bruijn-sekvens, och den låter dig attackera alla statliga system (som ett digitalt lås) med mycket färre försök än det finns möjliga kombinationer.

Ur ett rått säkerhetsperspektiv är ditt lösenord helt enkelt "A B C", och lösenordets relativa styrka beräknas därefter.

Ur ett användarperspektiv är det förmodligen för svårt att vara användbart. Servern ger ingen indikation på det aktuella läget (letar det efter det andra lösenordet än?) Och därför kan användaren inte säga vilket lösenord som ska tillhandahållas.

Ur ett försvarsperspektiv finns det lite värde här. Lösenordsattacker blir lite mer komplicerade att genomföra och befintligt attackverktyg måste skrivas om för att tillgodose detta konstiga system. Det kan vara tillräckligt för att övertyga en angripare att gå vidare, men om du är ett viktigt mål så hjälper det inte alls.

Jag kommer att ta upp några punkter här.

För det första, antar att angriparen inte vet att lösenordsschemat är ett dåligt antagande, och du ' korrekta att det är säkerhet genom dunkelhet. Om varje användare kan lära sig detta inloggningsschema kan angriparen också. På grund av detta är banan inte bättre än om det bara fanns ett enda lösenord ABC.

Du kanske tänker, "Om du inte har fler lösenord ökar antalet brute force gissningar exponentiellt? " Svaret är nej. Tänk på ett alfabet med längden z och tre lösenord längden a , b och c . Antalet möjliga lösenord för var och en är z^a , z^b och z ^c . Om du ska prova alla möjliga värden för varje lösenord i alla möjliga ordningar, behöver du z ^en * z ^b * z^c gissningar, vilket är lika med z ^{(a + b + c)} . Det händer precis att längden på det enskilda lösenordet ABC är a + b + c , så antalet gissningar krävs också z ^{(a + b + c)} .

Det finns också designproblemet att användarna kommer att förvirras och / eller frustreras av detta system, särskilt om de har problem med att komma ihåg sina lösenord. Människor har tillräckligt med problem med att komma ihåg ett lösenord för varje webbplats de besöker (och det är därför många återanvänder lösenord). Tre lösenord skulle vara ännu svårare att komma ihåg, och jag skulle inte bli förvånad om några av dina användare använde samma sträng för alla tre.

Kräver tre formulärinlämningar för att logga in kommer säkert att sakta ner en brute force-attack, men du kan lika enkelt uppnå det genom att lägga till en fördröjning i verifiering av lösenord på serversidan.

Det är säkerhet genom dunkelhet - om allmänt antagen kommer angripare bara att försöka tre gånger. Vid vilken tidpunkt kan du lika gärna ha ett enda lösenord men ställa in en längre minimilösenordslängd för att säkerställa att det är så länge som tre separata lösenord sammanfogas.

Det går inte att skilja från ditt lösenord genom att helt enkelt vara A || B || C .

Tvåfaktorsautentisering är mer användarvänlig men ändå säkrare.

Utan, en lösenordet är fortfarande knappast mindre säkert än lösenordsslag.

En angripare som kan hitta ditt lösenord kommer sannolikt också att ta reda på ditt knackningsschema.

Att välja att knacka är som att välja en algoritm. Tänk på det som offentligt .

Även om lösenord är säkerhet av dunkel kan de mycket enkelt ersättas av helt andra.

Som sagt, det finns scheman som liknar din knackning, men lite mer användbar:

• Slumpmässigt begär en av flera hemligheter (lösenord, fraser, iTANs...).
  Det här är mycket snabbare än att ange alla hemligheterna, och är säkrare eftersom angriparen bara lär känna en hemlighet i taget (som kan ogiltigförklaras efter användning).
  Chanserna för angriparen kan autentisera korrelerar med det relativa antalet hemligheter de känner. Ändå kräver det att användaren känner till alla hemligheter och deras ordning .

• Ingångstiming , dvs analysera tiderna mellan och för alla lösenord tecken medan användaren skriver.
  Det här är svårare att ta reda på och förfalska än att knacka och har undersökts några gånger IIRC. Nackdelar:

  • Timing varierar något varje gång en användare anger lösenordet, även om det fortfarande kan räcka för att särskilja användare
  • Tidpunkten kan till och med ändras helt när användaren väljer att ange den annorlunda, t.ex. under inledningsfasen efter att ha valt lösenordet (användaren lär sig fortfarande att ange lösenordet), eller när de inte kan ange det som de brukar göra (skador, hålla en smörgås i ena handen ...)

Säkerhet genom dunkelhet är bra när du snabbt kan ändra ditt dunkelschema , dvs " ändra labyrinten "med liten ansträngning , snarare än betongen som dess väggar är gjorda av (se till att labyrinten inte kan kringgås ).

Begreppet hamnbankning gäller egentligen inte direkt för inloggning på webbplatser. Åtminstone inte i den mening som du har föreslagit. Med portknackning ansluter du till olika portar i en viss ordning för att öppna önskad port. I ditt exempel lägger du in alla lösenord på en webbplats. Som andra har påpekat skiljer sig detta egentligen inte från att sätta ihop alla lösenord. Om inte alla lösenord du använder är mycket långa, kan du lika gärna sammanfoga dem och använda ett lösenord. Oklarheten i denna metod är inte heller så användbar, eftersom någon måste bygga den och någon måste veta hur man använder den, vilket räcker för att en angripare ska få reda på hur den fungerar. Du förklarade det precis för världen.

I stället kan du kanske använda olika webbplatser för att representera olika portar. Låt oss säga att du försöker logga in på webbplats D. När du ansluter till webbplats D kommer den inte ens att visa en sida om den inte ser att du har loggat in på webbplatserna A, B och C, korrekt och i den ordningen. På det här sättet skulle angriparen inte bara behöva knäcka de olika lösenorden utan de måste göras på tre olika webbplatser och användas i rätt ordning för att till och med komma åt webbplats D, där ett annat lösenord skulle krävas.

Detta förlitar sig fortfarande på en viss oklarhet, men det skiljer sig mer från att bara dela upp ett lösenord på en webbplats.

Positiva>

• Det skulle lura vanliga brute-force-attacker. Automatiserade attacker från botnät eller enkla verktyg fungerar inte direkt.
• Det kan vara möjligt att lura en keylogger på det här sättet. I loggarna skulle det se ut som om användaren kom ihåg lösenordet vid tredje försöket. Om angriparen använder det här lösenordet fungerar det inte. Men bara om han inte vet eller gissar vad som händer. Men han äger dig ändå i det här fallet.
• Användaren tvingas använda flera ord => längre lösenord.

Negativ

• För komplicerat för en normal användare.
• Liksom portknackning är det delvis säkerhet genom dunkelhet. Om angriparen vet att han kan anpassa attacken.

Totalt

Som att slå på porten tillför det bara en liten fördel mot enkla attacker. Den största fördelen skulle vara längre lösenord och som lättare kan genomföras är lösenordsregler.

Hur som helst, om dina användare inte har något emot det är det något du kan göra. I slutändan räknas varje säkerhetsfunktion. Men jag skulle inte råd att göra det.

Bara en anmärkning: denna metod används redan i lösenordåterställning -scheman i vissa delar av branschen. Om du glömmer ditt lösenord kan du använda din e-postadress för att starta en sekvens av personliga frågor för att återställa ditt lösenord (men många gånger är det bara en fråga). Det görs mer välsmakande för användaren genom att vanligtvis begränsa sammanhanget till en sekvens av väl valda frågor som ger användaren en möjlighet att använda (förhoppningsvis) hemliga men välkända svar.

Också några av de bättre bankerna ger ytterligare en uppsättning säkerhetsfrågor om de inte känner igen den dator du loggar in från (i samma riktning som det ovan nämnda schemat för lösenordsåterställning).

Till exempel:

  Ange ditt lösenord: ***** Din dator känns inte igen, svara på följande ytterligare frågor: Vilken stad växte din mamma upp i? *********Vilken är din favoritfilm? *************  

Detta kan göra det möjligt för smarta användare att ge ganska obskyra svar på en rad frågor som de väljer, samtidigt som det gör det enkelt att komma ihåg sekvensen av "lösenord". Naturligtvis kan vanliga användare fortfarande använda enkla att gissa svar på frågorna "okänd dator", men det har alltid varit användaren att tillhandahålla bra lösenord.

PROS : Detta system delar vissa fördelar med tvåfaktorautentisering.

1) De flesta webbläsare och lösenordsbesparingssystem stöder inte det , så kommer bara att komma ihåg ett av lösenorden högst. Så det kommer åtminstone inte att lagras i klartext någonstans.

2) Personer som använder samma lösenord överallt måste använda minst två lösenord som inte delas med andra webbplatser.

Nackdelar : Systemet är dock totalt sett bristfälligt, och jag skulle hävda att det är värre än autentisering av ett lösenord.

1) Eftersom deras föredragna, lösenordsskyddade lösenordsförvaringssystem som de använder för de viktigare lösenorden kan inte användas, oddsen är att de använder något mindre bra för det här lösenordet. Post-it, textfil, vad som helst.

2) Andra har hävdat att detta är lika starkt som lösenordet "ABC". Det är det inte. Jag skulle säga att i värsta fall är det bara lika starkt som lösenordet "A".

Detta beror på att jag (och den typiska användaren) skulle använda lösenorden "lösenord 1", "lösenord2", "password3" Detta lösenordsgenereringssystem ger mig fördelen att jag kan ctrl-c, ctrl-v lösenordet och sedan bara skriva numret.

Om jag inte kan använda liknande lösenord har du minskat räckvidden av möjliga lösenord som jag kan ha: snarare än så säkert som ABC, har du nu bara samma säkerhet som ABD där A! = B! = C: du har gjort crackerjobbet enklare genom att minska deras sökdomän.

Och jag skulle ändå välja vilken förutsägbar sekvens som lösenordsinmatningsskriptet tillät: "Jan", "Feb", "Mar" kanske.

Och eftersom jag skulle använda en naturlig sekvens , det här är troligtvis den ordning som en lösenordssmällare skulle ha i ordboken, så en lösenordssprickningsmaskin kommer naturligtvis att försöka lösenorden i rätt ordning och gå direkt in. Alla smällare som känner till ditt system absolut skulle beställa deras ordlista på detta sätt.

3) Den andra faktorn som minskar säkerheten är att du måste ändra tre olika fält för att ändra lösenordet. Detta skulle avskräcka många från att ändra sina lösenord.

4) Detta är hemskt, hemskt användarupplevelse, som andra har noterat. Om du inte har en intern publik (anställda, studenter osv.) Förlorar du anpassningen genom detta användarvänliga tillvägagångssätt.

Som andra har sagt, motsvarar detta bara att ha ett lösenord som motsvarar A \ nB \ nC eller liknande. Det finns dock en fördel som jag kan tänka mig med detta schema: det hjälper till att minska saker av nätfiske; om ett system accepterar det första lösenordet istället för att acceptera de andra, vet du att systemet är äventyrat och helt enkelt loggar in ditt användarnamn och lösenord.

Men i så fall är det bättre att bara försöka logga in med en slumpmässigt lösenord innan du försöker logga in med ditt faktiska lösenord; annars har du precis äventyrat en hel del av ditt lösenord eftersom nu den första tredjedelen (ungefär) har loggats av det komprometterade systemet.

Jag tror inte att det är ens säkerhet genom dunkelhet som vissa har sagt - de tre lösenordsinloggningarna presenteras offentligt, nej? Visst att det tar lite arbete att justera några verktyg, men inget för svårt.

När det gäller brute-force-komplexiteten. Antalet möjligheter är detsamma som att ha ett enda lösenord med längd A + B + C . Så av den anledningen är det enda defensiva du får med detta schema att frustrera angriparen till en början. Dessutom, om systemet blev vanligt, skulle standardverktyg snabbt anpassa sig.

Som många har nämnt, för dedikerade attackändamål, är det inget starkare och inte lättare / svårare att komma ihåg än en sammankoppling av lösenord. Det finns dock något operationssäkerhets (OPSEC) -värde som är oberoende av lösenordsstyrka. Inte mycket värde, kom ihåg, men som någon som tillbringar mycket tid på Worldbuilding Stack Exchange-webbplatsen sprang min fantasi vild.

Tänk om du vill att en tjänst inte ska endast begränsas till auktoriserade användare, men du vill förhindra att någon av misstag snubblar på dess existens. Detta är inte längre ett enkelt entropiproblem, utan snarare ett spion-mot-spion-informationsteori-problem. Ditt jobb är nu att minimera signal-brus-förhållandet (SNR) för alla som tittar över din lösenordsinmatning. Detta är nu inte relaterat till lösenordsstyrka.

En metod skulle vara att ställa in ett falskt beteende. Låt det se ut som om det är en inloggning för ett annat system. Endast konton med rätt behörighet omdirigeras till det meningsfulla innehållet. Du kan till och med låta andra anmäla dig till ditt dummyprojekt för att låta folk peka runt och tillfredsställa deras nyfikenhet.

Vi pratar emellertid spion-mot-spion nu. Någon kommer att inse att James Bond verkligen inte är så intresserad av ett forum som diskuterar de senaste trenderna inom gummiandar, och börja prysa. James Bond är bra på att inte avslöja information, men vid något tillfälle, med en pistol som hålls mot hans [senaste] flickväns huvud, kommer det att bli misstänksam om han inte avslöjar sitt gummi-ducky-forum-lösenord för Dr. Dr. NoGood är ingen dåre; han tar reda på det.

Så vi satte upp James med två lösenord. Den ena släpper in honom i sitt vanliga gummiduckforum, det andra in i den topphemliga kärnmissilsimulatorn. Vi kan inte ignorera lösenordssäkerheten i verkligheten här. Hans lösenord för kärnmissilsimulator kommer att behöva vara långt: så länge som sammankopplingen av dina tre lösenord. Hans lösenord är förmodligen kortare. Bra också, för någon har sett honom logga in på sitt ducky-konto tidigare. De vet hur många karaktärer som ska starta brute-forcing. Vi vill inte att de av misstag ska hitta det säkra lösenordet innan vi hittar den där snygga.

Så med tanke på att det fortfarande är hemligt att missilsimulatorn finns, kommer det förhoppningsvis att avskräcka att "ogiltigt lösenord" återlämnas brute-forcers från att fortsätta. Dessutom kan du göra en enorm klimatupplevelse när James "skriver in sitt lösenord fel två gånger" innan väggen bredvid honom plötsligt smyger upp för att avslöja valvet bortom.

"Ju färre rörliga delar, desto mindre går det att gå fel."

Förutom att inte ge någon anmärkningsvärd fördel är denna idé mer komplex att implementera än ett enda lösenord. Som sådan finns det fler punkter med potentiellt misslyckande. Till exempel ...

Beroende på hur den implementerades kan det tillåta en förnekandeattack där Malcolm skickar lösenord X med jämna mellanrum. Om han gör det rätt så att han avbryter ett legitimt försök, mottar systemet A X B C och nekar dig inresa. På samma sätt, om han gånger skickar lösenord C direkt efter att du har skickat A B, låter systemet honom komma in och inte du.

En svarstimingattack kan kanske räkna ut att A var det rätta första lösenordet i A B C där det inte skulle märka att D var prefixet för enlösenord DEF.

För att lägga till alla andra fantastiska svar, skulle denna typ av lösenordsskydd inte ge något skydd mot keyloggers eller man i mitten attacker. Eftersom du fortfarande skulle lägga ditt lösenord i en sekvens kan keyloggerna spela upp dina handlingar och ändå få auktorisering. 2-faktor autentisering som föreslås av @Archimedix skulle vara det mest effektiva sättet att mildra detta.

Som andra har nämnt, är det funktionellt samma som ett långt lösenord. För att göra implementeringen mindre förvirrande kan den implementeras genom att fråga alla tre lösenorden på samma skärm.

Något i den här riktningen görs av min online-mäklare där den ber om medlemslösenordet och handelslösenordet under inloggningen. Vi måste få båda lösenorden rätt för att logga in. Dessutom måste jag ändra mitt medlemslösenord var tionde dag eller så och det finns regler om att inte upprepa de tre föregående lösenorden etc.

Min bank ( ICICI Bank) som tidigare implementerats två lösenord, ett för visning för att anges för att logga in och få tillgång till information, och ett annat för transaktion för att registreras när som helst en åtgärd som skulle resultera i en finansiell transaktion utfördes. Mitt Visa-betalkort är också säkrat av ett system de kallar 3-D Secure där de, oberoende av betalningsportalen, tar mig till sin egen webbplats för att ange ett lösenord för att slutföra transaktionen. Jag vet att detta är den äkta Visa-webbplatsen, för de låter mig anpassa meddelandet som ska visas.

Så idén är inte utan motstycke, men inte implementerad på exakt samma sätt som du säger. Att lägga till flera lösenord är något som åtminstone bankirer och aktiemäklare verkar övertygade om.

Stoppa värdelös teknisk komplexitet

Enligt ett tidigare korrekt svar är

  A \ nB \ nC  

ungefär samma som

  ABC  

(eller kanske lättare, angående @ Marks svar, om Bruijn-sekvensen ).

Därifrån, om du verkligen behöver hålla din hemlighet:

1. Använd standardverktyg som är starkt testade ett tag. (Om du inte är säker, föredrar du att dela och fråga runt istället för att använda någon form av dunkel.)

2. Håll dem uppdaterade.

3. Lär dina användare om lösenfraser (se xkcd: Password Strength och diskutera om IS)

4. Tänk på att social engineering (på Wikipedia) är det första ​​strong> sättet för säkerhetsfel. (En annan känd xkcd: Säkerhet).

5. Övervaka ditt system och kontrollera dina loggar.