3 ms·

Adding Easy SSL Client Authentication To Any Webapp

50 points by scriptjunkie 13y ago

deftnerd 13y ago
It's sad that I didn't realize he easy this was to implement now. I'm building several sites that implement bitcoins and this has clear advantages over simple usernames and passwords. My thought is allow the user to authenticate with the SSL cert. If they're at an IP never seen before, require a password. Thoughts? My concern is with people that have a compromised computer that has a Remote Access Toolkit installed on it. Perhaps always require the SSL cert AND a password pair? Not that passwords would be safe on an infected machine. These days it seems that the only way to be sure is to require additional authentication from a second device such as a phone with a 2FA app like Google authenticator or Authy or a hardware device like a Yubi key. Even sending one-time text message confirmation xodes .
- deftnerd 13y ago
  I'm embarrassed that I didn't notice my auto-correct mangling my comment. I'll comment from my desktop in the future. I meant to say that it's amazing how easy this is to implement now and even sending one-time text message confirmation codes during every authentication attempt works.
michaelmior 13y ago
"Private keys cannot be guessed – Because users didn’t choose them!" I don't follow this logic. Sure they're likely to have more entropy than a user-selected password (and almost certainly be longer). However, there's nothing about the fact that the key isn't selected about the user that makes it un-guessable.
- asdfaoeu 13y ago
  It's because it actually has enough entropy to be completely improbable guessing.
  - michaelmior 13y ago
    Some users (of course a tiny minority) generate random passwords. I think the point holds, I just think the presentation isn't completely accurate.
    - joesb 13y ago
      > They can be guessed – Regardless of complexity requirements, users will find and use the simplest pattern allowed, and attackers routinely take advantage. It's right in the article that they are talking about average user behavior of choosing guessable password, even if you tell them not to.
