Editorial

Passwords are dead! Now what...?

It seems that our cyber-identities are constantly under attack and the recent password leaks from high profile sites like LinkedIn, eHarmony, and last.fm are signaling the fact that our data in the cloud is not as secure as some had hoped. Most people use dozens, if not hundreds of different websites and keeping track of all of these logins is difficult. The result is that many people use the same password on multiple sites, compounding the criticality of these security breaches. So what's the solution?

The first issue is that companies need to do a better job protecting our data and especially our security credentials. The fact that LinkedIn never salted the password hashes has made the task of cracking passwords infinitely easier. The salt would've had minimal overhead to LinkedIn and would've gone a long way to reducing the impact of the breach. In addition, there are many tools available that help organizations detect and stop these types of attacks. While at HP Discover, we've seen several good offerings that would also help an organization know that they were under attack. From tools like HP Fortify that tests application security to Tipping Point for network monitoring to ArcSight for information analysis, there are applications and processes that can be put into place to help prevent these leaks from happening in the first place.

Having said that, no system is 100% secure; breaches will happen and passwords will be released. So is the password a dinosaur, a relic from the past that has outlived its usefulness? And if so, how should we be protecting our identities?

One way is to have a central password safe that all sites rely on for authentication. This is something that Facebook as a platform is offering. Indeed, you can even login to Neowin with your Facebook account if you so choose. This has the benefit of allowing you to pick an ultra-secure password and not risk forgetting it. It also means that you can hopefully rely on the universal platform to properly store and secure your passwords in such a way that even if they are compromised, the actual data can not be read. However this seems to be a poor idea overall for many reasons, not the least of which is that if history has proven anything it's that no system is safe. Indeed, put all of your valuables in a single repository just means the bad guys will focus their fire at that target.

Another idea is to use a token in your possession that constantly changes. Sites like eBay and World of Warcraft already provide this functionality and it's a good way to help secure your identity. Even if someone steals your password, they can't login as you without the token. This isn't a foolproof solution though, as last year's attack on RSA proved, but it's another layer of protection (called two-factor authentication) that is a step in the right direction. Unfortunately this doesn't scale well if you have to carry 100 tokens around on your key chain in order to access the web.

Perhaps the best solution would be to tie access information into your mobile phone. More and more people are using smartphones, so instead of a token, sites could provide an app for your phone or perhaps send an SMS message that contains a passcode to you. The downside is that more companies would have access to your phone number and if you lose your device, you increase the chance of allowing anyone to access your data on the web, but this might be a better solution than having poorly secured passwords that attackers can easily obtain.

Do you think the age of the password is nearing an end and that we need something more secure? Or are you not concerned about most of the data sitting out on the web anyway?

Report a problem with article
Previous Story

Sneak peek of the Metro-supported Google Chrome

Next Story

Cronus USB lets you use a 360 controller on a PS3 and vice versa

53 Comments

Commenting is disabled on this article.

I dont like logging into places through fb. For security reasons as pointed out, it makes some sense, but i like a degree of privacy. When I post on sites like this I dont use my actual name, but if I post when logged into my fb account some sites will just show my name, with a link to my fb. This I dont like. Its a privacy concern I have and for this reason I rarely log into websites with my Fb.

Just move to a PKI system. There are already CA's on the web that will issue free certs. Someone write a program to have a SmartCard-esque USB card. From there, you can write your cert to it, and that can be your authentication. Pair it with a PIN to access the device, and there you have it. Although it would suck if you lost that USB, you could always call and request a new one from the CA. =/ Just an idea. Although, if states started doing SmartCards in state IDs or Driver's Liceances, that could be an idea as well, but that would be getting into the whole going online with a real person identity... Who knows, there are plenty of options available, but not many of them are viable for a site to implement for public use. Just think if Facebook mailed out a USB stick with every account that was opened...

There's no perfect security measure.

The problem is having one layer of security only. If this layer fall you're out of luck. One password only will never be strong enough.

Passwords aren't dead.
Just blame website such as linkedIn, last.fm and so on for running Apache web server which has many zero-day security issues. They should have instead used a better & more secured web server/DB.

Meanwhile, you can start using software such as keepass which will generate and store a single & very complicated password for every website that you want, that's the future, not smartphone SMS.

You guys don't get it. Most users have 20+ sites, they are NOT going to drag out a phone or turn on a Web Cam just to login everyday. Not to mention a lot of people only have a basic phone, you know to make CALLS.

