.net programming, computers and assorted technology rants

Posts tagged “passwords

Cops Fail to Investigate Years of Corruption Due to Lost Password

Courtesy John Johnson, Newser

For the last eight years, a watchdog agency in India has diligently collected hundreds of corruption complaints about the Delhi police and forwarded them to the department. Not a single one has been acted upon. Conspiracy? Coverup? Nope, just good old-fashioned incompetence. Turns out, the police department didn’t know the computer password to access the complaints, reports the Indian Express.

The Central Vigilance Commission finally thought to ask the department why none of the 667 complaints it has forwarded since 2006 have been addressed, and the department chalked it up to a "technical issue," reports theBBC. And by that it meant that it didn’t know how to get into the appropriate online portal. Two officers have now received the proper training, passwords and all, presumably.

360 million recently compromised passwords for sale online

Courtesy Dan Goodin, Ars Technica

Underscoring the insecurity of many online dating, job, and e-mail services, security researchers said that they have tracked almost 360 million compromised login credentials for sale in underground crime forums over the past three weeks.

The haul, which included an additional 1.25 billion records containing only e-mail addresses, came from multiple breaches, according to a statement posted Tuesday by Hold Security. The biggest single list contained 105 million details, making it among the bigger online finds, the firm told Reuters. The cache included e-mail addresses that most likely served as user names and corresponding passwords. It remains unclear what service the account credentials unlock.


Or, how to go from "123456" to "XBapfSDS3EJz4r42vDUt."

Hold Security is the same firm that in October discovered the circulation of 153 million user names and passwords stolen during a massive breach of Adobe’s corporate network. A month later, the security firm uncovered 42 million plaintext passwords taken during a hack on niche dating service Cupid Media.

At 360 million, Hold Security’s latest find is big enough that it likely also came from hacks on poorly secured Web service servers that store large caches of user credentials. The risk of these types of attacks are biggest for users who choose the same password for multiple services. Once an attacker has someone’s e-mail address and password for one site, the credentials can be used to compromise every other site account that uses the same user name and password. Ars has long advised readers to use a long, randomly generated password that’s unique for each online account. You can find a much more detailed how-to here.

Anatomy of a hack

Courtesy Dan Goodin, ArsTechnica

Thanks to the XKCD comic, every password cracking word list in the world probably has correcthorsebatterystaple in it already.

Aurich Lawson

In March, readers followed along as Nate Anderson, Ars deputy editor and a self-admitted newbie to password cracking, downloaded a list of more than 16,000 cryptographically hashed passcodes. Within a few hours, he deciphered almost half of them. The moral of the story: if a reporter with zero training in the ancient art of password cracking can achieve such results, imagine what more seasoned attackers can do.

Imagine no more. We asked three cracking experts to attack the same list Anderson targeted and recount the results in all their color and technical detail Iron Chef style. The results, to say the least, were eye opening because they show how quickly even long passwords with letters, numbers, and symbols can be discovered.

The list contained 16,449 passwords converted into hashes using the MD5 cryptographic hash function. Security-conscious websites never store passwords in plaintext. Instead, they work only with these so-called one-way hashes, which are incapable of being mathematically converted back into the letters, numbers, and symbols originally chosen by the user. In the event of a security breach that exposes the password data, an attacker still must painstakingly guess the plaintext for each hash—for instance, they must guess that "5f4dcc3b5aa765d61d8327deb882cf99" and "7c6a180b36896a0a8c02787eeafb0e4c" are the MD5 hashes for "password" and "password1" respectively. (For more details on password hashing, see the earlier Ars feature "Why passwords have never been weaker—and crackers have never been stronger.")

Read More:


PayPal Chief: Obliterate Passwords

Courtesy Jon Brodkin, ArsTechnica

PayPal’s top security official is on a quest to kill passwords.

“Our intention is to really obliterate, within a certain number of years, both passwords and PINs and see the whole Internet—including internally in enterprises—obliterate user IDs and passwords and PINs from the face of the planet.”

That’s what Michael Barrett, chief information security officer at PayPal, told the network industry today at the Interop conference in Las Vegas. Barrett’s second job is as president of the FIDO Alliance, a recently unveiled consortium trying to create an open standard that could replace passwords. Google, Lenovo, and other companies have representatives on FIDO’s board of directors.

