Passwords

Passwords are a very simple mechanism for securing access, that can be understood by anyone.

It is a secret sequence of symbols (letters, characters, …​) that grants access to a resource.

Passwords can be found everywhere, for accessing online resources, like email, or when logging in on your computer or phone. A pin is also a password, the only accepted symbols are digits.

Passwords can be shared, this is both a good and bad thing.

When sharing an account, or PC, it is not uncommon to use a shared password.

On the other hand, passwords have multiple issues, they can be

This might happen through some malware running on the computer, or because the database on the website got stolen.

You could also

Even when following best practices (long passphrases, with symbols, using a password manager, …​), leaking passwords cannot be avoided, as the "owner" of the password is not the only one responsible for keeping it secret.

There are multiple ways to mitigate the disadvantages of passwords.

The first mitigation technique is to use different passwords for different services. By doing so, when the password is stolen/guessed/…​, it cannot be used for accessing other resources.

The second advice is to use a password manager.

Having to memorize different passwords is error-prone. Different services have different rules for what a good password looks like (small letters, numbers, "special" characters, …​) and some services might even require that those are changed periodically.

A password manager is, in principle, just a notepad where one can write down and read passwords, and where they are used.

It is not something innovative, but it can be a deal-breaker. Browsers already have an integrated password manager, but it is possible to use an external one, like KeePassXC.

The advantage of using an independent password manager is that it is more practical to organize everything together, instead of having passwords for websites in a browser, and all the others…​ somewhere else.

I have one database where to put the PIN of some payment cards, the passwords for all websites, the passwords for the Wi-Fi, passwords, and pins required by some applications on the phone…​

As the password manager can be integrated both with the browser and Android, I do not even need to copy-paste those. Filling the password field is just a click away, which is even more secure (and practical!) than copy-pasting.

If the password manager is responsible for filling the fields, it can help to avoid phishing attacks. For example, if the domain does not match, the password will not be retrieved.

Supposing you have saved the login information for https://example.com, the password manager can insert the data for you. If someone acquires the domain https://exampIe.com, and makes a website that looks exactly like https://example.com, as I and l are different letters that might look similar, you might be tempted to insert your password. Even the most näive password manager would not make such an error.

The main alternative I’ve used for passwords are ssh key.

It is possible to use passwords for logging in to remote machines when using ssh, but it is…​ not very practical.

Wouldn’t it be better to be able to log in without having to type anything at all?

When using ssh key, it is possible to generate a key pair.

The public key is saved on the remote, while the private key does not leave your device.

When connecting to the remote device, the server ensures through the public key that you possess the corresponding private key. No need to type a secret password.

compared to passwords, a private-public key pair has the following advantages:

The disadvantages are that

The last point is a usability issue; you might not always have your device with you. On the other hand, copying the private key on another machine should at least feel wrong.

It should also feel wrong to type your password or pin on an "unknown" machine, but it is not so, as we are often required to do it.

For example, type PIN at the ATM, or check email on the university PC, …​

Thus ssh key shares some similarities with passwords, but contrary to them, the "secret" is not sent to the server.

While ssh could be more ubiquitous, unfortunately, it is often a "plus".

Even on some hosting plans, SFTP (FTP over SSH) is not available or included in the basic plan, leaving you hopefully with at least FTPS (FTP over SSL), otherwise with plaintext FTP.

Also on Windows ssh is somewhat problematic.

The first issue is that there are multiple ports for Windows and the official version of ssh ported by Microsoft has some "interesting" differences…​

Then, on Windows, most programs are graphical, or might expect a graphical environment, thus connecting remotely via ssh is a niche use case.

Time-based one-time password (TOTP) has been gradually introduced on Github and other platforms.

It is a public standard, and multiple programs can handle it (KeePassXC included).

Contrary to passwords, the secret is that those codes are short, time-constrained, and single-use.

Thus even when accessing from an untrusted device, like a shared PC, minimizes the risk of granting permanent access to someone else to the account, as long as the code is generated on another device (like your phone).

Since it does not necessarily require a second device when working on a trusted device, it can still be used for automating logins, even if it might not be that easy (most programs have an interactive dialog for inserting the one-time password).

TOTP logins can be shared in two ways.

The first, and more "secure", requires some coordination: you can dictate the generated code (they are short) if a one-time use is necessary.

The other way would be to share the seed used for generating the OTPs. It can be imported into multiple programs/devices⁠^[1], but as it is a different action than using the codes for logging it, it should ring some bells if someone is asking you for it.

Compared with passwords managed by a password manager, the main advantage of a TOTP code is that it makes it possible to share something temporarily.

