Do you have our bonus card?

The trials and tribulations of password handling
Keine Kommentare

With the leak of thousands of unsalted hashes from LinkedIn, eHarmony and, password handling has hit the headlines in the past few weeks. How can savvy website operators avoid this embarrassing fate?

Do you collect Miles? Are you a member of our savers’ club? What’s your frequent flyer number? Is it just me or is it getting really annoying that every time you shop you get asked for it. If I wanted to join all the programs I’d probably have 20 or more plastic cards in my wallet. And, of course, to make use of the collected points, miles or whatever ‘currency’ they came up with, you need a PIN. Or a password. I have no idea how I should remember them all – let alone pick a unique one per card and service. Or, for that matter, how anyone else should be capable of doing it.

I’d say that makes password-based authentication the most often implemented feature on the web. One would assume that since developers all over the world do implement it over and over again, it’s hardly more then the proverbial finger exercise. Given the number of (open source) frameworks for PHP, there should be many ready-to-use – and secure – solutions for all types of verification. Yet we see compromised service and leaked user data on a weekly basis.

LinkedIn lost approximately 6.5 million password hashes the other day, managed to do the same with 2.5 million hashes – just to name the more prominent websites. As embarrassing as it might be to have to admit that an attacker managed to break in and was even able to take the user data along with him, it’s only a matter of time. There is no such thing as 100% security and as soon as any server is up and running, it’s bound to be attacked.

Knowing it’s more likely than not that an experienced attacker will be able to gain access to the user data at some point, it becomes even more important to think about how to securely store this information. And here’s where things get really embarrassing: many sites still store passwords in cleartext in their database! A security nightmare that is explained by the need for the administrative staff or support team to be able to impersonate a user.


Unsere Redaktion empfiehlt:

Relevante Beiträge

Benachrichtige mich bei
Inline Feedbacks
View all comments
- Gib Deinen Standort ein -
- or -