Read More:


7 Ways To Make Up Passwords That Are Both Secure & Memorable

Courtesy Yaara Lancet,  MakeUseOf

secure passwords

Off the top of your head, how many different passwords do you have? If your answer is 10 or less, you must be using the same password for different services, which puts you at risk. On the other hand, I counted 146 passwords stored in my password manager, and that doesn’t include ones I use on an everyday basis and therefore never bothered to add. If something happened to my password manager, these passwords will be lost. There’s no way in the world I’m going to remember them all.

Having a different password for each service is a must in today’s online world, but there’s a terrible weakness to randomly generated passwords: it’s impossible to remember them all. But how can you possibly remember hundreds of passwords? The human brain is only capable of so much, isn’t it?

Three years ago, Tina wrote a fantastic post about creating good, secure passwords that are easy to remember. The post includes some excellent tips, and I highly recommend that you read it too. Today, I’m going to re-visit this important subject, and fill you in on some priceless tips and tricks on creating strong, solid passwords that are impossible to guess, but will nonetheless be easy to remember.

What Makes A Password Safe?

This should be obvious to most by now, but no article about passwords is complete without it. Read these criteria even if you think you already know them, it never hurts to make sure!

  • It must be at least 8 characters long.
  • It must not contain easily guessed information such your birth date, phone number, spouse’s name, pet’s name, kid’s name, login name, etc.
  • It shouldn’t contain words found in the dictionary.
  • It should contain special characters such as @#$%^& and/or numbers.
  • It should use a variation of upper and lower case letters.

The Base Password

secure passwords

The trick to remembering a large number of passwords is having a base password you change according to the service you’re signing up to. The idea of the base password is by no means a new one, and I’m sure most of you already know all about it. To me, the real challenge is finding a good base password I can actually remember. While most suggestions for a strong base secure password include changing letters to numbers and symbols (i changes to 1 or !, s changes to $ or 5, etc.) and changing the spelling of known words (love becomes luv, to becomes 2), I find these methods confusing. This way of writing doesn’t come naturally to everyone, and you may forget what you replaced your letters with.

If this method works for you, by all means, go ahead. Choosing a strong base password like “spooner”, changing it around to become $p0on3r, and attaching the service’s name to it will work great. If you’re looking for other original ways to generate a strong base password, here are some great ones.

Use A Favorite Book

choosing secure passwords

This is probably my favorite method of all, and can be really fun if you like books. Choose a book you own in paper format, open it on a random page, or find a paragraph you especially like, and locate a word you can use as the base for your password.

For example, I used Charles Dickens’s Oliver Twist. I turned to page 109 at random, and found the word “jocularity”. This is the 4th word on line 33 on this page, and therefore my base password can be 109jocularity334. You can use a paragraph number instead of line number, if you wish, and play around with the numbers to place them in a way that’s easier for you to remember. For good measure, you can add some symbols in strategic place.

You can even go ahead an mark the word in the book with a pencil, to make sure you can find it again if you happen to forget the password. Just don’t keep the book next to your computer!

Example for full password: 109$jocluarity33#4MUO

Play Around With Vowels

This is a method you can use for the base password and the way you append the service’s name. There are many ways to do this creatively, one of which is taking a favorite phrase or activity and removing the vowels from it. You can also use the vowels again at the end of the password, to make it really hard to guess.

For example, I like to ride horses, so I can take the phrase “Ride A Horse”, remove the vowels, and get this: “RdHrs”. I can now choose to append the vowels at the beginning or end of the password, like this: “RdHrsieAoe”. This looks completely random, but it’s actually not, and if you know what phrase you used, you can be typing it quickly in no time. If you want to make it more secure by replacing some letters with numbers or symbols, go right ahead. You can also attach a number or symbols you know you’ll remember, but don’t use something too obvious like your postal code or date of birth.

When appending the service’s name, you can also play around with vowels. For example, let’s say you’re creating a password for Amazon. You can use the first two vowels and first two consonants of the service, and end up with “mzAa”. You can get really creative with this, and find the way that’s easiest for you to remember, but as long as you stick with the same method all the time, you should be in the clear.