You give them something easy, hmmm like a password!. Or else you lose business.

I think the industry is looking in the direction involving technologies related to smart cards that are your mobile device. Mind you, smart cards can't protect you from humans (likely humans working for a companies support department) making mistakes or poor judgement decisions and having social based attacks work.

TPM 2.0 is said to be a mandatory part of the spec for on all Windows 8 mobile devices is designed to hold a lot more keys than before specifically so third parties can store trust data there. And in Windows 8, the TPM 1.2 is now fully a smart card. TPM 2.0 it's a smart card with a *lot* of room for third party certificates.

The TPM is a good technology that is underutilized in both the Linux and Windows world, and completely non-existent in the Apple world. It's a damn shame how hard it is (it's practically impossible) to find a good enthusiast level motherboard with a TPM 1.2 chip actually installed on it. Lots of the motherboards have TPM headers, but good luck actually getting a TPM for it that works.

Oh, and anyone who says a TPM is evil (easy to find people who will say this) have probably never actually used one with either Windows or Linux.

I've been using Kaspersky Password Manager that is bundled with Kaspersky Pure, does a similar thing to the Firefox password manager but its all stored securely on my system and either uses a master password or master key (USB drive and pin number) to access the login info. The only downside is that it does not yet work with 64-bit browsers.

Sites should do more to protect our Data. The Privacy protection laws globally need tightening up to make it a legal requirement to have a minimum encryption of user data.

I have been using LastPass for a while.It is a good solution in terms of ease rather than security,I persume, because there is no 100% safe solution.
my fear is that it gets attacked also.this would be a disaster.

medhunter said,
I have been using LastPass for a while.It is a good solution in terms of ease rather than security,I persume, because there is no 100% safe solution.
my fear is that it gets attacked also.this would be a disaster.

they're all great, providing you remember to backup the system, unless you know all the passwords anyway, what happens *when* your windows breaks & gets reformatted? the best place to store your passwords is in your head. passwords do not need to be hard to remember, neither do they need to be seriously complex. They just need to be unique to you, something that you can easily remember, then make derivatives for each site.

you live at

59 Cromford Avenue, Ashbourne, Derbyshire. your telephone is 05555123456. your dogs name is cassie. your mums name is charlotte.

you know all the above details, so a derived pass could be

59CdAeAeDe123456@Cassie&Charlotte

1st & last letter of each word of the address, part of the phone number. the @ & makes it look like an email address which is far easier to remember than random jibberish, but still as complex & not guessable to anyone but yourself.

With LastPass your passwords are stored in the cloud so there's no need to back anything up... I can get my log ins anywhere (as long as I know my password and I have my two-factor authentication code generator with me), the data stored in the cloud is only ever encrypted and decrypted on the client, and LastPass will help you generate random, secure passwords for every new site you sign up to, so there's no need to ever use the same password across websites. To keep my account as secure as possible, I make sure the password to it is 25 random characters that I can remember without needing to write them down, and I make sure that LastPass is set up against an email account I don't use for anything else, and that too has a similarly-complex password that again I have memorised.

I have over 150 sites' logins stored in my LastPass account; there's no way in a million years I'm going to remember over 150 derivative passwords in my head *and* remember which site they belong to even using the memory technique you've mentioned. Even trying to store 10 unique passwords this way is going to be way beyond the average person's abilities.

LastPass is not 100% safe, nothing is... but it's a pretty good solution for now.

stereopixels said,
With LastPass your passwords are stored in the cloud so there's no need to back anything up... I can get my log ins anywhere (as long as I know my password and I have my two-factor authentication code generator with me), the data stored in the cloud is only ever encrypted and decrypted on the client, and LastPass will help you generate random, secure passwords for every new site you sign up to, so there's no need to ever use the same password across websites. To keep my account as secure as possible, I make sure the password to it is 25 random characters that I can remember without needing to write them down, and I make sure that LastPass is set up against an email account I don't use for anything else, and that too has a similarly-complex password that again I have memorised.

I have over 150 sites' logins stored in my LastPass account; there's no way in a million years I'm going to remember over 150 derivative passwords in my head *and* remember which site they belong to even using the memory technique you've mentioned. Even trying to store 10 unique passwords this way is going to be way beyond the average person's abilities.

LastPass is not 100% safe, nothing is... but it's a pretty good solution for now.

