Bad, bad passwords

Pass­words are an aber­ra­tion. In a ide­al world, we wouldn't have pass­words, but only keys.

The con­cept of a pass­word as a se­cu­ri­ty mea­sure is flawed, and leads to mul­ti­ple is­sues. Among oth­ers:

1. When the pass­word is sent by the client to the serv­er, any man in the mid­dle can read it and use it.

2. Re­mem­ber­ing pass­words is not some­thing hu­mans are good at. This leads to se­cu­ri­ty through Post-its and short pass­words.

3. Gen­er­at­ing and han­dling good, se­cure pass­words is dif­fi­cult. It re­quires cryp­to­graph­i­cal­ly-se­cure pseu­do-ran­dom num­ber gen­er­a­tors, and spe­cif­ic soft­ware which can store them semi-se­cure­ly. Most pass­word man­agers are ex­treme­ly poor­ly made by peo­ple who have no ex­per­tise what­so­ev­er in se­cu­ri­ty or user ex­pe­ri­ence. This, in turn, means that few per­sons use such soft­ware, and the ones who use it may have a wrong sense of se­cu­ri­ty.

4. Val­i­da­tion of pass­words is not an easy task ei­ther, like shown by thou­sands and thou­sands of com­pro­mised web­sites, in­clud­ing very pop­u­lar ones. Al­though many frame­works made this task eas­i­er by hid­ing hash­ing and salt­ing log­ic un­der an in­ter­face with two meth­ods: one for stor­ing a pass­word, an­oth­er one for val­i­dat­ing it, there are still to many pro­gram­mers who be­lieve that stor­ing an MD5 of the pass­word is per­fect­ly fine.

5. Man­ag­ing pass­words for a com­pa­ny is also quite com­pli­cat­ed, which leads to pass­words reuse (how many times, work­ing as a free­lancer, did I have a root pass­word to the pro­duc­tion servers of my cus­tomers?!) and wrong life­time of pass­words (ei­ther reg­u­lar re­new­al, which is a wrong prac­tice, or no ex­pi­ra­tion for ac­counts which shouldn't be used any longer.)

This makes pass­words a flawed fea­ture, and a dan­ger­ous one. If there is one ad­vice I can give to some­one, it would be this one:

Don't use pass­words. Use keys in­stead.

Keys don't have many of the flaws pass­words have:

1. Since they are used to solve a chal­lenge, man in the mid­dle at­tack is prac­ti­cal­ly im­pos­si­ble.

2. One don't need to re­mem­ber a pri­vate key (and prob­a­bly couldn't).

3. Keys are gen­er­at­ed by an ap­pli­ca­tion any­way, with­out the al­ter­na­tive for hu­man-based gen­er­a­tion. Of course, some ap­pli­ca­tions are good at what they do, some are not.

4. Val­i­da­tion of keys is straight­for­ward. There is not much a pro­gram­mer can do as mis­take here.

5. If keys have an affin­i­ty with a ma­chine or a user, reuse be­comes im­pos­si­ble. Also, few net­work ad­min­is­tra­tors have the stu­pid­i­ty to re­new keys every 30 days. Ex­pi­ra­tion, how­ev­er, re­mains an is­sue.

Of course, there are cas­es where we can't rely on pri­vate/pub­lic key pairs, and so we must fall­back to pass­words, which leads to the dis­cus­sion about the pass­word poli­cies, what is se­cure and what isn't.

In my en­tire life, I've prob­a­bly seen a thou­sand of dif­fer­ent sys­tems which re­quire pass­words. I wouldn't be sur­prised if less than a dozen among them had a pol­i­cy which en­cour­ages se­cure pass­words. Most are com­plete­ly stu­pid. They en­cour­age se­cu­ri­ty by Post-its, or sim­ply force to use poor, easy to hack but dif­fi­cult to re­mem­ber pass­words.

Length

The length is a cru­cial as­pect of a pass­word. “1234” is not a se­cure pass­word, but nei­ther is “T30K”. For any sys­tem which should have at least some se­cu­ri­ty, min­i­mum length pol­i­cy should be en­forced.

Many sys­tems en­force the op­po­site: the max­i­mum length. While this is not in­her­ent­ly wrong, the max­i­mum val­ue they set is. A val­ue of 16 char­ac­ters seems to be par­tic­u­lar­ly pop­u­lar, and I have no idea why (and why not 15 or 20). I've equal­ly seen lim­i­ta­tions to a max­i­mum of 10, 8, or, in one case, 4 char­ac­ters.

Low max­i­mum lim­i­ta­tion has three neg­a­tive con­se­quences:

• When deal­ing with ran­dom­ly-gen­er­at­ed pass­words (which are of­ten from 20 to 50 char­ac­ters long), this lim­i­ta­tion is painful to deal with.

