Tag Info

New answers tagged

1

Although the argument that security itself should be enough of a reward is a fair one, there are some companies out there that already do this. For example Mailchimp (who I have no affiliation with apart from being a customer) have been giving 10% discount since March 2013 if you enable 2FA on your account (and before that it was 2% since February 2012). ...


2

The same reason people don't get rewards for paying child-support or showing up for work, it's something that you are supposed to do. You don't get kudos for doing things you are supposed to do. Chris Rock did a nice presentation on this subject.


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 ...


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 ...


2

Firstly, what is a strong password? The astonishing majority of websites use meters based on the maximum achievable entropy of a character space, rather than on the entropy of passwords actually created by users. Strength meters fail to incite users to create actually random passwords, and they fail to capture the fact that users routinely reuse passwords ...


1

Most websites/services would struggle to offer an incentive for a user having a strong password. Of course, badges and rep on sites such as *.stackexchange but otherwise i don't see what could really be offered? This is of course ignoring the leaking of information, or target painting for the users without stronger passwords. I am unsure as to whether or ...


2

Setting up a system as you describe would be an information leak which would tell an attacker which users to attack, so would be a bad idea on that reason alone. Also, it's not necessary. If you want users to choose strong passwords all you need to do is set length and complexity requirements.


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 ...


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 ...


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 ...


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 ...


1

I wouldn't worry about it. 72 characters is a quite decent password length, and password truncation is a common practice. Your users will trust you with many security options (like hash algorithm and the number of iterations) which affect security much more than password length. Implementing a warning wouldn't hurt though, that is, if you have nothing else ...


1

Say you use Diceware you can generate a memorable, secure passphrase. For the technically inclined, each word in your Diceware passphrase yields 12.9 bits of entropy, the way passphrase security is measured. If you want a passphrase to be uncrackable, ever, using today's technology (and the technology of the foreseeable future), you need 128 bits of ...


0

I gave this answer to another question, but I think it addresses your question as well (in a roundabout way). What is "password strength"? In most people's minds, it's the difficulty factor malicious actors would have when they are trying to guess your password. Password strength meters generally answer a slightly different question: how many iterations ...


2

No, don't make password reset based on anything submitted in a form. You need to determine the users identity through a method besides your own website. Either via two factor authentication (usually phone) or via a known email address. The danger here is brute forcing, guessing, or stealing the data needed for a password reset. Yes, it is often quite ...


0

Most of the comments here are pretty good and identify the key issues. However, one point which needs to be considered is that you need to assess these types of questions in context and be very careful regarding generalisations which state that it is either good or bad. Questions of password history are related to the concept of password aging and requiring ...


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 ...


-5

Passwords should be hashed using an approved stretching algorithm, such as PBDKF2 or bcrypt. Furthermore, they should be combined with a unique salt which is then saved with the hash. Since the salt is unique, attacks may only occur against the given hash and its salt. Since the hashing function is computationally prohibitive (when implemented correctly), ...


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!), ...


1

An historical example of such a poor algorithm is Microsoft's LM hash. As you said Felipe, in order to create a strong password, you need among other things to mix uppercase and lower case letters. Why? Because by doing so there can be 52 different possible letters constituting each character of the password: 26 lowercase + 26 uppercase. By converting the ...


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 ...



Top 50 recent answers are included