so you protect all your other completely different passwords for each site, with 1 Password? & a 2-part authentication code? Logical? but if that ever gets compromised? then they have access to ALL your passwords & what sites you actually visit.

sure it's convenient & yes I agree, remembering 150 site logins would be nye on impossible for 95% of people. but how many of those sites are really critical? so it's likely that 130 of those sites are just very minor sites? do you use these everyday? every week? so it wouldn't be the end of the world to use the same password for the majority of those sites, or the same pass on 10 diff sites? etc. but the main critical sites, banks, paypal, ebay, linkedin, facebook (as it's a privacy nightmare & has a lot of personal info), emails. they should all have completely different passwords.

but the average user doesn't register on 150 - 200 websites & use those websites on a daily or even weekly basis. + the fact that when a site is compromised, the hacker doesn't really know what sites you are a member of & he isn't likely to go round trying every site they know to see if you are a member. sure, they'll try emails, paypal, ebay & so on. but the majority of them will be an unknown.

I can see it now... The facebook authenticator... much like the one for WoW, except instead of stylish art on it, and a free core hound pup, you will recieve pics of Mark Zuckerberg on it, and your free gift will be 1 share of facebook stock...

So, I read the article... Passwords are dead, and your solution is??? Seems they all are equally as bad as the 'dead password' if put into action.

Thanks for wasting my time. Facebook is anything but the 'digital safe' you have high hopes of it being.

Short term - Lastpass
Long term - Many websites already force login using Facebook. Facebook is not suitable in it's current form because (1) The authentication popup is too susceptible to being spoofed as it's just a website (not easy to tell it's from Facebook, the address bar could be replaced with an image which mimics an address bar) and (2) Facebook does not provide enough level of control to the user of what the website/app is allowed to access (a website/app can FORCE you to allow Facebook to hand over your persoanl information or DENY access to the app altogether if you don't approve the request).

