From pass­words to passkeys: Mak­ing authen­ti­ca­tion better

Let’s face it — every­body hates pass­words. The main rea­son may be that they are no longer fit for pur­pose. But how did we get here? And how can we make it bet­ter? 

The incep­tion of pass­word-based authen­ti­ca­tion is wide­ly asso­ci­at­ed with the intro­duc­tion of the first gen­er­al-pur­pose time-shar­ing oper­at­ing sys­tem (CTSS) in 1961. 

With CTSS, mul­ti­ple users could share a sin­gle com­put­er sys­tem, each with their own pri­vate files. To pro­tect access to per­son­al files, the idea of cre­at­ing a mas­ter doc­u­ment where user­names were asso­ci­at­ed with pass­words seemed easy to imple­ment and secure enough for its purpose. 

Soon enough, the vul­ner­a­bil­i­ty of hav­ing a mas­ter doc­u­ment con­tain­ing all user cre­den­tials in plain text became appar­ent. Skilled users could bypass secu­ri­ty to access it, and sys­tem admin­is­tra­tors or those with access to back­ups could eas­i­ly read or cre­ate copies of the file with unvet­ted access. 

To address these secu­ri­ty con­cerns, a new method for stor­ing and val­i­dat­ing cre­den­tials was devel­oped with the arrival of the Unix oper­at­ing sys­tem. Instead of keep­ing pass­words in plain text, an encrypt­ed ver­sion would be stored in the mas­ter file. When a user entered their cre­den­tials, the pass­word was imme­di­ate­ly encrypt­ed, and the encryp­tion result was com­pared to its stored version. 

This approach ensured that even if some­one gained access to the mas­ter file, it would not auto­mat­i­cal­ly allow them unau­tho­rised access to user accounts. Since then, oth­er tech­niques like ​“salt­ing” and ​“pep­per­ing” pass­words have been added to the mix (adding extra char­ac­ters so that iden­ti­cal pass­words result in dif­fer­ent encryp­tion out­comes), mak­ing cre­den­tials even hard­er to steal. 

Want to try out dif­fer­ent types of encryp­tions? Check out CyberChef.

Encrypt­ing pass­words added a lev­el of secu­ri­ty, but it didn’t stop users from try­ing mul­ti­ple val­ues to dis­cov­er them. The select­ed key­words need­ed to be hard­er to guess. 

Ear­ly rec­om­men­da­tions sug­gest­ed using pass­words of at least five char­ac­ters. This fol­lowed a study reveal­ing that a 1‑character pass­word from 26 low­er­case let­ters could be guessed by a com­put­er sys­tem in approx­i­mate­ly 30 mil­lisec­onds. In con­trast, a 6‑character pass­word from all avail­able char­ac­ters would have tak­en 174 years with the tech­nol­o­gy of that time. 

How­ev­er, enforc­ing longer pass­words alone was again found to be insuf­fi­cient for guar­an­tee­ing a good lev­el of pro­tec­tion. Anoth­er study revealed that most users often opti­mised for mem­o­ra­bil­i­ty, set­ting their pass­words based on dic­tio­nary words, birth­days, and sim­i­lar pat­terns. (This is, in fact, a very mod­ern prob­lem — if you want to have fun, check out the ​“Top 200 Most Com­mon Pass­words List | Nord­Pass” from Nord­Pass. If you see your pass­word there… well, maybe it’s time to change it.) 

So, in 2003, the Nation­al Insti­tute of Stan­dards and Tech­nol­o­gy (NIST) pub­lished an 8‑page doc­u­ment describ­ing a series of rec­om­men­da­tions that quick­ly became the indus­try stan­dard we all know and love, such as: ​“Pass­words need to use a mix­ture of cap­i­tal let­ters, num­bers, and sym­bols” or ​“Users should change their pass­words every 90 days.” 

The NIST pub­li­ca­tion has since been reg­u­lar­ly updat­ed, now favour­ing long but easy-to-remem­ber pass­words (e.g., There’sAPizzaOnThatRoof) and advis­ing that users should only be asked to update their cre­den­tials if there are signs they may have been stolen. 

And they lived secure­ly ever after… or did they? 

Six­ty-three years after their incep­tion (at the time of writ­ing this), it seems we are still search­ing for the mag­ic for­mu­la that will make pass­words secure. When look­ing at data breach inves­ti­ga­tion reports, the con­sen­sus year after year appears to be that the vast major­i­ty of suc­cess­ful attacks involve a human ele­ment, with the key path lead­ing to unau­tho­rised access being… cre­den­tials! (Stolen, guessed, etc.) 

If you’re curi­ous, check out Verizon’s ​“2024 Data Breach Inves­ti­ga­tions Report | Ver­i­zon”. 

