Banker, der udsteder numeriske brugernavne, er ret irriterende. Og mens jeg er mere paranoid end de fleste, har du sandsynligvis ret i, at nogen bare fik fingre med deres ID og ikke klar over det, før de låste dig ude.

For at besvare spørgsmålet hjælper nogle banker med at sikre, at du forsøger at logge ind med den rigtige brugerkonto. Disse "sikkerhedsbilleder", du ser på nogle bankloginsider, ja bankerne fortæller dig, at disse billeder hjælper dig med at sikre, at du logger ind på deres hjemmeside. Men den virkelige fordel er at hjælpe brugerne med at indse, at de forsøger at logge ind på en andens konto. Websteder, der bruger denne proces, beder om dit brugernavn på hovedsiden til login og fører dig derefter til en ny side med dit 'sikkerhedsbillede' og adgangskodefeltet. De kan også bede om en anden form for godkendelse (sikkerhedsspørgsmål osv.), Før de beder om adgangskoden, hvis du logger ind fra en computer, de ikke har set dig logge ind fra før.

Hvis hver gang du logger ind, ser du det billede, du valgte ved tilmelding, er det mere sandsynligt (forudsat at du bruger webstedet ofte nok) til at bemærke, når billedet er anderledes. Dette kan betyde, at du logger ind på et phishing-websted, men mere sandsynligt har du fedt fingret på brugerkontoen.

REDIGER: - For at besvare din redigering -

Når du beskæftiger dig med numeriske bruger-id'er, er der kun 10 cifre, og de er proppet i et meget lille område på 10-taster og mobile enheder. I betragtning af mange titusinder (eller hundreder) tusinder brugere, manglen på cifre, og hvor tæt de er i to af de tre almindelige layouter, er der virkelig ingen måde at sikre tilstrækkeligt, at et ID er forskelligt nok fra et andet til at forhindre almindelige forkert indtastningsfejl .

Hvis du også tænker over det fra et præstationssynspunkt, er det en meget effektiv og hurtig proces at finde ud af, om et nyt ID er uniq, i de mest veldesignede systemer. At opdage, om et nyt ID er anderledes end andre, kræver dog iterering over hvert andet bruger-id og sammenligning af de to med hvad din algoritme er. Dette ville være en (relativt) langsom og smertefuld proces. Med nok tid og kræfter kan du cache ngrams og andre sammenligningspunkter for at hjælpe med at fremskynde det, men det vil stadig være langsomt.

Kort sagt, jeg er ikke opmærksom på, at nogen virksomhed gør dette på bruger-id'er, bestemt ikke på numeriske. (Men jeg vil med glæde læse en hvidbog eller ingeniørblog om nogen, der gør det)

Et par andre brugere (inklusive Philipp) har nævnt kontrolsifre, som jeg ikke diskuterede, da jeg oprindeligt fokuserede på det systemets side og de forskellige brugernavne fokuserer på spørgsmålet. Men i yderligere tanke har det en plads i denne samtale. Kontrolsummer bruges ofte til at forøge kontonumre, dvs. kreditkortnumre, som enhver programmeringsstuderende i første semester kan skrive et valideringsværktøj til. Dette eliminerer alt andet end forkert indtastning og kan kontrolleres på klientsiden uden at blive sendt til indtastningsformularen. Det er umuligt at sige (uden intern viden) om nogen bruger dette på numeriske brugerkonti ... Jeg ville vove mig at nogen er det, men jeg har ikke set det, og da det ikke ville gøre det interessant diskussion (eller dokumentation) inden for samfundet, har ikke hørt om nogen, der gør det. Jeg tror, ​​vi alle kan være enige, det er din bank ikke. :)

You could generate the passcode by taking a consecutive number and append one or more additional digits to it which are a checksum of the actual number. You can check the validity of a passcode on the client-side by checking if the checksum-digits entered by the user match the actual part of the passcode.

One checksum-digit reduces the chance to accidentally enter a valid passcode of another user to one in ten, two to one in hundred and three to one in thousand.

The downside, however, is that the longer the passcode, the harder it is to memorize, which will in turn lead to people forgetting their passcodes and again consume human resources to recover it. That means that the designer of the system has to find the right balance between inconveniences generated by people entering passcodes of other people and people forgetting their passcodes.

De forhindrede et angreb på din konto. Dette er et ønsket resultat - havde de været i stand til at prøve ubegrænsede adgangskoder, ville de have gættet din. Angrebet blev stoppet i tide og kostede dig en mindre besvær. Hvis dette mønster blev gentaget for alvorligt at generer dig, kan banken blot udstede en ny tilfældig adgangskode.

De er ikke lige så interesserede i at forhindre billige ulemper som at forhindre dyre svindel.

EDIT :

Problemet med et tilfældigt tildelt 8-cifret nummer er, at du sandsynligvis ikke vil huske det, hvis du ikke behøver at bruge det regelmæssigt. Hvordan kan du huske, om dit nummer er 82640927 eller 82604927?

Noget, der længe har været brugt til at reducere skrivefejl, er Luhn-kontrolcifret algoritme. Det validerer nummeret og beder systemet om at bede en bruger om at indtaste nummeret igen, hvis et ciffer er forkert, eller hvis et par cifre ved et uheld transponeres. Kreditkort har brugt dette i årtier. Men Luhn-algoritmen forhindrer ikke alle utilsigtede problemer eller stopper bevidste forsøg.