99% of websites only need to know that (1) user is not a spam bot and (2) that it is the same user logging into the account regardless of their identity or personal information. But Facebook lets websites demand Real Name, Date of Birth, Basic Information, Friends List, Email Address etc. even though the user may not be comfortable handing over this level of information which the website doesn't actually need, but feel like they don't have much of a choice (or don't bother reading it) because they want to get access to the app as the main priority.

Facebook needs to step up to the plate with user privacy controls like this and have more secure authentication mechanisms if they want to take up the authentication market. They already have the head start by having the most users with real names.

If not Facebook, someone else will come to do the same thing but with better privacy to get them over the line.

It's not the fact "Data in the cloud is not secure".
The problem is these 2 bit companies do not invest anything in to hashing, salting, encoding and finally encoding passwords. Some bit companies, *cough* *linkedin* *cough* *esri* *cough* save passwords in a DB table as plain text.

Brian Miller said,
It's not the fact "Data in the cloud is not secure".
The problem is these 2 bit companies do not invest anything in to hashing, salting, encoding and finally encoding passwords. Some bit companies, *cough* *linkedin* *cough* *esri* *cough* save passwords in a DB table as plain text.

The LinkedIn passwords were stored as SHA1 encrypted hashes. Not plain text.

On the site I'm developing, I've got password, OTP and SSL client certificate support.
Client SSL certificate is a winner I think, when stored on smartcards, it's pretty secure.

WP7 said,
I've started using lastpass today, very good. recommend you all having a look

Been using last pass for a LONG time, never an issue. Master password is 18 characters.

companies need to do way more IMO for password protection, in Linked In's case md5 a password just isn't enough, (the developer originally behind it has come out today saying that the hash algorithm is no longer safe at all to use.) as they can just use brute force, rainbow or reference techniques to find a match. I am hearing a lot of talk that using salt with your passwords is the way to go, but again IMO proper encryption such as AES is an absolute must. my 2 cents anyways

Actually, not too bad a method if you use Firefox. (I actually use Chrome but they have something similar, though not quite as good.)

Generate a random password for each site you visit. Let the browser remember it.

Set a strong master password to protect the browser password store. This encrypts the passwords on disk. You have to enter the password when you start each browser session.

If you use multiple devices, use Mozilla's Firefox Sync service. This stores your passwords in the cloud, but they are encrypted with a key of your choosing, which is in turn encrypted on disk by the master password that you chose.

As long as your master password is strong and your encryption key is strong and you don't have any malware running on your machine to capture it, you can live a pretty safe online life.


But, clearly, this sort of attack is only going to become more common, and the best security is security that people will actually use. Something must be done and I'm not sure what it should be.

One problem with this method (Which is what I do), is that Firefox can't currently store the passwords for login forms that are created through JavaScript.

There's no need to be generating login forms through JS, but sites still do it.

Myself, I'd use Facebook's method (which can be enabled) where you type in your email and password as normal, but it then sends a random 6-digit number via SMS to your phone which you have to type in on your next screen to allow you to proceed with your login...

Definitely hope authenticators won't become mainstream, it was bad enough getting it out everytime I wanted to log into WoW - now multiply that 10-20x if websites took it up too.

I want something really secure, like a facial recognition that you can just hold a picture in front of to trick it.

I remembe rreading an article a couple of years ago saying that passwords were going to be replaced by pass-phrases. Obviously, it never happened.

I'm no security expert, but passwords should be combined with something like Verisign VIP access technology or what RSA is doing with token tech.

Forgetpasswords, retina scanning, and fingerprinting, give me an RFID tag under my skin that I can just wave at some sensor in my computer. It reads the RFID, does some wacky computation crap and viola, nothing to remember, your RFID is not stealable (Unless someone cuts your arm off) and because of the encryption used your password is unhackable,

DONE! Where's my prize?

RickoT said,
Forgetpasswords, retina scanning, and fingerprinting, give me an RFID tag under my skin that I can just wave at some sensor in my computer. It reads the RFID, does some wacky computation crap and viola, nothing to remember, your RFID is not stealable (Unless someone cuts your arm off) and because of the encryption used your password is unhackable,

DONE! Where's my prize?

RFID has been hackable for several years now. Maybe a newer implementation can prevent it, I'm not sure.

"Perhaps the best solution would be to tie access information into your mobile phone. More and more people are using smartphones, so instead of a token, sites could provide an app for your phone or perhaps send an SMS message that contains a passcode to you. "

IMO, this is a terrible idea as it would only increase mobile phone theft. Passwords are safe enough, companies just need to learn how to secure them properly and not make noob security mistakes.

Tom said,
"Perhaps the best solution would be to tie access information into your mobile phone. More and more people are using smartphones, so instead of a token, sites could provide an app for your phone or perhaps send an SMS message that contains a passcode to you. "

IMO, this is a terrible idea as it would only increase mobile phone theft. Passwords are safe enough, companies just need to learn how to secure them properly and not make noob security mistakes.


Google used a mixed approach
Google Sesame
http://www.zdnet.com/blog/igen...-experiment-concluded/14679

or 2step auth http://support.google.com/acco....py?hl=en&answer=180744

Tom said,
"Perhaps the best solution would be to tie access information into your mobile phone. More and more people are using smartphones, so instead of a token, sites could provide an app for your phone or perhaps send an SMS message that contains a passcode to you. "

IMO, this is a terrible idea as it would only increase mobile phone theft. Passwords are safe enough, companies just need to learn how to secure them properly and not make noob security mistakes.

& poor old me who has a fast broadband connection, but where I live I have to go outside, walk about 100 yards in order to get a signal on my mobile phone. I would not want to keep doing that just to log in to a website. especially if it's raining & or snowing etc.

I pretty much believe that since almost all devices have some kind of camera these days, retina scan security is eventually going to be one way to secure access.
Also many devices have it right now, and I do think more sites may eventually implement fingerprint scanning.
I think that is pretty much one of the only true ways to confirm the person trying to access the information is actually the person they say they are.
Cutting out eyeballs and chhopping off fingers are mainly a thing of the movies, so not to much concern there.

Off to create some good retina security, although chances are multiple people already have. LOL

DirtyLarry said,

Cutting out eyeballs and chopping off fingers are mainly a thing of the movies, so not to much concern there.
if it became a widespread method of security then i could see it not been " a thing of the movies" Why would a criminal have any problem chopping someones finger off?? and whats to stop people being forced in to it?? "scan your finger/eye or ill kill you and do it anyway"

exotoxic said,
if it became a widespread method of security then i could see it not been " a thing of the movies" Why would a criminal have any problem chopping someones finger off?? and whats to stop people being forced in to it?? "scan your finger/eye or ill kill you and do it anyway"

It would become about the "Level" of criminal.
Right now the lock on your front door prevents "Casual" criminals and only casual criminals, if someone REALLY wanted into your house there are multiple ways of doing it from a batterram to a chainsaw through the wall..

So too would it be with your PC security, "Passwords" prevent casual criminals: Kiddies and friends family etc being nosey. But when someone "Really" wants that data, they get it. Adding fingerprinting would make it a lot harder, and the amount of effort a criminal would be willing to go through to get your data would need to be properly rewarded. Hacking somoenes finger off to get at a single credit card number on a websight would just not be worth it... hacking the finger off a directoer of a credit card database however "might" be worth it.. but it would most certainly deter the script kiddies and thier little games..

DirtyLarry said,
I pretty much believe that since almost all devices have some kind of camera these days, retina scan security is eventually going to be one way to secure access.
Also many devices have it right now, and I do think more sites may eventually implement fingerprint scanning.
I think that is pretty much one of the only true ways to confirm the person trying to access the information is actually the person they say they are.
Cutting out eyeballs and chhopping off fingers are mainly a thing of the movies, so not to much concern there.

Off to create some good retina security, although chances are multiple people already have. LOL

I bet someone would eventually find a way to steal and latter insert a finger/retina scan somewhere between the scanning device and the authentication software.

Just because biometrics are unique IDs doesn't mean that a system built on them would be inherently secure. Strong passwords can be fairly unique as well.

DirtyLarry said,
I pretty much believe that since almost all devices have some kind of camera these days, retina scan security is eventually going to be one way to secure access.
Also many devices have it right now, and I do think more sites may eventually implement fingerprint scanning.
I think that is pretty much one of the only true ways to confirm the person trying to access the information is actually the person they say they are.
Cutting out eyeballs and chhopping off fingers are mainly a thing of the movies, so not to much concern there.

Off to create some good retina security, although chances are multiple people already have. LOL

whilst a good idea, that retina scan has to be converted into transmittable data. 1's & 0's or a unique hash, which is then transmitted to the website & checked to see if it matches with whats stored.

if the db is compromised we have the same problem again. we also have the same problem if the transmission is intercepted or sniffed out on non https or SSL connection.

Clearly passwords aren't going anywhere soon and I don't believe this is necessarily a user issue (but clearly more secure passwords for end users is always usually helpful but not the final answer) but rather organisations need to start taking security seriously and going to extra mile. Those LinkdIn passwords weren't even salted etc.

Agreed. It'd be good to have laws in place that makes good security enforced. e.g. any site that contains user logins must have as minimum an encrypted password with salt.

Ideally though, we'd ditch passwords and go with public/private keys. Here is how it would work:

1) You give a website your public key when signing up (email and public key, no password)
2) When you go to login, you provide them with your email via HTTP POST
3) In the background, the site send you token encrypted with your key
4) Browser detects this and decrypt sites token (using users private key) and stores in session
5) Done.

