4 ms·

So I've been thinking about systems like this for a bit. How is this different than Client-side certs, except it requires an addon? How do you sync keys betwe

by e1ven 15y ago

So I've been thinking about systems like this for a bit. How is this different than Client-side certs, except it requires an addon? How do you sync keys between machines? If I'm going to have to deal with syncing and installing a plugin, why not just install 1Password, and have it automatically generate unique-passwords for each site..?

romaimperator 15y ago
1. One difference is that a different key pair is used for every domain so you don't have to worry about your public key being used to uniquely identify you. Also, I think this is easier for novice users than creating a cert. 2. I plan on adding in an import/export feature for the next release. 3. This should be more secure than passwords because the only information that the server gets is your public key, which of course is assumed to be public knowledge. No more wondering if the website you're using is properly storing passwords. Thanks for the questions.
- ef4 15y ago
  Do browser-generated SSL client certs really share keypairs between unrelated domains? AFAIK, each one asks the browser to generate a new keypair. Unless of course they've chosen to be federated with someone who has already issues you a cert.
  - marshray 15y ago
    Yes, browsers can be a bit promiscuous with who they hand your client cert to. It depends on the browser, who issued the cert, and what websites the user has agreed to supply their client cert for. If a specific website issued the cert, it won't be terribly useful to another site, but it could leak some personal info. If a well-known CA (e.g. DigiNotar) issued the cert, it might be valid across a wide range of sites (e.g. Dutch government and other sites). The TLS protocol is a bit lacking in this regard. A man-in-the-middle type attacker can impersonate a server to a browser and get the "public" client cert.
- 7952 15y ago
  Could you fit the private key in a QR code? http://bitbills.com/how http://bitbills.com/how
s_tec 15y ago
This is a great idea, and hopefully browsers will adopt it directly one day. In the mean time, this plugin is a nice way to test the concept. I have a massive collection of passwords in my LastPass plugin, and managing them is a real mess. Sites are always changing their login URLs or doing other things to break the experience. Most of my family just uses the same password for all their logins, rather than deal with LastPass. With this new mechanism, you only need to store the private key, which is far simpler. If a hacker steals your password from the server, they can log in as you. If a hacker steals your public key from the server, though, they still can't do anything. They need the private key to actually log in. So, besides being simpler, this new approach is actually more secure.
- romaimperator 15y ago
  I was hoping too that browsers would have it built-in instead of the password managers.

by e1ven 15y ago

romaimperator 15y ago

1. One difference is that a different key pair is used for every domain so you don't have to worry about your public key being used to uniquely identify you. Also, I think this is easier for novice users than creating a cert. 2. I plan on adding in an import/export feature for the next release. 3. This should be more secure than passwords because the only information that the server gets is your public key, which of course is assumed to be public knowledge. No more wondering if the website you're using is properly storing passwords. Thanks for the questions.

ef4 15y ago
Do browser-generated SSL client certs really share keypairs between unrelated domains? AFAIK, each one asks the browser to generate a new keypair. Unless of course they've chosen to be federated with someone who has already issues you a cert.
- marshray 15y ago
  Yes, browsers can be a bit promiscuous with who they hand your client cert to. It depends on the browser, who issued the cert, and what websites the user has agreed to supply their client cert for. If a specific website issued the cert, it won't be terribly useful to another site, but it could leak some personal info. If a well-known CA (e.g. DigiNotar) issued the cert, it might be valid across a wide range of sites (e.g. Dutch government and other sites). The TLS protocol is a bit lacking in this regard. A man-in-the-middle type attacker can impersonate a server to a browser and get the "public" client cert.
7952 15y ago
Could you fit the private key in a QR code? http://bitbills.com/how http://bitbills.com/how

s_tec 15y ago

This is a great idea, and hopefully browsers will adopt it directly one day. In the mean time, this plugin is a nice way to test the concept. I have a massive collection of passwords in my LastPass plugin, and managing them is a real mess. Sites are always changing their login URLs or doing other things to break the experience. Most of my family just uses the same password for all their logins, rather than deal with LastPass. With this new mechanism, you only need to store the private key, which is far simpler. If a hacker steals your password from the server, they can log in as you. If a hacker steals your public key from the server, though, they still can't do anything. They need the private key to actually log in. So, besides being simpler, this new approach is actually more secure.

romaimperator 15y ago
I was hoping too that browsers would have it built-in instead of the password managers.