Posts Tagged ‘passwords’

Password theory is good – password practice is poor

November 25, 2013 Leave a comment

There’s nothing wrong with passwords. At least there’s nothing wrong with the theory of passwords.

You have a locked room. The only way into the room is through a single door. The only way through the door is with a single key. You have the only key. What’s wrong with that?

Throughout this article we’ll talk about locked rooms and keys. The locked rooms are your accounts, mostly on the internet; and they contain your valuable personal data. The keys are your passwords to those accounts. You should have a separate key for each locked room. If you have a single key for multiple rooms and you lose that key or it is stolen, the finder can get into all of your rooms.

So, just like any key to any room, we have a responsibility to keep it or them safe if we want to keep our property safe. We need to make sure they cannot be guessed; that we do not leave them lying around for others to find; that we make it as difficult as possible for hackers to steal them directly from our desktop computers (anti-virus, firewalls and above all else, common sense); and that we do not make copies and use the same key for multiple rooms (we need a different key for every different room).

The problem is that we hear about new password thefts almost every day. Some of them happen because of earlier password thefts. As soon as your password is stolen, you are no longer the only person who can get into your locked room. Any person who has your password, the key to your locked room, can steal all of your personal, private and valuable information. Here’s a selection of thefts, basically just what I can remember – there’s many, many more – from this year alone:


Adobe 150,000,000
Apple 275,000
Cupid Media 42,000,000
Drupal 1,000,000
Evernote 50,000,000
Living Social 50,000,000
LoyaltyBuild 1,500,000
MacRumors 860,000
Morningstar 182,000
Nintendo 24,000
Racing Post unknown
Scribd c300,000
Twitter 250,000
UbiSoft up to 58,000,000
Ubuntu 1,800,000
vBulletin 900,000
Yahoo 450,000


Criminals get passwords either by knowing them (because they are given them, or they are insufficiently hidden), or they guess them. In the first case they use social-engineering psychology to persuade the user to hand them over (more information on social engineering here, and spear-phishing here), or they find them unhidden by the user. In the latter case they guess the most common passwords, or use automated dictionaries to try every possibility until the right password (key) for a known account (locked room) is found.

Most websites include a limit on the number of failed access attempts allowed within a predetermined period. This means multiple attempts to guess the right password while online are almost certain to fail. That is why criminals steal password databases from websites – so that they can try millions of automated guesses offline without being interrupted. The purpose is still to find the key to gain entry to your locked room, and to steal everything of value within it.

But there’s an easy solution: use complex passwords that cannot be manually guessed, and electronically hide them so that automated guessing still won’t work.

There are two methods for ‘electronically hiding’ text: encryption and hashing. Encryption involves converting text into an apparently meaningless jumble of characters in a manner that can only be unjumbled if you have the secret decryption key – which can be the same as (symmetric encryption) or different to (asymmetric encryption) – the encrypting key for your password. Encryption, by definition, comes with the ability to decrypt – the ability to return the jumble back to the original text. Hashing is different. Hashing is one-way only. Hashing converts the original text into a meaningless jumble that cannot be de-hashed back to the original.

Hashing is the right solution for websites to hide their users’ passwords. It means that even the website doesn’t need to know the password, only the hash, which they cannot return to the original password key. With this method passwords need never and should never be stored by websites.

When you create a new account you are asked to provide a password. That password is hashed, paired with your user ID (often, but not necessarily, your email address), associated with your account, and stored. Whenever you want to access your account, you again enter your password. It is hashed again. If your user ID and the new hash result match with something stored, you are allowed access to the associated account.

Hint: if you forget your password, distrust a website that is able to send you your old password by email – it shouldn’t have your password. The ‘correct’ procedure is to guide you to a place where you can create a new password.

So, the effective use of passwords is a partnership. User’s need to create good passwords and keep them safe, while internet companies need to store them safely and securely. It is my contention that done properly, this will be enough.

Alternatives to the simple password
Before we go too far on the strengths and weaknesses of passwords, we should mention the alternatives.