Example for full password: RdHrsieAoe#285$Mkae

Use Motor Patterns

choosing secure passwords

This is a cool tip I found over at lifehack.org, and one I’ve been using for codes and such all my life without even realizing. Motor patterns are not about remembering actual passwords. Rather, you remember the pattern your fingers take when typing that password on your keyboard. Have you ever remembered a code you have to punch in or a phone number by the pattern you use to dial it? This is the same thing, and can be used to generate passwords that look completely random, but are easy for you to remember.

There are many ways you can go about creating such a password, but my favorite way is to base it on a number you know you’ll remember (again, nothing too obvious!). Let’s take 285, for example. The easiest way to create a pattern out of it would be to use the letters that are directly below these numbers on my keyboard. For example, 2wsd8ikl5tgh. Looks completely meaningless, doesn’t it? You can spruce it up with more complex patterns, upper case letters and symbols, but don’t go too far, or you might forget your password!

If you really want to play safe, you can continue with motor patterns when appending the service’s name as well. For example, by using the letters to the left of each key, MUO can turn to MnUyOi.

Example for full password: 2wsd8ikl5tghMnUyOi

Connect The First Letters Of A Passphrase

This s a fun way to create passwords that are really easy to remember. Pick a phrase you love, such as “Love Makes The World Go Round”, and use the first letter of each word to create a new word: LMTWGR. You can now use this base password in any number of creative ways. Some ideas are: reverse it, add numbers and/or symbols you’ll remember, or use first and last letters of each word (LeMsTeWdGoRd).

Now all you have to do is append the service’s name, and you’re done.

Example for full password: Le2Ms8Te5Wd#Go$RdMUO

Mix Words

This a great way to create secure passwords, but I find it a bit harder to use and remember without getting confused. Nevertheless, it’s still a very useful method, and since our brains don’t all work the same, I’m sure some of you will love it.

Take a phrase, activity, etc. with two or three words, and mix the letters up so all first letters come first, all second letters come second, and so on. For example, if my phrase is “chocolate milkshake“, my password will look like this: cmhiolckoslhaatkee. You don’t have to choose such long words, of course, you can always go for something like “eat cake” – ecaatke. It all depends on how secure you want to be.

If you want to take it a step further, use capital letters for one word and lower-case letters for the other. You can also insert your favorite number/symbol combination, as I’ve been doing with my other examples. The final step is to append your service name, and you’re done.

Example for full password: cMhIoLcLoLlHaAtKeE285MUO


choosing secure passwords

Reversing words is an obvious yet effective way to create secure passwords. Although I love black cats, my password can never be or include the phrase “Black Cat”. By reversing this phrase to taCkcalB or kcalBtaC, I get something that looks pretty much random, and is a much better fit for a base password. Some symbols and numbers could make it even more secure.

You can also use the reverse method on the service name. If you’re creating a password for eBay, try appending yaBe instead.

Example for full password: kcalB#$taC285OUM

Add Spaces

You may not be aware of this, but many services allow spaces in the passwords you create for them. I would not rely on spaces for your base password, as some services will not allow you to use them and you’ll be stuck, but you can try adding a space between your base password and service name, and see if that works. If it does, it’s another layer of security for your password.

Check Your Password

Now that you’ve devised a base password you can remember, it’s time to check how secure it really is. HowSecureIsMyPassword will tell you how long it would take a desktop PC to crack your secure password, and also provide you with tips on how you can improve it.

secure passwords

The Password Meter is also a great place to check your password, and gives your password a score from 1 to 100. It provides detailed feedback and suggestions on how you can improve your password.

These Are Just Some Suggestions

There are endless ways to create memorable and strong passwords. Remember that even the methods mentioned above are only examples, each of them can be used in slightly different ways to create completely different results. Go with what you think would be the easiest for you to remember, and build your password around that. As long as you follow the basic guidelines, and use the same rules for all your passwords, you shouldn’t have problems.

If you’re not convinced, and would rather continue with random ones, find the best ways to manage your passwords. If you need further help in managing your huge password collection, head over to our password management guide for some priceless information.

How do you create secure passwords that are easy to remember? Have some tips to share? Tell us in the comments!

