Regular reminder that new users in general don't care at all about the security of your site.
Most of your signups are not going to generate and store a secure password "just to try you out", as evidenced by the most common password here "123456". If you force people to signup to try your site/app, many (most?) of them are going to use a crap password. If you're _lucky_ that'll be 123456, and not their email/facebook/internet-banking password.
The answer isn't to try and force "good passwords" from users who don't care. Remember, by definition - they don't care.
We need to start trying to not require users to come up with passwords until they do care. Maybe just cookie me and let me tromp around as an unauthenticated user until I do something that needs me to set up a password-protected account. Maybe ask for my email and send me a login link that hooks me into my account/data without me setting a password (lets face it, your password security is going to fundamentally rely on the security of my email account, 'cause your "forgot password" story says you'll happily send a password rest link there, right?
I know Start-up-de-jour desperately needs "signed up user numbers" for their investor pitch, but that's not going to motivate me to stop using 123456 or password123 as a password when startupdejour.io demands I create an account just to look around.
Emailing a single-use "sign in link" to a user (Slack calls these "Magic Links") is the way forward. Yes, it move the single point of failure to the user's email account, but expecting the regular user to use (and remember) unique passwords for each service is impossible -- they simply won't do it. Plus, when/if your service is breached, you won't compromise all their other accounts as well.
It's really a shame that we haven't solved this problem yet as an industry.
I was thinking we could build a general purpose version of "Magic Links" for logging in, where the format of the email is well-defined, and the user's browser is able to receive these messages on their behalf through some form of integration. You could imagine a webmail provider offering some kind of polling or websocket API for listening for when these messages arrive.
When the site they're visiting indicates through its web page that, "I'm trying to authenticate you by email", then the browser can fetch recent incoming messages of this type, then parse them and display UI chrome like "Xyz.example.com wants to authenticate you". You click a button to log in passwordlessly, which involves sending an HTTP request to a link specified in the email. Coordination occurs on the server side and the login is allowed.
There are probably some details I'm not considering, but it doesn't seem like it'd be too hard to build a prototype, and if standardized and deployed it would eliminate the need for passwords. I gather that Mozilla Persona works along similar lines, though I confess to not knowing the exact details. There would be practical difficulties integrating all of these things together, though: email, browser, and website login, and gaining adoption in the real world.
There are also sites that don't require email on signup, but this feature could be supported only for people who want to supply email. The email address used for this feature could also be a different technical address unrelated to the primary mailbox, where only login requests are sent. This could also help expedite the email traffic to ensure it's real-time. The browser could automatically fill in the email address when challenged by a website supporting this login method.
Alternatively, perhaps a browser vendor could introduce a de facto standard where sites can integrate via an API with the browser's password safe features. Chrome can save passwords and synchronize them across devices. Maybe it wouldn't be too hard for sites to comply with a microformat that helps the browser understand when to generate a password on signup, and when to provide it, etc.
This has some advantages but there are negatives too. Do I really want Google or Facebook to get a notification every single time I log in to a service because they get an email with a "magic link"?
Google / Facebook already know enough about services used, do we really want to transfer even more information their way?
Also, another trouble with this is the loss of anonymity.
There are very few places to register an email address without an SMS number. There are few places to get an SMS without a real name and address.
Yes, I'm sure there are places to get these things for someone willing to put in a lot of effort, but for everyone else, their email provider has their SMS, their SMS provider has their name and address.
So by requiring email as authentication, essentially every online identity comes back to your real name and address through a small number of hops.
It used to be possible to spin up a TOR session and interact with real services you would otherwise use. Between the crunch on anonymous email and cloudflare's endless captchas, TOR is increasingly useless for interacting with normal services.
This is a feature, not a bug. Unfortunately it turns out that many people are abusive when anonymous and use that to their advantage so anonymity has been curbed to keep control over that problem.
> There are few places to get an SMS without a real name and address.
I'm building a service to solve this problem right now. It works already and I hope to make it live within the month, it just wants styling and polishing.
The idea is you sign up with just a username and password, no email address required. You pay with Bitcoin and can buy a mobile phone number, from a selection of countries, for ~$3/mo. You can then use the web interface to send and receive messages.
Email address in my profile - please get in touch if you're interested in learning more.
Mail.com? Outlook.com? A lot of them, if you provide an SMS number, you'll need to verify it, but you can skip it by providing security questions or an alternate email address (that itself does not need to be verified).
There are already Gmail/Microsoft/Facebook providing single sign on for users.
That doesn't mean applications are bothering to support them.
Actually, Facebook is ubiquitous for popular apps to the point it's often mandatory. (too bad for privacy :( )
Google App for business (and Microsoft to a less extent) have market shares among professionals but many SaaS and hosted applications cannot integrate with it at all.
Good points. I'm not proposing a single owner, but rather a federated protocol where sign-in operates over email with each person's mailbox provider. The hope is that each mailbox provider will provide the sign-in.
You seem obsessed with one implementation. Passwords themselves are obsolete.
Actually the problem is already solved for at least a decade: Certificate based authentication. Browsers support it. Try StartSSl registration, for example.
Yeah - but that's like saying "email security and integrity has been solved for two decades", while _technically_ true, how many of you have talked your mom through setting up PGP and had her then "just use it"? (or tried to handhold a less-than-technical colleague through getting a StartSSL account?)
I'm pretty sure if any service less-technical than a CA authority starts pushing wide-spread user-driven in-browser certificate-based authentication, within days there'll be scammers and phishers faking the setup process to install untrustworthy ssl root certs so they can mitm Paypal/Facebook/everybody... How would _you_ explain to your mom the difference between installing Pinterest's new authentication certificate, and installing, say, the Charles Proxy ssl MITM cert?
> How would _you_ explain to your mom the difference between installing Pinterest's new authentication certificate
Actually, even with current terrible UIs, there's a reasonably big difference between installing client certificate (there even used to be a <keygen> HTML tag for those - although it's unsurprisingly marked as "deprecated" now) and trusted CAs.
Browser vendors have refused to touch that for years, so everything PKI-related has a cryptic UI hidden beneath 3+ clicks deep in the most obscure settings dialog areas. And some pieces are completely missing, like session state management (it's just like with HTTP auth - there are hacks to implement it, but they're hacks).
Another issue is, with current implementations not really fancying the idea of CA-less self-signed client certificates, so you'll most probably need a certificate-per-site approach. And with a ton of certificates (even if they all for the same public key), you'll need to automatically sync them to another devices somehow.
(The usual reasoning for not doing anything I saw was "no one uses this". Sure thing, given it's barely usable.)
You can add multiple client sertificates to a single account for example in case of git hosting services. Why would it be impossible for other services?
I'm not a big fan of Steve Gibson, but his SQRL project looked very promising to solve the issue of passwords and password storage (both user and server side).
It's worth pointing out that in this particular case, some people will have created their Last.fm accounts more or less solely for use with Audioscrobbler, a protocol which allows them to track music listens through various third-party music players.
The important bit about that is that the Last.fm/Audioscrobbler account credentials get typed directly into the third-party players - usually there's no browser involved in authentication, and in some cases the players will also be on a mobile device.
There's a definite incentive for passwords to be simple (if you're going to type them in on a mobile keyboard) and weak (because it's just music metadata).
So, a 'magic link' style of logging in might work here, but it would have to be complemented by an easy way of generating auth tokens for player apps - for instance, short one-time-use codes that expire quickly.
I wrote a simple web app to work with last.fm's api. A little fiddly, but in essense it worked. Somewhere buried in settings were all the apps that have access to my account. I then went back to Spotify and noticed it wanted my username and password. And ever since, I just haven't been bothered. I'd rather some throwaway autogenerated app linking passwords and authenticating consistency.
Copying and pasting links isn't that hard. Go to last.fm, generate OTP token/link, paste into Spotify. Done. I should have some easy way to identify authenticated apps under my account and kick them out, or reset all.
Not all of us use Web mail. And I might not want a link automagically opened there and then, under a browser.
>Yes, it move the single point of failure to the user's email account
That is already the case for the supermajority of people. They use one email account for everything and you can simply "Recover Password" on various services once you gain access to their email account.
Not many people purposefully use unique, individual email addresses for every single service they sign up for...
This SO MUCH. I can't stand when I get an email, from some service that I haven't used in 10 years and that I have no recollection of actually signing up for, saying "Oh sorry we had a hackings. You need to change your password."
This happened with Yahoo's weird online publishing service thing. I don't even remember the name of it but one of my passwords was in their service and, at the time, I was using the same password everywhere. By the time I got the "Oh we got hacked" email, my twitter account was compromised as well as a few other sites. I didn't even remember signing up for their service let alone having an account.
I feel like some sort of regular clean out should also be standard. If I haven't looked at your site in 5 years, why would my account still be available? I know there are situations where that could cause problems but I'd rather lose an account for (random forum that I signed up for in 2008) than possibly have a breech that could, somehow, lead to my information getting stolen...
The security model based on passwords kept by site provider is totally broken. I, as a user, don't want to keep 20 different passwords for 20 different sites.
What I want, is host my own security agent through which I can talk with any site. If I want to authenticate with site x, I simply point it to my security agent url and that's that. Open ID was/is an idea.
This approach will drastically lower the incentive for an attacker. Each attack will only get the data of one user, not millions.
... Until the openid provider is breached, like LinkedIn was. Then you get access to everything for everyone.
Decentralized schemes are safer overall. Ideally you want something like what LastPass does: local credentials replicated on the network in encrypted form. This way you take away responsibility for safe storage from unreliable websites, but you don't place the whole burden on the user (as the data is replicated and locked by a single password).
I don't trust third parties, no matter who they are. Technology can be developed so that the burden on the user is reduced, but nodoby wants to go there, because after all companies do want to have as many data about the user as they can...
I don't trust 3rd parties but I do evaluate the threat that comes directly from large companies to be lower than the threat that comes from criminal hackers.
What on last.fm ever needs a secure password though? Maybe someone can listen to my premium radio if I paid for it, or scrobble as me, but I really don't care about either of those. As a user, a less secure password for sites that need less security just makes sense.
See, I disagree. I think scrobbling is Last.fm's biggest feature and it's important for them to keep it accurate. I would be devastated if someone messed up my scrobbles, I've been scrolling for 10 years and have amassed very nice statistics about my listening habits. On top of that I have to imagine they sell this data to record companies and the less accurate the data the less valuable.
why should users care ? what makes you think it's our job to make them care, we built another shitty system, it's not the users fault, asking them repeatedly to do something proven by cognitive science to be very challenging for most is just dumbness incarnate....
So why are we pretending they do - and requiring them to give us email addresses and set up secure passwords?
(Especially when the "upgrade password storage to something more secure than plain text or MD5" is constantly being deprioritised below "add features X, Y, and Z that the product owner claims our next three investors on our pitch schedule have Tweeted about in the last month"... "We'll 100% definitely get to it once Series A comes in. for sure! Except perhaps for the 7 million 'legacy users' we signed up with plaintext passwords during our growth hacking private investor and seed round stages...")
OpenID is dead thanks to OAuth. I hope IndieAuth could get some traction but the problem with it is that every user needs to have their own tld domain but many registrars and dns services don't even use two factor authentication.
I would like to see websites make password changing a simple and standardized API call. That way integration with things like 1password will allow it to automatically change the password with each login. Or I can schedule them all to be updated every day, etc.
This drastically reduces the amount of valid logins from a dump that's even just a few days old.
2factor is simply not enough (though I still want it for important logins). Automatic password changing would be complimentary.
>I would like to see websites make password changing a simple and standardized API call. That way integration with things like 1password will allow it to automatically change the password with each login.
There isn't really a need for a standardized API it would make things easier but if 1password wanted it's not a very hard thing to do without it.
All you need is to do an HTTP request to change the password most sites allow that to be done in a single request, CSRF might be an issue but non single action forms are usually not protected or there is no need for that and there are ways to bypass CSRF also.
For a company like 1password it wouldn't be hard to build a request profile for say Alexa 500/1000 and automatically change the passwords once a breach hits, I have a similar setup of several scripts that update the password for various services I have by generating a random password in Keepass getting the old password sending the password request post and updating the Keepass entry.
LastPass does this. I actually used it about a year ago to automatically change the passwords on about three dozen sites. It failed on two pages that had recently been updated. It's a very useful feature though.
>I have a similar setup of several scripts that update the password for various services I have by generating a random password in Keepass getting the old password sending the password request post and updating the Keepass entry.
You would benefit from open-sourcing them, so others could help you keep up with websites changing.
Automatic password changing would be a mess if you ever got locked out of your password manager, combined with the fact that if the protocol for password changing was to be breached, you'd be locked out of that account as well.
The protocol isn't any different than it is today you need to know the account and the current password, there isn't anything more to breach then today it's no different than any password change form.
If you get locked out of your password manager you are already fucked.
And in any case It doesn't prevent users from reseting a password manually directly on each site.
You can export passwords from your password manager to a text file on a thumb drive, and store that in a safe, secret place. It's not perfect but works OK if you don't change passwords often.
Because it still does exactly what I want it to do, and what I've wanted it to do since I signed up in 2004, which is keep logs of every song that I listen to. The user-generated content side of it was added after I signed up (I think?) so I don't see how I could really miss it.
You might be interested in https://libre.fm/ if you aren't confident about the future of Last.fm. It can be used as a drop-in replacement to track your music plays.
I'm annoyed that I didn't keep using it consistently. I even had it tracking usage from an offline iRiver H340 MP3 player - at the end of the day, I'd upload a database from Rockbox.
Oh you must have left awhile ago then. I agree they ruined the best music discovery service on the web, but even without it the site was dated but functional.. until last year.
Last year CBS decided the whippersnappers needed a redesign and took out around 80% of the features and put the site into a perpetual beta state.
Didn't really give up until they had the fabulous idea to replace direct streaming with playing poor match Youtube videos as radio. That killed radio finally and made a none functioning joke of the main reason I bought my network music player.
Was mad about that as Last radio was my first choice for work listening.
The site was dated as they were frozen in 2008 - After CBS bought them there was one update very soon after then the site didn't change at all until last year. Minor updates and bug fixes only.
As for the update last year, pretty and vacant, doesn't bring back the things I loved about the site, but lets me see lots of pretty graphs of things I'm not interested in. I took a look at libre fm after that, but that's even more abandoned.
It's tragic how corporate greed can kill such an awesome site. They wasn't even ashamed to ask for money in countries where they didn't had adverts while they were removing the features from its users.
Soundcloud launched in 2008. Spotify launched in 2008. Only a year or so after Facebook opened signups to anyone IIRC. Not exactly sure what the impact on Last.fm would have been but it evidently wasn't good.
You can get even better idea of their site growth (or lack thereof) from the above link (scroll to the bottom of the page) http://www.leakedsource.com/blog/lastfm
You don't even need a breach to hack 123456, I expect it to be in every pentester's top20 first-tries (contingent on whatever profile they have on the target, obviously).
> The number of passwords and the severity of the hack was not uncovered until today. The passwords were stored using unsalted MD5 hashing
I'm 100% sure it was known it was MD5 before, and I'm 100% sure I've seen pastebins with lots of successfully bruteforced hashes, because my password was among them.
> it’s 2016 people — use a platform like LastPass to generate randomized, complex passwords that are unique to every service for which you sign up.
Another way to read this statement is that passwords simply doesn't work. We need something different. Something better.
And from the comments we find this:
> I am a bit confused. The article states that this happened in 2012, why is it posted today? Something happened in relation to this breach?
I think this also needs much better clarification. What has happened since 2012 which makes this newsworth now? And where is the LeakedSource report they cite but never link to? Where can I get more info?
123456 is actually a /fantastic/ password if you don't care what happens to the account. If you aren't going to the trouble of using a password manager, and the account doesn't mean much to you, then using weak passwords like this rather than your "good" password is a great idea. Save the entropy for your email and bank accounts.
I see your point, but 123456 is still a stupid password. A brain-dead password scheme like "1 <NameOfMyCat> <Domain>" (e.g., "1 Snuggles last.fm") is just as easy to remember, won't show up in rainbow tables, is nominally difficult to brute force, and you're more likely to be able to use it, as opposed to '123456', which many sites will balk at.
(To be clear: I am not endorsing this scheme. It is superior to '123456', but it is still bone-headed.)
The point is that you should only use this kind of password in places where you really do not care about someone else getting access.
It doesn't really matter what it is. It matters that it's something you're not for a moment tempted to think of as a "real" password and that you would never dream of using for any account where a data leak would affect you, but merely as a "they're stupidly asking me for a password for an account I don't care about, so lets just give them this" token.
I'd lean towards agreeing with you that it's better to pick something else, but only to slightly reduce the inconvenience of someone messing with your account "just because".
123456 is literally in the top 10 list of worst passwords. You might as well not have any password at all. I agree that your banks and sensitive logins should have the better passwords, but you can have a decent password, it be memorable, and it still do its job on services you don't care as much about.
Speaking of Last.fm, I really wish the thing had app-specific passwords as an option. I've been shuffling between Linux music players as of late, with Scrobbling as one of my requirements. Most of them have just required a login and pass instead of using OAuth. It would be nice if last.fm let me authorize them on an app-by-app basis.
Man, I'm getting desensitized to the enormous numbers of accounts whose information gets leaked when a platform gets hacked. 43 million here, 68 million there. I'm semi-joking, but at this point it's almost like I need Facebook or Google level hacks (multiple hundred millions or billions) to actually think, "This is huge."
I've been thinking that for a while, but also how come it's never me? I've had accounts with several hacked systems and sure I try to have pretty strong passwords but... I appear to be safe every time.
Famous last words maybe, but then I'll just change my password?
You may appear safe but you never know... Services like Google and Facebook are pretty proactive about making sure unknown users can't access your account easily -- meaning that if someone from Thailand tried to access your account when you usually use it in the US from an unknown device, it'll generally not allow the login. But other services aren't as proactive and may be compromised, so it's definitely better to be safe. The best way is to use unique passwords for every service (or use OAuth with a service provider you trust), and a simple way to do that is with a password manager.
I personally recommend 1password, because they haven't had vulnerability issues like LastPass and don't store passwords in their cloud, but they store it in "your" cloud, e.g. iCloud, Dropbox, and it works very well on iPhone. But at the minimum just using a separate password for everything is the best way to mitigate these kinds of issues.
It looks like our current approach isn't working. What if we had each site publish its login/registration endpoints in a URL, e.g. .well-known/loginurls?
Then the password manager could detect you're trying to register or log in and log you in itself, generating your password in the process. Why aren't logins machine-accessible yet?
I made a similar proposal 3 years ago and submitted it to HN. There was a bit of interest, but a lot of people back then seemed to assume that passwords were going the way of the dinosaur anyway so why bother?
Now that Persona is defunct and there is no privacy-respecting alternative in sight, perhaps we can finally acknowledge the truth that passwords are here to stay for the foreseeable future.
Also, using .well-known looks better than what I originally proposed (header or <meta> tag). For maximim compatibility with existing systems, there should be an option for this URL to respond with the actual login URL as well as any restrictions on the password format (length > 6, numbers > 1, symbols > 1, disallowed symbol list, etc.)
Password managers already do that, they just check for password type field and the site.
Keepass does that pretty sure all the others also do.
But again what problem are you trying to solve? using password managers is easy as pie today including automating signup and generating passwords, most people do not use them.
I started using LastPass just the other day because the recent news made me nervous.
It's NOT easy. The interfaces are clunky. I have to pay to get some basic features like browser plugin. There's a lot of false positives (it suggests me sometimes to save a password even if the field is not for passwords.) Generating secure passwords is hard because some sites validate length and charset only serverside and the poor manager has the invalid password already saved. Some sites play tricks to discourage pasting passwords. More than once I was unable to log in LastPass's online vault because of an "temporary error".
All in all, it was horrible, ergonomy-wise. I don't wonder at all why people aren't using them.
You're totally right. I use 1password, love it, couldn't live without it, but forgot how unintuitive and tricky it is, until I helped my wife get setup on it.
It took a while just to get up and running with the app/browser plugin/her own account, and now it's going to take a while for it to be part of her regular workflow.
The very first login I gave her (online banking) had such a bad interface 1Password couldn't auto-login.
So the next lesson was "how to work around bad website UIs, using a variety of non-intuitive menus and keyboard shortcuts".
We both use Dropbox to sync our vaults, so then I was talking to her about 2FA (pro/cons for text vs. Google Authenticator app), off-line recovery codes, an appropriate 1pass master password, etc.
There's no way she'd happen across a PW manager and love it. She's using it only because I want her to have access to all our online financials, all of which have long randomly-generated passwords.
I wish you luck! FWIW, I've found 1Password to be consistently better than LastPass.
I'm using lastpass and I haven't had to pay for the browser plugin.
I've been using lastpass for the past year or so, and I've had no real issues with it ergonomics-wise. I can't even think of any sites off the top of my head that have given false positives.
It does seem painfully slow and unresponsive sometimes though, which isn't ideal. It's slow enough to disrupt my flow more than just typing in the same password for every website.
I could use the plugin for a trial period, but now it says that I have to be a premium member? Maybe it's because I also installed the app to my smartphone, thus my smartphone become the one device I can use the free version with?
Who wants to be helping every relative set them up and adding to the unpaid support load? So they get mentioned in passing and then people think "Yes, I should do that" and never bother.
A lot of my password usage now is for apps, not web. I still know of no good way to do this with a password manager other than lots of copying and pasting, which is even more cumbersome on a phone than on a PC. I favor the apps that allow me to use TouchID.
It would be nice if the EU would do something useful like require all sites to hash salted passwords and prohibit the use of weak hashes for new accounts. Instead we get the ridiculous cookie nag.
Another vote from a fellow European to keep Brussel bureaucrats out of internet.
They have no clue or somehow good intentions always turn our horrible.
An old saying about countries that can't get together a government (like ironically Belgium!) - - it's the best for the people for having a country without the government because then they can't make more stupid laws.
The tragicomic part is how they enforcing password complexity:
Your password is not strong enough. New passwords must:
Be at least six characters long
Contain one or more numbers
Include at least one of the following special characters: !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~, or a space
So password efZeLmur3ivio4t7 is not safe enough to be used by last.fm and they use md5 without salt to protect it?
A password that follows that "security scheme" is pass1!, which KeePass 2 reports as having a quality of 18 bits. efZeLmur3ivio4t7, an illegal password, has a quality of 86 bits. Whoever was responsible for that decision should be fired. Either implement a real password strength algorithm based on entropy, or don't implement any except maybe minimum length.
Yes, we could argue that user should use more secure password, but on the other hand, I always wonder why startups these days are still busy rolling out their own custom account management than leveraging OAuth or hosted solution like Auth0. Seriously, in how many cases do we have a feature that is so unique that is not available via these alternative solutions?
Even though I have 1password setup, I would be so reluctant to create new passwords, I'm more willing to use OAuth whenever I can.
Recommending a closed source cloud service to send all your passwords to in a thread on HN about a closed source cloud service that lost all passwords is a great way to demonstrate deep and fundamental knowledge about the principles of software security!
I spent 3 days off work a few weeks ago watching the Dota International and spent the whole time searching through my emails for 'account', 'registration', etc. trying to find everything I'd ever signed up to and finally move it all to a password manager because I really knew better and was lazy for the past several years. It took 3 days of like 6 hours a day half doing this to update all that I could think of and find. That ended up being about 150 passwords in total.
Even still, I missed last.fm and probably a whole host of other ones that I'll never remember. Passwords are a goddamn nightmare.
I don't know who's downvoting you - but this is a really important idea.
As a new curious user of your new startup's website, I don't give a damn about being "secure". I've probably given you a fake name and a stupid password just so I can poke around and see if your site sucks any less than the other 5 or 6 new sites desperately craving my attention this morning.
If I can get in and look around without having to lie about my personal details - you're _way_ more likely to get a"proper password" and my real contact details if/when I decide I'm actually gonna add you the the list of "stuff I use" instead of "crap I signed up for once and never went back again" or "site I used a few times but none of my friends signed up so I stopped going there".
OpenID was a solution for that, but it got turned into this horrible thing that is OAuth2.
Mozilla Persona could have been another solution – just log in with your browser account – but that got killed.
And in the current web, I’m not sure something like that will ever happen, as the web is moving even more away from universal standards, and towards more and more closed walled gardens.
Question about password best practices. Our site just went through pen testing, as part of auditing for PCI compliance.
One thing we got dinged on was that we don't keep a password history, so that the user can't revert to their previous password. The tester's report said, "This, in turn, results in users utilizing a single password for a long period of time, which may result in password disclosure"
It seems to me that this is the opposite of the truth. If I'm keeping a password history, then in the event of a breach, there is that much more data that would leaking, potentially disclosing password data if we made a mistake in the rest of how we handle it (hashing, etc.). And while I'm not a crypto expert at all, it seems to me that if there's a list of salted, hashed passwords, then given that the salt is a constant per user, an attacker would have some leg up in discovering the original password if there were many samples that included the same salt.
If I want to minimize the data I can disclose about users, I ought to minimize the amount of data that I'm storing about them.
It is a risk trade-off: letting the user reuse passwords used in the last X months is seen as less risky than storing the last 12 passwords (assuming the user is made to cycle their password monthly) if you are storing the credentials securely (if anything is plain or reversible, you need to fix that ASAP).
Having 12 strongly salted+hashed password strings is not going to help an attacker much compared to having 1, even if you use the same salt (though I've not doe the maths myself, you'll need to ask a cryto expert for actual risk figures).
You could of course use a different salt per stored password instead of per user, to mitigate this completely.
Remember that password reuse risk flows both ways: if they reuse the password in your application and your application is well written with regard to securely storing credentials, they may be reusing the same password in another application that is less secure so you are more at the mercy of the password data from elsewhere that is storing things plain.
PCI Compliance is kind of arbitrary. I once worked for a company that kept all their passwords in plain text, and still managed to get compliance. I was just an intern at the time, and I still thought that was kind of weird, especially since this was around 2011 and not the mid-90's.
Consider that leaking their past passwords only matters if they reuse them elsewhere.
If they reuse passwords, then chances are you will expose them just as much if you don't force them to rotate passwords, when they end up putting their password into a scam site or run by people who store plain text.
And if you don't check for reuse, you are not forcing them to rotate passwords.
In the face of that, you can't do much better than to make it harder for them to keep reusing passwords on your site so at least a password leak elsewhere won't expose their account with you.
(And re-using the salt is a mistake; don't do that)
Unfortunately it triggers any site that it doesn't explicitly know wasn't affected by heartbleed, which makes it trigger that vast majority of my passwords. This renders it more or less useless :(
Maybe now I can get access to my account. I forgot my password and tried to jump through their hoops to reaccess my account. They involved calling the support department during business hours. It was the holiday season, so I just gave up.
We've had zero knowledge password authentication protocols for 20 years. At this point, any pain and suffering from these leaks is blood on the hands of browser vendors and web standards bodies.
Hmm, I used to use last.fm, better change my password. Hmm, 1Password shows I was using a generated unique password, so that's good, though it wasn't as long and complicated as the ones I use now. And this password was generated June 7, 2012. Wait, when was the hack again? March 22, 2012.
Ah, looks like I was covered. But hey, now it's an even longer password with even higher entropy, so that's not a bad thing.
Be at least six characters long
Contain one or more numbers
Include at least one of the following special characters: !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~, or a space
There's no way I'll remember a last.fm password like that! :(
It's not that it's difficult; it's not a good idea. It does not increase randomness (entropy), and would probably decrease it. In that situation, update the hash with a new method upon login.
We really need some laws around this... Prison time for web developers that store passwords insecurely, and substantial fines for anyone whose password can be brute forced from one of these leaks.
As someone who has very strong feelings about sites not letting me choose secure passwords, or storing them insecurely...no.
Fines for storing passwords insecurely and getting breached, sure. This is already handled by PCI/HIPAA, but could definitely stand to be improved. Prison time? There's no possible way that would end well.
Fines for "anyone whose password can be brute forced from one of these leaks"? So that means 80% of people out there would be given "substantial fines". Not going to happen.
> So that means 80% of people out there would be given "substantial fines". Not going to happen.
How is that any different than giving speeding tickets? If you behave recklessly in a way that puts others at risk, you should have to make restitution to society.
Hmm not sure I understand your reasoning here.. You don't think there's a difference between speeding and choosing a weak password for a site like last.fm? The latter might be a bit silly, but how does it put others at risk?
With the Dropbox hack for example, the reason they got hacked is because one of their employees reused a password, presumably from another site that got hacked. So that's one vector, where every time a site gets hacked, people using weak passwords (and reusing them) create the risk of future hacks.
But more generally, exposing your account credentials allows others to impersonate you and potentially scam others, expose the data of others, etc. In the case of Last.fm there obviously isn't a ton of potential for abuse directly, other than maybe firing off fake song plays to pocket the royalties, but the potential for greater harm exists in the general case. E.g. consider the enormous percentage of credit card transactions that are fraudulent, largely because of scammers using PII that's stolen in these large scale hacks. That absolutely effects the fees and interest rates for everyone else using banks in any way, so even if your own identity isn't stolen you're absolutely still affected.
And even in some hypothetical scenario where the only person harmed would be the person using the weak password, there is still precedent for regulation because we have laws requiring people to wear bike helmets, preventing kids from smoking, etc.
Got it, I certainly disagree and don't think the 41.000.000 last.fm users (whose passwords were cracked in two hours) should receive a substantial fine. I don't think there's a whole lot of precedence for this type of legislation either; what you're suggesting requires at least two other crimes to be committed by someone else (before someone else would potentially be at risk due to the user's bad password choice) - in addition to recklessness on behalf of the service provider (which also may be regulated and/or illegal under PCI/HIPAA/etc as grandparent points out). In other words:
1. User signs up for a web service, uses weak password.
2. Web service recklessly stores passwords/hashes in an easily crackable way.
3. Someone hacks the web service, steals usernames and passwords/hashes, then leaks the data.
4. Someone potentially uses the leaked credentials/user information to impersonate user, commits identity theft, fraud etc.
5. User receives a "substantial fine" for using a weak password (like 96% of the users of this online music service).
I had written a more long-winded response, but it probably suffice to say that there are major issues/contradictions/implications of what you're proposing. Like how would you enforce it, should law enforcement only rely on data theft/leaks, or should they have direct access to all user databases for online services? How would they prove the integrity of the data leaks? How would you prove that the password is reused, and how'd determine the size of the fine? Does it matter if the password is strong, but reused and one of those services stores it in plain text and is hacked? Would it be legal to use a weak password for a service if the hashing algorithm is strong, or just as long as the service isn't hacked and the data leaked?
> How would they prove the integrity of the data leaks?
Most jurisdictions already have security breach notification laws. If you're already required to report data loss to customers and/or the government, then at that point I don't think it's unreasonable to require companies to provide a copy of any leaked credentials since they should all be deactivated anyway.
> How would you prove that the password is reused, and how'd determine the size of the fine?
If companies were required to turn over credentials that had been breached, then this would be determined from the entire set of breached credentials.
> Does it matter if the password is strong, but reused and one of those services stores it in plain text and is hacked?
Sure, that's exactly why you're not supposed to ever reuse passwords even if they're strong.
> Would it be legal to use a weak password for a service if the hashing algorithm is strong, or just as long as the service isn't hacked and the data leaked?
I think there should be some minimum entropy level that's required regardless of the hashing algorithm. E.g. given that passwords can be automatically generated and stored, there is zero reason ever to use a password that's less than 30 characters of completely random characters.
> what you're suggesting requires at least two other crimes to be committed
The fact that these crimes are interconnected is why such a law is needed in the first place. And all these attacks are automated, so if you're reusing your last.fm password on Facebook and it takes ten minutes to brute force your last.fm password, then your Facebook account is going to potentially be pwned in ten minutes and 1 second.
If there were some benefit to having weak passwords then that would be one thing, but the way I see it it's just people creating a national security risk out of pure laziness.
With a weak password, step 2 is redundant, even with more than the recommended rounds of bcrypt/scrypt, if your password is "123456" it's getting cracked.
verify(candidate, storedEntry) has to run in a time reasonable for a web service to handle, which means that 123456 is still going to get tried against all the accounts in a reasonable time.
Most of your signups are not going to generate and store a secure password "just to try you out", as evidenced by the most common password here "123456". If you force people to signup to try your site/app, many (most?) of them are going to use a crap password. If you're _lucky_ that'll be 123456, and not their email/facebook/internet-banking password.
The answer isn't to try and force "good passwords" from users who don't care. Remember, by definition - they don't care.
We need to start trying to not require users to come up with passwords until they do care. Maybe just cookie me and let me tromp around as an unauthenticated user until I do something that needs me to set up a password-protected account. Maybe ask for my email and send me a login link that hooks me into my account/data without me setting a password (lets face it, your password security is going to fundamentally rely on the security of my email account, 'cause your "forgot password" story says you'll happily send a password rest link there, right?
I know Start-up-de-jour desperately needs "signed up user numbers" for their investor pitch, but that's not going to motivate me to stop using 123456 or password123 as a password when startupdejour.io demands I create an account just to look around.