Passwords are designed to provide user authentication – to prove that Joe Smith really is not just any Joe Smith, but the right Joe Smith. In security terms, authentication is often described by the number of factors it uses – with the implication and a degree of validity that the more factors used, the more secure the authentication. (Personally, I do not believe that is necessarily true.) ‘Factors’ in this sense are things you know (like a password), things you have (like a token), things you are (like a biometric), and so on. The two most commonly used additional factors today are soft tokens and biometrics.

Soft token 2FA
An example of the most commonly used two-factor user authentication is the separate token sent out-of-band to the user’s mobile phone. This is a one-off code. Now you could say that ‘the thing that is owned’ is the separate code, or the phone that it is received on. Either way, the user now requires something he knows (password) and something he owns (phone/token).

I have two problems with this. Firstly, whenever you introduce complexity into security, you also introduce weakness – the phone and the communication sending it can both be attacked separately. The second issue is that this complexity makes it harder to use – and users do not want any more difficulty. If 2FA is an option, most users opt to ignore it. That in itself is not an issue, because we’re back where we started. But the fact that there **is** a 2FA option can mean that users take less care, whether they opt for 2FA or not, simply because it is clear that the vendor is taking more care. There is a danger that 2FA can cause a false sense of security.

Biometric authentication
Biometrics is getting a lot of publicity. Governments use facial biometrics for surveillance and passports; law enforcement uses fingerprints for criminal recognition; and Apple uses finger scans for opening the new iPhone.

I have three concerns. Firstly, nearly all biometrics can be forged. It took researchers just days to break through Apple’s iPhone finger scan. Secondly, what do you do if your biometric is compromised? If your password is compromised, you create or request a new password. What do you do if your iris, or your voice, or your thumbprint is compromised? And thirdly, it’s that old false sense of security – people using biometrics tend to think they are more secure than they actually are.

My contention, which I shall try to demonstrate below, is that passwords – used correctly – are adequate on their own. All we have to do is use them correctly.

Creating secure passwords and keeping them safe
Criminals get into locked rooms by guessing the password key.

When Gawker was breached in 2010, researchers found that the ten most popular passwords were

  1. 123456
  2. password
  3. 12345678
  4. lifehack [LifeHacker is a Gawker publication]
  5. qwerty
  6. abc123
  7. 111111
  8. monkey
  9. consumer
  10. 12345

When LinkedIn was breached in 2012, researchers discovered that the ten most popular passwords were:

  1. password
  2. 123456
  3. 12345678
  4. 1234
  5. qwerty
  6. 12345
  7. dragon
  8. pussy
  9. baseball
  10. football

How long do you think it would take to guess passwords like these?

Of course, if the passwords are all held in a single database without any form of electronic jumbling, then a password thief doesn’t need to guess anything because he’s got them written down in front of him. So the websites store the passwords ‘hashed’.

Now the criminals have to start guessing. To help this process, they use computers and specialized dictionaries called rainbow tables. Rainbow tables are effectively long lists of precomputed hash outputs together with the original input text that was used.

Stolen password hashes are then simply compared to the rainbow tables. If the hash output is found, then the password is known – that is, the password has been cracked.

So when you consider a new password, you should also consider how they are cracked with rainbow tables. Any word that appears in a dictionary will be in the tables. Any number up to at least 999,999,999 will be in the tables. All conceivable combinations of letters up to a certain length, and all conceivable combination of letters and numbers up to a certain length, will appear in the tables. In short, if you use a password made up of any combination of letters and numbers up to, say, seven characters, and that password is stolen, you should consider it already cracked and available to the criminals.

This will include some of the commonly recommended methods for coming up with passwords – such as initial letters from quotations. “into the valley of death rode the six hundred” could provide ‘itvodrt600′. That looks like a strong password – but you should assume that it’s in a rainbow table somewhere.

The way to avoid rainbow tables is to use a very long password that mixes uppercase, lowercase, numbers, special characters and punctuation marks. The problem then becomes one of usability – passwords that are difficult to guess are even more difficult to remember.

The best way to produce, store locally and safely, and use strong passwords is to use a reputable and recommended password manager. I’m not going to recommend any myself – you must research that on your own. But the one I use generates passwords for me such as


I consider that to be reasonably secure against most tables.

