Adding Easy SSL Client Authentication To Any Webapp(scriptjunkie.us)
scriptjunkie.us
Adding Easy SSL Client Authentication To Any Webapp
http://www.scriptjunkie.us/2013/11/adding-easy-ssl-client-authentication-to-any-webapp/
5 comments
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.
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.
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.
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 ).
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.
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
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 ).
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.
In OSX, client certificates are stored in the Keychain, which must be unlocked with your password. The problem with almost every "security product" comes down to the fact that Windows (and Linux, I think) don't have equivalent protected-storage APIs integrated throughout the desktop environment.
linux has "equivalent protected-storage APIs integrated throughout the desktop environment",KDE has kwallet[1],GNOME has libsecret[2] and lxqt has lxqt wallet[3].Firefox has an extension to store its passwords in KDE's kwallet[4] and GNOME's gnome-keyring/libsecret[5].Chrome has support for both wallets[6]
all linux destributions ships with libsecret and that will be the API to target if anybody want to store sensitive information securely in a linux desktop session.
[1] http://en.wikipedia.org/wiki/KWallet
[2] http://lwn.net/Articles/490518/
[3] https://github.com/mhogomchungu/lxqt_wallet
[4] https://addons.mozilla.org/en-US/firefox/addon/kde-wallet-pa...
[5] https://addons.mozilla.org/en-Us/firefox/addon/gnome-keyring...
[6] http://productforums.google.com/forum/#!topic/chrome/r65mTFM...
all linux destributions ships with libsecret and that will be the API to target if anybody want to store sensitive information securely in a linux desktop session.
[1] http://en.wikipedia.org/wiki/KWallet
[2] http://lwn.net/Articles/490518/
[3] https://github.com/mhogomchungu/lxqt_wallet
[4] https://addons.mozilla.org/en-US/firefox/addon/kde-wallet-pa...
[5] https://addons.mozilla.org/en-Us/firefox/addon/gnome-keyring...
[6] http://productforums.google.com/forum/#!topic/chrome/r65mTFM...
Windows provides Data Protection APIs, which allow any program to encrypt data using a key that's derived from the user's password. Reset the password, lose that data. (It also has options for in-memory data, based on a user's session or process scope.)
It doesn't protect you from arbitrary code running in your security context that has access to your encrypted data. Without app-level verification (like kernel verifies current binary is signed and hasn't been tampered with), I'm not sure that's even possible.
It doesn't protect you from arbitrary code running in your security context that has access to your encrypted data. Without app-level verification (like kernel verifies current binary is signed and hasn't been tampered with), I'm not sure that's even possible.
As usual, if you can't trust the client machine, no solution is secure. Not even any mobile two way authentication.
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.
All the good stock trading sites I've used in the past have had separate trading passwords, it just makes sense.
Do you often login to your Bitcoin exchange account without performing any write actions? If the majority if the time you're not logging into a read-only session, having an extra password seems rather pointless. If an attacker has compromised the 2FA system, they've most likely compromised your device.
"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.
It's because it actually has enough entropy to be completely improbable guessing.
Some users (of course a tiny minority) generate random passwords. I think the point holds, I just think the presentation isn't completely accurate.
> 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.
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.
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_... 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.
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.
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.
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.
The problem with this is that some sites still only support max 20 characters.
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..
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?
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?
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.
It depends if the certificate is marked as "exportable". If it is, then it can be moved/copied.
I've used PGP keys cross-device (using both android and osx clients), why can't SSL?
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.
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.
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.
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.
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 .