Image credit: Lock image via Shutterstock, Password image via Shutterstock, Woman search book image via Shutterstock, Keyboard image via Shutterstock, Turn back sign image via Shutterstock

Password Storage Disclosure

Courtesy of troyhunt.com

Should websites be required to publicly disclose their password storage strategy?

I don’t know how Evernote stored my password, you know, the one they think might have been accessed by masked assassins (or the digital equivalent thereof). I mean I know that their measures are robust but then again, so were Tesco’s and according to their definition, “robust” means storing them in plain text behind a website riddled with XSS and SQL injection (among other security faux pas).

Last year we saw LinkedIn breached and some millions of SHA1 passwords with no salt exposed. Last week we saw Australia’s own ABC do the same thing; it took me 45 seconds to crack 53% of those and others have since gone on to crack more than 90% of them. These storage mechanisms are not robust, they’re stupid. The problem, of course, is that consumers don’t know a website’s password approach is stupid until after they’ve entrusted their passwords with the site. That is a fundamental problem.

I propose that websites should be required to disclose their password storage mechanism. The disclosure would sit right next to the point where the password is provided for persistent storage, namely on the registration and password change pages. It would be as simple as this:

Let me explain the thinking.

Consumers don’t care (but companies do)
Well actually, that’s not entirely true; consumers don’t care about password storage when they’re signing up for a service, they just want to get online, buy their book / t-shirt / porn then move along to something else. However, consumers do care if their credentials are leaked and other adverse things happen as a result. Of course they shouldn’t have reused their damn passwords in the first place but unfortunately, this is the world we live in.

No, public disclosure of password storage mechanisms won’t change consumer behaviour, but it will change corporate behaviour. Let’s take a case in point – Tesco. You would never see this on their registration page:

That’s not because they don’t store them in plain text, they do (allegedly), rather it’s because there’s no way an organisation like Tesco will ever willingly acknowledge it. Let’s face it, plain text storage of credentials is probably the single most widely criticised security practice in the industry right now and encrypted passwords (remember folks, this is different to “hashed”) is not far behind it. No, an organisation would far sooner fix their sloppy password storage than publicly acknowledge such a glaringly bad practice.

“But it will make it easier to crack passwords”
But it won’t, and there are several reasons why this argument doesn’t stick. First of all, let’s pull out a bit of Kerckhoff’s principle just for good measure:

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.
One ought design systems under the assumption that the enemy will immediately gain full familiarity with them.
Now of course that last statement is precisely what happens in cases like the ABC; it was as simple as Googling a cipher to immediately understand how their cryptography had been implemented. In the vast majority of cases, the implementation is one of the default models offered by the web framework being used. We know this because we have extensive evidence from numerous breaches.

The other simple reason this statement isn’t valid is that the password crypto knowledge is only of any use after the site has already been breached and passwords disclosed. Stating the password storage mechanism provides absolutely zero value to an attacker attempting to exploit, say, a SQL injection risk – it’s just not even in the same ballpark.

Would a statement about poor password storage make a site a bigger target? Ignoring for a moment that other, totally independent flaws must exist in order to gain access to the (hopefully) protected passwords in the first place, if an organisation lacks the confidence in their password storage mechanism to publicly disclose it, should some pressure not be placed on them?

Another reason this doesn’t make much sense is that many websites leak information about the password storage mechanism anyway. Ever used a “forgot password feature” and been emailed your password? There’s disclosure that they’re not hashing it so it’s either immediately accessible once the database is disclosed or accessible once the key is obtained and once a box is popped, this is very, very frequently a trivial task. There’s an entire site dedicated to naming these purveyors of poor password management over at plaintextoffenders.com so certainly there is voluminous public data on them already.

How much information should be disclosed?
Password storage isn’t always just as simple as “we use this hashing algorithm with this salt” and indeed the protections offered by, say, symmetric encryption may be as good as null and void if the key management strategy is bad. So how much information should be disclosed? Where do you draw the line between a simple statement as seen in the badges above and a more comprehensive – and perhaps revealing – statement of a website’s security position?