The responsibility of the website
The fact remains that if the vendor doesn’t keep passwords hashed, then it really doesn’t matter how complex I make them.

So if it is incumbent on me to generate strong passwords, then it is equally incumbent on the website to store them securely. That means hashing them.

Actually, it means more than that. It means using a strong hashing algorithm (not all are equally good); it means using a slow algorithm (some were designed for speed when computers were slow, with the unintended consequence of making cracking faster and therefore easier); and they should be salted. Salting is the addition of additional random characters to the user’s password. Basically, salt makes the password even harder to crack – it turns a medium strength password into a strong password.

This is standard best-practice. Unfortunately, too many websites do not conform to best practice. In the last few weeks we have heard:

  • Adobe did not hash its passwords; it encrypted them (better than nothing, but not as good as hashing) It also stored users’ password hints next to the encrypted passwords in plain text – making it, in some cases, obvious what the password was.
  • LoyaltyBuild stored users’ credit card numbers unencrypted and with the cards’ CVV numbers.
  • Cupid Media stored its users’ passwords in plaintext.

What is the point of coming up with a long, complicated, unguessable password if the website just hands it to the criminals on a plate?

Conclusions and recommendations
For password access to locked rooms to work, they need to be strong (from the user) and hashed and salted by the website. Clearly that frequently doesn’t happen; and that’s why we have rampant identity theft.

Since it doesn’t happen voluntarily, we need a new code of practice backed by regulation if necessary. Much of it will fall on the website; but that’s a small price to pay for a secure and trusted internet.

Firstly, websites should require a minimum strength password from their users – so strong, in fact, that it becomes easier to use a password manager than to try to make them up.

Secondly, users must learn not to reuse the same password on multiple sites. Security audits must confirm this as part of staff awareness training, and schoolchildren need it to be taught in schools.

Thirdly, websites must be required, by law if necessary, to make it clear how they protect their users. Inadequate password security could then be shunned by users and ridiculed by professionals.

With these three basic developments, password-protected access will do the job it was designed to do: locked rooms will stay locked, personal and private.

Categories: All, Security Issues

A hack by any other name tastes just as bad

June 23, 2013 Leave a comment

What is a hack? No, seriously, I need to know.

Last weekend the People/Mirror reported that Scout7 had been hacked and Manchester City’s scouting database compromised.

Scout7 came back and said it hadn’t been hacked and the integrity of its systems was sound. But City’s database was accessed by someone other than City.

Scout7 was saying that as far as its systems were concerned, it was a legal access via genuine credentials — implying that City must have lost, mislaid, or had its password stolen. It’s an interesting idea. The implication is that if you lose your house-keys and someone finds them, gets in while you’re out, and reads your personal, private diary, you haven’t been burgled.

That, of course, is emotionally absurd. But Scout7 is saying that it (the housebuilder) cannot be blamed for the burglary and doesn’t need to do anything about it. We’ll come back to that.

Meantime, how does this apply to ‘breach notification’? Is a breach a hack? Is the illegal use of legal credentials by a clear bad guy something that will require notification? Will companies be able to claim, we weren’t breached because the hackers got in through legitimate passwords, therefore we don’t need to tell anyone?

Incidentally, Kurt Wismer has an interesting story equally hinging on lack of semantic clarity: was the poor targeting in Stuxnet down to some lax manager saying , ‘make me a virus’, when he really meant, ‘make me a trojan’? Worth reading.

But back to Scout7. No, it cannot avoid its liability by implying it was a customer’s fault for losing his/her password. We all know that passwords do not provide adequate access security. So relying on them, and not adding a second factor to the access control, is effectively building something not fit for purpose. So as far as I am concerned, it got hacked.

Categories: All, Security Issues

LivingSocial got hacked; 50 million passwords stolen, but it still hasn’t learnt all the right lessons

April 30, 2013 Leave a comment

