5

Edit: This scheme has since been standardised as WebAuthn - go use that instead!

I have a userbase which really isn't all that inclined to create a secure password for a website. They're also almost entirely on mobile devices, so I would like to try something a little different rather than them type 'password1' and just wait for it to get guessed. So, firstly, some assumptions:

  • Web browsers almost always remember the password for you anyway.
  • Mobile devices are increasingly gaining features which identify a particular user more securely (touch ID, for example).
  • This uses HTTPS; Malicious clients (intercepting) are largely a non-issue.

The resulting implication:

  • The website authenticates the device and the device authenticates the user. Therefore, we might as well use something better than a poorly chosen password for website <-> device.

Given this, the intention is to use a client generated key pair. The most similar thing asked before is Using RSA for Web Application Authentication, however this approach appears to be a little different.

So, the protocol itself. Firstly, the join process:

  • The client generates an RSA key pair.
  • The public key is sent to the server (over HTTPS). This only ever happens once per device.
  • The server stores the public key as a device.
  • The server creates an account and relates the device to the account. [A]
  • The first session token along with the new device ID is encrypted using the public key, and the result is sent back to the client. The device ID is both a number and a randomly generated string.
  • The client decrypts it, stores the device ID and the private key, and sets the IP locked session token as its cookie.
  • All further requests are authenticated using the session token.

Login (typically due to changed IP)

  • The client tells the server which device it is by sending the device ID.
  • The server asks the client to prove it by encrypting the new session token with its stored public key of that device, and sending it.
  • The client decrypts the data and sets the session as it's cookie.
  • Provided it really is who it said it was, the session is now valid.

Adding a device to an account (e.g. a new phone to replace the one you just washed):

  • The device gets a device ID for itself by doing a join similar to above but does not create an account; [A] does not occur. The device is currently able to authenticate but is not associated with any account. (And this association is purely at the server end).
  • Enter your email address (or some other account related information such as a username) on the new device.
  • The server identifies the requested account and sends it an email or SMS containing a link.
  • The user loads the link (on any device). This causes the server to relate the new device to the original account, provided it's within e.g. 24 hours.

Known vulnerabilities:

The following vulnerabilities all also relate to your typical password system.

  • It's as strong as the email account/ SMS receiver etc.
  • SSLStrip and XSS being used to grab the stored private key, in the same way they could grab document.cookie or the autofilled user/password fields. Although the whole site is HTTPS only, there may be some unknown exploit with the surrounding infrastructure.
  • Someone else could grab the physical device and use the site.

Benefits over a password system:

  • The 'password' is private, even from the server, helping against data leaks and MITM.

  • The 'password' text is considerably stronger as it's essentially equivalent to one in the region of 300-500 characters long.

  • The server only contains a list of public keys. Someone gaining this list via a data leak would still have to break RSA.

  • It's unphishable as the user never directly enters a password.

  • If an intruder breaks HTTPS, i.e. by going around it with something like SSLStrip, they'd still have to break the password as it's not then on the wire as clear text.

  • Actually simpler to use; the user simply enters, at a minimum, an email address.

    Given this, my assumption is that such a system may provide more security and simplicity than a password one can. However, why is this not being done, and, should it be done; am I missing something? Or should I stick to the mainstream password setup and just live with it - any responses would be greatly appreciated!

Side notes

  • I'm aware of client certificates which this has parallels to, but they seem to use complicated terminology and UX for a user to understand, thus they doesn't get used all that much. On a similar thread then, it may make a user feel odd not using a password; it may be perceived to be less secure. (?)

  • Provided the technique is sound and the 'perception issue' isn't a concern, I intend to opensource the implemented solution for both greater security/ simplicity on the web with a corresponding full audit of the implementation.

Community
  • 1
Luke Briggs
  • 176
  • 6
  • Assumptions: `Web browsers almost always remember the password for you anyway.` Does this matter if you don't have PWs? `This uses HTTPS; Malicious clients are largely a non-issue.` Huh? No. What part of HTTPS stops EvilClient from creating a connection to your server? Right, nothing. – deviantfan Dec 13 '15 at 21:55
  • 1
    That's essentially trying to say the device is the thing we're actually authenticating, because it's the one remembering it most of the time. Ah, sorry, malicious in the sense of someone intercepting the link of a known user. – Luke Briggs Dec 13 '15 at 21:57
  • 1
    `The website authenticates the device and the device authenticates the user. Therefore, we might as well use something better than a trashy password.` If the user changes devices and/or the device gets stolen and/or 100 other things... your "trashy" PWs are used for a reason. I think you're prone to get into the diy-trap. As pretty much everyone on this site here says, don't invent your own crypto stuff, it won't be secure. – deviantfan Dec 13 '15 at 21:57
  • 1
    Chances are though, a stolen device remembered a password anyway - i.e. if the person can get into the device by guessing your pin, they've got free reign over a lot of already authenticated apps/ websites. – Luke Briggs Dec 13 '15 at 22:01
  • Look up U2F hardware tokens – Natanael Dec 14 '15 at 01:37
  • Sounds like TLS client certificate authentication. – user253751 Dec 14 '15 at 01:49
  • @immibis The OP mentions CA TLS. – Aron Dec 14 '15 at 01:55
  • @LukeBriggs I think you are missing the point. The reason that CA TLS isn't used nearly as much as people should is not because of the perceived security issue. It is the key distribution problem. In this case your algo will fail catastrophically approximately once a year (when the user loses/upgrades/washes his/her phone). – Aron Dec 14 '15 at 01:59
  • @Aron the general idea is that's where email (or SMS, or some other suitable side channel) steps in to authenticate a new device (i.e. the "adding a device to an account" aspect). I appreciate that it's a bit of a drag to have to go through your email about once a year, but by that time, the user probably forgot their password and would be doing that same route on a traditional system anyway. – Luke Briggs Dec 14 '15 at 04:09
  • 1
    Your question sees to be well thought out. For a quick reality check, I would like to mention [SQRL](https://www.grc.com/sqrl/sqrl.htm). This too, is a password-less authentication protocol, you can compare your solution with. – Marcel Dec 14 '15 at 07:12

2 Answers2

2

So, the main differences from a traditional password system are:

a) It's not bound to humans, but devices; with the key being the asymmetrical "device password". As said already, stolen devices etc. are a risk; even it small, it's there. Other than that it might not be what the user want; with passwords, the user can choose if the browser should store it or not.

