Iszi chose this week’s question of the week, Tom Marthenal‘s “Why do we lock our computers?” - as Tom puts it:

It’s common knowledge that if somebody has physical access to your machine they can do whatever they want with it, so what is the point?

This one attracted a lot of views, as it is a simple question of interest to everyone.

Both Bruce Ediger and Polynomial answered with the core reason – it removes the risk from the casual attacker while costing the user next to nothing! This is an essential factor in cost/usability tradeoffs for security. From Bruce:

The value of locking is somewhat larger than the price of locking it. Sort of like how in good neighborhoods, you don’t need to lock your front door. In most neighborhoods, you do lock your front door, but anyone with a hammer, a large rock or a brick could get in through the windows.

and from Polynomial:

An attacker with a short window of opportunity (e.g. whilst you’re out getting coffee) must be prevented at minimum cost to you as a user, in such a way that makes it non-trivial to bypass under tight time constraints.

Kaz pointed out another essential point, traceability:

If you don’t lock, it is easy for someone to poke around inside your session in such a way that you will not notice it when you return to your machine.

And zzzzBov added this in a comment:

…few bystanders would question someone walking up to a house and entering through the front door. The assumption is that the person entering it has a reason to. If a bystander watches someone break into a window, they’re much more likely to call the authorities. This is analogous with sitting down at a computer that’s unlocked, vs physically hacking into the system after crawling under a desk.

It removes a large percentage of possible attacks – those from your co-workers wanting to mess with your stuff – thanks enedene.

So – protect yourself from co-workers, casual snooping and pilfering and other mischief by simply locking your machine every time you leave your desk!

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

User Experience Stack Exchange moderator Ben Brocka asked this question on Security Stack Exchange after the UX community asked whether they should disallow common passwords as a matter of course.

Cyril N‘s top scoring answer focuses on a highly valuable response – educating the individual to behave better. From his answer, two key points arise:

Some UX specialists says that it’s not a good idea to refuse a password. One of the arguments is the one you provide : “but if you ban them, users will use other weak passwords”, or they will add random chars like 1234 -> 12340, which is stupid, nonsensical and will then force the user to go through the “lost my password” process because he can’t remember which chars he added.

and

Let the user enter the password he wants. This goes against your question, but as I said, if you force your user to enter another password than one of the 25 known worst passwords, this will result in 1: A bad User Experience, 2: A probably lost password and the whole “lost my password” workflow. Now, what you can do, is indicate to your user that this password is weak, or even add more details by saying it is one of the worst known passwords (with a link to them), that they shouldn’t use it, etc etc. If you detail this, you’ll incline your users to modify their password to a more complex one because now, they know the risk. For the one that will use 1234, let them do this because there is maybe a simple reason : I often put a dumb password in some site that requests my login/pass just to see what this site provides me.

The only problem with this is called out in a comment by user Polynomial who suggests a hybrid solution:

Reject outright terrible passwords, e.g. “qwerty123″, and warn on passwords that are a derivation of a dictionary word / bad password, e.g. “Qw3rty123″ or “drag0n1″

Personally, I like the hybrid solution, because as Iszi points out, most password attacks are conducted offline, where the attacker has a copy of the hash database. In this scenario, dictionary attacks are a very low CPU load, very fast option that is easily automated:

…it is realistic to assume that attackers will target “common” passwords before resorting to brute force. John The Ripper, perhaps one of the most well-known offline password cracking tools, even uses this as a default action. So, if your password is “password” or “12345678″, it is very likely to be cracked in less than a minute.

Dr Jimbob has provided the logical Security answer: It depends! The requirements will be very different for an online banking application and for an application that will only cause minor inconvenience to one end user if compromised. Regulatory requirements may define the level of security protection you require. He also points out that:

Very weak passwords (top 1000) can be randomly attacked online by botnets (even if you use captchas/delays after so many incorrect attempts)

Bangdang also supports disallowing common passwords, and has a final section on the tradeoffs between security and usability, along with the effects of successful compromise, which include fingerpointing and blame.

Tylerl provides some insight from his experience analyzing attack code:

the password ordering is this:

1. Try the most common passwords first. Usually there’s a list of between 10 and 500 passwords to try
2. Try dictionary passwords second. This often includes variations like substituting “4″ where an “A” would be or a “1″ where there was the letter “l”, as well as adding numbers to the end.
3. Exhaust the password space, starting at “a”, “b”, “c”… “aa”, “ab”, “ac”… etc.

Step 3 is usually omitted, and step 1 is usually attempted on a range of usernames before moving to step 2.