• The lim­it is usu­al­ly not con­sis­tent across the sys­tem. For ex­am­ple, for a long time, Mi­crosoft silent­ly lim­it­ed (trimmed) my pass­word to 16 char­ac­ters at some lo­ca­tions, but not on oth­ers, which means that when en­tered in forms where it was not trimmed, I was faced with a er­ror telling that my pass­word is in­valid. As a user, I'm not ex­pect­ed to know or care about the trim­ming.

• Com­bin­ing mul­ti­ple words to form a pass­word is im­pos­si­ble. “cor­rect horse bat­tery sta­ple” is 28 char­ac­ters long, and won't work with most sys­tems.

While it is un­der­stand­able that there should be some lim­i­ta­tion of the length, the val­ue should be rea­son­able. A max­i­mum length of 1 000 char­ac­ters seems a good com­pro­mise be­tween se­cu­ri­ty con­sid­er­a­tions and net­work band­width us­age. In prac­tice, I wouldn't blame a pro­gram­mer who lim­it­ed the length to 100 char­ac­ters, but I see no valid rea­son to set it low­er.

Char­ac­ters

Fifty years ago, there was ASCII. Since 1991, we have Uni­code stan­dard, and while its sup­port is still lim­it­ed with some tech­nolo­gies and lan­guages (such as PHP), it's quite well done in oth­ers (such as Python). How­ev­er, many pro­gram­mers be­lieve that they al­low char­ac­ters be­yond a sub­set of ASCII to en­ter the pass­words, bad things will im­me­di­ate­ly start to hap­pen.

This leads some pro­gram­mers to lim­it pass­words to cap­i­tal and small Latin let­ters, dig­its and a few sym­bols they are com­fort­able with. With more than six­ty pos­si­ble sym­bols to use, this is not that bad in terms of se­cu­ri­ty, but what about user ex­pe­ri­ence?

1. The ran­dom­ly gen­er­at­ed pass­words may not use the same char­ac­ters as the ones pro­gram­mers de­cid­ed to al­low.

2. Users may not be com­fort­able with those char­ac­ters; for in­stance, a Russ­ian user will nec­es­sar­i­ly be forced to switch to a dif­fer­ent key­board lay­out just to en­ter his pass­word.

3. Users need to read the stu­pid lim­i­ta­tions and to ap­ply them when cre­at­ing or chang­ing their pass­words. The fact that vi­su­al­ly iden­ti­fy­ing which char­ac­ters are al­lowed and which are not is not par­tic­u­lar­ly easy makes the sit­u­a­tion even worse.

“This isn't a great deal”—a pro­gram­mer could re­ply. Well, it is. Im­pact­ing user ex­pe­ri­ence should al­ways be a great deal, but some­times, it is nec­es­sary for tech­ni­cal or fi­nan­cial rea­sons. Here, the worst thing is that there are no tech­ni­cal or fi­nan­cial rea­sons what­so­ev­er. Even worse, you're wast­ing mon­ey to de­fine a com­pli­cat­ed lim­i­ta­tion for al­lowed or de­nied char­ac­ters, when you may do it much sim­pler.

In Uni­code, there are three pos­si­ble prob­lems with pass­words.

1. Con­trol char­ac­ters are ex­treme­ly prob­lem­at­ic, since dif­fer­ent sys­tems will be­have dif­fer­ent­ly when han­dling them. Don't al­low those char­ac­ters for pass­words. Nev­er. No­tice that this lim­i­ta­tion doesn't im­pact most users: I can hard­ly imag­ine a le­git­i­mate user en­ter­ing a con­trol char­ac­ter in a pass­word field in his brows­er. The only case when there is a neg­a­tive im­pact is when the au­then­ti­ca­tion is per­formed by a ma­chine which ac­tu­al­ly sends a bi­na­ry stream of data, and don't care if there are con­trol char­ac­ters or the zero byte.

2. Nor­mal­iza­tion could be an­oth­er prob­lem, but it's ac­tu­al­ly very easy to solve. In Uni­code, char­ac­ters can be nor­mal­ized dif­fer­ent­ly. An ac­cent­ed let­ter can be writ­ten as a sin­gle char­ac­ter—that is an ac­cent­ed let­ter it­self, or an ac­cent fol­lowed by a let­ter, or a let­ter fol­lowed by an ac­cent. Vi­su­al­ly, there will be no dif­fer­ence for the user. How­ev­er, the hash of dif­fer­ent rep­re­sen­ta­tions of the same string will be dif­fer­ent, which means that your sys­tem may end up telling to the user that the pass­word is in­valid, while the pass­word he ac­tu­al­ly en­tered is per­fect­ly cor­rect for a hu­man.

   The prob­lem is eas­i­ly solved by ap­ply­ing a spe­cif­ic and con­sis­tent nor­mal­iza­tion be­fore hash­ing a pass­word. This is pure­ly a tech­ni­cal is­sue, and most lan­guages and frame­works have enough sup­port to make it easy.

