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 .
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.
"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.
> 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.
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.
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.
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.
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..
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.
... 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 ).
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.
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.
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.
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.
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.
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.
26 comments
[ 2.4 ms ] story [ 70.0 ms ] threadMy 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 .
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.
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.
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.
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.
... 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 ).
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.
All the good stock trading sites I've used in the past have had separate trading passwords, it just makes sense.
This is all just dismissed as "not the subject of this post"
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...
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.
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.
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.
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?