

Foamicate: A new system for authenticating users without using passwords. - romaimperator
http://foamicate.com

======
marshray
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.

~~~
igrekel
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
...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.

------
e1ven
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
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
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
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.

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

~~~
bri3d
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.

------
jacquesm
Finally expertsexchange.com has competition.

~~~
billybob
Foamicate: foamy fornication. Uh... maybe that wasn't what they wanted to get
across?

~~~
cynwoody
Once they launch, they should recruit Senator Santorum for their board.

------
kijin
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?

~~~
georgemcbay
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.

~~~
romaimperator
To be honest, I didn't think about the similarities between the words. I named
it that as an homage to the project's birthplace, a coffee shop named Foam
Coffee and Beer.

~~~
kijin
And yet, people are getting the impression that this has something to do with
Rick Santorum's frothy mix of you-know-what. I hope you find a more serious-
sounding name soon, before you take whatever the next major step in your
project is. What about foamauth? You could argue that it makes the traditional
login _form_ disappear into _foam_ , or something like that :)

------
sgdesign
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
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.

------
7952
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
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
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/>.

~~~
7952
Maybe add one more:

Allow user to securely login to websites from virus infested machine in an
internet cafe.

How do these various systems compare based on that law? Google one time
password or card space?

~~~
Spearchucker
Neither.

Google and identity is a bad idea regardless of the problem you're trying to
solve (<http://www.identityblog.com/?p=1204>). It's the worst of the three.

OTP is good, but challenge-response is better. Is your OTP from a second
factor?

Card Space is my personal favourite, but the [card] portability issue hasn't
been solved. U-Prove holds promise. CardSpace, with U-Prove and second-factor
challenge/response would be _awesome_ :-)

So as I said, neither of those is ideal.

But then I have solved exactly that problem (securely login to websites from
virus infested machine in an internet cafe) before, for the UK MoD.

I used identity federation (WS-*), and opted for Chip & PIN authentication on
the identity provider side, thereby cutting out replay attacks. The solution
is complex, and costs a lot more money than the average web site would be
willing to pay. Unless someone credible like the Passport Office or DVLA
volunteers as an identity provider.

Here's the case study.
[http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?...](http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000003478).

~~~
7952
So its an argument about which third party you trust? Google or the DVLA?
perhaps people trust google because they have to already. If you are running
chrome and using gmail you are implicitly trusting them with your data. I
agree that this is a bad way of picking a tehnology.

I like the chip and pin approach; its a good solution. Perhaps banks should
provide federated login. Do you trust them ? :)

~~~
Spearchucker
It's about context. I trust my bank for banking. I would trust the DVLA to
assert my identity where a directed assertion is required, and where I agree
to it. I don't trust Google at all because an ad company has _no_ business
looking at my email, let alone asserting my identity to third parties.

So technically I don't trust any third party. I trust some of them in varying
degrees based on what I'm trying to do.

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

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

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

------
guan
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
Does Chrome sync localStorage among browsers?

~~~
guan
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
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>.

------
jonny_eh
This won't work for iphone users, right?

------
daenz
I read this as Foarnicate.

------
rwj
Is there plans to support sharing you keys between devices?

------
VikingCoder
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
How would that work anonymously?

Usually the purpose of "signing in" is authenticating who you are.

~~~
aero142
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.