The main disadvantage is that some machine with the secret is required for generating the OTP code, at least it does not have to be a different and/or unique machine.

The seed used for the TOTP algorithm has at least 80 bits of entropy (I did not find any service using less than 80), it is more or less comparable to a lowercase ASCII string of 16 characters, no special characters.

Since it is generated by a machine, it cannot be really compared to most 16-character long passwords, as it would generally be not that random.

Thus, while harder to guess than most passwords, it does not seem much. But that is not an issue, it is also possible to use "longer seeds", which would be more difficult to guess.

Magic links are just temporary links that are, normally, sent to your e-mail address.

It has the advantage that they are easy to use (just click the link instead of remembering a password), and leakages are not a concern since they only have short validity.

The first downside is that you do not have necessarily access to your mailbox all the time.

You might also be trying to log in on one device (a computer), but you have set up your mail on another device (your phone), too bad that such links are generally too long to type.

The second downside is that emails are not always delivered instantaneously, it happened more than once that I had to wait half an hour(!) for an email from Microsoft, before being able to proceed with my task.

The third downside is that even if the mail is received instantaneously, the whole process is much slower compared to inserting a username and password on every half-decent website, especially with a password manager.

There also needs to be some attention when creating a magic link. First of all spam filters can mark them, hiding them from the end user. Secondly, some antimalware programs might scan your inbox and visit the URL. For this reason, most magic links require further interaction with the user, for example clicking on a button, visiting the link alone should not be enough (making them probably less magic).

There is one last issue: mails are generally unencrypted, but using another medium, like a specialized application or encrypted mail, would make the process even more impractical.

At least magic links are still possible to share, if you want to grant access to someone else to your account, you can forward them the mail.

Some services make it possible to create temporary, or multiple passwords.

Such alternate passwords provide similar benefits to TOTP, it makes it possible to partially share an account.

A temporary password expires after some time, and an alternate password can be withdrawn.

This makes it more secure to log in from an "untrusted" device.

HMAC-based one-time password (HOTP) is another method for generating login tokens, similar to TOTP, but with a major difference.

In the case of HOTP, the generated token does not depend on the current time, but on a counter.

The client and server maintain a count separately.

The client increases the counter every time a new OTP code is generated.

It is not clear to me how the server increases the counter too, I was too lazy to read the documentation.

If the token was copied on a second client, this would not know that the server and client already increased the counter.

The server can detect that the counter/token (on the second device) is wrong, and act accordingly.

It is thus less practical to set up HOTP on multiple devices, as it requires synchronizing the counters between those.

The only advantage that comes to mind is that it can be sold as a security feature. If there is a second HOTP device in the wild, you might be able to detect it.

The disadvantage is that if the device that was used last time breaks, and not it is not yet synchronized, it might get difficult to log in again.

Another difference is that there are no time windows for inserting the token.

In practice, HOTP does not seem to be used much, and it is not supported by some password managers by design (one of the issues is merging databases where the counter differs, the other one is modifying the database every time), thus if able to choose between HOTP and TOTP, one should prefer HOTP.

Often claimed as an alternative to passwords, it’s not.

How can I be sure that the fingerprint analyzed on my phone or PC is not sent over the wire? If the biometric data is leaked, is it possible to update it?

Even if it would be, what happens after I’ve used all my fingers? Should I change my face if I’ve used facial authentication?

What if I cut the finger I’m using for authenticating? Or what if I’m wearing makeup? What if I’m aging?

Also, biometric devices can be fooled. The easiest example is facial authentication, where a photo might be sufficient.

In general, the fact I am standing in front of a camera does not mean I want to unlock, authenticate, or trigger some action. Maybe I just want to see what’s there.

On the other hand, if I’m typing my password/OTP/whatever, then it is pretty clear I want to trigger some action.

Another issue is what if I want to let someone else log in to my account, without me being there? If the system is not fooled with a photo, then we have an issue.

Thus biometrics are not a replacement for passwords, they are a convenience.

They also do not provide privacy, on the contrary.

In practice, when using biometric data, the biometric data is (hopefully) only used locally, and the interaction with programs is done with some cryptographic methods.

The main issue is if the biometric data can be extracted from the device. The same concern also holds for passwords, but those can be changed.

What happens after a phone is lost or sold? What happens when pressing the reset button?

How are accessibility issues handled? Some skin diseases will make it difficult or impossible to scan your finger reliably.

I’m always reluctant to use centralized remote systems as an alternative to passwords.

Do I want to let Facebook, Twitter, Microsoft, Google, Apple, or any other company know if I’m going to watch a movie or read some newspaper? Does this type of tracking have any consequences?

What happens if my social media account is (rightfully or not) suspended? Can I still read the newspaper? Can I still make an appointment with the doctor?