User now has valid session token, without any password stored or transmitted. Secure (even if DB is hacked, public key means nothing), and if browsers get on board to support this, the whole thing becomes fully automatic. Just enter your email and the rest is done. The only security risk is if the private key gets stolen, and hackers would need to do that per user.

Can anyone see any issues with that approach? (lets ignore the fact that windows is terrible for public/private keys, and pretend in an ideal world, everyone knew what encryption keys were).

Windows is... bad with private / public keys? How exactly? I've been hosting my own private PKI sets with and without Active Directory for over 10 years. How exactly are they worse than anyone else? I use ECC certificates to enforce authentication between clients and servers. Trusts in Windows can be formed at the user, system, and service level. Heck, I'm pretty sure Windows Vista was the first OS with the first browser to support ECC certs. I know no other browser supported ECC certificates when Vista came out.

k776 said,
Can anyone see any issues with that approach? (lets ignore the fact that windows is terrible for public/private keys, and pretend in an ideal world, everyone knew what encryption keys were).

If a person is hacked and their private key is stolen, it means that the hacker has full access to any website the person has registered for. But it also means that you have to hack every individual to actually gain access, there is no centralized location where you can obtain access to a vast amount of user accounts.

Also, the user would need to either duplicate the private key to every computer where they want to access the site, or register multiple public keys in which case they'd need to do that from a computer with an existing registered key.

Could be cumbersome?

Also look for the other post I made in this news article about TPM 2.0. I believe Microsoft stated at BUILD would be required as part of the spec for tablets. Shame it's not required for desktops / motherboards (or if it will be, I haven't heard anything about it).

k776 said,

