
I long for the future where I can safely assume my passwords are stolen - jenandre
https://medium.com/i-m-h-o/898b8f78b021
======
PaperclipTaken
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.

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.

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.

edit: <http://en.wikipedia.org/wiki/Public-key_cryptography>

~~~
switch33
This is a good idea; but if your single computer is hack'd that is just as bad
as if someone just got on your computer when you were just walking away and
you were still logged in.

It makes identity and account problems just as problematic.

I actually like the auditing idea; however I think he goes a bit overboard
about having GeoIP for every single login because I know many people log in
from tons of different locations all the time.

Maybe a more simpler alternative would work; but it needs to be well thought
out for sure.

~~~
6d0debc071
IP checking's not necessarily going to help. If I get your passwords, I'm
going to try them with every site I know about in a matter of seconds.

Public key crypto does seem to be a better solution - I've heard it proposed a
number of times among security people now. And it has some nice features even
when you assume that user computers are still vulnerable to attack.

• It seems to be a harder problem to hack all the users of a service than it
is to hack the service itself

• If you abstract the public key stuff into the browser nothing would change
in that regard. You can use different passwords packaged with your key.
Personally I don't think it's worth the bother if you assume that people tend
to use the same passwords but... whatever.

• You could do all the crypto on a token and use interface controllers to
reduce your attack surface there.

The difficult bit, as far as I can tell at the moment, is that it requires
people to know that there's a file they need to keep safe if they want to hang
onto their accounts. I really think you'd need a physical token to get it down
to the level that many people are capable of understanding, and then you'd
better pray they don't lose it....

If we're gonna trend that way, we add complexity - and that's not going to get
people to adopt.

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

~~~
rgbrenner
in what way? they have 2 articles on the front page, 0 on the second page, at
this moment.

~~~
pi18n
They've had quite a few posts on the front page in the last week or so.

------
jtheory
There are a lot of comments touting using public keys for this.

So, you have one laptop and one mobile phone. How do you set up your
"password" on both? Assume you're not "technical".

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.

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.

~~~
count
This is a solved problem. Look at CAC/PIV smartcards. Virtually anyone with a
computer is used to carrying around a credit card or ID card. Just add a PK
circuit.

~~~
jtheory
All of the problems I mentioned are solved for technical users, or special
situations with the right equipment available (like a CAC reader... I
certainly don't have one of those integrated into _my_ mobile phone, or laptop
for that matter).

That doesn't help when we need a _general_ solution with usability that comes
close to remembering a password.

------
jtheory
The first problem with myaudithooks.com is the vulnerability of the audit
site, _especially_ if this is a hosted service accepting login reports
streaming from lots of different sites.

I know, the actual usernames/passwords aren't part of the audit trail.

Or... the passwords aren't. The usernames probably are, because otherwise how
would this login report be linked to the right user?

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.

Alternative: don't crack it, just ruin it. How is myaudithooks.com going to
really lock down the API calls so that _only_ 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.

I do think the general idea is good, though -- just not centralized.

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)".

It's also hardly ever used.

I suspect some of the problem is that the _timestamp_ bit would make sense to
most users, but the _source_ is more likely to be confusing for the general
public. A raw IP address certainly won't be useful, and location is very scary
_if_ 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.

~~~
jenandre
The usernames do not need to be part of the audit trail -- the unique URL
identifies the site it came from. You know you your own logins, presumably, so
it doesn't need to be there.

myaudithooks.com should not be centralized -- I 100% agree. You should just be
able to put any old URL there. If I want my audit entries to go to my box, I
absolutely should be able to.

You're right, some attacker could post bogus information if the know the
url... however, the urls should be unique enough that they can't just be
randomly "guessed" by an attacker. Another alternative is to provide a
callback url, the way stripe does, so the service can "authenticate" the audit
log entry before I consider it valid. For example, if I receive an audit log
entry with id "abcd1234", I can hit <http://mydogfriends.com/audit/abcd1234>
to make sure it responds appropriately.

The idea isn't fully fleshed out yet, but I think it wouldn't take a lot of
work to make it happen.

~~~
jtheory
The really tricky bit is always figuring out how to apply the idea to the
general public.

Where would all the users who find websites by typing domain names into Google
ask mydogfriends.com to send their audit entries?

People running websites are also not necessarily technical -- often there was
a techie involved during set up, but then it's just "apply the wordpress
updates when it prompts you" and that's that. Support for audit trails needs
to be built-in by default if it'll be widespread.

Interesting stuff, anyway. It's worthwhile to keep fleshing out the ideas and
possible pathways.

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

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
<http://www.gpg4win.org/about.html> ).

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.

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

Wouldn't an attacker who's gained access to a secondary account through a
password derived from a db dump change the audit URL?

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.

~~~
chacham15
A user isnt only vulnerable when the db gets hacked. People have other ways at
getting at passwords (sometimes they guess). The idea is that if you see a lot
of incorrect password attempts, you also know that something funny is up. Or,
you could also see that a login attempt was issued from a computer in Nigeria
(even with correct credentials). Imagine if you got a popup on your phone
whenever you logged into your bank account. Wouldnt you feel a lot more safe
that no one else has your information?