In general the answers go to show just how extensive that key problem the security industry has: the trade off between usability and security. You could add strong security at every layer, but if the user experience isn’t appropriate it will not work.

This is why for major roles/access improvement projects we are seeing significant investment in the people/human capital side of things – helping projects understand human acceptance criteria, rejection reasons and passive blocking of projects which on the face of it seem perfectly logical.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

Are you a systems administrator of professional computer systems? Well, serverfault is where you want to be and that’s where this week’s question of the week came from.

New user mucker wanted to understand why, if hashing is just an algorithm, it cannot simply be reverse engineered. A fair question and security.SE as usual did not disappoint.

Since I’m a moderator on crypto.se this question is a perfect fit to write up, so much so I’m going to take a slight detour and define some terms for you and a little on how hashes work.

A background on the internals of hash functions

First, an analogy for hash functions. A hash function works one block of data at a time – so when you hash your large file, the hash function takes so many blocks (depending on the algorithm) at once. It has an initial state – i.e. configuration – which is why sha of nothing actually has a value. Then, each set of incoming blocks alter those values. (Side note: collision resistance is achieved like this).

The analogy in this case is like a bike lock with twisty bits on. Imagine the default state is “1234″ and every time you get a number, you alter each of the digits according to the input. When you’ve processed all of the incoming blocks, you then read the number you have in front of you. Hash functions work in a similar way – the state is an array and individual parts of it are shifted, xor’d etc depending on each incoming block. See the linked articles above for more.

Then, we can define input and output of two things: one instance of the hash function has inputs and outputs, as does the overall process of passing all your data through the hash function.

The answers

The top answer from Dietrich Epp is excellent – a simple example was provided of a function – in this case multiplication – which one can do easily forwards (O(N^2)) but that becomes difficult backwards. Factoring large numbers, especially ones with large prime factors, is a famous “hard problem”. Hash functions rely on exactly this property: it is not that they cannot be inverted, it is just that they are hard.

Before migration, Serverfault user Coredump also provided a similar explanation. Some interesting debate came up in the comments of this answer – user nealmcb observed that actually collisions are available in abundance. To go back to the mathsy stuff – the number of inputs is every possible piece of data there is, whereas for outputs we only have 256 bits of data.  So, there are many really long passwords that map to each valid hash value, but that still doesn’t help you find them.

Neal then answered the question himself to raise some further important issues – from a security perspective, it is important to not think of hashes as “impossible” to reverse.  At best they are “hard”, and that is true only if the hash is expertly designed.   As Neal alludes to, breaking hashes often involves significant computing power and dictionary attacks, and might be considered, to steal his words, “messy” (as opposed to a pretty closed-form inverted function) but it can be done.  And all-too-often, it is not even “hard”, as we see with both the famously bad LanMan hash that the original poster mentioned, and the original MYSQL hash.

Several other answers also provided excellent explanations – one to note from Mikeazo that in practise, hash functions are many to one as a result of the fact there are infinite possible inputs, but a fixed number of outputs (hash strings). Luckily for us, a well designed hash function has a large enough output space that collisions aren’t a problem.

So hashes can be inverted?

As a final point on hash functions I’m going to briefly link to this question about the general justification for the security of block ciphers and hash functions. The answer is that even for the best common hashes, no, there is no guarantee of the hardness of reversing them – just as there is no cast iron guarantee products of large primes cannot be factored.

Liked this question of the week? Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

This week’s blog post was inspired by camokatu‘s question on what to do when a Utility company doesn’t hash passwords in their database.

It seems the utility company couldn’t understand the benefit of hashing the passwords. Wizzard0 listed some reasons why they might not want to implement protection – added complexity, implementation and test costs, changes in procedures etc. and this is often the key battle. If a company doesn’t see this as a risk they want to remediate, nothing will get done. And to be fair, this is the way business risk should be managed, however here it appears that the company just hasn’t understood the risks or isn’t aware of them.

Obviously the consequences of this can range from minimal to disastrous, so most of the answers concentrate on consequences which could negatively impact the customer, and the main one of these is where the database includes financial information such as accounts, banking details or credit card details.

The key point, raised by Iszi, is that if personally identifiable information is held, it must be protected in most jurisdictions (under data protection acts), and if credit card details are held, the Payment Card Industry Data Security Standard (PCI-DSS) requires it to be protected. (For further background information check out the answers to this question on industry best practices). These regulations tend to be enforced by fining companies, and the PCI can remove a company’s ability to use credit card payments if they fail to meet PCI-DSS.

Does the company realise they can be fined or lose credit card payments? Maybe they do but have decided that is an acceptable risk, but I’d be tempted to say in this case that they just don’t appear to get it.