b) Below HTTPS, there's another layer of encryption.

... Other than that, I can't see anything suitable for increasing security
(sessions are everywhere, even without your idea, etc.etc.).

About your benefits:

The 'password' is private, even from the server.

This is not beneficial. If someone can't trust the server,
he shouldn't use it anyway.

The 'password' text is considerably stronger.

Not necessairly true. Passwords can have any length. Combined with the browser PW storage,
I actually use some PWs suitable for being used as AES key, just because.

The server only contains a list of public keys.
Someone gaining this list would still have to break RSA.

For doing what? Using the server as user x? No.
Getting the cleartext password? => Hashes are used with normal passwords.

If an intruder breaks HTTPS, they'd still have to break the password too as it's not then on the wire as clear text.

If HTTPS is done right, someone able to break it is able to break your RSA layer too.

Actually simpler to use; the user simply enters, at a minimum, an email address.

See the downside described in the beginning of the post.

tldr: Your idea is not stronger than passwords in any way (and it is probably weaker, but I didn't think too much about that). Given the conceptual differences which may not be liked by admins and users, that's enough reason to not use something complicated like this scheme if a simple password scheme is enough and well tested.

As some of your "benefits" are clearly not, and you didn't recognize that ...
again and again: Don't roll your own crypto, it won't be secure.

deviantfan
  • 3,854
  • 21
  • 22
  • Server trust: This ones more on the basis of being aware of a data leak. I.e. even if an intruder has access to the database, they can't do much with it. Choosing to store it: Our users would almost always say yes, however this is a very valid point. Considerably stronger: Referring to our users here; people who use 'password1' etc almost all the time. Breaking HTTPS: This is more referring to using SSLStrip/ XSS; the most common ways of doing it i.e. go around it rather than actually breaking the crypto itself. Rolling crypto: Standard crypto; essentially just generating a password – Luke Briggs Dec 13 '15 at 22:44
2

Clarification:

I have a userbase which really isn't all that inclined to create a secure password for a website.

I really wonder how you know that? You could have this information either by two ways:

First, you have an extremely friendly userbase and asked a lot of them "Hey, what's your password?", or (much more likely) you somehow have access to the cleartext of stored passwords (I hope I don't have to mention that this is not good practice at all).

Concerns:

In addition to @deviantfan's concerns:

I don't know how sensible/important the information is you process/provide on your website, but what would be the usecase if a device simply breaks (which occasionally happens nowadays)? Would all user data be gone?

Adivce:

Don't invent your own crypto!

Use passwords but in the right way! Have a look at this if you need guidance of how to securely store passwords.

Community
  • 1
Sebastian
  • 330
  • 1
  • 8
  • I was waiting for somebody to bring this up! In short, no, I don't have a list or access to them (and for piece of mind, I would never store passwords in clear text either!). It mainly arises from the common persona of people using the system; without wanting to criticise my own userbase, think "people with short memory loss". Plus of course from testing groups. – Luke Briggs Dec 14 '15 at 07:54
  • The target audience is essentially people who are not in the required mental state to form a good password (better sounding!) – Luke Briggs Dec 14 '15 at 08:06
  • Well, then that sounds more like a target audience where my concern could happen a little bit more often than just occasionally – Sebastian Dec 14 '15 at 08:14
  • Re: would the data be gone - nope - it's kept on the server; it would just be a case of following the "adding a device to an account" part above. – Luke Briggs Dec 14 '15 at 08:24
  • I don't know if I got this straight, but doesn't the second step require the initial phone? – Sebastian Dec 14 '15 at 08:29
  • Nope it doesn't - I'll clarify that in the post; In short though, the system works by authenticating devices and relating a device to an account. So, the new device has it's own key pair and it's public key at the server end is simply related to the account. – Luke Briggs Dec 14 '15 at 08:33
  • Join with email address Y. Device A is associated with account Y as both are created together. (Device A is lost). Device B joins on it's own - it's currently associated with no accounts at all. A link in an email, when loaded, associates device B with account Y. – Luke Briggs Dec 14 '15 at 08:36