Can anyone see any issues with that approach? (lets ignore the fact that windows is terrible for public/private keys, and pretend in an ideal world, everyone knew what encryption keys were).

using public/private keys, whilst good. would require that the site uses SSL https, otherwise the keys will easily be compromised as they'll be transmitted unencrypted. i don't know of a working plugin system that allows pgp keys to use keys in a way that would be required. not everyone can afford to have trusted ssl certificates or trust certificates.

2 factor authentication (such as yubikey) is good.

passwords with salt whilst are good, it's not just the salt what offers the protection. it's the hashing algorhythm.

lets not talk about encryption for passwords, encryption & hashing are totally different.

encryption is 2 way. there's encryption & then decryption. you don't ever want the password to be decrypted & if a site uses encryption rather than hashing, then that site is no more secure, in fact is less secure at protecting passwords than using md5. essentially, if the site/server is compromised, the attacker will have access to the decryption key & with that, they could decrypt the passwords faster than it takes to crack md5 hash.

hashing is not encryption, it's 1 way obfuscation. it can't be decrypted itself. all you can do is run strings through a system until you create get the same hash, kinda like brute force.

salting makes it better because the password then becomes more complex before it's hashed, so it's likely to take far longer to brute force in order to get a matched hash.

With the software I help develop, we chose to use sha256 minimum but sha512 is recommended option, we also use Salt keys.

note I said keyS.

1 salt key on it's own whilst good, is not that good! for instance.

100 users register & 50 of them choose the exact same password.

having 1 salt key means that those 50 users will each have identical hashes.

In my CMS that I help develop we use 2 sha256 generated salt keys for each password.

1 salt key is stored alongside the users password hash (this is unique for each user), the 2nd salt key is stored in a file OUTSIDE of the DOCUMENT_ROOT (that is, it is above the www web root of the server and is inaccessible to the browser.)

by doing that, it doesn't matter if 1000 people have the same password, they will each have a totally unique password hash. & if the DB is compromised, yes they will get the pw hash, + the unique salt key for that user. but without the 2nd salt key stored outside the doc root, they would not be able to get a match on the hash by bruteforcing it very easily (especially if sha512 is used) in that case, the attacker would not only have to compromise the DB, they would also need to compromise the server itself, which makes it much more inconvenient.

remember, if you only have 1 salt key & it is also stored in the same DB, then it offers no more protection, because the attacker will have the salt too & will be able to use that salt alongside his bruteforce to produce a matching hash.

& if an attacker has used SQL injection to get the passwords, he can sure as hell get any information that is stored in the DB, emails, post data, credit card details, telephone numbers. just 1 vulnerability in the website that allows SQL injection, & the whole DB is then compromised!

whilst not impossible that both the server & DB get hacked, it takes a lot more skill & knowledge to compromise a server, than it does to compromise a DB via SQL injection.

as the author says, nothing will ever be 100% secure. you just have to make it harder and more inconvenient for the attackers to do & that is all you can do.

Lamp Post said,
If a person is hacked and their private key is stolen, it means that the hacker has full access to any website the person has registered for.
Right, but it's no worse than the hacker installing a keylogger and getting their plain text passwords. And if it does happen, as you said, it's one user at a time, not 6.5 million in one go.

Lamp Post said,
The user would need to ... register multiple public keys. Could be cumbersome?
That is a valid point I hadn't thought of. If a computer crashes with your private key, you don't want to be locked out of everything.

said,
whilst not impossible that both the server & DB get hacked, it takes a lot more skill & knowledge to compromise a server, than it does to compromise a DB via SQL injection.
So at minimum, sites should be doing something like `Sha256(Sha256(password + salt) + pepper)` (where salt is per user on the DB, and pepper is a hardcoding string in the app source), so someone would need to hack both the DB and the server.

I've been doing it like this (salt and pepper) for years, soon after starting to work with DBs (until switching to BCrypt for encryption). How do major sites get this wrong :-(

k776 said,
So at minimum, sites should be doing something like `Sha256(Sha256(password + salt) + pepper)` (where salt is per user on the DB, and pepper is a hardcoding string in the app source), so someone would need to hack both the DB and the server.

I've been doing it like this (salt and pepper) for years, soon after starting to work with DBs (until switching to BCrypt for encryption). How do major sites get this wrong :-(

that's a very bare minimum yes. using iterations on the hash will improve it even more by rehashing the hash 100+ times over, will slow a bruteforce attack down considerably (you just need to know how many times it has been re-hashed)