8 ms·

Foamicate: A new system for authenticating users without using passwords.

63 points by romaimperator 15y ago

guan 15y ago
Foamicate uses a browser extension. Is there any reason the client side portion can’t be implemented in JavaScript with keys stored in localStorage?
- tomkinstinch 15y ago
  Does Chrome sync localStorage among browsers?
  - guan 15y ago
    I’m not sure; would you consider that a good thing or a bad thing for this purpose? If you consider it a bad and a security risk, then I would answer that the RSA private key would still be protected by a master password on the client side. You essentially end up with a solution like LastPass or 1Password with a different password for each service, with the added benefit that the server only has the public key so users aren’t affected if attackers obtain a copy of the server database. If a good thing, well, it’s not clear to me that Foamicate syncs across browsers either.
    - romaimperator 15y ago
      Right now it does not. I can't think of a way to sync across browsers without syncing first to a remote server and I'd prefer not to require people trust my server anymore than they have to. I plan on adding in import/export of the database soon. Here's the roadmap for the addon https://github.com/romaimperator/Foamicator/wiki/Roadmap https://github.com/romaimperator/Foamicator/wiki/Roadmap.
  - rorrr 15y ago
    Not yet. There's a feature request from a year ago: http://code.google.com/p/chromium/issues/detail?id=84510 http://code.google.com/p/chromium/issues/detail?id=84510
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
deleted 15y ago
[deleted]
mbleigh 15y ago
Mozilla has already been working on a standards-based implementation of user agent authentication: https://browserid.org/ https://browserid.org/
- bri3d 15y ago
  Foamicate looks much more decentralized - while it's possible to run your own BrowserID server, the recommended production setup is to authenticate users against the central browserid.org federated sign-on service. At any rate, I think we learned from OAuth 1 that 18-step, cryptographically involved sign-in processes aren't going to be widely adopted by developers.
- SMrF 15y ago
  I'll be surprised if a widely adopted single sign-on solution emerges from a standards body. Standards should be formed from working code, not the other way around. Also, I'm not sure what standard you are talking about. They have a very nice spec here: https://wiki.mozilla.org/Identity/BrowserID https://wiki.mozilla.org/Identity/BrowserID But this is not a standard. Mozilla's contribution to this space is obviously going to carry more weight than foamicate, but I say let the best solution win and let's see what else we can come up with. Don't shoot this down by saying it's not a standard.
krupan 15y ago
Higher security, and not needing to type passwords on my phone would be awesome.
daenz 15y ago
I read this as Foarnicate.
sgdesign 15y ago
This looks like a cool technology, so sorry to be somewhat off-topic. But unless there's something I'm not getting, isn't this a really bad name? Basically one letter change away from reading like "Fornicate"…
- fredley 15y ago
  I agree, name isn't great, and I think the description of what it is/how it works needs work if this is going to take off. If you don't know what RSA/public key cryptography is already, you're going to have a hard time digesting the text on this site.
- ComputerGuru 15y ago
  Honestly, I read this headline bleary-eyed from a nap.. and that's what I saw until I did a double-take. It's not the fact that it's a one-letter change, it's the fact that rn is m minus a pixel here and there.
VikingCoder 15y ago
At this point, I just wish I could use my two-factor authentication on Google to sign in to any site on the internet, and disable all other methods of signing in. Bonus points if I could do it anonymously. Meaning, the site never has any idea of who I am.
- marshray 15y ago
  How would that work anonymously? Usually the purpose of "signing in" is authenticating who you are.
  - aero142 15y ago
    Most logins are just a way of showing that you are the same person that logged in previously. Gmail is an often public identifier that could link to you IRL.
rwj 15y ago
Is there plans to support sharing you keys between devices?
kijin 15y ago
Interesting concept with an unfortunate name. Foarnicate? Foarnicator? With just the right font and kerning, "m" becomes indistinguishable from "rn". Also, a common problem with all browser-based authentication systems seems to be what happens when the user loses the browser. (Hard drive failure, theft, etc.) With LastPass, I can retrieve my passwords by reinstalling the add-on and entering my master password, because all the data is kept on their servers. With browser-based authentication schemes without a central server, once you lose your browser, it's gone. It's also virtually impossible to remember a randomly generated private key, unlike even a 10-word passphrase. So I'll only ever be able to use this with unimportant sites, not e-mail or banking. I see that this problem is mentioned in the "technical limitations" section, but any good idea to fix this without asking users to trust a central server?
- Myrth 15y ago
  I also had to double take on the name... For issue with losing the browser key, probably can be resoled by having a prominent backup/restore on USB drive feature.
  - kijin 15y ago
    Well, the problem is that ordinary people don't take regular backups, right? I don't think it can be solved by bugging people to back up more often. Next thing you know, people will be asking on forums how to disable those annoying backup notifications.
