Support my work ♥

No password login concept

Passphrases are long and hard to remember. We still need an email address and sometimes also a second factor. But how much security do we actually gain with this? What if we used a different system that would put less burden on the users mind?

(Very short) Historic context of logins

The evolution of it security and authentication started before I was born. On the big picture it started out like this:

  1. Physical security only: There was no internet, if you could walk into the room with the machine, that was it. Connecting two systems was done by installing a cable
  2. Rarity: It was so expensive to get a computer that those few that had access to such a machine for the most part had better things to do. First multi user systems had accounts for organisational purposes. Plaintext passwords, no TLS (former SSL) or SSH
  3. IP based security: IP won the protocol war over Apple Talk and others. The first NFS version with any sort of security was created with IPs/Subnets per export (aka. per shared foler)
  4. User & Password with groups: With HTTP 1.0 the need for sessions arose, because now users started moving between machines and the first laptops appeared and now machines could move between networks too. Anonymous accounts are in their prime. Secret services blossom and infiltrate many systems and snoop on many cables and internet exchanges
  5. Client certificates: SSH public key authentication, signed eMail, ...
  6. API keys: With machine to machine communication increasing handling just one field is simpler than two plus it is simpler to enforce minimal length
  7. Password managers: longer passwords, need to share lots of passwords in a team
  8. Single Sign On (SSO): centralising authentication or outsourcing it to another provider. Simplifies services but creates new dependencies and risks
  9. Second factor (2FA): SIM cards, SmartCards, RSA number tokens, One-Time-Pads (lists of random numbers one has to cross out on each access, very easy to disrupt service with desync), SMS token, challenge response
  10. Pass-Phrases: After years of hacked accounts because people choose password or 0000 as their secret there is a shift to longer secrets. Remembering a sentence as a password is about as hard as a complicated, long password but gives much more it security

Nowadays on of the biggest problems with pass phrases is that they get reused over many services. So obtaining one username/password or email/password pair has a high chance to enable access to multiple services.

An email and TOTP authentication scheme

I propose a new schema where the user uses a combination of their email address and and TOTP token to login.

Why?

  • No additional network connection required
  • Protects against keyloggers
  • Follows the principal of Datensparsamkeit
  • Users can use one application eg. FreeOTP Authenticator (Android/Apple) from Red Hat for multiple services on the same device
    • There are TOTP clients for desktop users too

Why not?

It still requires people to either have a smart phone or some experience with computers.

This can be mitigated by making the page that displays the QR-Code an already signed in page, then the user must login by receiving an email and confirming their address every time.

Specification: What is the security scheme supposed to do?

Registration / Signup

Is done by sending the user an email with a link to a confirm page showing the TOTP QR-Code.

TOTP secret lost

In case the user looses their device, then they can request a new secret via their email account.

To prevent abusive users this new secret must not be applied without the user using it.

Also, applying a rate limit (eg. once per 30min) would improve matter further so the user is not flooded with emails.

Implementation: How does it work?

I propose the following fields in your user structure:

struct User {
    // ... other fields

    email: String,
    active_totp: TotpSecret,
    /// If this is `Some(secret)` we will replace the
    /// active secret with this one the first time 
    /// it is used to complete intentional reset
    /// while preventing a DoS attack and then set
    /// this to `None`
    next_totp: Option<TotpSecret>,
}

Registration / Signup

  1. The signup form must contain at least their email address
  2. The user clicks on a confirm link leading to a page showing a QR code of the TOTP secret that the user scans with their app (Computer or SmartPhone)
  3. The user generates their first TODP code to complete the registration and do their first login

Login

  1. The user enters their email address and the current TOTP code from their application

That's it, no async messages or challenge response needed.

Assurance: Does it really work?

As with many other services the users security lies with the eMail account.

Not storing pass-phrase-hashes in your own database is something that can not be stolen and there is no need for dealing with hash salts.

Demo Implementations

I am building a working prototype, stay tuned.

If you have a catchy name, let me know: @dns2utf8

Alternative concepts

EMail only - no persistent password

  • You need an email address to create an account.
  • For every login you get a "reset email" with a temporary password, that is valid for a short time (eg. 10 or 30 minutes).

I like this concept because a lot of people work like this anyways since they keep forgetting their password and reset it all the time already.

Companion app

  • You must have a smart phone with a recent firmware (last two years) - used to be a specific brand eg. iPhone only
  • After Login/Password you must press a button in the app

I dislike this concept because it excludes a range of people (old, poor, rural, colour blind, injured, ...) and uses up a lot of space on mobile phones.

Another huge minus is that these apps track the use outside of the normal usage. There are a number of companies out there that try to collect as much data as possible on all users and then try to sell it later. Why is this a problem here?

Banks and Insurance companies can use their connection logs to guess the mental health state of their clients. With an app on the device they get a connection every time the device wakes up, which is strongly correlated with the users usage pattern since most people don't use their devices while they are asleep.

links

social