So when they don’t get it, don’t care, or won’t respond in a way that protects you, the customer, what are your next steps?

from tdammers – responsible disclosure :

Contact the company, offer to keep the vulnerability quiet for a limited amount of time, giving them an opportunity to fix it.

In the meantime, make sure you’re not using the compromised password anywhere else, make sure you don’t have any valuable information stored on their systems, and if you can afford to, cancel your account.

from userunknown -

contact their marketing team and explain what a PR disaster it would be if the media learnt about it (no, I’m not suggesting blackmail…:-)

from drjimbob - 3 excellent suggestions:

Submit it to plaintext offenders?

Switch to another utility company?

Lobby your local politicians to pass legislation that companies that do not use secure hashes (e.g., bcrypt or at very least salted hash) on their password data are liable for identity theft damages from any compromise of their systems?

But in addition to those thoughts, which at best will still require time before the company does anything, follow this guidance repeated in almost every question on password security and listed here by Iszi -

Use long and complex passwords for all websites & applications, and do not re-use passwords across any websites & applications. Additionally, limit the information you give these websites & applications to only that which is absolutely necessary for them to serve their purpose

How passwords should be hashed before storage or usage is a very common question, always triggering passionate debate. There is a simple and comprehensive answer (use bcrypt, but PBKDF2 is not bad either) which is not the end of the question since theoretically better solutions have been proposed and will be worth considering once they have withstood the test of time (i.e. “5 to 10 years in the field, and not broken yet”).

The less commonly asked question is:

why should a password be hashed?

This is what this post is about.

Encryption and Hashing

A first thing to note is that there are many people who talk about encrypted passwords but really mean hashed passwords. An encrypted password is like anything else which has been encrypted: it has been rendered unreadable through a process which used an extra piece of secret data (the key) and which can be reversed with knowledge of the same key (or of a distinct, mathematically related key, in the case of asymmetric encryption). For password hashing, on the other hand, there is no key. The hashing process is like a meat grinder: there is no key, everybody can operate it, but there is no way to get your cow back in full moo-ing state. Whereas encryption would be akin to locking the cow in a stable. Cryptographic hash functions are functions which anybody can compute, efficiently, over arbitrary inputs. They are deterministic (same input yields same output, for everybody).

In shorter words: if MD5 or SHA-1 is involved, this is password hashing, not password encryption. Let’s use the correct term.

Once hashed, the password is still quite useful, because even though the hashing process is not reversible, the output still contains the “essence” of the hashed password and two distinct passwords will yield, with very high probability (i.e. always, in practice), two distinct hashed values (that’s because we are talking about cryptographic hash function, not the other kind). And the hash function is deterministic, so you can always rehash a putative password and see if the result is equal to a given hash value. Thus, a hashed password is sufficient to verify whether a given password is correct or not.

This still does not tell us why we would hash a password, only that hashing a password does not forfeit the intended usage of authenticating users.

To Hash or Not To Hash ?

Let’s see the following scenario: you have a Web site, with users who can “sign in” by showing their name and password. Once signed in, users gain “extra powers” such as reading and writing data. The server must then store “something” which can be used to verify user passwords. The most basic “something” consists in the password themselves. Presumably, the passwords would be stored in a SQL database, probably along with whatever data is used by the application.

The bad thing about such “cleartext” storage of passwords is that it induces a vulnerability in the case of an attack model where the attacker could get a read-only access to the server data. If that data includes the user passwords, then the villain could use these passwords to sign in as any user and get the corresponding powers, including any write access that valid users may have. This is an edge case (attacker can read the database but not write to it). However, this is a realistic edge case. Unwanted read access to parts of a Web server database is a common consequence of an SQL injection vulnerability. This really happens.

Also, the passwords themselves can be a prized spoil of war: users are human beings, they tend to reuse passwords across several systems. Or, on the more trivial aspect of things, many users choose as password the name of their girlfriend/boyfriend/dog. So knowing the password for a user on a given site has a tactical value which extends beyond that specific site, and even having an accidental look at the passwords can be embarrassing and awkward for the most honest system administrator.

Storing only hashed passwords solves these problems as best as one can hope for. It is unavoidable that a complete dump of the server data yields enough information to “try” passwords (that’s an “offline dictionary attack”) because the dump allows the attacker to “simulate” the complete server on his own machines, and try passwords at his leisure. We just want that the attacker may not have any faster strategy. A hash function is the right tool for that. In full details, the hashing process should include a per-password random salt (stored along the hashed value) and be appropriately slow (through thousands or millions of nested iterations), but that’s not the subject of this post. Just use bcrypt.