- georgemcbay 15y ago
  I have to assume the name is on purpose and Dan Fox (the author) thinks it is clever. While the cleverness of the name is debatable (likely depending partially on how old you are), the name basically guarantees that a large portion of the population won't take this project seriously. I'm very liberal and far from a prude and the name just makes me eye-roll/groan and assume the worst about the maturity of the project owner. Save the clever names for bands. If you want your work to be taken seriously in a computer security context, come up with something less likely to make an 8th grader snicker.
jarin 15y ago
What's the difference between this and just storing a long session ID in cookies?
- marshray 15y ago
  Attackers haven't gotten around to writing a tool to grab the private key along with the cookies yet.
jacquesm 15y ago
Finally expertsexchange.com has competition.
- billybob 15y ago
  Foamicate: foamy fornication. Uh... maybe that wasn't what they wanted to get across?
  - cynwoody 15y ago
    Once they launch, they should recruit Senator Santorum for their board.
7952 15y ago
Surely the only real advantages are: - Server has no knowledge of password, and less knowledge than a hashed password. - Master password based private key is possibly more secure than a cookie. However, if the client machine is compromised a virus could get hold of the private key, and have access to numerous websites. The best way to improve security is to have a third party login provider (openid, Google, Facebook etc), preferably with three factor authentication. This allows the client, and the server to be compromised, and still limit damage.
- joe_the_user 15y ago
  Third party logins really don't supply any enhanced security as such. But they do supply more "security theater" which is not actually what you want. Three factor does provide more security but there's no reason to involve a third party - in fact, the more parties, the more likely someone is to fumble something.
  - Spearchucker 15y ago
    You're right. It's the poor man's identity federation. Before I start, let me make myself very clear - I think Dan did an awesome job with Foamicate. Seriously. One guy. The balls to put something out there that's innovative and seeks to solve a REAL problem. I'm impressed. And if I were in a position to, I'd ask Dan to work for me. That said, it's worth (IMO) considering what an identity system should provide - User Control and Consent: An identity system should only reveal information identifying a user with the user's consent. The Facebook/Google/OpenId model fails this one. Minimal Disclosure for a Constrained Use: The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution. Again, OpenId falls short in that the identity provider knows where the user is going. Justifiable Parties: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship. Microsoft Passport is a great example of why this's a bad idea. Directed Identity: A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles. My Facebook identity is public, but I can't and shouldn't use that to access a private resource like a collaboration site on my company's extranet. Pluralism of Operators and Technologies: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers. The part where anything that's exclusively browser-based fails. The same system should work online, from a phone, and from a PC or server running any arbitrary OS. Human Integration: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks. UX. The usability problems with Foamicator have been discussed here already. Consistent Experience Across Contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies. A smart card is a good example of this - I have a card for cash, a loyalty card for coffee, and an access card for work. Using them is consistent, event though their context is not. The only technology I know of that meets all 7 laws is information cards (Higgins Project, and CardSpace). Information cards haven't taken off because adotpion by identity providers is, well, basically zero. Which is a shame. Anyway, if you're interested in this you can find more information at http://www.identityblog.com/ http://www.identityblog.com/.
marshray 15y ago
There have been several security systems over the years with this same problem. The issue is basically here: Step 1: Require users to install a binary plug-in. (OK, the website doesn't exactly say it that way.) But web security begins and ends at the user. All of the security depends on the user noticing security warnings and then refusing to continue. Look at it from the user's perspective. "In order to create an account on this website you must turn off your malware blockers, click here, then click 'OK' to the next 3 warning screens that are going to tell you that what is about to happen is a really bad idea. Trust us, we're legit." I would wager any site that places selection pressure on their userbase to favor those who agree to install random binary stuff from the web is going to have more issues with user credentials than those which do not. Disclosure: I work for an authentication company (PhoneFactor) that has replaced these plugin-based systems in the past.
- thematt 15y ago
  We use PhoneFactor at work for authenticating VPN access. Great system, very easy to use.
  - marshray 15y ago
    Glad you like it. :-)
- igrekel 15y ago
  Not to mention the other problems with using key based authentication with an unsophisticated client. - User A at client company X is the one usually using the system - User A goes on Vacation - User B needs something from teh system, they forgot to plan this before A left. They call A to ask the password...
  - marshray 15y ago
    ...User B can't get the password with which to impersonate A. Login authentication is working as designed. This is a feature, not a bug. If User B needs access to something controlled by User A, they need to talk to their admin.