There are other questions, for which I could not find a simple answer:

And what if the provider is down, or cannot be reached where I am connecting from (for example because of firewall rules in a public space)?

But also supposing that all those are non-issues, there are a lot of other questions that have no clear answer.

What should I look at when clicking "sign-in with your social media account"? How can I be sure that the service will not be able to access anything?

What information can the website gather from my social media account?

I guess that my social media account can access the data on the website. What if the content of the website is against some policy of the social media account, for example, it talks about religion, guns, or political issues? Is it OK? Can it have consequences?

Other unanswered questions:

The whole process provides less flexibility, for sharing access to some websites, do I need to share access to my social media account too?

One might argue that similar issues exist with passwords, TOTP, and SSH keys, but, assuming that no malware is running on your device:

If this is either case, there is no sharing between services and your email address (maybe the service does not even know your email address).

I’m sure there are specific types of attacks that are not possible thanks to OAuth, but…​ nothing runs locally…​ It does not prevent a future implementation from leaking more information than necessary (by malice or accident).

It might seem paranoic not to trust any third-party service, after all, I did not compile from scratch the operating system I am using, nor I did audit any line of code of most programs I use, and I use closed-source programs too.

I believe the risks are of different categories.

If the implementation of any social media account has a bug that can be exploited, it might be possible to do it remotely, worldwide, and access multiple services at a global scale.

If my implementation/workflow has a bug, I suppose that I should at least need to interact with some webpage able to exploit it, and probably will only have access to one service.

If some malware runs on my machines (and thus does not need any interaction and/or can access all my services at once), I will have a problem with and without SSO, it does not seem to make a big difference.

MFA systems require something more than a username and a password to authenticate.

There are different types of factors that can be used, listed in the table below, the most common ones are

I do not like MFA if it requires biometric data and/or dedicated devices as a second authentication method (the first one is normally the password)

Software tokens (like TOTP), certificates, and keys (like ssh) can be very practical by itself, in fact, ssh keys are easier to use than passwords.

As an example of a bad user experience, my bank requires the usage of their closed-source application (a software token), which does not run well on my phone.

It happened more than once that I could not log in because the application crashed, and given the scarce backup capabilities of mobile devices, I’m always afraid when some updates are available.

Obviously, my bank is to blame, it is possible to build a more robust program, but it also costs money. I’ve contacted them reporting the issue, also providing all the details about my phone I code, and extracts of logcat logs, and nothing changed. The last answer I got was that they cannot support all devices on the market :/

Too bad it was not my decision to use the application, but that it was forced on me, as when I opened my account there was no need to use an application.

To be honest, I would prefer bizarre password requirements. I would save the password in my password manager/browser and continue with my life.

But even if the application would work without issues, there is also always the question: what if my device breaks?

With passwords, it is obvious that I can backup them.

With my bank application, even with administrator rights, I did not manage to restore the backup successfully on a different device (or even the same device).

With TOTP, it might not be obvious, but it is possible to back up the seed too, and configure multiple independent programs and devices.

My experience (with three different systems!) is miserable because I do not control when and how the token is generated.

In one system, the token is sent to me by email, and in another via SMS. Both systems have some delay, which is mostly acceptable. Except that it happened more than once that I had to wait half an hour(!) for an email from Microsoft, before being able to proceed with my task. There is nothing one (as end-user and as service provider) can do, except contact Microsoft, as the whole infrastructure is maintained by them, and works like a black box.

The third system uses an application on the phone (which makes everything worse), but the generation of the token is triggered during login, thus it also has some delay.

Thus, even if it might be less secure, I prefer much more to obtain an email (except by Microsoft). Even an SMS would be better, and I’m one of those people who normally does not want to give his phone number for any reason.

Either way, MFA generally does make your life harder, and more or less impossible to automate some tasks. I used, for example, to download some data with curl and a cron job. I tried to reimplement something similar after the login process got "upgraded" to a 2FA login and realized I could do something better in my free time.

Anyone claiming that any MFA is better than no MFA is lying to you.

This section is the most incomplete, the main reason is that I was not able to find an explanation that I could understand how it should work. Hopefully this changes in the future.

Passkey is the new kid in town, it promises to fix all issues, it has been blessed by Apple, Microsoft, and Google, and it will provide passwordless authentication, but I have not understood yet how it works, and why it should be more secure than current alternatives.

Google has an initial description of what passkeys are supposed to be

Ok, it almost sounds like a key pair, just what people are used to doing with ssh keys.

Except that, which device do I have to unlock?

Unfortunately, the section that should clarify how they work, only makes me wonder why I should want to use them

