Tag Info

Hot answers tagged

60

Why, indeed? Allow me to ignore that question for a moment, and answer your implied question: Should we? That is, should we continue to have users create their own password, which is often weak, instead of just having the system generate a strong password for them? Well, I am of the controversial opinion that there is a pretty strong trade-off here - ...


50

No, you cannot conclude that. The password can be hashed on the server-side only, which implies that the password is sent in plain text to the server and stored in a variable. Then, nothing stops the Web application from displaying the sent password to the user, in the case where the very same script that has received the password is giving you the feedback ...


31

The most likely reason is that the backend only supports case-insensitive passwords. To quote OWASP: Occasionally, we find systems where passwords aren't case sensitive, frequently due to legacy system issues like old mainframes that didn't have case sensitive passwords. The chances of this happening are much higher with stodgy old institutions ...


29

Getting the password to the user The only times I have seen systems that set the password for the user, it is send to the user via email (obviously in plaintext), which is obviously a bad idea[*] (and SMS, Mail, etc are not that much better). So that would leave displaying the password when creating the account (which might also be a bad idea because of ...


27

Security of storing Hash History Is it safe to keep the history of hashes? Relatively. I can imagine some scenarios where this would harm the security of the user, eg: A user uses a relatively weak password, realizes this and updates the password to a better password, based on the previous password (simple example: superawesome -> !sup3eraw3s0m3!), ...


25

You can use source code as password. However I'd strongly recommend against using source code as a passphrase. The reason for this is entropy. Passwords / passwphrases need to provide lots of entropy (100 bits+) and programming languages usually pose severe constraints on the formulation of instruction thus resulting in less entropy per character than even ...


22

We don't know how to measure the strength of a password, by looking at the password. Of course, there are many tools that purport to be "password strength meters" and give you a nice green colour. However, they are all baloney and do not give you the "true" strength; instead, what the password strength meter tells you is: "assuming the attacker is a ...


18

Like most password generation algorithms, this one relies on security through obscurity. As long as nobody suspects that you use this method, nobody will use a cracking tool which tries random valid source code snippets and the rule of strength = possible_characters ^ number_of_characters will stay valid. But as soon as someone suspects that you might be ...


15

Organisations want users to be responsible. If the user chose the password, they can be blamed for choosing a bad one. Unfortunately, in the real world, organisations may have to be more concerned about seeming to take some of the responsibility for intrusions than about insuring they can't happen. Users want to choose something they can remember Many ...


14

You can't conclude the password was stored in plain text if it is redisplayed soon after you changed it. On the other hand if it is displayed after a while (days for instance) it may be a good hint that the password is indeed not hashed (it is stored in plain text or encrypted). Anyhow, redisplaying a password is clearly not a best practice because it may ...


14

Typically, it is a choice between usability and security. Users have a surprising amount of trouble with capitals in password so capitalizing password before hashing them makes it easier on the user. Of course, that also decreases the maximum entropy of a password of a given length. To compensate, you should use longer passwords... If you're lot limited to ...


10

Yes, you should hash password reset tokens, exactly for the reasons you mentioned. But no, it's not quite as bad as unhashed passwords, because 1) reset tokens expire and not every user has an active one, and 2) users notice when their passwords are changed, but not when their passwords are cracked, and can thus take steps to limit the damage (change ...


9

Yes, there are obvious flaws. Here are some: You can't make hashing slow by introducing simple delays. An attacker doesn't have to evaluate the hash the same way you did; they just need to get the same answer in the end. That means whatever is making the hash slow needs to be a necessary component of the hash -- it must be impossible to compute the hash ...


9

Actually, the comments on how Google deals with old passwords (still recognising them to retrieve a locked-out account), got me thinking on the pro's and con's of this, and whether you could use it to avoid people re-using old passwords in a relatively secure way. Not that I actually think you would want that (personally I think that 99% of "enforced best ...


9

One respondent touched on the right answer, but didn't expand on it enough, so I will. You are asking the question from a computer- or IT-centric perspective. But why does that IT exist? To serve the customer. Let me repeat this: The customer is not there to serve you, you are there to do what they need you to do. So with that in mind, let's revisit the ...


8

A few reasons: It would leak information about which accounts have weaker passwords. Even if not publicly accessible, if an attacker got access to password hashes and the password strength indicator value was also retrieved they could eliminate the cracking of the harder passwords from their attack. "Password strength" is not really a metric. The strength ...


6

One of the reasons that banks often have case insensitivity in their passwords is because of phone banking: banks existed FAR before the internet existed, even before telephones were a thing. So once telephones became widespread, many major banks allowed people to to banking stuff via the telephone. it makes sense: all you need is two account numbers and a ...


5

As others have mentioned this doesn't necessarily mean the password is stored in plain text but is a bad sign and bad practice. Some ways to determine if your password is stored in plain text are: Using the password recovery to see if it's emailed to you (this indicates plain text or 2 way encryption at the most). Check the password requirements, if ...


5

Think about it this way, if you choose the user's password for them, they will forget it, and have to use password reset systems. The 'forgot my password' is usually less secure than the password, so making the password more secure, but causing more password resets makes the entire system less secure as it would be harder to detect fraudulent 'forgot my ...


5

If your password hashing function is any good, or even if it is bad but not hopelessly so, then adding the dots should not weaken the password. Password hashing functions, like other kinds of cryptographic hash functions, are supposed to be "all or nothing": either you have all the exact input, and then you hash to the output, or you learn nothing. The ...


4

SHA256 and MD5 are hashing algorithms, or "one-way encryption" if you will. A hash function is any function that can be used to map digital data of arbitrary size to digital data of fixed size (Wikipedia (Hash function)) So to get the (probable*) plaintext that was hashed, brute-force is the only way. There are rainbow tables as well as you mentioned ...


4

When LinkedIn was hacked in 2012, nearly 6.5 million password hashes were leaked. Because LinkedIn failed to salt their passwords, it was easy to compute hashes of common English words and combinations, and analyze which were used the most. I'm not saying this is the only way, but it's one of the possible ways to figure out the "worst used passwords", as ...


4

However, the server must store some form of the mailbox password so that the user can be authenticated. Should a security breach occur on the server, wouldn't it be just a matter of time for a determined hacker (and a powerful hacker, if, say, a government desides to be one) to figure out the real mailbox password? Security is about trade-offs. It is ...


3

Well Dmitry is right when he says 72 characters is good. If the characters are random enough. (1.78 bits per character). You can use the approach described (security warning that password is "too long"). Or simply limit password length (with security warning). If you expect your users to enter more than 72 characters, you could as well use SHA-512 to ...


3

I don't pick my own passwords. I use a password manager that generates random passwords for me. However, most web sites are based on the idea that users will memorise their passwords. It's much easier for a user to memorize a password they picked themselves, rather than one assigned to them. In practice as well, users typically use the same password on ...


3

I think many of your questions (eg SHA-512 vs bcrypt) are answered in the guide linked to by AviD. But it doesn't actually say anything about PHP, so I'll answer that part. Hashing a Password in PHP5 It's good that you want to understand the underlying concepts, but actually securely hashing a password in PHP5 is quite easy: $hashedPassword = ...


3

You don't know. You technically don't even know whether the password is stored at all, let alone whether it's stored hashed. Them being able to email you the password immediately after you tell it to them says nothing of storage.


2

You are correct, however note that there is no indication that AES256 is cracked (and normally it won't be anytime soon either). Considering the strength of AES256 it will take several millions of years (even with quantum computer as the best known theoretical attack is Grover's quantum search algorithm. This allows us to search an unsorted database of n ...


2

I also could not find any password storage policies that mention that passwords should not be upper-cased. But I also didn't find any guides which told me not to set every password to "password", not to remove all special characters, or not to shorten them to 4 characters. It's just obvious. You should not change the password that the user supplied. This ...


2

but I was just wondering if there actually is a password for it? Yes. SSH uses your system users (that's the whole idea of it, to allow users to remotely access a systems account), so there is a password for it (stored in /etc/shadow) If there is one, is it possible to just disable it? Yes. You can (and should, as you are not using your password ...



Only top voted, non community-wiki answers of a minimum length are eligible