2. Passwords must contain at least one of each of the following: one alphabetic uppercase, one alphabetic lowercase, one numeric, and one special character.
3. Passwords shall not contain any two identical consecutive characters (example: 22apples, 14588904).
4. Passwords may contain no more than two identical consecutive characters in any position from the previous password.
5. Passwords shall not contain any dictionary word.
6. Passwords shall not contain any proper noun or the name of any person, pet, child, or fictional character.
7. Passwords shall not contain any employee serial number, Social Security number, birth date, phone number, or any information that could be readily guessed about the creator of the password.
8. Passwords shall not contain any simple pattern of letters or numbers, such as "qwerty" or "xyz123".
9. Passwords shall not be any word, noun, or name spelled backwards or appended with a single digit or with a two-digit "year" string, such as 98xyz123.
10. Pass phrases, if used in addition to or instead of passwords, should follow these same guidelines.
11. Passwords shall not be the same as the User
12. Password length will be selected to provide a level of protection commensurate to the value or sensitivity of the resources or data it protects, but not less than eight characters.
That requirement actually isn't as rigorous (or as difficult to implement) as it sounds. The keyword there is "password" instead of passwords. Based upon similar systems, I feel comfortable that this is not a typo.
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 :) )
Whenever the user changes a password, the user has to provide a (single) previous password.
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?
I've just intentionally ignored that case in the past. :-) Ie, sending a password reset email will bypass the check, just as you suggested. There are some other things that people can (and I'm sure do) do to try to meet the requirement, but there isn't really a solution. For example, a lot of people who hit this restriction are just trying their old password with one or two characters appended, so you can try the hash of a few substrings of the new 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? :-)
The fact that you know your password is what identifies you as the legitimate owner of your account. If you forget your password, you can't identify yourself as the legitimate owner of your account and thus, to the eyes of the system, you aren't. And about the only person who should be able to change the password of an account is its legitimate owner.
So, to answer your question:
Do they just ignore that rule in that case?
That case should not even happen in the first place.
That's ridiculous. It is extremely easy to forget your password, that situation does happen and resetting passwords should be catered for in the system.
Your premise is basically false. A system administrator should be able to reset a password.
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.
Kerckhoffs's principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.
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.
I agree, but "password is not secure if everything about the system, except the key, is public knowledge" is better than "password is saved in plain text".
We only store hashes of your previous passwords - we never store them in plaintext. We don't have the ability to enforce a silly requirement like "none of the n grams in a new password can be the same as those in an old password."
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).
If your Facebook password and banking passwords are the same, or you believe your Facebook password is actually protecting anything you do there, then yes, you should be worried.
I'm curious what you mean by that. I work on security at Facebook (and actually help with the system that detects malicious logins), and think we have a pretty good / secure login system, even compared to a lot of banks.
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.
Alright - It's nice to know that Facebook has an industrial strength login system. Nobody would know that unless, like here, someone like you chimed in to mention it. (And thanks for that)
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)
It's true that a lot of sites don't go to the trouble of implementing particularly secure login systems (it's a lot of work!). Sadly I think this includes many banks.
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?
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.
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.
> 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.
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?
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 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.
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.
Glad it's helpful! If that's too hardcore for you, check out "Login Notifications" as well (on the same page). This sends you a text whenever someone logs in from an unrecognized browser (but allows the login).
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.
5. Passwords shall not contain any dictionary word.
Bear with me as I close my eyes and hammer wantonly on my keyboard:
kjhjks;dfijwefasdkfj
Aha! First try, and I've already generated an insecure password containing five dictionary words. Until vowels are banned as well, I fear our national security is in peril.
This looks exactly like the Dept of Energy password guidlines when I worked there.
For item #5, you should be aware that they check for dictionary words of 3 or more letters, both forwards and backwards. I'm not sure what dictionaries they were using, but I found that most of the Japanese, Russian and Finnish words/phrases that I frequently pick from were forbidden.
With all these restrictions, I wonder how far they are reducing the possible key space? Some of these suggestions actually remove a number of permutations - like for instance you can't put in two digit years - this must remove a HUGE number of combinations!
Then you remove ALL the dictionary words, all proper names, all the TSAs serial numbers, all reversed words - well, that's gotta make cracking an 8 letter password easier :-)
I actually did an analysis of that once but I can't seem to find it now. There actually is a pretty big reduction of keyspace (in the billions) but most of it is keyspace you don't want anyway. That is actually why the best policy is to have minimum length requirement of 12-14 characters and nothing else.
Not quote my point. What I'm saying is that you make an assumption that 8 letters are used due to the ridiculous complexity requirements. Then you get all the possible combinations of letters and numbers for 8 character passwords. Then you remove all dictionary words and reversed words, all dictionary words (and reversed words) ending with a year, all combinations with repeats, all serial numbers and known patterns (like ABC). Then you further remove from this list all the combinations that don't have mixed case, a number and a special character.
I'm interested in knowing how many possible passwords are left?
Using 94 possible characters for an 8 character password means there are 6.09568939 × 10^15 possible passwords. Removing even 20million means you still have 6.09568937 × 10^15.
There's a problem that people when faced with a dialogue box asking them for a password will be unable to think of a strong password, but that's solved by giving them some form of auto generation.
Writing passwords down is not a security problem, if the slip of paper is kept safely.
Because when it comes to changing passwords, it would take me about 45 minutes to come up with a new password that met the rules and had a reasonable chance of me remembering it. I took to writing them down as I was trying to come up with something, and keeping the paper handy for a few days because I'd frequently forget the passwords by lunchtime and lock myself out of the system.
One thing to remember about these rules is that there are some other ones not publicized. All you know when it refuses to take your password is that it says "password doesn't match" instead of "password doesn't meet the rules." I got some different error message when I tried using Russian obscenities, but I forget that error message.
> My first thought here is that if you are going to have such an extreme password policy, you could at least set the minimum password length to ten or even twelve characters
Well, and then in reality you have a couple of those old 40 ton host systems lurking in the basement and all its former tamers are long gone, everyone is just glad it is still running and somehow it only allows exactly 8-char passwords with characters and digits only... and somehow it still is one of the most fundamental systems of what you are doing on a day-to-day basis so if you are introducing a central password policy and maybe even a central identity management (which I assume those huge departments are using) then you have to make the bitter decision of accommodating for the "old timer" systems as well or leaving out the proverbial 20% of your systems that see 80% use each day...
My bank requires 8 to 10 characters, [a-z]|[A-Z]|[0-9] only.
They also require you to know something easily researched from facebook (elementary school, mother's maiden name, etc.) when you use a new machine.
That they refer to this as two factor authentication makes me question their ability to do simple addition, something I consider a fairly important skill for a bank.
That was another point I meant to raise. Even if your password policy and weak-password checks are sane, if your account recovery procedure is weak, there are still planet-sized holes in your security perimeter.
And for any large system (say, Facebook, with, oh, nearly a billion accounts), user support requests (many of which are access related) are a huge cost. It doesn't take many of these to eat through $2-$5/account/year value they're seeing.
Not that it excuses this so-called security, but for the insecurity question, you could just lie. Only problem is, then you have to remember your lies.
> They also require you to know something easily researched from facebook (elementary school, mother's maiden name, etc.)
I'll never understand why someone would provide this information to Facebook. My friends already know the details of my life relevant to our relationship.
maybe because they're part of a "$foo High School class of '99" group/page/whatever with some friends, or perhaps both parents and grandparents are linked as friends, making it pretty easy to figure out mother's pre-marriage surname?
It's not just the explicit facts you provide, a significant part of the deeper value is from the linkages between them.
Unfortunately, many banking web sites require short passwords with no special characters. Likely, due to legacy databases and storage. I've even seen 6 character max restrictions. Or worse, the 4-digit pin ones (10,000 combinations yikes, I sure hope they have a limit and lockout for incorrect guesses).
Oh god, PIN codes... Two years ago my girlfriend and I had to go to our banks and get cash. Luckily they're right across the street from each other, so we walk in to mine first. I go to the ATM, tap in my pin, do my thing and we move across the street. I'm standing by the door while my girlfriend goes to the machine. I'm still fiddling with the receipts in my pocket and whatever when I hear something. The ATM, plastered in signs to cover your screen, not let anyone see you putting in your pin, etc.– was calling the tones on the speaker. Anyone who cared to listen could hear her pin. I've yet to encounter another machine that does that, but man– if I ever got a hold of the who decided that a 4-digit pin was a good idea for security there would be quite an unpleasant exchange...
That would be Caroline Shepherd-Baron [1234] 'One by-product of inventing the first cash machine was the concept of the Pin number.
Mr Shepherd-Barron came up with the idea when he realised that he could remember his six-figure army number. But he decided to check that with his wife, Caroline.
"Over the kitchen table, she said she could only remember four figures, so because of her, four figures became the world standard,"'
My bank upgraded from a 4-digit pin code authentication to a 6-letter ([a-zA-Z0-9]{4,6}) system. About legacy databases ...
Naturally, I complained and they told me it wasn't that big of a deal, because the actual transactions were protected by TAN generators. I had no answer to that.
Maybe I'm confused, but are they saying that you do use independent 2-factor authentication? If so, then that does reduce the risks associated with a weak password, even if it would be better to use a strong password in combination.
Sorry for being unclear. For the actual transactions, there is a TAN required, but for sniffing around your transactions, seeing all your bank account information and so on, all you need to log in as the 6-letter password.
Surprised no one has mentioned OpLop for passwords. I keep a list of sites (containing a site nickname and a password hint). I then wrote a simple md5base64 perl script which combines the nickname and password (similar to OpLop..basically md5(nickname+pass)). Script throws the result on to my clipboard, and I hit paste. Thus, no two sites use the same password. If one site is compromised (ex: zappos.com), I just need to change that one password. Script is on my phone, desktop, and cloud drive.
I use multiple passwords, a different one based off the importance of the site. I was amazed at how many sites impose a 12 character limit (Fidelity...really?).
My personal favorites are the ones that silently truncate your password. A few have done this to me, and it used to take a while to realize wtf was wrong when I couldn't sign in right after creating an account. Now I just start shortening the password until it works, which 'fixes' a good 99% of just-signed-up login failures.
Yeah, I was annoyed by the 12-character limit at Fidelity too. They also prevent punctuation and other characters.
I think the problem is that they unify the website password with a password you can enter on the phone if you call them. I guess that makes it easier to remember for a customer so that they don't have two separate passwords, but touch tone-enterable passwords have completely different requirements from Internet passwords, so think it would be better to decouple them.
I personally believe that a great startup idea is a website or app that operates like KeePass or 1Password or Revelation, and allows you to enter your passphrase like xkcd suggests, and manages all of your other passwords and logins for you. I'm guilty of using the same password for a lot of sites, and I really need to get that in order. Making it easy for regular users to adopt would be key. It's an idea, I have no idea how you'd execute it.
That said, I'm developing a web-based management interface for my contract work that is only going to be used by a few key users/stakeholders. I'm trying to come up with a way incorporate xkcd passphrases into it, forcing my users to adopt it. I don't know how well it would go over though. Guess I just have to try it and see.
Compiling/sharing a list like this, so that it can be used in password strength checkers, would be a strong plus.
The best password is one that's never been used before. Rainbow tables and other methods mean that any known password (and in a list of exhaustively compiled passwords, finding only 1.3 million distinct values is "small") can be found very quickly given access to hashes, or tried relatively quickly via brute-force. Even a series of login attempts to known / common account names with top-50 (or some n) passwords will generate many hits.
I'd love to see online sites check against known lists. I've suggested it to several. One problem is coming up with a good "known list".
It would be even more useful for this to be added to standard OS/system security features.
Additionally, if you want linux support and don't care so much about the web support that 1Password gives you (your password file is also a website that uses JS to decrypt your passwords) or the prettiness and would like to save US$60 KeePassX works perfectly well.
>> "None of the passwords contain a colon, because that is the delimiter used to separate usernames and passwords in the combo lists my scripts generate."
That only works for his database of username:password combinations due to how he stores them. It won't protect you from someone else's database of password combinations.
Since he collects only publicly available username/password combinations, you're already screwed and avoiding his list is slamming the door after the horse is gone.
cough $250 in sales from folks who chose "password" in 2011. I suppose I could tell them "Wait wait, put your credit card back for a second and listen to a complicated instruction designed to solve a problem you don't have.". Doesn't seem to be a huge upside, though.
Because it's intrusive. There are lots of opinions on how far a website should go to ensure their users select strong passwords, but I implement a strawman password roster.
If some of the throwaway sites and forums that I sign up to once started forcing me to select a more secure password it would be extremely annoying and I wouldn't sign up.
I'm perfectly happy with my 6 letter a-z password for one time forums, that I use anonymously, and that I might occassionally log back into twice.
Incidentally, the password I use is "openit". This password means nothing to me. If you did some detective work on me I'm 100% sure that you would be able to get access to some sites that I use by entering that password.
Not having to use symbols, capitals, and strong passwords for these throwaway sites, means that I can effectively maintain about 10 different password sets, where my most important "tier 1" passwords are reserved for my SSH keys and email.
Facebook does - we have a blacklist of common passwords, and you cannot register an account with them or change your password to them.
That being said, I think with sufficient protections against brute forcing, password complexity requirements are largely a waste of time. The percent of users' accounts you can get into with the number of attempts allowed before locking you out is so small that it's not cost-effective, and the majority of people trying to break into accounts are doing so at scale for financial gain.
It's comprised in part of what we observed as the top hundred or so user passwords, so I'm hesitant to share it. I hope to do a more in-depth post about some stats we're able to run on password usage - I'll see if it makes sense to disclose (part of) our blacklist in there.
Some do, with rules about complexity: minimum length, mixture of different classes of characters (lower, upper, numeric, special). Beyond that, I am not aware of websites looking through something like his considerable list of passwords to rule out choices.
That is due to the cloudflare service. You can actually leave a note, I do follow up on those.
Edit: It's a good thing I'm using that too, 108K hits from this in the last four hours. CloudFlare saved my site from 800k requests and 6GB in bandwidth.
With our TeddyPass app we are pretty loose on what users can use as their login password, but we employ pretty robust techniques to prevent brute-force attacks and other common methods. With our system key user data (like stored usernames, passwords, and the description of the account entry) is fully encrypted based on the user's password and other factors. As a result we can't retrieve their data even if we wanted to, so it's in our best interests to allow people to use just about any password they can comfortably remember (within reason).
What if China is using their well known hacker resources to secretly build a giant list of username password combos like this guy, but on a massive scale.
They could use botnets to log in to hundreds of thousands of bank accounts and transfer money. There wouldn't be an easy way to detect them because they'd look like legitimate transactions, and the only option would be to temporarily shut down online banking transactions.
I wonder how much of a disruption they could cause?
Targeted stikes, yeah, it can work. Massive downloading of gmail account passwords, NOPE. It will set off internal alarms. But yeah, to target one individual, it is indeed possible and they did a string of those when they cracked the rotating RSA key.
Do you have a reference for people doing an online brute force attack in the RSA attack? IIRC the only brute forcing they did was offline (i.e. cracking hashes that they had locally).
Or maybe that's what you were saying, and I'm just misunderstanding you :).
Thank you for sharing the various methods you use to collect the passwords. That is extremely detailed.
I was curious if you ever considered putting a date stamp on the log for when you found a particular password. Because you have been collecting for such a long time, you may see some interesting trending.
Anyone else worried that Athena (http://www.project2025.com/athena.php, link in article is messed up) is actually going to start by installing a keylogger or uploading password files from ones own computer ...
I thought openID would solve the password problem, because it would allow for each person to remember one password only (which is still better than password1234). What reasons prevented the widespread adoption of openID? For example, if I were a startup, I'd want to have openID on my site to make it easier for users to register, and help them to not forget their passwords. Yet for some reason there are few sites that support it. Any thoughts?
Is there something specifically wrong with the concept of password haystacks? I understand it as "force the attacker to search an extremely large potential keyspace." The tool I linked to simply calculates the keyspace that a given candidate password is in.
What's dubious? I don't think there are many (any?) people who understand what he's talking about and would be able to implement it, but wouldn't be able to figure it out on their own. Of that set, the set of people who are malicious is even smaller, if not non-existent.
"I visit a number of public and private hacking-related forums to get wordlists and hacked passwords. I often pay for VIP memberships (usually the lifetime ones) so that I can access premium content areas. "
and when the men with no sense of humor invite you for an interview with out tea and biscuits what would you say to that.
ok the are grey areas and I have on behalf of a FST100 organization broken in to a system with explicit permission and clearance from v senior manger and I also had far better contacts at BT's board level to lobby in case or security dept threw a hissy fit than most people
There is nothing dubious about collecting information if you do it legally.
Further, it is what you do with it not the potential that would get you into legal trouble, otherwise Google, Facebook and every other company would be under legal uncertainty.
Indeed, your hacking actions were far more risky without prior consent from all parties involved.
The difference is that all of these passwords are public knowledge and already published in some form. My compiling these passwords into a single list is different from gathering them directly from the source!
In Australia, close to a decade ago, the Microplex (Optusnet) servers had a backdoor that revealed all the passwords via a generated webpage.
Someone found this, posted the link to the newsgroups... then had their computer seized by the Australian Federal Police. Collecting passwords, at least in Australia, can get you in big trouble.
Incidentally, I don't think that's a good thing, but it is a thing. Beware Australian security researchers!
http://xato.net/passwords/worst-password-policy-ever
Their policy is:
1. Minimum password length is eight characters.
2. Passwords must contain at least one of each of the following: one alphabetic uppercase, one alphabetic lowercase, one numeric, and one special character.
3. Passwords shall not contain any two identical consecutive characters (example: 22apples, 14588904).
4. Passwords may contain no more than two identical consecutive characters in any position from the previous password.
5. Passwords shall not contain any dictionary word.
6. Passwords shall not contain any proper noun or the name of any person, pet, child, or fictional character.
7. Passwords shall not contain any employee serial number, Social Security number, birth date, phone number, or any information that could be readily guessed about the creator of the password.
8. Passwords shall not contain any simple pattern of letters or numbers, such as "qwerty" or "xyz123".
9. Passwords shall not be any word, noun, or name spelled backwards or appended with a single digit or with a two-digit "year" string, such as 98xyz123.
10. Pass phrases, if used in addition to or instead of passwords, should follow these same guidelines.
11. Passwords shall not be the same as the User
12. Password length will be selected to provide a level of protection commensurate to the value or sensitivity of the resources or data it protects, but not less than eight characters.
You just can't make this stuff up!