As I said earlier, this is all comes back to the simple fact that whilst it’s possible to create more elaborative password protection schemes, it’s rarely the case. Nine times out of ten (ninety nine times out of one hundred?) the crypto algorithm, key strength and salt would be sufficient. If there are defences beyond this then great, but if you’re just whacking a single round of SHA1 with a salt on the password then regardless of what else you’ve done there’s the potential for very fast pwnage.

This information could be contained in a short statement at the point of password creation so at registration and password change facilities. The vast majority of cases will fall into one of a handful of simple pattern relating to algorithm and strength so would be easy to template. Smarter crypto people than me would find the right balance of information, but IMHO the first image in this post (which, incidentally, is from the ASP.NET universal membership provider) tells you everything you need to know.

Legislative implications
Of course the problem with any sort of requirement like this is legislation and the problem with legislation is that it’s going to different depending on where the website is located. There are no easy answers to this, but there are precedents.

Here’s a good case in point: the EU cookie law. Without a doubt, this is one of the stupidest online laws you will find. If you’ve had the distinct pleasure of not seeing this in action before, here are some examples:

“Hey, you’re going to get these little bytes of data stored securely within your browser but they make the website better, honest, and if you don’t like it then you can GTFO because there’s never a ‘decline’ button anyway (but you can then weed through your browser settings, disable them and screw up your ability to logon just about anywhere)”.

If the EU can pass such an inane, illogical, impractical, zero-value law that gives nothing back to the consumer and merely impedes usability, surely they can cope with such a fundamental requirement as to confirm that such an essential security practice has been properly put in place?

And speaking of security, mandatory data breach laws are a good example of where legislation has some number of precedents. The US has had laws in place to address this for a decade, the EU has had their Directive on Privacy and Electronic Communications for a few years now and even down here in Australia there’s a renewed push to implement a mandatory data breach notification law (it’s surely just a matter of time).

If such broad support can be garnered for notifying consumers after a company has screwed up their security, surely it must be feasible to do it before they’ve lost everyone’s passwords?

How would you roll this out?
You provide a moratorium after which companies need to comply. There are many precedents of this; the EU cookie law is one, Australia’s spam act of 2003 is another one. There is no shortage of precedents of similar laws where periods of grace have been provided for companies to get compliant. Naturally you allow sufficient time because let’s face it, a whole bunch of orgs are actually going to fix their crappy implementation rather than whack the big “plain text” badge up on the site.

What about the overhead on organisations who then need to abide by this new regulation? C’mon, we’re talking about a single statement that exists in maybe two places on the website and you provide a long lead time to implement it. The only time this is going to amount to anything more than a trivial amount of work is if an org feels compelled to change their approach to storage rather than disclose the current state and honestly, is this not a good thing? If an organisation is either too embarrassed to disclose their password storage mechanism or if disclosure leads to increased risk, they’ve failed at it badly and it’s better for that information to be public now rather than after a breach when it’s too late.

Then of course there’s enforcement – what happens when an org doesn’t comply? Or worse, lies about the password implementation? Inevitably this depends on the jurisdiction of the offending site, but there are many precedents of controls and penalties already in place to handle similar laws for such grievous offences as not declaring those extra few bites in the response header (cookies) or not disclosing a breach (ok, these guys should really get the book thrown at them). If we can fine companies for not putting an unsubscribe link in an email, we can fine them for jeopardising passwords.

The constructs exist already.

In summary…
We have a security problem on the web, of that there is no doubt. What compounds this is that we also have a bullshit problem. You can see this problem in action every time an organisation talks about being “robust” or “never being hacked” or any other number of subjective, unquantifiable statements that tell you nothing about the measures that are actually in place and amount to little more than marketing speak. This is just not good enough. Trust alone is not good enough. We need accountability before passwords are compromised, not after.

What password storage disclosure does is solves the bullshit problem which in turn goes a long way to solving the security problem. You cannot both make claims of “robustness” and admit to SHA1 with no salts, they’re simply not compatible statements. Of course it won’t address the vector by which the passwords were obtained in the first place when a breach occurs, but it will change the approach to password storage by many organisations as they simply will not stand up and publicly admit to storage in plain text. There will also be a significant number that will be reluctant to admit to insecure cryptographic storage and those that do will open themselves to public derision, and rightly so.