- scriptjunkie 13y ago
  Private keys should have over 128 bits of entropy, which is enough to make it un-brute-forceable with at least the amount of energy likely to be obtained by any human organization on earth. http://en.wikipedia.org/wiki/Brute-force_attack#Theoretical_limits http://en.wikipedia.org/wiki/Brute-force_attack#Theoretical_... That's what makes it un-guessable. Also, some users do choose passwords with at least as much entropy and are also unguessable. But most don't.
  - dmix 13y ago
    I use automated high-entropy password-generators and a surprising amount of websites cap lengths to 30-50 characters (or even 8 chars sometimes like a Canadian bank I won't name). Allowing super-long passwords would be a good starting alternative to SSL.
    - tmikaeld 13y ago
      The problem with this is that some sites still only support max 20 characters.
  - mnordhoff 13y ago
    Security FYI: This situation concerns RSA keys, not 128-bit symmetric keys; our problem is "factoring a really big number", not "guessing a really big number". A 128-bit RSA key can be broken in seconds. RSA keys are commonly 2048 bits at the moment. NIST's rough rule of thumb is that a 2048-bit RSA key is equivalent in secureness to a 112-bit symmetric key; for 128-bit equivalence, you need around a 3072-bit RSA key. (2048 provides fine security for the next few decades at least.) Edit: You referred to "128 bits of entropy", which could be interpreted as "equivalent to a 3072-bit RSA key". I'm not accusing you of recommending insecure RSA key sizes, I just wanted to make a public service announcement. I've seen people make that mistake before.
- tiziano88 13y ago
  Social engineering techniques can be very effective when trying to guess a user's password (birth date, pet name, etc.). Also think about not-so-random password like "password", "qwerty", "12345" etc..
nly 13y ago
Imho the gaping hole with client certificates at the moment is that, in current browser implementations at least, I don't think they are well secured. Notice when using his demo pages you are asked by your browser for confirmation before you use your shiny new certificate, but otherwise no credentials are required. It's relatively easy for someone to steal client certificates from my machine whether I'm here or not. [wf9bhh4z.default]$ pwd /home/nly/.mozilla/firefox/wf9bhh4z.default [wf9bhh4z.default]$ strings cert8.db | grep nly.*junkie nly's scriptjunkie.us ID ... I'm not sure if this default behaviour is a switch that can be flipped somewhere, or whether they are actually encrypted, but that protection can only ever boil down to some other credential like the users Windows password (which will be weak). When it comes down to it today, I feel a mobile solution, like Google Authenticator that can live comfortably in my pocket, is just more workable as a 'something I have' credential, and I then don't have to entirely trust whatever random PC I'm using. With QR codes it's even almost as convenient. (I also don't think password auth need be totally disregarded, see : https://news.ycombinator.com/item?id=6767249 https://news.ycombinator.com/item?id=6767249 ). That said, I commend the author for seeking alternatives to password authentication and doing all this excellent work to make it easy to use. It's good, desperately needed work.
- revelation 13y ago
  As usual, if you can't trust the client machine, no solution is secure. Not even any mobile two way authentication.
  - nly 13y ago
    That's true, but there are outright trivial things a lot of sites just don't do to limit the impact of compromise. I just sold some Bitcoin for example (I know right...) and the exchange doesn't require any special credentials for initiating trades or withdrawals: just the same password and 2FA code I use to login to my account. All the good stock trading sites I've used in the past have had separate trading passwords, it just makes sense.
    - MichaelGG 13y ago
bsilvereagle 13y ago
As far as I can tell, client certs can't be cross-device. You would need a new cert on every device you plan to use with the site.
- dmix 13y ago
  I've used PGP keys cross-device (using both android and osx clients), why can't SSL?
  - geofft 13y ago
    You can export and import certs between devices, the UI is just awful. Possibly more awful than all the PGP UIs, if such a thing is possible. Certainly you can't drive this flow from the website alone. The best you can do is point your users at various browser-specific instructions.
    - zaraflan 13y ago
      At which point you're back to the same basic problem with passwords: the weakest link and root-problem is the average user's lack of knowledge. There wouldn't be such a mad scramble to find a decent alternative to passwords if everyone was using KeePass or the like, and no alternative is going to be near-future viable if it relies on something too complicated for the nearly-everyone who isn't using strong generated passwords. 2FA is working because all the user has to do is get a text. Anything beyond that level of difficulty is simply a non-starter at this point.
- jlgaddis 13y ago
  It depends if the certificate is marked as "exportable". If it is, then it can be moved/copied.
jakozaur 13y ago
Love it so much! An easy way to detect user and could prevent quite a lot of phishings attack. One issue is the browser compatibility. It work on Chrome, but I tried it on my iPhone Safari and it doesn't work. Is there any way to fix it?

50 points by scriptjunkie 13y ago

It's sad that I didn't realize he easy this was to implement now. I'm building several sites that implement bitcoins and this has clear advantages over simple usernames and passwords. My thought is allow the user to authenticate with the SSL cert. If they're at an IP never seen before, require a password. Thoughts? My concern is with people that have a compromised computer that has a Remote Access Toolkit installed on it. Perhaps always require the SSL cert AND a password pair? Not that passwords would be safe on an infected machine. These days it seems that the only way to be sure is to require additional authentication from a second device such as a phone with a 2FA app like Google authenticator or Authy or a hardware device like a Yubi key. Even sending one-time text message confirmation xodes .

deftnerd 13y ago
I'm embarrassed that I didn't notice my auto-correct mangling my comment. I'll comment from my desktop in the future. I meant to say that it's amazing how easy this is to implement now and even sending one-time text message confirmation codes during every authentication attempt works.

michaelmior 13y ago

"Private keys cannot be guessed – Because users didn’t choose them!" I don't follow this logic. Sure they're likely to have more entropy than a user-selected password (and almost certainly be longer). However, there's nothing about the fact that the key isn't selected about the user that makes it un-guessable.

asdfaoeu 13y ago
It's because it actually has enough entropy to be completely improbable guessing.
- michaelmior 13y ago
  Some users (of course a tiny minority) generate random passwords. I think the point holds, I just think the presentation isn't completely accurate.
  - joesb 13y ago
    > They can be guessed – Regardless of complexity requirements, users will find and use the simplest pattern allowed, and attackers routinely take advantage. It's right in the article that they are talking about average user behavior of choosing guessable password, even if you tell them not to.
scriptjunkie 13y ago
Private keys should have over 128 bits of entropy, which is enough to make it un-brute-forceable with at least the amount of energy likely to be obtained by any human organization on earth. http://en.wikipedia.org/wiki/Brute-force_attack#Theoretical_limits http://en.wikipedia.org/wiki/Brute-force_attack#Theoretical_... That's what makes it un-guessable. Also, some users do choose passwords with at least as much entropy and are also unguessable. But most don't.
- dmix 13y ago
  I use automated high-entropy password-generators and a surprising amount of websites cap lengths to 30-50 characters (or even 8 chars sometimes like a Canadian bank I won't name). Allowing super-long passwords would be a good starting alternative to SSL.
  - tmikaeld 13y ago
    The problem with this is that some sites still only support max 20 characters.
- mnordhoff 13y ago
  Security FYI: This situation concerns RSA keys, not 128-bit symmetric keys; our problem is "factoring a really big number", not "guessing a really big number". A 128-bit RSA key can be broken in seconds. RSA keys are commonly 2048 bits at the moment. NIST's rough rule of thumb is that a 2048-bit RSA key is equivalent in secureness to a 112-bit symmetric key; for 128-bit equivalence, you need around a 3072-bit RSA key. (2048 provides fine security for the next few decades at least.) Edit: You referred to "128 bits of entropy", which could be interpreted as "equivalent to a 3072-bit RSA key". I'm not accusing you of recommending insecure RSA key sizes, I just wanted to make a public service announcement. I've seen people make that mistake before.
tiziano88 13y ago
Social engineering techniques can be very effective when trying to guess a user's password (birth date, pet name, etc.). Also think about not-so-random password like "password", "qwerty", "12345" etc..

nly 13y ago

Imho the gaping hole with client certificates at the moment is that, in current browser implementations at least, I don't think they are well secured. Notice when using his demo pages you are asked by your browser for confirmation before you use your shiny new certificate, but otherwise no credentials are required. It's relatively easy for someone to steal client certificates from my machine whether I'm here or not. [wf9bhh4z.default]$ pwd /home/nly/.mozilla/firefox/wf9bhh4z.default [wf9bhh4z.default]$ strings cert8.db | grep nly.*junkie nly's scriptjunkie.us ID ... I'm not sure if this default behaviour is a switch that can be flipped somewhere, or whether they are actually encrypted, but that protection can only ever boil down to some other credential like the users Windows password (which will be weak). When it comes down to it today, I feel a mobile solution, like Google Authenticator that can live comfortably in my pocket, is just more workable as a 'something I have' credential, and I then don't have to entirely trust whatever random PC I'm using. With QR codes it's even almost as convenient. (I also don't think password auth need be totally disregarded, see : https://news.ycombinator.com/item?id=6767249 https://news.ycombinator.com/item?id=6767249 ). That said, I commend the author for seeking alternatives to password authentication and doing all this excellent work to make it easy to use. It's good, desperately needed work.

revelation 13y ago
As usual, if you can't trust the client machine, no solution is secure. Not even any mobile two way authentication.
- nly 13y ago
  That's true, but there are outright trivial things a lot of sites just don't do to limit the impact of compromise. I just sold some Bitcoin for example (I know right...) and the exchange doesn't require any special credentials for initiating trades or withdrawals: just the same password and 2FA code I use to login to my account. All the good stock trading sites I've used in the past have had separate trading passwords, it just makes sense.
  - MichaelGG 13y ago

bsilvereagle 13y ago

As far as I can tell, client certs can't be cross-device. You would need a new cert on every device you plan to use with the site.

dmix 13y ago
I've used PGP keys cross-device (using both android and osx clients), why can't SSL?
- geofft 13y ago
  You can export and import certs between devices, the UI is just awful. Possibly more awful than all the PGP UIs, if such a thing is possible. Certainly you can't drive this flow from the website alone. The best you can do is point your users at various browser-specific instructions.
  - zaraflan 13y ago
    At which point you're back to the same basic problem with passwords: the weakest link and root-problem is the average user's lack of knowledge. There wouldn't be such a mad scramble to find a decent alternative to passwords if everyone was using KeePass or the like, and no alternative is going to be near-future viable if it relies on something too complicated for the nearly-everyone who isn't using strong generated passwords. 2FA is working because all the user has to do is get a text. Anything beyond that level of difficulty is simply a non-starter at this point.
jlgaddis 13y ago
It depends if the certificate is marked as "exportable". If it is, then it can be moved/copied.

jakozaur 13y ago

Love it so much! An easy way to detect user and could prevent quite a lot of phishings attack. One issue is the browser compatibility. It work on Chrome, but I tried it on my iPhone Safari and it doesn't work. Is there any way to fix it?