3. Spe­cial Uni­code char­ac­ters like the ones which can­not be dis­played on some sys­tems are prob­lem­at­ic in user names or oth­er el­e­ments which are dis­played pub­licly. When it comes to pass­words, they are nev­er dis­played, which means that the prob­lem is ir­rel­e­vant here. Even in a case of pass­word re­set pro­ce­dure, it's the new­ly gen­er­at­ed pass­word which is sent by email, not the old one.

Aside those cas­es, any oth­er char­ac­ter should be au­tho­rized. Why couldn't a Chi­nese guy write his pass­word in Chi­nese? Why should a per­son from Greece switch the key­board lay­out to en­ter a pass­word us­ing sym­bols she may not even be used to? And es­pe­cial­ly, why low­er­ing the se­cu­ri­ty of pass­words with no tech­ni­cal ben­e­fit what­so­ev­er?

Ex­pi­ra­tion

There is one fun­da­men­tal rule when it comes to pass­word se­cu­ri­ty:

Pass­words should not ex­pire on sched­ule.

Users shouldn't be forced to change their pass­word every 30 days. Nor every 90 days. Nor every 365 days.

Au­to­mat­ic pass­word ex­pi­ra­tion sucks. It en­cour­ages users to write their pass­words on a Post-it, or in a plain text file. It makes users hate their sys­tem ad­min­is­tra­tor, and hate the sys­tem which forces them to change their pass­words. Please, don't force poor se­cu­ri­ty prac­tices just be­cause you can.

There are ab­solute­ly no rea­sons for forc­ing a pass­word to ex­pire au­to­mat­i­cal­ly. If you think it is a way to pre­vent brute force (and if you're re­al­ly that des­per­ate that this is the only thing you have to pre­vent brute force), then you should set pass­words to ex­pire every two min­utes, be­cause of­ten, brute force is as fast as a few min­utes. Rare are hack­ers who will spend a month brute-forc­ing a pass­word (and se­ri­ous­ly, if you are ad­min­is­ter­ing a sys­tem where some­body can stay un­no­ticed while brute-forc­ing an ac­count for a month, con­sid­er search­ing for a job which is bet­ter suit­ed for you).

Stor­age

Stor­ing and val­i­dat­ing pass­words is a tricky task. It re­quires a sol­id un­der­stand­ing of the sub­ject (no, no, com­put­ing an MD5 hash of a pass­word is not the right ap­proach!), and re­quires a large amount of code to be writ­ten and thought­ful­ly test­ed.

A bet­ter ap­proach is to let some­one else, some­one more ex­pe­ri­enced than you, man­age the pass­words. Luck­i­ly, with OAuth and OpenID, this ap­proach is not only pos­si­ble, but also easy to im­ple­ment.

For prac­ti­cal­ly every ap­pli­ca­tion at Pel­i­can De­sign & De­vel­op­ment, the only au­then­ti­ca­tion mech­a­nism is through OAuth 2 with Google as provider. This means a lot of things:

• I don't have to write and test all the source code re­lat­ed to pass­words salt­ing and hash­ing, to brute force at­tacks, to pass­word re­set pro­ce­dure, to de­vice-based au­then­ti­ca­tion, etc. Google does that, and I'm pret­ty sure it does that much bet­ter than I could do it.

• I don't store pass­words, not even in a salt­ed and hashed form. This makes my in­fra­struc­ture less in­ter­est­ing for an at­tack­er.

• I don't even re­ceive pass­words from the users. If an at­tack­er com­pro­mis­es a ma­chine and finds a way to mon­i­tor every­thing which comes in, he still won't get the pass­words.

• I don't pay for send­ing SMS mes­sages for cus­tomers who want ad­di­tion­al safe­ty with de­vice-based au­then­ti­ca­tion. Google pays that.

• Google han­dles all the cook­ie stuff, re­mem­ber­ing pass­words on client side in or­der to bring bet­ter user ex­pe­ri­ence to my cus­tomers, in or­der for them to avoid en­ter­ing their pass­word too of­ten. All that for free. Thank you, Google.

Del­e­gat­ing pass­words val­i­da­tion and man­age­ment to an­oth­er en­ti­ty is es­sen­tial: not only does it in­crease se­cu­ri­ty, but it de­creas­es tremen­dous­ly the mon­ey and time wast­ed han­dling this part of the ap­pli­ca­tion.

More pass­words don't in­crease se­cu­ri­ty

Some com­pa­nies are forc­ing users to en­ter mul­ti­ple pass­words through mul­ti­ple sys­tems in or­der to ac­cess the in­ter­nal re­sources. By ask­ing for more pass­words, they hope that they will in­crease se­cu­ri­ty.

This is a wrong ap­proach, and a harm­ful one, since it gives a wrong sense of se­cu­ri­ty.

How pass­words can be com­pro­mised?

• The sys­tem it­self can be.
• The user may have a key­log­ger in­stalled.
• The man in the mid­dle can mon­i­tor the traf­fic.
• Some­body can gain ac­cess to the user's ma­chine or of­fice and get the pass­words stored by the brows­er or writ­ten on Post-its.

Ex­cept the first case, hav­ing two pass­words in­stead of one have ab­solute­ly no ef­fect. On the oth­er hand, its neg­a­tive im­pact on user ex­pe­ri­ence is very im­por­tant.

Don't force the user to en­ter mul­ti­ple pass­words to ac­cess a re­source. If pass­word-based se­cu­ri­ty is not enough (and as I pre­vi­ous­ly ex­plained, it's not), you should use de­vice-based au­then­ti­ca­tion ad­di­tion­al­ly to a pass­word. A com­mon form is to send an SMS to a per­son af­ter he en­ters a pass­word, the mes­sage con­tain­ing a short code the user should en­ter on the web­site.