Summary: we hash passwords to prevent an attacker with read-only access from escalating to higher power levels. Password hashing will not make your Web site impervious to attacks; it will still be hacked. Password hashing is damage containment.

A drawback of password hashing is that since you do not store the passwords themselves (but only a piece of data which is sufficient to verify a password without being able to recover it), you cannot send back their passwords to users who have forgotten them. Instead, you must select a new random password for them, or let them choose a new password. Is that an issue ? One could say that since the user forgot his old password, then that password was not easy to remember, so changing it is not a bad thing after all. Users are accustomed to such a procedure. It may surprise them if you are able to send them back their password. Some of them might even frown upon your lack of security savviness if you so demonstrates that you do not hash the stored passwords.

Password policy questions are a perennial fixture of IT Security stack exchange, and take many forms.

Take, for example, the recent XKCD comic on the subject:

Shortly after it was posted, user Billy ONeal asked directly whether the logic was sound: Is a short complex password or a long dictionary passphrase better? You will find answers that support either conclusion, as well as answers that put the trade-offs involved into context.

Of course, part of knowing how easy a password is to crack is knowing how a password cracker works. Are there state of the art techniques or theory specifically for attacking pass phrases? Are there lists of the most common words or ngrams used in passwords and pass phrases?

So we’ve got no consistent idea about what constitutes a “good” password, although we can probably guess at what weak passwords will fall first. But then who is responsible for deciding a user’s password strength? Pretend for a moment that we agree what a strong password is. Should we stop users from choosing “weak” passwords, or is it their own fault for not understanding information theory and the entropy content of their chosen string of characters?

The definitive answer is “it depends”. It depends on how valuable the assets being protected by password access are. It depends on whether the value is appreciated by you as service provider/systems administrator, or by the user as customer/asset owner (or by a combination of those roles, or by someone else). It depends on how much inconvenience you’re willing to put your users to, and on how much inconvenience your users are willing to accept.

So, you’ve decided that you do want to enforce a policy. How does that work? Some websites enforce a maximum password length, is that a good idea?. Should passwords be truly random?

To summarise the discussion this far: there are different ideas of what makes a good password, of who is responsible for deciding whether a password is good or bad, and of how to enforce good passwords once you do decide you want to. But all of this discussion has already put the cart before the horse. Are your passwords going to be brute-force, or will the attacker use a key logger? Maybe they’ll attack the password where it’s stored?.

Indeed, while we’re asking the big questions, why passwords at all? Might biometric identification be better? Why not just forget all of this complication over strong passwords and start taking fingerprints instead? Some reasons include the possibility of false positives from the biometrics system (who hasn’t tried holding up a photograph to a facial recognition system?), and the icky disgustingness of some other attacks.

Suffice it to say that the problem of password security is a complex one, but one that the denizens of security.stackexchange.com enjoy tackling.

This week’s question, asked by @AviD, turned out to have subtle implications that even experienced security professionals may not have been aware of.

A quick bit of background:

With all the furore about passwords, most companies and individuals know they should have strong passwords in place, and many use system enforced password complexity rules (eg 8 characters, with at least 1 number and 1 special character) but how could a company actually audit password strength.

John the Ripper was a pretty good tool for this – it would brute force or use a dictionary attack on password hashes, and if it broke them quickly they were weak. If they lasted longer they were stronger (broadly speaking)

So far so good, but what if you are a security professional emulating an attacker to assess controls? You could run the brute forcer for a while, but this isn’t what an attacker will do – maths has provided much faster ways to get passwords:

Hash Tables and Rainbow Tables

Hash Tables are exactly as the name sounds – tables of hashes generated from every possible password in the space you want, for example a table of all DES crypt hashes for unsalted alphanumeric passwords 8 characters or less, along with the password. If you manage to get hold of the password hashes from the target you simply match them with the hashes in this table, and if the passwords are in the table you win – the password is there (excluding the relatively small possibility of hash collisions – which for most security purposes is irrelevant as you can still use the wrong password if its hash matches the correct one). The main problem with Hash tables is that they get very big very quickly, which means you need a lot of storage space, and an efficient table lookup over this space.

Which is where Rainbow Tables come in. @Crunge‘s answer provides excellent detail in relatively simple language to describe the combination of hashing function, reduction function and the mechanism by which chains of these can lead to an efficient way to search for passwords that are longer or more complex than those that lend themselves well to a hash table.

In fact @Crunge’s conclusion is:

Hash tables are good for common passwords, Rainbow Tables are good for tough passwords. The best approach would be to recover as many passwords as possible using hash tables and/or conventional cracking with a dictionary of the top N passwords. For those that remain, use Rainbow Tables.

@Mark Davidson points us in the direction of resources. You can either generate the rainbow tables yourself using an application like RainbowCrack or you can download them from sources like The Shmoo Group, Free Rainbow Tables project website, Ophcrackproject and many other places depending on what type of hashes you need tables for.

Now from a defence perspective, what do you need to know? 

Two things:

Longer passwords are still stronger against attack, but be aware that if they are too long then users may not be able to remember them. (Correct Horse Battery Staple!)

Salt and Pepper. @Rory McCune describes salt and pepper in this answer:

A simple and effective defence that most password hashing functions provide now is salting – the addition of a per user “salt” value stored in the database along with the hashed password. It isn’t intended to be secret but is used to slow down the brute force process and to make rainbow tables impractical to use.  Another add-on is what is called a “pepper” value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database.

Question of the Week #1

How does changing your password every 90 days increase security? As selected by @HendrikBrummermann this has been one of our more popular posts, with discussion on the reasons for password expiration:

• To mitigate the problems that would occur if an attacker acquired the password hashes of your system
• It prevents people who use the same password for everything from getting your system compromised if their password is figured out somewhere else
• Compliance reduces the risk of penalties of non-compliance (thanks @AviD)
• By resetting password every X days we are telling the user – Hey, this is important and it should not be taken lightly

and Against password expiration:

• Your password, and the attacker’s guess at your password, are independent. The probability that the attacker’s next guess is correct is the same even if you change your password first.
• Nothing encourages passwords on post-its quite like frequent expiration, especially if there are also high complexity requirements
• It annoys users
• They end up having to work out a new password – which research shows is often is derived from the previous one in a way that is very easy to crack nearly half the time
• You can expect additional support costs to cover users who have forgotten

How to balance the pluses and minuses depends on your organisation’s risk profile and other requirements.

An alternative to password expirations is requiring stronger passwords, and we have questions and research on that also.

The associated question – Why do sites implement locking after 3 failed attempts - details another aspect of the defence against brute forcing, and discusses why 3 may or may not be a suitable number.

These questions, answers and commentary are well worth a read if you are trying to set a password expiry policy in your own organisation, or want some background as to the risks.

According to Rory Alsop’s post the most popular topic at our IT Security site is passwords.  So in this post I’ll provide a tour of some relevant questions and answers, and a look at how it sparked further investigation of the sorry state of password protection in some current systems.

There is an amazing amount of confusion, disinformation and bad practice out there with respect to password management.  This is all the more frustrating because the basics were worked out back in the dark ages (1978 to be precise) for Unix by Bob Morris and Ken Thompson (Password Security: A Case History, Morris & Thompson, 1978). They not only covered the importance of hashing passwords with salts and a slow algorithm, but they described what is now called a “pepper” (a second salt stored apart from the password database).

So if you peruse the dozens of ‘passwords’ questions you’ll find frequent reference to the basics.  We’ve also tried to summarize some of the key points in the ‘passwords’ tag info.  By the way, that’s one of the cool things about StackExchange sites in general – how they provide for a little “wiki” for each tag, to allow us to put key information just a mouse hover or one click away from readers.

Of course even among good practitioners, there are debates about the finer points, and that is another thing you’ll find here.  See e.g. the spirited conversation about highly iterated password hashes for web apps vs the risk of DDoS attacks at Do any security experts recommend bcrypt for password storage?.

In the end, you’ll often find that the right approach depends on what kind of “security” you’re looking for.  As our Frequently Asked Questions points out, this depends on context – what assets you’re trying to protect from what sorts of threats, how your different vulnerabilities compare, and how that all fits into your business plan.

I’ll end with a look at one question which demonstrates the kind of expertise we have already attracted to the site: MySQL OLD_PASSWORD cryptanalysis?.  I asked this after stumbling across some other questions about how MySQL used to deal with passwords.  To my amazement, within hours, noted cryptographer Thomas Pornin had not only cracked the old algorithm, but he included some code to demonstrate just how totally broken the OLD_PASSWORD scheme was.  Subsequently we also found a paper from 2006 with more details.  Evidently the folks at Oracle who work on MySQL hadn’t gotten the memo then, and still have a lot of work to do to improve their current scheme, as described at Looking for example of well-known app using unsalted hashes.

So stay ahead of the crowd: when you have a question about security, see if we have a good answer.  If not, ask away.  And if you see questions that need more work, please contribute to providing good answers!