Tech­nol­o­gy has rapid­ly advanced since 1961, with most com­pa­nies mov­ing their ser­vices to the Inter­net and requir­ing users to reg­is­ter. As a result, the num­ber of pass­words for the aver­age user has increased expo­nen­tial­ly. With so many pass­words to man­age, it’s easy to see how most peo­ple fall into the same old habits: choos­ing mem­o­rable pass­words or easy pat­terns (e.g., start­ing with a cap­i­tal let­ter and end­ing with an excla­ma­tion mark, re-using the same cre­den­tials for mul­ti­ple accounts, or keep­ing their pass­words writ­ten down in plain text somewhere). 

The unfor­tu­nate side of this sto­ry is that while users keep mak­ing old mis­takes, attack­ers keep get­ting bet­ter at exploit­ing them. 

Pass­words seem to have out­grown their pur­pose. So, what can we do to keep them rel­e­vant and make authen­ti­ca­tion stronger? And what is authen­ti­ca­tion, anyway? 

NIST defines ​“authen­ti­ca­tion” as the act of: ​“Ver­i­fy­ing the iden­ti­ty of a user, process, or device, […] to allow access to resources in an infor­ma­tion system.” 

From this def­i­n­i­tion, we can extrap­o­late the three fun­da­men­tal ele­ments of authentication: 

1. Iden­ti­fi­ca­tion: The asser­tion of an iden­ti­ty. Think of a user­name — this is the claim of being a spe­cif­ic user. 
   

2. Ver­i­fi­ca­tion: The ​“proof” that a user is who they claim to be. Think of the pass­word — the proof pre­sent­ed to ver­i­fy the claimed identity. 
   

3. Autho­ri­sa­tion: The abil­i­ty of a ver­i­fied user to access resources or per­form actions. 

Focus­ing on the ​“ver­i­fi­ca­tion” ele­ment, we can fur­ther sub­di­vide it into three main types or ​“fac­tors”: 

1. Knowl­edge fac­tor: ​“Some­thing you know.” A secret only the spe­cif­ic user knows (pass­word, PIN, answer to a secu­ri­ty ques­tion, etc.). 
   

2. Pos­ses­sion fac­tor: ​“Some­thing you own.” A phys­i­cal enti­ty that the spe­cif­ic user pos­sess­es (smart­card, token device, key, etc.). 
   

3. Inher­ence fac­tor: ​“Some­thing you are.” This is intrin­si­cal­ly unique to the spe­cif­ic user (face shape/​features, fin­ger­prints, voice, etc.). 

So, if pass­words are only one of the avail­able types of authen­ti­ca­tion (specif­i­cal­ly the knowl­edge fac­tor), why not swap them for a dif­fer­ent, more secure fac­tor? It comes down main­ly to two rea­sons: pass­words are cheap to imple­ment, and every­one nowa­days knows what they are and how to use them. By con­trast, con­sid­er the finan­cial and cog­ni­tive costs of pro­vid­ing each employ­ee with a phys­i­cal token or imple­ment­ing some­thing like a fin­ger­print read­er (not to men­tion the eth­i­cal dif­fi­cul­ties with peo­ple reject­ing the idea of hav­ing their bio­met­ric data stored somewhere). 

If com­plete­ly chang­ing the main fac­tor of authen­ti­ca­tion is dif­fi­cult, adding one or more extra fac­tors to the mix has proven over time not only to be more achiev­able (espe­cial­ly fol­low­ing the rapid increase in smart­phone sales in recent years) but also one of the most effec­tive steps in enhanc­ing the secu­ri­ty of user accounts. 

The num­ber of fac­tors used, their types, and their method of deliv­ery have proven to be key dif­fer­en­tia­tors in deter­min­ing the like­li­hood of an account being com­pro­mised, with lev­els of pro­tec­tion reach­ing as high as 99.9% when using cer­tain com­bi­na­tions of methodologies. 

Let’s take a quick look at the most com­mon types of mul­ti­fac­tor authen­ti­ca­tion cur­rent­ly available. 

These are unique sets of char­ac­ters or num­bers that are valid for a sin­gle login ses­sion or trans­ac­tion. They are usu­al­ly gen­er­at­ed by an algo­rithm and deliv­ered to a user. The most com­mon deliv­ery method is through SMS, but phone calls and emails are also used. 

• If the deliv­ery is through SMS or phone call, the extra fac­tor would be ​“pos­ses­sion” since only the autho­rised user should pos­sess the autho­rised device/​number. 

• When deliv­ered through email, on the oth­er hand, it is a ​“knowl­edge” fac­tor, as only the autho­rised user should know the email account where the code will be sent and how to access it. 

TOTP is a ver­sion of OTP where a code is gen­er­at­ed based on three elements: 

1. A cryp­to­graph­ic hash function 
   

2. A secret key 
   

3. A mov­ing fac­tor (time) 

The most com­mon deliv­ery method nowa­days is through soft­ware appli­ca­tions (think of authen­ti­ca­tor apps on your phone). 

And if you ever won­dered why you need to scan that QR code when adding an account… Well, that’s the secret key! 