jonny_eh 15y ago
This won't work for iphone users, right?

63 points by romaimperator 15y ago

guan 15y ago

Foamicate uses a browser extension. Is there any reason the client side portion can’t be implemented in JavaScript with keys stored in localStorage?

tomkinstinch 15y ago
Does Chrome sync localStorage among browsers?
- guan 15y ago
  I’m not sure; would you consider that a good thing or a bad thing for this purpose? If you consider it a bad and a security risk, then I would answer that the RSA private key would still be protected by a master password on the client side. You essentially end up with a solution like LastPass or 1Password with a different password for each service, with the added benefit that the server only has the public key so users aren’t affected if attackers obtain a copy of the server database. If a good thing, well, it’s not clear to me that Foamicate syncs across browsers either.
  - romaimperator 15y ago
    Right now it does not. I can't think of a way to sync across browsers without syncing first to a remote server and I'd prefer not to require people trust my server anymore than they have to. I plan on adding in import/export of the database soon. Here's the roadmap for the addon https://github.com/romaimperator/Foamicator/wiki/Roadmap https://github.com/romaimperator/Foamicator/wiki/Roadmap.
- rorrr 15y ago
  Not yet. There's a feature request from a year ago: http://code.google.com/p/chromium/issues/detail?id=84510 http://code.google.com/p/chromium/issues/detail?id=84510

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

deleted 15y ago

[deleted]

mbleigh 15y ago

Mozilla has already been working on a standards-based implementation of user agent authentication: https://browserid.org/ https://browserid.org/

bri3d 15y ago
Foamicate looks much more decentralized - while it's possible to run your own BrowserID server, the recommended production setup is to authenticate users against the central browserid.org federated sign-on service. At any rate, I think we learned from OAuth 1 that 18-step, cryptographically involved sign-in processes aren't going to be widely adopted by developers.
SMrF 15y ago
I'll be surprised if a widely adopted single sign-on solution emerges from a standards body. Standards should be formed from working code, not the other way around. Also, I'm not sure what standard you are talking about. They have a very nice spec here: https://wiki.mozilla.org/Identity/BrowserID https://wiki.mozilla.org/Identity/BrowserID But this is not a standard. Mozilla's contribution to this space is obviously going to carry more weight than foamicate, but I say let the best solution win and let's see what else we can come up with. Don't shoot this down by saying it's not a standard.

krupan 15y ago

Higher security, and not needing to type passwords on my phone would be awesome.

daenz 15y ago

I read this as Foarnicate.

sgdesign 15y ago

This looks like a cool technology, so sorry to be somewhat off-topic. But unless there's something I'm not getting, isn't this a really bad name? Basically one letter change away from reading like "Fornicate"…

fredley 15y ago
I agree, name isn't great, and I think the description of what it is/how it works needs work if this is going to take off. If you don't know what RSA/public key cryptography is already, you're going to have a hard time digesting the text on this site.
ComputerGuru 15y ago
Honestly, I read this headline bleary-eyed from a nap.. and that's what I saw until I did a double-take. It's not the fact that it's a one-letter change, it's the fact that rn is m minus a pixel here and there.

VikingCoder 15y ago

At this point, I just wish I could use my two-factor authentication on Google to sign in to any site on the internet, and disable all other methods of signing in. Bonus points if I could do it anonymously. Meaning, the site never has any idea of who I am.

marshray 15y ago
How would that work anonymously? Usually the purpose of "signing in" is authenticating who you are.
- aero142 15y ago
  Most logins are just a way of showing that you are the same person that logged in previously. Gmail is an often public identifier that could link to you IRL.

rwj 15y ago

Is there plans to support sharing you keys between devices?

kijin 15y ago

Interesting concept with an unfortunate name. Foarnicate? Foarnicator? With just the right font and kerning, "m" becomes indistinguishable from "rn". Also, a common problem with all browser-based authentication systems seems to be what happens when the user loses the browser. (Hard drive failure, theft, etc.) With LastPass, I can retrieve my passwords by reinstalling the add-on and entering my master password, because all the data is kept on their servers. With browser-based authentication schemes without a central server, once you lose your browser, it's gone. It's also virtually impossible to remember a randomly generated private key, unlike even a 10-word passphrase. So I'll only ever be able to use this with unimportant sites, not e-mail or banking. I see that this problem is mentioned in the "technical limitations" section, but any good idea to fix this without asking users to trust a central server?

Myrth 15y ago
I also had to double take on the name... For issue with losing the browser key, probably can be resoled by having a prominent backup/restore on USB drive feature.
- kijin 15y ago
  Well, the problem is that ordinary people don't take regular backups, right? I don't think it can be solved by bugging people to back up more often. Next thing you know, people will be asking on forums how to disable those annoying backup notifications.