We learnt over the weekend that LivingSocial got hacked, and 50 million passwords were compromised (I reported on the story for Infosecurity Magazine here: 50  million LivingSocial passwords stolen. We know that the passwords were salted and hashed with SHA1. And we know that LivingSocial thinks that’s enough, because talking about the hack it said, “The information accessed includes names, email addresses, date of birth for some users, and encrypted passwords – technically ‘hashed’ and ‘salted’ passwords. We never store passwords in plain text.”

It is, of course, far from enough. SHA1 hashed passwords will take only a few seconds to crack using standard rainbow tables. Salted SHA1 hashed passwords will take a little longer, but not much. The only ‘correct’ thing LivingSocial has done has been a forced password reset for its users, and a subsequent shift to the more secure bcrypt hashing algorithm. But frankly that’s too late for any users that have had their passwords stolen if they’re re-used on other accounts (statistically highly probable).

LivingSocial has so far given no details on who perpetrated the hack, with what, or when. That last is important since all of the users’ other accounts using the same password have been vulnerable since the moment the hackers exfiltrated the data. Nor do we know if the hackers gained access to any salting scripts on the server – which would largely nullify any benefit from the salt process.

I don’t have a LivingSocial account, so I’m OK. But I decided to sign up after the hack. The sign-up page wanted an email address. I gave it ‘yougottabejoking’. It also wanted a password. I entered ‘12345678’. It accepted both, and gave me an account – this account:


My LivingSocial Account – no prizes for guessing the password...

My LivingSocial Account – no prizes for guessing the password…


Had I done this before the hack, said hackers would now be in possession of both my email address and my password – a password that even salted and hashed would not take long to crack. If I used the same password elsewhere – as many users do – then all of those other accounts would also be cracked.

My point is this. Salting and hashing is pretty useless if the password is weak. Salting and hashing (especially with bcrypt) is very good if the password is strong. So rather than allowing me to enter a 12345678, LivingSocial should be imposing a strong password policy that forces all users to use a strong password.

Categories: All, Security Issues

The Data Protection Regulation should be amended to force companies to disclose how passwords are stored

December 7, 2012 Leave a comment

Over the last couple of days it has been disclosed that an amazing amount of personal data on 1.1 million Americans has been lifted from the US Nationwide insurance group. Passwords do not appear to be involved – it’s a storage of data rather than an interactive site. But the point is that this data would appear to have been unencrypted – at least the company concerned hasn’t specified one way or the other; and that’s the problem.

Time and again we learn of plaintext passwords being stolen. Plaintext is unacceptable, but it happens. Sometimes, they are stored hashed by SHA1. This is unacceptable because dictionary attacks and Jens Steube’s newly announced brute force attack makes them surprisingly vulnerable; but it happens. At the very least, passwords should be stored hashed with SHA1 – preferably better – and salted.

I for one would be reluctant to commit my password to any site that stores that password with anything less than salted SHA2. But they don’t tell us, do they.

So I call now for the European Commission to amend the proposed Data Protection Regulation to include a requirement for all sites that store user passwords to make it clear on their site, at registration, precisely how those passwords are stored: plaintext, hashed (with what), or hashed and salted. This is the only way we will be able to force vendors to improve the way in which they handle our data.


See also: Storing passwords: why you should flavour your hash with salt

Categories: All, Security Issues

Password is too weak…

August 11, 2012 23 comments

It’s good to see providers beginning to rethink their password policies. But this from BT?

BT password

Password paranoia?

This was the rejected password:


I cannot begin to imagine what a strong password would look like…


see also: Yahoo says my password is too weak

Categories: All, Security Issues

News stories on Infosecurity Magazine: 17, 18, 21 and 22 May, 2012

May 22, 2012 Leave a comment

My recent news stories…

You don’t need to be hacked if you give away your credentials
GFI Software highlights the problems of users’ carelessness with their credentials: who needs hacking skills when log-on details are just handed over?
22 May 2012

A new solution for authenticating BYOD
New start-up SaaSID today launches a product at CloudForce London that seeks to solve a pressing and growing problem: the authentication of personal devices to the cloud.
22 May 2012

New HMRC refund phishing scam detected
Every year our tax details are evaluated by HMRC. Every year, a lucky few get tax refunds; and every year, at that time, the scammers come out to take advantage.
22 May 2012

UK government is likely to miss its own cloud targets
G-Cloud is the government strategy to reduce IT expenditure by increasing use of the cloud. It calls for 50% of new spending to be used on cloud services by 2015 – but a new report from VMWare suggests such targets will likely be missed by the public sector.
21 May 2012

New Absinthe 2.0 Apple jailbreak expected this week
The tethered jailbreak for iOS 5.1, Redsn0w, still works on iOS 5.1.1. This week, probably on 25 May, a new untethered jailbreak is likely to be announced at the Hack-in-the-Box conference.
21 May 2012

TeliaSonera sells black boxes to dictators
While the UK awaits details on how the proposed Communications Bill will force service providers to monitor internet and phone metadata, Sweden’s TeliaSonera shows how it could be done by selling black boxes to authoritarian states.
21 May 2012

Understanding the legal problems with DPA
We have known for many years that the EU is not happy with the UK’s implementation of the Data Protection Directive – what we haven’t known is why. This may now change thanks to the persistence of Amberhawk Training Ltd.
18 May 2012

Who attacked WikiLeaks and The Pirate Bay?
This week both the The Pirate Bay and WikiLeaks have been ‘taken down’ by sustained DDoS attacks: TPB for over 24 hours, and Wikileaks for 72. What isn’t known is who is behind the attacks.
18 May 2012

BYOD threatens job security at HP
BYOD isn’t simply a security issue – it’s a job issue. Sales of multi-function smartphones and tablets are reducing demand for traditional PCs; and this is hitting Hewlett Packard.
18 May 2012

25 civil servants reprimanded weekly for data breach
Government databases are full of highly prized and highly sensitive personal information. The upcoming Communications Bill will generate one of the very largest databases. The government says it will not include personal information.
17 May 2012

Vulnerability found in Mobile Spy spyware app
Mobile Spy is covert spyware designed to allow parents to monitor their children’s smartphones, employers to catch time-wasters, and partners to detect cheating spouses. But vulnerabilities mean the covertly spied-upon can become the covert spy.
17 May 2012

Governments make a grab for the internet
Although the internet is officially governed by a bottom-up multi-stakeholder non-governmental model, many governments around the world believe it leaves the US with too much control; and they want things to change.
17 May 2012

Categories: All, Security News

Infosecurity Magazine news stories for 15/16/19 March 2012

March 20, 2012 Leave a comment

My news stories on Infosecurity Magazine for Thursday 15, Friday 16 and Monday 19 March…

Duqu: a government intelligence agency built cyberweapon?
Last week Kaspersky Lab announced that it had discovered an unrecognized programming language within the Duqu worm code. It asked the research community for help in diagnosis; and the research community responded.
19 March 2012

Four EU Member States to take part in ENISA’s ‘security week pilots’
Four EU Member States are planning to run national ‘security weeks’ during October 2012. The aim is to develop a fully-fledged combined EU and US Security Month by 2014.
19 March 2012

LulzSec’s Kayla given bail
Ryan Ackroyd, a 25 year-old Brit from South Yorkshire, was granted bail at Westminster Magistrates’ Court pending a plea and case management hearing at Southwark Crown Court scheduled for 11 May.
19 March 2012

Did Anonymous accidentally blow covert surveillance of Assad’s emails?
On 6 February hacktivist group Anonymous delivered a threatening email to Bashar Assad’s personal email account. On 7 February his use of that account ceased.
16 March 2012

Trends and truths in DDoS attacks
Neustar has analyzed the evolution of DDoS attacks over the last year, showing the techniques that are used and the problems that will come.
16 March 2012

Password managers on mobile devices – fail
Elcomsoft, a computer and mobile forensics specialist, is today presenting the results of its analysis of mobile device password managers at Amsterdam’s BlackHat Europe conference.
16 March 2012

Kaspersky’s February malware scorecard
Kaspersky Lab has published its monthly malware report for February, discussing Duqu, Google Wallet and Google Analytics, mobile threats and attacks on corporate networks.
15 March 2012

2011 Global Encryption Trends Study
Ponemon’s Global Encryption Trends Study commissioned by Thales is a treasure trove of insights into the corporate view of security.
15 March 2012

Quis custodiet ipsos custodes – Who watches the watchmen?
The Dutch Big Brother Awards for 2011 have been announced. There are three prize categories: People, Companies and Government.
15 March 2012

Categories: All, Security News

Think like a cracker to hack an Apple

February 9, 2012 Leave a comment

Elcomsoft is a hacker. A white hat hacker, one of the old school, not one of these new-fangled, bad boy (or girl) black hat criminal cracker hackers, but a hacker nonetheless.

It produces encrypted file recovery systems, usually in the form of password recovery tools. They may be used by some of the cracker hackers as password cracking tools, but they are built as honest-to-goodness password recovery tools. And most of us could have used one at one time or another. Now Elcomsoft has a new string to its bow: the very first Apple iWork file cracker – sorry, password recovery tool.

Why is this the first? Because, explains Elcomsoft, Apple’s encryption is “an industry-standard AES algorithm with strong, 128-bit keys. Brute-forcing a 128-bit number on today’s hardware remains impossible.” This effectively means that the only way to recover an encrypted iWork file is to hack the password. But, says Elcomsoft, “Apple used the PBKDF2 algorithm to derive an encryption key from plain-text passwords, with some 4000 iterations of a hash function (SHA1).” If that’s as much geek-speak to you as it is to me, the bottom line is that brute-forcing the passwords would be too lengthy to be meaningful.

Unless, and this is where thinking like a hacker comes in, you can find some way to reduce the likely number of possible passwords. First, Elcomsoft notes that the price range for iWork shows that it is a consumer rather than business product. Users are likely to be human beings rather than corporate automata. “Multiple researches,” says Elcomsoft, “confirm it’s a given fact that most people, if not enforced by a security policy, will choose simple, easy to remember passwords such as ‘abc’, ‘password1’ or their dog’s name. In addition, it’s in the human nature to reduce the number of things to remember. Humans are likely to re-use their passwords, with little or no variation, in various places: their instant messenger accounts, Web and email accounts, social networks and other places from which a password can be easily retrieved.”

From this starting point and armed with “ElcomSoft’s advanced dictionary attack with customizable masks and configurable permutations,” brute forcing the passwords suddenly becomes a lot simpler; and iWork recovery is now included in the Elcomsoft Distributed Password Recovery Tool. It is, says Elcomsoft, “the human factor and advanced dictionary attacks that help it recover a significant share of iWork passwords in reasonable time.”

Breaking Apple iWork Passwords

Drage, RIPA and implications for the rule of law

October 16, 2010 Leave a comment

The Oliver Drage case is still causing a lot of discussion; and a lot of learned and technical people are exercising their minds on how to defeat the relevant clauses within the RIP Act that requires us to surrender our computer passwords for no other reason than the police or other lawful entities tell us to. Almost all of these methodologies require us to be devious to one degree or another, and/or to tell an outright lie (and hope to get away with it simply because it cannot be disproven).

I have a problem with this. If I suspect a policeman or other authorised body to be on a fishing trip with no genuine moral reason to require my passwords, I will decline to provide them. That’s out of principle. It is ‘principle’ that will also require that I neither lie nor behave deviously. Why should I compromise my principles? It is this law that is immoral, not me.

This leads us inevitably and inexorably to the overriding question: is or should the rule of law be sacrosanct in a democracy? In reality, there is no easy definition for ‘the rule of law’; but I’m going to suggest that (in the UK) it embodies two elements: that nobody is beyond the law; and that the law is whatever Parliament declares the law to be.

So, it comes down to this: if I believe in the rule of law I would have to surrender my passwords to any authorised body simply because Parliament has declared this to be the law; if I decline to surrender my passwords, then I do not accept the rule of law. I am, in the old sense of the word, declaring myself to be outside of the law: I am an outlaw.

This is the conundrum. If I tell lies and act deviously about my password, then I am a bad person but probably free. But if I don’t tell lies and don’t act deviously, then I am a good person but locked up. Can any thinking person have any respect for either such a law or indeed those who first framed and subsequently maintain such a law?

The law is an ass. Our law-makers are asses. And Parliament is the House of Asses.



Get every new post delivered to your Inbox.

Join 127 other followers