The extra fac­tor for TOTP would be ​“pos­ses­sion,” as only the autho­rised user should pos­sess the device where the code is displayed. 

Unlike the pre­vi­ous two meth­ods, no one-time pass­word is need­ed with push noti­fi­ca­tions. A user is sent a noti­fi­ca­tion to their trust­ed device, and all they need to do is autho­rise or deny the request. 

The extra fac­tor for push noti­fi­ca­tions would again be ​“pos­ses­sion,” as only the autho­rised user should pos­sess the device where the noti­fi­ca­tion is sent. 

And now sure­ly they lived secure­ly ever after… right? 

Well….right-ish. 

Imple­ment­ing MFA is def­i­nite­ly one of the best steps for­ward in improv­ing secu­ri­ty, but it is not infal­li­ble. We can quick­ly rank the pre­vi­ous­ly pre­sent­ed meth­ods from weak­est to strongest. 

From the table above, it is clear that the type of fac­tor cho­sen can make a sig­nif­i­cant dif­fer­ence to the lev­el of secu­ri­ty pro­vid­ed, as well as the num­ber of fac­tors used (the more, the bet­ter; best if cho­sen from dif­fer­ent types, e.g., push noti­fi­ca­tions + bio­met­rics using your phone’s fingerprint/​face recognition). 

One thing to bear in mind is that achiev­ing a 100% lev­el of secu­ri­ty is not the goal, as this would be impos­si­ble. What we are try­ing to do is make our­selves hard­er to com­pro­mise so that attack­ers are less like­ly to invest their efforts in us and focus on those who are less savvy instead. 

There’s a joke that sum­maris­es this well: 

Two friends are walk­ing through the woods when sud­den­ly a vicious-look­ing bear starts walk­ing toward them. The first man imme­di­ate­ly opens his back­pack, pulls out a pair of sneak­ers, and puts them on. The sec­ond man looks at him and says, ​“You’re crazy! You’ll nev­er be able to out­run that bear!” To which the first man responds, ​“Oh, I know that. I don’t have to out­run the bear. I only have to out­run you.” 

So now we have a bet­ter idea of how to pro­tect our­selves through stronger authen­ti­ca­tion. This, how­ev­er, does not solve our ini­tial conun­drum: we are still using passwords! 

Well, the good news is that in 2012, an open indus­try asso­ci­a­tion (FIDO) was found­ed with a clear mis­sion to ​“help reduce the world’s over-reliance on pass­words.” Since its foun­da­tion, it has grown to include over 250 mem­bers, includ­ing major names like Google, Apple, and Microsoft, and intro­duced sev­er­al tech­nolo­gies that will help us final­ly get rid of passwords. 

Pass­word-less authen­ti­ca­tion has been with us for a while through meth­ods like Sin­gle Sign-On (all those ​“Log in with Google” but­tons you see) or mag­ic links (enter your email address and get a link that will auto­mat­i­cal­ly log you in). But these meth­ods just move the pass­word some­where else. 

One of the lat­est tech­no­log­i­cal advance­ments in this space seems promis­ing enough to poten­tial­ly remove pass­words com­plete­ly. It is called ​“passkey,” and the rea­son it looks so promis­ing is that it does not require any pass­words and is already native­ly sup­port­ed by devices launched in the past few years (yes, your iPhone, Android phone, or lap­top most like­ly already sup­ports this!). 

Passkeys work by reg­is­ter­ing a device with a ser­vice provider instead of using a user’s login infor­ma­tion. The device must be able to pro­duce encryp­tion keys, which are used for authen­ti­ca­tion (a provider reg­is­ters a device key and vice versa). 

The bad news is that, at the time of writ­ing, despite the high num­ber of devices sup­port­ing the tech­nol­o­gy, ser­vice providers are still slow to adopt it. This may be due to the invest­ment required and the risk that the new authen­ti­ca­tion method might still be too com­plex for less tech-savvy users. 

So, will authen­ti­ca­tion get bet­ter? Will we final­ly move past pass­words and be able to buy our bar­be­cue with­out going through an exis­ten­tial crisis? 

If you ask me, the future looks bright, although it may still take some time. In the mean­time, I can only sug­gest a few things: 

1. Use strong pass­words. Just because ​“123456” is the most used pass­word in the world doesn’t mean you should use it too. (Need some help? Check out Cor­rect Horse Bat­tery Sta­ple | Gen­er­ate Secure Mem­o­rable Pass­words). 
   

2. Use a dif­fer­ent pass­word for each ser­vice. This is not Mor­dor, and we do not want one login to rule them all. 
   

3. Use a pass­word man­ag­er. This will make points 1 and 2 much eas­i­er to achieve. 

But most of all, don’t make attack­ers’ lives easy—use more than one fac­tor of authen­ti­ca­tion! 

As a last piece of advice, check out Have I Been Pwned to see if your email has been com­pro­mised in a data breach. And who knows, if some­thing comes up, it might be a great oppor­tu­ni­ty to put into prac­tice all you’ve just learned.