~~~
glurgh
The scenario presented starts with a stolen db. Also it's about recording
successful, rather than unsuccessful logins.

Gmail is a good counter-example - it does tell you of your last login but who
keeps track of these? You log in from home, from work, from your iPhone, from
your friend's wifi, etc.

And you needn't stop there. What if the auditing service is compromised? What
if the convenience-inclined user is using the same password at
myfancyaudit.com as they are at mydogfriends.com and at their bank? Maybe I'm
missing something but it mostly seems like a way of shuffling trust around
without significantly improving security.

~~~
chacham15
Its not shuffling around security and neither is it adding any (at least in
the crypto sense). Rather, it is a post-mortem way of knowing whether
something is wrong. Assume that neither the auditing agency is cracked nor the
original service. If your password gets phished and the attacker logs in as
you, you will get a notification about it. Then, you can at least do something
retroactively (even seconds later if you get a notification on your phone) to
prevent further injury instead of finding out weeks later when all the damage
is already done.

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

... and since it relies on DNS, it's useless.

------
MarkMc
Humans are notoriously bad at choosing passwords, so what about this approach:

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.

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

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.

~~~
endianswap
That's just a bigger password that they're instructed to keep a copy of then?
If you're going to do that, just add a proper OTP factor like a SecurID token
that they can carry with them.

~~~
MarkMc
Yes a SecurID token is probably more secure than a piece of paper, but it is
also less convenient and more expensive.

Also, the piece of paper with 4 words will have 52 bits of entropy while a
SecurID token with 6 digits has only has 20 bits of entropy. So I wonder
whether SecurID would be easier for an attacker who has access to the password
hash and salt to derive the original password...?

In any case, whether you use a piece of paper or SecurID the main point is
that financial sites which only require email+password are being negligent in
their duty to protect user data from unauthorised access.

------
hooande
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).

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.

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.

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

~~~
drdaeman
Physical devices are there for a reason.

If some malware gets to your phone or computer, sniffs the password and steals
the keyfile it's over. There're no other options but to immediately revoke the
key. Hardware security tokens are specifically meant to mitigate this issue.

Otherwise, there're many software implementations out there. Your browser
should already have one (search for HTTPS client certificate authentication),
although it's not universal due to some X.509 PKI architecture constraints.

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

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

~~~
jacquesm
you're leaking a lot of valuable information here.

~~~
CurtMonash
If I can't keep my email address secure, I'm dead meat anyway.

And the fact that I have a number of websites is not exactly a secret.

~~~
CurtMonash
Umm, that could more accurately have been phrased "email accounts".

------
pallavkaushish
I tried using various Single Sign On solutions but somehow their system are
not satisfactory. I recently heard about this new company called SmartSignin -
<https://www.smartsignin.com> 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?

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

The doc is a bit outdated but the prototypes work.

[1] <http://www.thesibyl.net>

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

We need an open standard for this.

------
elchief
Just use Google OpenID on your site, then you don't have to worry about your
customers' passwords getting stolen.

Simplistic? Yup. Perfect? Nope. Does the trick? Sure.

~~~
venomsnake
And when google bans the account for no good reason?

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

------
EGreg
Or there is also this solution:

<http://www.faqs.org/patents/app/20120110469>

What do you guys think of it?

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

------
Spearchucker
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].

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.

Many comments here suggest the use of PKI. PKI is _part_ of a solution and, as
with logging and audits, requires more.

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 _can_ be
trusted.

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.

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.

The only viable choice then becomes the organisation that _already_ deals in
identity - government departments that issue passports, ID cards and driving
licences.

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

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

The tradgedy is that while these solutions exist, are mature and proven, there
is just not enough incentive to make them a reality.

Some closing notes: Any good identity system must adhere to _all_ the laws of
identity (<http://www.identityblog.com/?p=352/#lawsofiden_topic3>).
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...

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

[2] "This thing" is really an identity meta system.

[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).

[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 _must_ be claims-based, so
that it functions in a world of federated identities.

~~~
count
Isn't the issue with PKI the 'I', rather than the PK?

In the case of replacing passwords at a website, the issue of 'credibility' or
'trust' is irrelevant - you have no trust or credibility with a u/p, so why do
you need that with a PK?

If I'm just replacing user/pass with a PK, why do I need a CA and all the
infrastructure around that? The goal is to put something serverside that
cannot be used against me elsewhere - a 'public' token that lets us
communicate in secret.

The only concern is one of tampering, which would be a problem in either
direction anyway.

~~~
Spearchucker
Mostly because you need the "I". Unless you start accumulating PKs as we do
passwords. Some sites will require access revocation, others not. Some require
known identities, others not. Unless an identity system is ubiquitous it won't
gain widespread adotpion. For it to be adopted it needs to address every
scenario that an identity meta system faces.

~~~
count
Why can't I just use the same PK everywhere? The whole point is it's not
reversible to the Private key. Nothing else about how passwords are handled
would have to change.

