I had to use a similar government website with mandatory training and a stupid password system like this. And then after finishing creating my account, they repeated back to me what my password was on the next page, and in the confirmation email they sent me. I don't know if you know, but that should never be possible.
It should never be done, but it being possible isn't necessarily an issue in the way that one might think.
Code-wise, it's simple to show the password and also send an email with it, without saving the password as plain text. You just send off your in-memory copy before hashing it appropriately (bcrypt, pbkdf2, etc.).
Of course, there's still the issue of emails themselves being insecure (unencrypted through many servers out of either side's control), so it should never be sent.
Yeah, the problem is if you request the password later through a form and it's sent to you in clear text then. That's when you know they aren't storing them securely. Even in the best case where the passwords are being encrypted, they aren't using one-way hashing to ensure the original passwords can't be recovered if the database is accessed maliciously.
Yup. It's not the initial one that says there's definitely a problem (bad as it already is) but rather when they demonstrate the ability to retrieve the plain text later.
You send it from the server. Again, this is a bad idea - but that's because email is unencrypted, not because the password is persistently stored unencrypted.
Should cease to exist the moment the user advances to the next page ... It's either being stored locally
A typical application server pipeline goes something like this:
At any point during app code execution, you can write to the response stream. It's trivial to write the password to the response without having to store it (again, a bad idea, but it in no way implies any form of persistent storage).
The action of "advanc[ing] to the next page" involves sending the request - containing the password - and receiving a response as part of the same bidirectional stream. You don't store the password from the request then retrieve it for the response. You can send it directly back out the response (making a copy in the very much temporary response stream, that does not last significantly longer than the original in-memory copy). Of course, this is a bad idea because you expose the password on-screen, but it's not significantly less safe than the act of sending the password in the request in the first place.
Basically, the "moment the user advances" actually encompasses the entire request and response. It's not like the password disappears from memory the moment they click submit.
My point is people seem to jump to the conclusion of "password is send in response/email" = "they're storing the password as plain text or reversible encryption". This is not true. It's perfectly possible to send the password while only persisting a properly hashed copy of it. At that point the only copy kept by the server is the hashed copy - there might also be a plain text copy floating around email servers and in the page response, but that's a separate issue (and is transient - so would have to be intercepted real-time as opposed to a database leak months/years later).
Also, there are only two dangers to sending the password in the response. The first is that someone can see the password on-screen. That's obviously bad. The second is that the password exists in memory for longer than just the request would require. That's ... not good, but the security impact is pretty minimal. And as long as the request is secure, the response on the same stream is just as secure.
At the end of the day, doing either of those things is bad practice. But it does not necessarily mean the password storage itself is poorly implemented. It does kinda suggest that is happening, since bad security is usually not in isolation, but this is not definite.
Yeah for me it's the email component that makes it annoying, I don't my password for a website anywhere I won't be using it. Seeing my password chilling in the inbox is irritating.
Yes, I've deleted my original response. I had a moment of complete brain-deadedness and forgot how websites work. I haven't done it in a long time, I had it in my head that hashing is done on the client side.
Firing off an email from the browser (without opening an external client or taking advantage of some special feature) is no mean feat, and unless this was very recent, would involve sending the plaintext somewhere else to have it emailed back to you.
Actually its trivial and has been done for a very very long time. The server will always be able to see whatever you send it unencrypted / plaintext. The encrypting is done server side.
What you do then is just make your password random keys like 93kHYdnia783jsyd7, to remember it you just save that in a file on your desktop named mypassword.txt
So on your keyboard you would start with say 1. Your password could be 1qazXSW@3edcVFR$. So you're starting at 1 working down to Z, then you hold shift, move over to X up to @, release shift, move over to 3, etc. you could do any combination you'd like. For example, instead of hopping over to X, you could go to C. Easy to remember and there are many different combinations.
Our minimum used to be 15, but then they instituted 2 factor security for everything in such a way that password access is almost never used. Somewhere along the line they scaled password access back to 10 characters.
Well there it is. It's a government website. It needs to be secure. Password restrictions have always annoyed me on websites where it's just my shit that going to get fucked. Yes all of these restrictions will make my shit more secure, but if I want my password to be hunter12 then that should be my perogative. But on a government website it makes sense.
Edit: politeness
Edit 2: Jesus fucking Christ I get it. These types of passwords are more susceptible to brute force passwords. I don't need 20 of you motherfuckers to tell me the same damn thing.
Password strength should be measured by bits of entropy, not arbitrary limitations. These forced limitations actually reduce the amount of possible combinations making brute forcing easier. Also, people are likely to compensate for the difficult restrictions by just writing it down. Maybe not a big deal for a one-off government website, but forcing password restrictions like this for a bank account means someone is just going to write it down on a piece of paper or save it in their phone which makes it that much easier for someone to get access to it.
Which I why I said it annoys me when it's just my shit. I should get to pick exactly what password I want for my bank account. I agree with that point.
I was pretty upset work a shit as government website we used to document unclassified training had requirements like that, but my fucking bank was letters and numbers only 8 characters max, no upper case.
My bank makes you use your account number as your login name. I have to have a written copy of the number every time I want to access my online account. So secure!
But they can. And if they do, their account number is written on the check. Therefore, an account number should never be treated as confidential or secret information.
I'm not even that old and remember memorizing friends' phone numbers in case you were calling away from home (where your phone book was).
Seems like memorizing something as important as a bank account # wouldn't be too demanding. And if you're worried about having to have a written version of it every time you login, it's already on every personal check in your checkbook.
You should easily to be able to remember your bank account number if you log in with any kind of regularity. I know my bank account number, the login number, and credit card number.
Bits of entropy is a great way of measuring potential security, but a horrible way of measuring actual security.
This all goes without saying, but people won't use a difficult password out of generosity to your system. If you say "make a password" and you make no restrictions, you maximize entropy mathematically - my password could be '$A&FruitBalloon*<F12>@R{Sunglasses Emoji}<pageUp>', or it could be 'password'. And most people are not going to use the first when the second is so much simpler.
If you think of the search space as a one dimensional graph of arbitrary units of complexity, a graph going from 0 to infinity but having most of the passwords between in the first ten 'units', vs a graph going from one to one hundred and having none in the first ten and most in the 50's is a more secure system.
You shouldn't measure password strength by how secure it could be, but by their worst and average cases, because a hacker doesn't succeed when they find every single password, they succeed when they find just one.
I feel like all these restrictions would make it less secure? I mean the more restrictions you add, the less possibilities there are for passwords. Which means less passwords that an intruder would have to guess. Add enough restrictions and eventually 'hunter12' will be the only possible password to use.
This is the layman's understanding but (as is often the case) it is incomplete.
Let's say there are no password restrictions, except that the maximum number of characters allowed is 10, and you can't use crazy characters like Unicode - any printable character visible on your keyboard is fair game. The number of possible password combinations is 60510648114517025000. That's a lot - probably too many to reasonably guess any if we assume that the actual users' passwords are randomly generated in this space. But that's the problem, isn't it? They won't be.
On such a site, some portion of the users will opt for no password at all, a password of 1234, a password of 123456, a password of "password", etc. An attacker will guess all of these things first since they know that some people will be using them. If they can get an appreciable amount of users in a very small amount of time, they will. And then they can just move on to the next site and do it all over again, rather than spending time trying to crack passwords.
Adding restrictions like the ones in the OP will reduce the total attack space, yes. But that doesn't really matter when that is so rarely the thing that the attacker is targeting. What a competent attacker is targeting is the user. If you make your users make more "random" passwords, then they're less likely to fall victim by using something that's in the attacker's pre-sorted list of likely passwords.
EDIT: That's not to say this example (in the OP) is perfect. It's definitely a sort of half-baked system, but the spirit of the restrictions is perfectly valid.
I get what you're saying, but in my head I imagine a type of program that enters and runs through every possible password combination (sort of like Wheatley from Portal 2 "Hm, let's try...AAAA...Nope. Alright then, let's try...AAAB...") then adding these restrictions greatly reduces the time it'd take for that machine to guess the right password. It might still take a long time, but you only have to guess it before the next mandatory password change.
Of course, I guess a site like this would flag an account that had too many wrong passwords entered within a period of time, so maybe my point is moot...
What you're talking about is true brute-force attacks. They exist, and they're the assumption in a lot of cryptographic discussion, but only because they're easy to calculate. The fact is that true brute-force attacks are not as effective as other methods, and are therefore almost never used. That was essentially my point. While the OP restrictions will increase the effectiveness of an incredibly ineffective strategy, they will greatly decrease the effectiveness of an otherwise very effective strategy (in this case, I'm talking about dictionary or hybrid attacks). The tradeoff is very often a good one.
If you want to encourage passwords with more entropy, just mandate longer passwords.
Also: What characters did you count? I only found 81 useable characters with the "No unicode" rule and with discarding commonly disallowed characters (such as <>):
Like I said to someone else, I don't know much about hacking so I can't speak to that, but from a non hacker's point of view it makes sense. I can see the point you're making, though.
Restrictions like OPs make the site less secure because meow a hacker has a set of rules they can use to pre filter their attack list. Many less combinations to try meow.
I think people have a hard time with the scale. They don't realize the 6634204312890625 combinations is from the 8 characters is a huge amount. And then the other restrictions are actually about making sure you don't get caught by a using a stupid password.
The real practical effect is that the user is likely to write the password down instead of memorizing it, resulting in access to the system only requiring access to the user's workspace.
In case anyone is interested, here is the information this set of rules is giving a potential attacker, and their consequences:
Passwords must be at least 8 characters in length: means that it's safe to assume that a lot of passwords will be exactly 8 characters in length.
Passwords must include at least one non-alphanumeric printable character: rules out passwords that consist only of alphanumeric characters (order 109 ); very likely that there will be exactly one symbol, and that it will occur either at the start or at the end of the string; good chance the symbol will be one of the four symbols (#, *, $, @) shown in the rules.
Passwords must include at least one number: as above, very likely that there will be exactly one number, and that it will occur at the start or end of the password; good chance that it will be the number 1 or some number between 50 and 98, i.e. year of birth, minus any years with repeated/consecutive numbers.
Passwords cannot contain repeated characters: rules out many more (> 1011 ?) potential passwords that feature runs of the same character. Prevents users from using the string password in their passwords, also stops people from using passwords like $password1, $password2, etc.
Passwords cannot contain (alphanumerically or not?) consecutive characters: this one is incredibly stupid, intended to prevent combinations like 12345, abc, and the like, but forbids many short (2-3 character) combinations that can easily be generated randomly.
But it's okay! Then, when the hack invariably happens, the IT guy can look at his boss and say, "Hey man, I don't know what else I could have done. Stupid user wrote down his password instead of memorizing a new one that fit my rule every month. In addition to all of his other passwords."
And the boss goes, "Yes, this is certainly the user's fault."
Fair point, but I don't think it's necessarily the worst thing, so long as the person appreciates how important it is to keep the written copy safe and secure.
That depends on where they leave it. Leave it by your computer and it's easy to find. Stick it in your wallet and it's as secure as your credit cards. Especially if you obfuscate the passwords and/or sites they go to in some way.
Saying it's the biggest hole of all is a bit of a hyperbole, I was just quoting a professor I used to have, but I still think it's very high on the list. Most other things can be accounted for, a competent IT security worker can defend a server against automated attacks with some effort. Setting some rules to stop people from using passwords like "password" isn't difficult to stop smarter attacks.
But if someone writes down their information the security that IT can provide doesn't matter much anymore. It switches the focus of protection from the IT department to the user; now one of the easiest avenues of attack is just to get that password. If someone leaves their password on their desk, someone with access to the building can just walk in and take it. All they need to do is find one. Excessively frequent mandated password changes only increases the chances of it happening.
Sure for your day to day employee this doesn't matter but in high value situations it's a real risk. I'm pretty sure no one cares if you write down your personal passwords in your own home, I'm talking about in business situations.
Yeah, it's definitely a bigger risk in a business environment. With that context in place, I'd agree that it's important to physically secure passwords. But how much that matters also depends on the physical security posture of the whole building, your floor, your area, etc. Generally speaking though, averaging out the entire internet population, I would argue that writing down your password is way less dangerous than using a weak one.
It's kind of sad that is quite close to how i do my work password, but with A1, B2, C4, F1, F5, are some of my favorites and I get excited when i use them (make the same stupid joke every time i do my password).
I didn't realize that was happening, actually. I friend setup a now => meow shortcut on my iPhone. I keep forgetting to remove it and now I never even see it anymore.
You'd think so, but the fact is that without these restrictions a high number of people would use passwords that are extremely easy to guess (i.e. abcd1234 or some such). With these restrictions, yes, they give a small amount of additional information to the attacker, but they ultimately increase the security of the average user.
Restrictions are a double edged sword: It stops stupid people from making stupid passwords, but each one makes the whole system orders of magnitude less secure. The no consecutive characters alone eliminates billions, possibly trillions of combinations within a reasonable length. Ideally there are other ways to try to prevent stupid people making stupid passwords than to compromise the whole system for everyone.
each one makes the whole system orders of magnitude less secure. The no consecutive characters alone eliminates billions, possibly trillions of combinations within a reasonable length.
Reducing the password space by billions or trillions is not making it orders of magnitude less secure.
Even if you excluded 999 trillion passwords from all possible 8 character passwords (with caps/noncaps,symbols,numbers) you'd only be excluding 15% of the possible combinations. I don't really have the time to figure it out, but just go to a random password generator and take a look at how many times you'd have to regenerate a password, on average, to hit one of these exclusion policies. It will be extremely rare.
The XKCD is absolutely correct though, because one of the important parts of a password is being able to remember it. A long passphrase with some randomness thrown in will make a password which is impossible to brute force.
Title-text: To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize.
It's difficult to calculate what the change would be (it may be more than I'm estimating). Like I said in another post, this particular strategy is sort of half-baked, but still, the logic is sound.
What's funny is that any 3 or four word phrase is more secure than whatever bullshit this site is cooking up. And easier to remember. Hackers rarely use method thinking to figure out your password, it's pretty much bot programs and such. We as a people have made passwords harder and harder on people while actually making it easier for computers
What's funny is that any 3 or four word phrase is more secure than whatever bullshit this site is cooking up. And easier to remember. Hackers rarely use method thinking to figure out your password, it's pretty much bot programs and such. We as a people have made passwords harder and harder on people while actually making it easier for computers
Tight passwords may be more secure, but its a matter of scale. If you had to bail water out of your boat, you could choose a number of different vessels, each with a different efficiency. Your hands, a cup, a large cup, a bucket, a large bucket, etc.
Or, you can realize that you'll only ever get to a certain level of efficiency and you need to re approach the problem with a different system.
So you install a robust pump system and never need to worry about water filling your boat again, no matter how hard it pours.
The passwords are the things you're using to bail out your boat. The size of the vessel corresponds to the different "password guidelines." The pump system would be something like 2-step verification.
this is stupid though. if you want to make it secure, add more characters. some semi-random combination of characters with defined limits is stupid - more so when you want to have the passwords rolling.
#1 Important Thing: make your password long (12+ characters)
#2 Important Thing: don't use dictionary words
#3 Important Thing: mix it up. Every capital letter, number, or symbol will help your PW be slightly harder to crack.
These are in order of magnitude of importance. 100, 10, 1.
A 20-character PW with no dictionary words is a nightmare to crack, even if it's entirely lower-case letters.
Having worked for the government and had to abide by those restrictions, i can personally verify that most people had their password written down next to there keyboard.
Which is why I always prefer the B@ttery_h0rse approach to passwords. Easy to remember, pretty secure, and no writting it down.
Gov. site I'm required to be a part of makes me change the password every 30 days with the same restrictions. I just open up a sticky note and randomly smash the keyboard copy/paste until one is accepted. Then I leave the sticky note open to copy/paste from any time I log in.
If you find this frustrating, how do you feel about the entire database of Government workers getting released during hacks of the Office of Personnel Management, or citizens' personal info getting released in hacks of the IRS?
The price of security is less accessibility.
The price of accessibility is less security.
You will, no doubt, forget that password. It's so annoying how overly secure they are. You know how many times my account has been broken into via bruteforce? Zero. Zero times. You know how many times my password has leaked because of the database was hacked and my password revealed, is something like 20 times.
I'll use a difficult password for important shit, that is high priority, thank you very much. But for you fucking fitness forum, eat a dick if you are going to make me jump through hoops like that.
O fuck I thought this was Photoshoped or sending. This is just fucking ridiculous. Chances are it would take me forever to come up with one I liked and would remember.
Sort of reminds me of the how the government FAFSA site operated when I had to apply for student loans several years ago. It literally blocked you from continuing if your browser version was above what they explicitly checked against, which were very obsolete versions at the time. The staff recommended I somehow downgrade to IE 7 or go to a public library to find an older browser for their site access. What a joke.
That's easy. Just request everything in paper form so that you can protest against their draconian anti-freespeech measures of forcing you to type a weird password against your will.
Create a random ass password, select "forgot password" and see if it allows you to make it whatever you like. This little trick likes to work on many academic systems.
I'm going to help you out. For government passwords it's really easy to make a pattern instead of a password. Easy to set. Duplicate. Remember. Really hard to crack with an algorithm and damn near impossible for someone to guess.
Pattern. Look at your keyboard. Make a pattern while holding shift.
!Q@W#E$R
Then release shift and do the same thing again.
1q2w3e4r
So the whole password is:
!Q@W#E$R1q2w3e4r
You can do different patterns but this was to just show you an idea of what you can do to satisfy these crazy passwords. I have a different pattern password for all of my stuff now and a very intricate one for my bank in case anyone catches onto my patterns.
Wait wait wait. This is a real thing that exists? I honestly thought it was an exaggeration to illustrate how absurd it's gotten, and was thinking how dumb all these people were for thinking it was real.
Well, that's kind of unfair. I mean, how many government websites are you going to be visiting regularly in your life, compared to the amount of social media and bullshit sites? If this were a site like reddit, yeah, fuck that noise. But this is a matter of National security. Hardly the same thing.
I tried applying for a job at the post office and it had crazy requirements like this. If anybody ever wants to go onto my account and apply for post office jobs for me I am totally okay with it
Surely enforcing all these rules just narrows down the number of passwords hackers have to try to bruteforce their way in. "Ok, take out all the words with consecutive alphabetical letters and repeating letters, that narrows down the pool a bit, now try them all with a capital letter at the start and a 1 and a # at the end... Aaaaand we're in."
What I really hate is passwords like1qaz2wsx#EDC$RFV meet the criteria perfectly but are so much less secure than something like "1234BottleBooke*&&!" because a dictionary attack will rape the "good" password (as the site evaluates it) but will do nothing on the repeating t's, o's, and &'s.
The past two banks I worked for were almost this bad. I currently have about 12 different passwords that are similar to these rules. I understand why they do this but seriously...it gets annoying
Some are reasonable but the no consecutive character thing is just fucking with you. I get not allowing "abcd" or "1234" but "steet". They think "&%127h4x0rstEEt()*JHFHJ" is too weak.
Worse when you're forced to use the site, like the university I went to. Password requirements as strict as this and you had to renew them every few months. Ended up with stuff like o9p0O(P) and such. Just four keys and switching between no-shift and shift.
That's why it's so annoying. My bank requires the same kind of password requirements AND you have to change your password every month. It's nerve wracking.
2.0k
u/buttonstoyou Mar 08 '16
How about I just go to a new website, how about that.