georgemcbay 15y ago
I have to assume the name is on purpose and Dan Fox (the author) thinks it is clever. While the cleverness of the name is debatable (likely depending partially on how old you are), the name basically guarantees that a large portion of the population won't take this project seriously. I'm very liberal and far from a prude and the name just makes me eye-roll/groan and assume the worst about the maturity of the project owner. Save the clever names for bands. If you want your work to be taken seriously in a computer security context, come up with something less likely to make an 8th grader snicker.

jarin 15y ago

What's the difference between this and just storing a long session ID in cookies?

marshray 15y ago
Attackers haven't gotten around to writing a tool to grab the private key along with the cookies yet.

jacquesm 15y ago

Finally expertsexchange.com has competition.

billybob 15y ago
Foamicate: foamy fornication. Uh... maybe that wasn't what they wanted to get across?
- cynwoody 15y ago
  Once they launch, they should recruit Senator Santorum for their board.

7952 15y ago

Surely the only real advantages are: - Server has no knowledge of password, and less knowledge than a hashed password. - Master password based private key is possibly more secure than a cookie. However, if the client machine is compromised a virus could get hold of the private key, and have access to numerous websites. The best way to improve security is to have a third party login provider (openid, Google, Facebook etc), preferably with three factor authentication. This allows the client, and the server to be compromised, and still limit damage.

joe_the_user 15y ago
Third party logins really don't supply any enhanced security as such. But they do supply more "security theater" which is not actually what you want. Three factor does provide more security but there's no reason to involve a third party - in fact, the more parties, the more likely someone is to fumble something.
- Spearchucker 15y ago
  You're right. It's the poor man's identity federation. Before I start, let me make myself very clear - I think Dan did an awesome job with Foamicate. Seriously. One guy. The balls to put something out there that's innovative and seeks to solve a REAL problem. I'm impressed. And if I were in a position to, I'd ask Dan to work for me. That said, it's worth (IMO) considering what an identity system should provide - User Control and Consent: An identity system should only reveal information identifying a user with the user's consent. The Facebook/Google/OpenId model fails this one. Minimal Disclosure for a Constrained Use: The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution. Again, OpenId falls short in that the identity provider knows where the user is going. Justifiable Parties: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship. Microsoft Passport is a great example of why this's a bad idea. Directed Identity: A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles. My Facebook identity is public, but I can't and shouldn't use that to access a private resource like a collaboration site on my company's extranet. Pluralism of Operators and Technologies: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers. The part where anything that's exclusively browser-based fails. The same system should work online, from a phone, and from a PC or server running any arbitrary OS. Human Integration: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks. UX. The usability problems with Foamicator have been discussed here already. Consistent Experience Across Contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies. A smart card is a good example of this - I have a card for cash, a loyalty card for coffee, and an access card for work. Using them is consistent, event though their context is not. The only technology I know of that meets all 7 laws is information cards (Higgins Project, and CardSpace). Information cards haven't taken off because adotpion by identity providers is, well, basically zero. Which is a shame. Anyway, if you're interested in this you can find more information at http://www.identityblog.com/ http://www.identityblog.com/.

marshray 15y ago

There have been several security systems over the years with this same problem. The issue is basically here: Step 1: Require users to install a binary plug-in. (OK, the website doesn't exactly say it that way.) But web security begins and ends at the user. All of the security depends on the user noticing security warnings and then refusing to continue. Look at it from the user's perspective. "In order to create an account on this website you must turn off your malware blockers, click here, then click 'OK' to the next 3 warning screens that are going to tell you that what is about to happen is a really bad idea. Trust us, we're legit." I would wager any site that places selection pressure on their userbase to favor those who agree to install random binary stuff from the web is going to have more issues with user credentials than those which do not. Disclosure: I work for an authentication company (PhoneFactor) that has replaced these plugin-based systems in the past.

thematt 15y ago
We use PhoneFactor at work for authenticating VPN access. Great system, very easy to use.
- marshray 15y ago
  Glad you like it. :-)
igrekel 15y ago
Not to mention the other problems with using key based authentication with an unsophisticated client. - User A at client company X is the one usually using the system - User A goes on Vacation - User B needs something from teh system, they forgot to plan this before A left. They call A to ask the password...
- marshray 15y ago
  ...User B can't get the password with which to impersonate A. Login authentication is working as designed. This is a feature, not a bug. If User B needs access to something controlled by User A, they need to talk to their admin.

jonny_eh 15y ago

This won't work for iphone users, right?