Den bedste måde at reducere utilsigtede kollisioner er at øge det potentielle antal plads og tilfældigt tildele brugere på tværs af nummerområdet. Blot at have 10 cifrede tal stopper ikke kollisioner, hvis brugerne er nummereret 0000000001, 0000000002, 0000000003, ... En måde at opnå dette på er at bruge et sekventielt frø og derefter føde det ind i en hash-algoritme til at producere det ti-cifrede nummer at tage et usigneret int af de fire nederste byte er en måde at opnå dette på.) Det er tilstrækkeligt tilfældigt, at to tal ikke har et forhold til hinanden, hvilket gør utilsigtede typografier virkelig få og langt imellem. Et Luhn-ciffer kan også tjene som en høflighedskontrol for at hjælpe brugeren med ikke at spilde tid på at indtaste et kodeord på et åbenlyst defekt kontonummer.

Webtjenester kan tage hensyn til placeringen af, hvor login-anmodninger stammer fra, og korrelere med dine tidligere log-in-forsøg. Svarende til hvordan kreditkortselskaber kontakter dig, når de bemærker "usædvanlig aktivitet" på dit kreditkort. Dette er et stykke logik, som en organisation, der leverer en tjeneste på nettet, kan bruge til at tackle hændelser som denne. Hvis de med stor tillid kan sige, at det brugernavn, der er knyttet til forbindelsen, ikke er dig - kan de tage skridt til at isolere disse begivenheder fra at påvirke den rigtige konto.

I dit tilfælde kan banken have logik programmeret eller analytiker udlede, om personen, der forsøger at logge ind med dit konto-id, var fra det samme område som dig - eller hvis de er sikre på, at det var et helt andet geografisk område.

En anden rute, der kunne hjælpe give dem et billede ville være de logfiler, der er tilgængelige for dem fra begivenheden. Det lyder som om den kundeservicemedarbejder, du talte, ikke havde adgang til de nævnte logfiler - og sandsynligvis ikke ville have haft ekspertisen til at se dem. Selv hvis de gjorde det - hvis de skal sige, at applikationen logger disse oplysninger ordentligt? Vil de endda ønske det? Hvor mange mennesker ville så have adgang til disse oplysninger?

Forhåndslogik i disse situationer kan hurtigt blive vanskelig. Hvordan din bank i dette tilfælde håndterede det lyder som det mest enkle og billigste svar for alle involverede. Hvis den eneste forstyrrelse for dig i tjeneste var et 5-minutters telefonopkald med din bank - er det en meget ringe måde at tackle en potentielt høj skadesituation på.

Der er en nøglefordel ved et tildelt brugernavn eller en adgangskode - det er normalt mere tilfældigt, end en bruger ville generere. For et numerisk brugernavn med kun 8 tegn er der 100 millioner (10 ^ 8) mulige permutationer. Dette er mindre end 1/3 af befolkningen i USA og omkring 1/2 befolkningen i Indonesien. Så denne metode ville bestemt ikke skalere sig ud over det antal internetbankbrugere.

Ja, det betyder, at brugernavne er let at gætte - en angriber skal bare gentage gennem 8-cifrede tal. Selvfølgelig skulle man være meget heldig at brute sig ind på en konto med høj nettoværdi på denne måde.

Men som du oplevede, kan den samme aktivitet let bruges til at udføre en benægtelse af Service angreb. Gæt bare tilfældigt adgangskoden N gange pr. Brugernavn i hurtig rækkefølge (hvor N er antallet af forsøg, der kræves for at udløse en kontolås). Om et par timer bliver banken nødt til at telefon-verificere hver online-bankkunde, og deres call-center vil blive overvældet.

Løsningen er at udvide brugernavnet tegnsæt. Ved også at tillade store og små bogstaver udvides antallet af permutationer til 218 billioner ((26 + 26 + 10) ^ 8), hvilket i høj grad reducerer effektiviteten af ​​ovennævnte denial of service-angreb samt utilsigtede kollisioner som den du oplevet.

Ulempen er, at brugernavne bliver mere komplekse for brugerne at huske og indtaste. Dette kan delvis afhjælpes ved at give brugerne mulighed for at vælge brugernavne. Og ulempen ved det er noget tab af tilfældighed.

En ting, som nogle websteder, som Google, ser ud til at gøre for at forhindre denne type angreb, er at efter en vis mængde loginforsøg ikke låse dig ude, men give dig noget, der kaldes CAPTCHA. Dette bruges mere til at forhindre botlogins, men det sænker også en ondsindet menneskelig bruger, da han / hun stadig skal finde ud af adgangskoden, og nogle CAPTCHA'er er hårde. Det kan også være en ulempe for en legitim bruger, men når du får en CAPTCHA på disse websteder, er det sandsynligt, at du ikke kan huske din adgangskode.

En anden ting, som nogle websteder ser ud til at gøre, er at låse et brugernavn midlertidigt, ikke permanent. For eksempel låste mit 2-årige kollegis websted dig ude i 15 minutter, da du indtastede den forkerte adgangskode 3 gange, derefter yderligere 5 kumulative ekstra for hvert nye adgangskodeforsøg, før låsen er op. Mange Android-telefons skærmlåse gør det også. Denne metode kunne tillade DOS-angreb, da den ondsindede bruger kunne prøve så mange forsøg, at den sande bruger faktisk aldrig ville være i stand til at logge ind igen, selvom at kæde tidsfristen til specifikke IP'er, cookies osv. Kunne afbøde dette under hensyntagen til, at IP'er kan spoofes.

Begge disse metoder fungerer mere for at afskrække bots end ondsindede menneskelige brugere, men de sænker menneskelige brugere, mens de ikke låser kontoen permanent for den legitime bruger i tilfælde af ulykker. Jeg er ikke sikker på, hvor godt hver metode fungerer for banker, da de er meget mere paranoid end for eksempel Google. Også de fleste af de websteder, jeg har set disse på brugte brugerdefinerede brugernavne, men jeg antager, at de også vil fungere for bankspecificerede numeriske brugernavne.