Ok, I still have no idea how passkeys work, it references the FIDO standards, which seems to require some particular hardware, and given the current state of hardware tokens, I’d rather avoid it.

The use-case with the PC and phone is nice, but only if we are talking about an "untrusted" machine. On my own, I do not want to use the phone. Also, as it uses the "operating system infrastructure", does it mean I need to have an online account on the Windows machine?

How would phones and PC connect? Bluetooth? NFC? Scanning an image? Cable?

But then this section makes me wonder, why should I want to?

Thus the TL;DR of this section is that passkeys are not practical. If the passkey is created on Android, I need my Android phone to use it.

If the Passkey is created on something that is not Android, then I cannot use my Android phone to log in. And passkeys are (apparently) only synchronized if I’ve logged in to the same Google account.

Which seems to rule out offline backups too.

This can’t be real.

I was going to assume that the webpage is not accurate and only showcases one particular workflow, but other resources confirmed what I just quoted.

After reading this and this page from Apple, it seems that on apple devices passkey are synchronized through iCloud (and it seems that you are not able to opt-out, I guess you are on Android phones…​).

The Microsoft page ^🗄️ also did not help to shed some light, is an online account required?

After further research, I landed on passkey.io, and passkeys-demo. Both pages provide a demo.

Both pages did not work for me.

After some further research, it turns out, that passkeys are generally not supported on Linux systems, so even if I wanted to, I would not be able to use them daily.

On passkeys.dev, there is a matrix for explaining in which constellation a Passkey can be used.

Why is a matrix needed? It is an open standard, the main point should be to have different interoperable implementations! I guess the limitations and inconsistencies are chosen design decisions by the single implementations, or the specification.

I mean, a passkey is a key pair, like ssh keys, there is no reason why it should not be possible to copy them across different devices.

To be honest, the biggest threat model for the most important accounts I have is me not being able to access them anymore. It might be something banal like me not being able to access my password and/or keys, or the service shutting down.

The second threat is someone unauthorized being able to access those accounts or data.

Many types of accounts could be more anonymous⁠^[3], if it were the case, in some cases I could not care less if someone else would be able to access them. Some are throw-away accounts, used only once or twice, and other accounts are often for accessing some (non-personal) data.

Most threats are remote and probably rely on big numbers. It is much more probable that some vulnerability that affects a lot of users is used and I would be one of the many victims.

Another threat would be the usage of an unsecured device, like a PC at the library.

Dedicated attacks are not impossible, but probably the last of my issues. It is not true that most people are not important enough to be targeted directly. Everyone is relevant enough to be targeted directly, but the chances happening for most people are low.

And I’m not talking about the daily scam mail with your name on it, it still counts as big numbers.

The most probable dedicated attack is someone accidentally seeing me inputting the password in the username field instead of the password field (thus being there black on white), and trying to take advantage of it.

While reading information about FIDO, WebAuthn, and MFA methods, the main threat model is denying access to everyone except you, which means the rightful owner losing access is a better outcome than someone else gaining access.

More often than not, I want some other people to be able to access my accounts. In case something bad happens (injury, premature death, …​) I want at least my family to be able to access my tax accounts, and the website for electricity, phone, water, and other things too. This should happen without trying to put my dead-cold thumb on my phone.

And even without resorting to tragical fatalities, sharing online accounts happens daily.

For example, a shared account for the library, or for some online store.

My view on the topic might be naive, organizations for example have different priorities (a breach might cost much more than having some people not be able to access their workplace, thus it is better for someone to lose access than someone else to be able to access).

As Passkey, WebAuthn, and all other authentication methods are proposing themself as alternatives for everyday use, it is problematic to see that there is way less interest in "normal people", and lock-in.

I’m not claiming that passwords are the best we currently have.

Passwords are simple, and the complexity lies somewhere else: handling them "securely".

Passkeys have a lot of complexity, and if everything works, handling them in such a way that someone else can access your account is much harder. But it also puts a lot of restrictions I’m not comfortable with, and makes the whole process clunky and unintuitive.

The best alternative is …​ ssh keys!

They are much more practical and secure.

Unfortunately, most places do not support login via ssh.

Currently, it seems to me that the combination password and a TOTP as a second factor hits a good sweet spot:

What drives me crazy is that many websites (Github included) propose an Authenticator App when they mean TOTP.

The issue with "authenticator app", is that it does not ring any bell.

If they would just write somewhere TOTP, it would be at least clear what authentication method they are proposing.

One bad description is all that led me to use one application I did not want to.

While it is a minor issue, it does not help to clarify the differences between all authentication methods, and as an end-user, it causes fatigue in searching for reliable and up-to-date information.