For­bid­ding past­ing pass­word is a ter­ri­ble idea

In some cas­es, Re­mote Desk­top con­nec­tion re­quires the user to type a pass­word in­stead of copy-past­ing it. This is a ter­ri­ble idea, which is un­for­tu­nate­ly used on some web­sites as well.

When a pass­word is copy-past­ed, the user may use long, com­pli­cat­ed pass­words. If the user is forced to en­ter the pass­word re­peat­ed­ly by hand, he will switch to a short pass­word (and if the sys­tem makes it manda­to­ry to use dig­its and sym­bols, it will also mean a very short and very poor pass­word as well).

What makes sense is to for­bid copy­ing a pass­word, es­pe­cial­ly in a “type pass­word”/“re­type the same pass­word” sce­nario, in or­der to mit­i­gate the risk for the user to make a ty­po¹.

Con­clu­sion

Those are a few pieces of ad­vice about pass­words. The most im­por­tant point is to avoid pass­words by re­plac­ing them by pub­lic/pri­vate key pairs or by let­ting an­oth­er en­ti­ty, such as Google, han­dle pass­words for you. If both are tru­ly im­pos­si­ble (which should be the case of, say, 0.1% of the sys­tems we use dai­ly), com­mon sense dic­tates to avoid low­er­ing se­cu­ri­ty by set­ting ar­bi­trary and tech­ni­cal­ly un­wise rules: con­strain­ing the max­i­mum length or the char­ac­ters or set­ting sched­uled ex­pi­ra­tion.

It should be not­ed that with a sane pol­i­cy which doesn't try to an­noy the users, the users them­selves may be more in­clined to use se­cure pass­words. Some may need help to for­get about their past bad ex­pe­ri­ences which pushed them to use Post-it pass­words such as “d@ta8asE” in­stead of easy to re­mem­ber, fast to type, er­ror prone and dif­fi­cult to crack pass­words such as “завтра разбирать развалины!”. In all cas­es, when it comes to pass­words, users should be helped and trained, in­stead of forced: there is noth­ing worse than fac­ing a “Your pass­word is not se­cure enough” mes­sage for an ob­vi­ous­ly se­cure pass­word².

An es­sen­tial as­pect is to train users to use pass­word man­agers. In an ide­al world, they would have only one pass­word and every­thing else will rely on it through a pro­to­col sim­i­lar to OAuth. In a real world, users are tempt­ed to reuse pass­words and since they type them by hand, they are also in­clined to use short pass­words. A pass­word man­ag­er can help by en­cour­ag­ing pseu­do-ran­dom­ly gen­er­at­ed, cryp­to­graph­i­cal­ly se­cure pass­words con­tain­ing a few dozens of char­ac­ters which can then be copy-past­ed.

If you're still forced to build your own au­then­ti­ca­tion sys­tem, make sure you read those an­swers as well:

• Why do cer­tain sites pre­vent spaces in pass­words?

• What best prac­tices should be em­ployed in a PHP lo­gin script?

^{¹ It should be not­ed that I have a doubt about the ef­fec­tive­ness of this ap­proach. Ad­di­tion­al­ly, re­set­ing a pass­word shouldn't be a great deal.}

^{² This was ac­tu­al­ly the er­ror mes­sage I got from Skype con­cern­ing my ran­dom­ly gen­er­at­ed ac­count con­tain­ing 23 to 25 char­ac­ters with small and cap­i­tal Latin and Greek let­ters, dig­its, sym­bols. Such stu­pid­i­ty is sim­ply ridicu­lous and pa­thet­ic from a prod­uct de­vel­oped by such a large com­pa­ny.}