5 ms·

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

by 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/.
  - 7952 15y ago
    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?
    - marshray 15y ago
      So after the user securely logs on the virus can transact with the site using properly authenticated credentials? Unfortunately, this is a very prevalent feature of modern malware. This is seriously important question these days. It's where 'login authentication' ends and 'endpoint security' begins.
      - Spearchucker 15y ago
        Authentication is just an assertion of identity. End point security is an obvious consideration. There's also authorisation and perimeter protection. Defence in depth. Layer security like the layers in an onion. That said, economics dictates that you wouldn't spend $20 protecting a $10 asset.
        marshray 15y ago
        Authentication in general is the process of proving that something is 'true' or 'genuine', in this case an assertion of identity. You say endpoint security is obvious, and I usually agree with you. But I can't count the number of times I've had to retrace this methodically with when talking about systems with very smart people. The distinction between authentication and authorization too. Like you're saying, classical risk management says the $10 asset isn't worth $20 of security. Sony learned the fallacy of that reasoning the hard way. If you have a database of 100K usernames, passwords, and email addresses of folks who entered a contest to win free movie tickets, you might not value that asset particularly highly. But if you don't secure, it properly could cost you $M to clean up later. Personal information doesn't always behave like an typical 'asset'. Sometimes it's more like having a surplus of toxic waste. Shoot, I could talk about this stuff all day. :-)
- 7952 15y ago
  With federated login you only have one provider that ever stores your password. There are fewer password hashes (or plain text) floating around in random databases. You can change your password once, and change it for numerous passwords. It is just easier to maintain good security with one login instead of many. It may not be more secure than a perfectly set-up browser and server; but surely it is in typical circumstances. In the case of key fob style three factor authentication a shared secret usually needs to exist. If the password hash, and the shared secret are stored on the same database; a hacker could get access by only needing to compromise that one server. By offloading the three-factor to a third party you are reducing that risk. Even with SMS style authentication a temporary shared secret exists (the contents of the text message). Of course if you are using federated login, it does present a single point of failure. You could argue that a private key is cryptographically better than a shared secret. But if the client machine is compromised the additional security is useless; and just gives you a false sense of security.
  - Spearchucker 15y ago
    There are viable alternatives to shared secrets. Check out zero-knowledge proof. The Wikipedia entry is actually quite good (http://en.wikipedia.org/wiki/Zero-knowledge_proof http://en.wikipedia.org/wiki/Zero-knowledge_proof).

by 7952 15y ago

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/.
- 7952 15y ago
  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?
  - marshray 15y ago
    So after the user securely logs on the virus can transact with the site using properly authenticated credentials? Unfortunately, this is a very prevalent feature of modern malware. This is seriously important question these days. It's where 'login authentication' ends and 'endpoint security' begins.
    - Spearchucker 15y ago
      Authentication is just an assertion of identity. End point security is an obvious consideration. There's also authorisation and perimeter protection. Defence in depth. Layer security like the layers in an onion. That said, economics dictates that you wouldn't spend $20 protecting a $10 asset.
      - marshray 15y ago
        Authentication in general is the process of proving that something is 'true' or 'genuine', in this case an assertion of identity. You say endpoint security is obvious, and I usually agree with you. But I can't count the number of times I've had to retrace this methodically with when talking about systems with very smart people. The distinction between authentication and authorization too. Like you're saying, classical risk management says the $10 asset isn't worth $20 of security. Sony learned the fallacy of that reasoning the hard way. If you have a database of 100K usernames, passwords, and email addresses of folks who entered a contest to win free movie tickets, you might not value that asset particularly highly. But if you don't secure, it properly could cost you $M to clean up later. Personal information doesn't always behave like an typical 'asset'. Sometimes it's more like having a surplus of toxic waste. Shoot, I could talk about this stuff all day. :-)
7952 15y ago
With federated login you only have one provider that ever stores your password. There are fewer password hashes (or plain text) floating around in random databases. You can change your password once, and change it for numerous passwords. It is just easier to maintain good security with one login instead of many. It may not be more secure than a perfectly set-up browser and server; but surely it is in typical circumstances. In the case of key fob style three factor authentication a shared secret usually needs to exist. If the password hash, and the shared secret are stored on the same database; a hacker could get access by only needing to compromise that one server. By offloading the three-factor to a third party you are reducing that risk. Even with SMS style authentication a temporary shared secret exists (the contents of the text message). Of course if you are using federated login, it does present a single point of failure. You could argue that a private key is cryptographically better than a shared secret. But if the client machine is compromised the additional security is useless; and just gives you a false sense of security.
- Spearchucker 15y ago
  There are viable alternatives to shared secrets. Check out zero-knowledge proof. The Wikipedia entry is actually quite good (http://en.wikipedia.org/wiki/Zero-knowledge_proof http://en.wikipedia.org/wiki/Zero-knowledge_proof).