Password ponderings

Password tanker

Long passwords are more secure than short ones, but if they are too long people write them down, so find the happy medium.
Bad advice

Lange passwords er sikrere end korte, men bliver de for lange så skriver folk dem ned, så find en gylden middelvej.
Dårligt råd

Give passwords as short an expiration as the users will accept. The more frequently they are changed, the better. That is really the only defense against password leaks.
Bad advice

Giv passwords så kort udløbstid som brugerne vil være med til. Jo oftere de skiftes jo bedre. Det er reelt det eneste forsvar der er mod password læk.
Dårligt råd

If the password does not contain both uppercase and lowercase letters, and special characters, it is too easy to guess.
Bad advice

Hvis passwordet ikke indholder både store og små bogstaver, og specialtegn, så er det for nemt at gætte.
Dårligt råd

I have looked at password security for more than ten years, and I blinded myself staring at that type of advice.

Jeg har set på password sikkerhed i mere end ti år, og jeg stirrede mig blind på den slags råd.

How long should they be, those passwords? Can we base the number on research instead of imitating what others do? Et cetera, et cetera.

Hvor lange skal de være, de passwords? Kan vi basere tallet på undersøgelser istedet for at lægge os op ad hvad andre har valgt? Og så videre, og så videre.

It is easy to get caught up in the logic around those advices. It is not that the they are wrong. They are really not. But their relevance has just eroded away.

Det er nemt at blive fanget af logikken omkring de råd. Det er ikke det at de er forkerte. For det er de egentlig ikke. Men deres relevans er bare rustet bort.

Heres the thing: We humans have a limited bandwidth when we prove our identity.

Her er problemet: Vi mennesker har en begrænset båndbredde når vi beviser vores identitet.

Because we want our authentication to be both fast and repeatable, it is limited how many data we can generate. That means that the set of all the possible data is relatively small. So small that a computer fairly easily can break a human password by using brute force with some optimizations.

Da vi gerne vil have at vores authentikering er både hurtig og gentagelig, betyder det at det er begrænset hvor mange data vi kan generere. Det betyder at mængden af alle de mulige data er forholdsvis lille. Så lille at en computer ret nemt kan bryde et menneskeligt password ved hjælp af brute-force plus nogle optimeringer.

By breaking the password I mean to break the encryption or hashing of the password.

Når jeg skriver at bryde et password mener jeg at bryde dets kryptering eller hashing.

You should never save an unencrypted password, but instead a hash of the password. A password check is then done by hashing it and comparing it to its saved hash. Hashing like this is done by a cryptographically strong hash function. Just a fancy name for a one-way function.

Man bør aldrig gemme et ukrypteret password, men istedet en hash af passwordet. Et password tjek klares så ved først at hashe det og så sammenligne det med dets gemte hash værdi. Denne slags hashing gøres med en kryptografisk stærk hash funktion. Det er bare et smart navn for en envejsfunktion.

The problem is that it is feasible with the computing power, that is within reach of most people, to basically test out all possible passwords, and that way "invert" the one-way function.

Problemet er at det er muligt med den regnekraft, som er indenfor de flestes rækkevidde, at teste alle de mulige passwords, og på denne måde "invertere" envejsfunktionen.

There is a nice trick to avoid this kind of inverting. Use a computationally heavy hash function. A simple hash function like a modern SHA, is lightingly fast to compute. But if your hash function is this SHA iterated 100,000 times, then the computation power required is noticeable, and brute-forcing becomes non-trivial. Unfortunately it also affects yourself, so this is only used in setups where it is the users own device that do the hashing. It is only used for password-protected documents as far as I know.

Der er et fint trick til at undgå denne slags invertering. Brug en beregningsmæssigt tung hash funktion. En simpel hash funktion, som en moderne SHA, er lynhurtig at regne ud. Men hvis din hash funktion er denne SHA itereret 100.000 gange, så koster den noget mærkbar regnekraft, og den er svær at brute-force. Dette rammer lige så vel én selv, så man bruger kun dette trick i setups hvor det er brugerens egen enhed der udregner hashes. Så vidt jeg ved kun til password beskyttede dokumenter.

There are more tricks. They are less compelling. You can pull one bad trick after another up of your hat, but it is a loosing battle. The scale of the task plus the computing power available equals a defacto inverse function for password hashes.

Der er andre tricks. De er mindre overbevisende. Du kan trække det ene sløje trick efter det andet op af hatten, men kampen er tabt på forhånd. Opgavens størrelse plus den tilgængelige regnekraft er lig med en defacto invers funktion for password hashes.

The basic problem is the small set of data that we can generate, as mentioned above. When I realized that, I saw what should have been clear all along.

Det grundlæggende problem er den føromtalte lille mængde af data vi kan generere. Da jeg nåede til denne erkendelse, indså jeg hvad der burde have været indlysende hele tiden.

Passwords are shared secrets.

Passwords er shared secrets.

The best security comes from sharing them with as few as possible. Of course, as everyone knows, with so few people as possible. But also, what every security architect should take note of, with so few machines as possible.

Den bedste sikkerhed fåes ved at dele dem med så få som muligt. Selvfølgelig, som alle ved, med så få personer som muligt. Men desuden, hvad især en sikkerheds arkitekt bør forstå, med så få maskiner som muligt.

Ideally the only machine that sees your password should be the one you use to enter it.

Ideelt set skal den eneste maskine der ser dit password være den du indtaster det på.

Minimize password spread.

Minimér password spredning.

Use this as your guideline when you design or purchase solutions. Then you will avoid a lot of attack vectors.

Brug dette som rettesnor når du designer eller køber løsninger. Så undgår du en lang række angrebsvektorer.

Note by the way, that solutions designed this way inherently solve many of the issues that the classical password advices are about. If you nevertheless set up enforcements in line with the classical password advices, it actually can hurt the security. Because you get the disadvantages without getting the advantages.

Bemærk iøvrigt at løsninger designet på denne måde automatisk løser mange af de problemer som de klassiske password råd handler om. Hvis du alligevel sætter politikker ud fra de klassiske password råd, kan det faktisk være negativt for sikkerheden. Fordi du får ulemperne uden at få fordelene.

Relateret:
Black bokse til sikkerhed
Online password tester