I long for the future where I can safely assume my passwords are stolen

There is a solution that is easier than auditing, found within the public key system. You could use the same password for every single website without any of them ever knowing what it is. You would instead associate your account with a public key and then use it to verify your identity every time you wanted to log in.<p>Then, the only vulnerability is your local machine. If someone hacks a website, the only password related information they can access is your public key, but you tell that to everyone anyway. They won't be able to use that to log onto any other website, even though you use the same password for all of them.<p>You would still probably want to use multiple public keys, and two-factor authentication (to eliminate the single-point-of-failure risk), but the technology already exists for us to be doing this. It just needs that extra layer that will make using such a system easy for grandma, and then of course for websites to start accepting public key authentication instead of password authentication.<p>edit: <a href="http://en.wikipedia.org/wiki/Public-key_cryptography" rel="nofollow">http://en.wikipedia.org/wiki/Public-key_cryptography</a>

Am I the only one who thinks that medium.com is abusing the HN ranking system?

There are a lot of comments touting using public keys for this.<p>So, you have one laptop and one mobile phone. How do you set up your "password" on both? Assume you're not "technical".<p>Next: your car (or apartment, etc.) is robbed. You lose both devices. OR: water damage. Whatever. You're away from home with one device, and its battery dies, wifi fails, whatever.<p>No worries, your brother/friend/colleague lends you a device. But... you're locked out of EVERYTHING on that device. All of your accounts require your public key, and you obviously don't have that at an internet cafe, or even at your brother's house, on a computer you're comfortable is safe.

The first problem with myaudithooks.com is the vulnerability of the audit site, <i>especially</i> if this is a hosted service accepting login reports streaming from lots of different sites.<p>I know, the actual usernames/passwords aren't part of the audit trail.<p>Or... the passwords aren't. The usernames probably are, because otherwise how would this login report be linked to the right user?<p>So then think about what you could do with that data, if you cracked myaudithooks.com. For the users/services using it, you'd have a comprehensive list (likely with usenames) of all of the sites these users access regularly, probably mostly with the same weak/reused passwords.<p>Alternative: don't crack it, just ruin it. How is myaudithooks.com going to really lock down the API calls so that <i>only</i> mydogfriends.com can report login events to mydogfriends.com... Otherwise you could have script kiddies just throwing in lots of junk data for fun, or a malicious attempt to discredit a bank, competitor, etc. by convincing many of their users (via fake audit reports) that their accounts are cracked.<p>I do think the general idea is good, though -- just not centralized.<p>Login auditing is good. I always appreciate the extra bit of info when I SSH into a server and see "Last login: (timestamp) from (IP.host.blah)".<p>It's also hardly ever used.<p>I suspect some of the problem is that the <i>timestamp</i> bit would make sense to most users, but the <i>source</i> is more likely to be confusing for the general public. A raw IP address certainly won't be useful, and location is very scary <i>if</i> they don't know it's not exact and sometimes wrong ("it said last login from the next town over... where my ex lives!!!"), and that means support costs for false positives.

Unfortunately, passwords are to account security what PHP is to web development. It may not be the best, it's not the fastest, it even may not be the most secure. But it's ubiquitous, it's free and if done right, it's an OK way to get the job done precluding more complex solutions that aren't as practical for most of us.<p>I think I posted this elsewhere or maybe here, but I got around the password remembering problem by keeping one master file of all passwords/usernames/emails etc... that I keep GPG encrypted ( specifically <a href="http://www.gpg4win.org/about.html" rel="nofollow">http://www.gpg4win.org/about.html</a> ).<p>All passwords in the master file are randomly generated. That is, of course, the account I'm creating is a throwaway at Paul's Peanut Brittle shop. Interestingly, paulspeanutbrittle.com isn't taken.

Wouldn't an attacker who's gained enough access to a system to get db dumps or modify serverside code to the point where they can capture incoming passwords simply turn off the audit calls?<p>Wouldn't an attacker who's gained access to a secondary account through a password derived from a db dump change the audit URL?<p>Beside that, knowing an account is compromised is better than nothing but often not particularly useful - see all the horror stories by people who've had their gmail account compromised. They tend to find out very quickly the account has been taken over, recovery is still difficult and the loss of data/time/neurons is often significant.

&#62; If I owned myaudithooks.com, I could have it email me based on certain rules. (...) I’d be able to sleep a little easier knowing that if one of my account credentials were compromised — whether it be due to my own carelessness or that of a random developer’s — I’d have a nice history and potentially even alerting so I know about it when it happens.<p>... and since it relies on DNS, it's useless.

Humans are notoriously bad at choosing passwords, so what about this approach:<p>When you register for an account you write down on a piece of paper 4 words chosen at random by a computer (eg. "regain gauge chest Texas"). Then to log you provide (a) your email address, (b) your password, and (c) the passphrase printed on the paper.<p>This is bit of a pain for the user, but it would greatly strengthen the security of the website because it would not depend on the security of any other websites. For a to-do-list website I can see it's not worth it, but I cannot understand how some financial websites still think it is acceptable to use only email+password authentication. (I'm looking at you, Mint.com and Schwab.com).<p>PS: I just tried registering for a Mint.com account - it didn't let me use "password" as my password, but when I used "password1" it said, "You have a Good password". Wow.

