My favorite bit: "Passwords may contain no more than two identical consecutive characters in any position from the previous password".
How would they know that unless they have your previous password in plaintext?
Security Fail
How would they know that unless they have your previous password in plaintext?
Security Fail
Whenever the user changes a password, the user has to provide a (single) previous password. This password is hash-checked against the current user password. Then the password duplication rules are applied.
(Note, none of the above should be construed as an indication that I agree with this approach to password policy :) )
What about if you forgot your password? (which I feel is the scenario I usually change a password in) Do they just ignore that rule in that case? If so, whats the point of having the rule?
So, to answer your question:
Do they just ignore that rule in that case?
That case should not even happen in the first place.
Your premise is basically false. A system administrator should be able to reset a password.
But in the end, none of that really keeps people from inventing new, easy to remember, and insecure passwords. Eventually people do learn to just alternate between about three different forms of passwords. IMO, most of these draconian policies are invented to make things look secure more than to provide real security. That seems appropriate for the TSA, right? :-)
'this_is_my_password" => hash1 'hash1_t' => hash2 'hash1_h' => hash3 etc
This way, when you enter the first character of a new password, they can hash it against your old password, see if it creates hash2 and refuse permission to use the new password. Hopefully this is the same way as websites can ask for only selected characters from a password when you log in.
I suppose since it's the TSA, they may use encryption and an HSM instead of hashes.
So you can assume the algo is public and the salt too (assume someone has a dump of your source code and your database - how do you keep the salt secret? You can't. This is the case where all the effort to protect passwords and use strong hashes is aimed at.)
The solution of "enter your old password" when you enter the new one is simple and doesn't compromise security.
The odds of a phisher who knows a bunch of valid Facebook credentials getting into any significant percent of the corresponding accounts are pretty low.
EDIT: If you want more protection than this, you can also turn on 2-factor authentication for your account, with "Login Approvals:" https://www.facebook.com/settings?tab=security§ion=a.... I don't think I have the ability to do this at login time with my bank (though they do offer / require it when taking high-risk actions like initiating transfers).
All that being said, you're absolutely right that sharing passwords across sites is a bad idea.
My point was more that - as a user you should not expect a site like Facebook (or Twitter or FourSquare) to spend as much time firming up their login system as you would your bank.
The fact that you actually do so is a nice bonus. But users would be well-served by not expecting the same level of attention to security from social sites and treat them accordingly.
(And sorry if I came off as being unfair to Facebook. I meant my comment to apply to that genre of sites in general)
One way around this is using SSO with a site who does spend a lot of resources on making their login system secure. For example, using Facebook Connect is a great way to get all that security (plus all our fake account detection) and the added bonus of not having to store (and properly hash) passwords. If only RockYou, Gawker, Sony and others whose credential databases have been compromised had done something like that... Fortunately, we have an answer even to problems like that with 3rd parties: http://bucks.blogs.nytimes.com/2012/04/02/how-facebook-tries.... I've spent multiple nights up late trying to crack hashed passwords on a big dump before attackers can, so we can help the victims who shared credentials between the compromised site and Facebook secure their accounts.
I'd love to raise awareness around the stuff we do to protect users. We've done blog posts and people have written articles, and users often see this stuff when e.g. they're traveling (ever been asked to identify photos of your friends?). What else do you think we could do?
Here are some example articles about what we do around login security - if you're interested, check out http://www.facebook.com/security to see other related stuff. https://www.facebook.com/note.php?note_id=10150172618258920 https://blog.facebook.com/blog.php?post=389991097130 https://www.facebook.com/note.php?note_id=425136200765
With the downside of compromising your users integrity and open your users up to even more tracking as well as relying on a 3rd party for a system-critical component and force your users to sign up for a facebook account.
Storing and properly hash passwords is not hard to do.
While I appreciate the work you do, facebook connect (as well as most, if not all, similar solutions) just sickens me and any service that exclusively rely on it is just pathetic (for the reasons above).
Todo: Create multiple fake facebook accounts for such services, can't believe I haven't done this already.
If you would just care to acknowledge that there might be potential issues with the things you mention your posts wouldn't seem like pure PR-statements.
Obviously using Connect means that there's a 3rd party with some data about your users. IMO that's worth the tradeoff, but if you feel differently, then don't bother with Connect (though I'm curious what concrete concerns you have, more specific than just "opening them up to even more tracking").
As far as reliability goes, I agree that minimizing external dependencies is a good idea. Again, this is a tradeoff - you're saying "I want to work on things that are specific to my app or site, not this boring login stuff that has already been solved." I suspect that in reality, our uptime is good enough that sites are more likely to notice issues from their own (or their hosting provider's) instability than from ours. But you're right - this does introduce the possibility of login being broken for your site if Facebook is broken. Hopefully the benefits Connect offers outweigh this risk, but again, you're fee to not use it.
> Storing and properly hash passwords is not hard to do.
Perhaps it's not that hard, but many still people fail to do it properly. And it's still not a silver bullet - even properly hashed passwords, when exposed from a compromised DB, can be reversed. Regardless, this is only a small part of the problem - dealing with stolen (e.g. phished) credentials is another, arguably more important, problem that's much more difficult.
> Todo: Create multiple fake facebook accounts for such services, can't believe I haven't done this already.
Please don't do that. We're pretty aggressive about proactively seeking out fake accounts and getting rid of them, and as a result I imagine this would end up being a pain in the ass for you. I'm curious what threat this mitigates?
As a user: My integrity. I don't want to link accounts on otherwise completely different services. You have no business in knowing what other services I use and I see no, absolutely no, advantages to being forced to use facebook connect. As an alternative? Sure! But exclusively? No. You fail to mention the advantages with using facebook connect so I would really hesitate to call it a tradeoff when you have nothing to gain...
And as a user I'm not free not to use it... And facebook haven't exactly had a solid track uptime record, it has even deserved a poor reputation in that regard - sure it isn't that bad but thing with relying on external parties is that it can only get worse than handling it yourself.
http://www.pcworld.com/article/193423/facebooks_sneaky_apps_...
Perhaps it's not that hard, but many still people fail to do it properly. And it's still not a silver bullet - even properly hashed passwords, when exposed from a compromised DB, can be reversed. Regardless, this is only a small part of the problem - dealing with stolen (e.g. phished) credentials is another, arguably more important, problem that's much more difficult.
The problem isn't, and has never been, that it is hard. The issue at hand is incompetence in its purest form and nothing else. And such incompetence will bite you in the ass regardless. Sure, I'd prefer my password not leaking but just deriving your password from the domain name or something like that is simple enough to combat that. In any case that is a tradeoff that isn't hard to make.
External dependencies is not only something a developer has to take into consideration, as a user you have to keep track of permissions, ever changing security settings - but for what? If I don't want to link my music usage to my facebook account what possible can I gain from using facebook connect? Seriously? Have you guys even considered that scenario? Of course you have, you just couldn't give a shit about your users privacy or concerns. Rather make an easy buck than creating a good platform, just don't pretend you try to do both.
You can't seriously argue that having to deal with all that shit is easier than signing up for a new account for every service.
Please don't do that. We're pretty aggressive about proactively seeking out fake accounts and getting rid of them, and as a result I imagine this would end up being a pain in the ass for you. I'm curious what threat this mitigates?
Even spotify recommends you to create an empty account ;) There is nothing you can do to stop me and the huge relief for my ass would be to not being afraid of spamming my friends with my spotify usage, not having to even care how spotify/whatever uses my facebook account (and how facebook/services will handle this in the future, facebook has a terrible reputation of adding new options with questionable defaults). Is it so hard to grasp that these are valid concerns? Valid concerns that should never, in anyones wildest dreams, ever have existed.
There is nothing of value you can offer me but there are countless ways you can annoy the shit out of me. Solution? Create dummy facebook accounts. It is the only solution to the problem that you have created - suit yourselves.
I don't trust facebook and I don't trust anyone else having any form of access to my facebook account (also, I'm so old fashioned that I don't even run executables that I get in the mail of an unknown sender). Anyway, thanks for making the web a worse place!
If you ever find yourself working for someone other than Zuckerberg, please note that integrity issues is part of security as well.
Often times users change their password because they've forgotten the old one, so we cannot ask for their last password in that case.
In other cases, users may have a number of previous passwords (some of which we know to be compromised). We want to check against these lists as well, and asking the user to enter all their previous passwords is obviously unhelpful. They also are unlikely to remember which ones are compromised (because e.g. we detected an unauthorized login from them and the user confirmed that it wasn't him; or because we found them in a publicly-available list of credentials from a phishing site or 3rd party database breach).
Believe it or not, it is not so uncommon for LargeCorps to store passwords in a way they can be retrieved again at least in one place - which is usually their central identity management system. This helps them enforce password policies and expirations across a wide range of systems and gives them better control and overview of all the many user accounts lurking around on all their systems. And obviously being able to make sure all accounts of a user are properly locked or deleted is more important to them than giggling at centrally storing potentially tens of thousands of passwords.
The system I know and maintain stores your current password and history in an encrypted form and protects them through various means, so if you got a full DB dump you would still have to brute-force. Works pretty well for us and the advantages seem to greatly outweigh this downside of having passwords stored somewhere in a retrievable form. Plus in typical LargeCorp you have (more or less) sophisticated logging and monitoring tools on top of that so a lot of suspicious activities are detected pretty well. And there are a LOT of other LargeCorps I know of which are using that same product and on a global scale.
So, such a system is definitely overkill in ye-old startup webshop, if only for the insane bucks it costs, but for LargeCorps with way too many systems piling up it can be very valuable.