This sounds like a good idea. I think it gets one thing wrong: Hacking living social was not about gaining access to anyone's living social account. It was about getting passwords that were reused on sites that actually matter (banking, etc).<p>A notification that someone has logged into your livingsocial|facebook|twitter|linkedin is only valuable if it compels you to immediately change all of your other passwords. Which might be a decent idea for a version 2 of this hypothetical software...automatically change all of my passwords whenever one of my accounts is compromised.<p>The sad thing is that people reuse their passwords so often. Just remembering two passwords, one for important stuff and one for social stuff, would go a long way toward making this a non-problem and taking a security burden off of a lot of startups.

Why are we not already using the equivalent of an RSA token for authentication on the web? Of course, the physical token is replaced with a software app on your computer or mobile device. Is there something about the physical device that cannot be replicated in software?

1. This is an excellent idea, for the reasons stated. Auditing is a huge part of enterprise best practice; it should be best practice for consumers as well, and enterprises should help them with it.<p>2. That said, the number of sites for which we need really solid security is probably under 10. For me it's primary email, 3 for websites I own/hosting/etc., Paypal, bank, arguably Amazon, and not much else. And frankly I forget my bank password and have to keep resetting it (which is part of why my email needs to be secure).

I tried using various Single Sign On solutions but somehow their system are not satisfactory. I recently heard about this new company called SmartSignin - <a href="https://www.smartsignin.com" rel="nofollow">https://www.smartsignin.com</a> and their website says that their patented technology doesn't store your password anywhere so it's impossible to hack it. I don't know how they do it but I'm intrigued. Does anybody else know anything about them?

You might take a look here [1], using asymmetric crypto. We are still developing it but that is our approach. Yes, there is some overhead but you will need it anyway.<p>The doc is a bit outdated but the prototypes work.<p>[1] <a href="http://www.thesibyl.net" rel="nofollow">http://www.thesibyl.net</a>

This is a clever security enhancement and wouldn't be hard for anyone to implement. Login data could also be sent over email to a specified address.<p>We need an open standard for this.

Just use Google OpenID on your site, then you don't have to worry about your customers' passwords getting stolen.<p>Simplistic? Yup. Perfect? Nope. Does the trick? Sure.

While I agree with the premise of the article; the author's proposal is somewhat ridiculous. It faces pretty much all the same problems as OpenID.

Or there is also this solution:<p><a href="http://www.faqs.org/patents/app/20120110469" rel="nofollow">http://www.faqs.org/patents/app/20120110469</a><p>What do you guys think of it?

I long for a future where passwords are no longer necessary because the info you want to access is public anyway.

First, it's awesome that this rather important subject is getting attention, and kudos to Jen for giving it thought and providing a perspective [1].<p>Logging adds value once an account is compromised, so is a contingency measure (minimising impact). Solving this problem requires mitigation (minimising probability) as well as contingency.<p>Many comments here suggest the use of PKI. PKI is <i>part</i> of a solution and, as with logging and audits, requires more.<p>PKI's biggest problem is that it doesn't scale. The question then becomes one of issuance. Self-issued certificates have no credibility so cannot be trusted. That problem is solved by using a certificate authority that <i>can</i> be trusted.<p>That leads to the next question, which is whom to appoint as a certificate authority (CA)? This thing [2] should scale, so my certificate must work world-wide, with any web site and, while we're at it, offline in meat space.<p>That makes canidates like my bank or a credit check agency bad choices, because they haven't the reach. Credit card companies like Visa, AMEX or Mastercard have better reach, but that only accounts for a tiny percentage of the world's population, because it excludes the poor.<p>The only viable choice then becomes the organisation that <i>already</i> deals in identity - government departments that issue passports, ID cards and driving licences.<p>Of course that's just national. The solution to that problem is to federate identities between governments. Awesome. First part of the problem solved [3].<p>The next part of the problem is anonymity, and it's various variations. This can be solved by using a privacy-enhancing credential - a problem that was solved by Stefan Brands at Credentica [4].<p>The tradgedy is that while these solutions exist, are mature and proven, there is just not enough incentive to make them a reality.<p>Some closing notes: Any good identity system must adhere to <i>all</i> the laws of identity (<a href="http://www.identityblog.com/?p=352/#lawsofiden_topic3" rel="nofollow">http://www.identityblog.com/?p=352/#lawsofiden_topic3</a>). Technologies like OpenId, Persona and OAuth don't even come close. SAML and WS-Federation do a much better job of it, but both SOAP/XML-based. Which makes them unpalatable to many. There's an oppotunity in there somewhere...<p>[1] Logging has been done - just not at the scale Jens envisions. Many military and intelligence systems inform the user of previous acvitivy on login. The better ones use geolocation to tell the user where the most recent logins occured.<p>[2] "This thing" is really an identity meta system.<p>[3] This technology exists in the form of WS-Federation and, to a lesser extent, SAML (which relies on the browser, so doesn't work at the service level).<p>[4] Stefan Brands came up with U-Prove, which was open-sourced by Microsoft after they aquired the technology. IBM have also come up with a privacy-enhancing technology (PET) called idemix (identity mixer). An important attribute of any self-respecting PET is that it <i>must</i> be claims-based, so that it functions in a world of federated identities.