Security? We don't need no stinkin' security!

Ok, apologies for the slightly dramatic title, but I've just come across something which actually made me go "WTF???!!!!" out loud. Well, almost.

There is a fairly popular web based portal type system (I can't say more than that to protect the innocent, i.e. the poor fools using the software) which is basically a sort of forums / community site software.

I had to do some integration work with it recently, migrating the users over from it to a dedicated forums system. I logged in to the database console to have a quick look at the tables to see what I could do. I had a look at the users table -- and quickly realised that they were storing *cleartext* passwords. They weren't even doing MD5 encryption or anything. That's got to be the biggest WTF I've ever seen with this kind of system -- how can it ever be acceptable NOT to encrypt passwords?!

What's even worse is that I found out today the reason for the lack of encryption is (and I quote) "apparently people wanted to be able to see their users' passwords".

If I had an attitude like that where I work, I wouldn't be there much longer!

It gets better, though. I found out today (again) that there is a security problem with cookies. What happens when you login is that the site sets a couple of cookies - one for your userid, and one for your username. Of course, if you happen to have... say... the cookie editor extension for Firefox, then you could (theoretically) change your username to anyone else's and edit their data away to your heart's content (except change the username / password, which requires the old password).

I just can't believe they'd store data like that on the client side where it can be edited! I know with persistent logins on websites I don't think there are too many options but at least use a UUID or something like that. Sheesh.

I once discovered that some existing code with which I had to interface
was performing FTP operations by calling a shell script which took the
site, name and password as command-line arguments. Since this ran
on a Unix system, anyone could see the password by doing a 'ps'.

I suggested that at the very least, the password should be passed in
via standard input, but this was one of those "it's a miracle anything
we've made works at all, so we dare not touch or improve anything"
environments.

There's a scary amount of sites out there that happily store plaintext passwords. I notice it every once in a while when using the "lost password" function and having seeing the old plain-text password in the mail.

That's really the only explanation that I can come up with: the developers were just too lazy to generate new passwords and emailing a link to activate the change. No, they just store the password in plaintext.

The cookie thing really baffles me. I think pretty much every major message board software has had some kind of bug that allowed privilege escalation via invalid cookie data. Sigh.

I once discovered that some existing code with which I had to interface
was performing FTP operations by calling a shell script which took the
site, name and password as command-line arguments. Since this ran
on a Unix system, anyone could see the password by doing a 'ps'.

I suggested that at the very least, the password should be passed in
via standard input, but this was one of those "it's a miracle anything
we've made works at all, so we dare not touch or improve anything"
environments.

The real WTF is that they don't know the .netrc file where you can store passwords for FTP sites. Or maybe it was a Unix version that didn't support that?

I worked for a while at a second-tier e-tailer. Not one of the big names, but big enough.

The whole company was a bunch of hacks built on top of hacks. Clearly code had been thrown at the problem, and whatever stuck was patched and repatched and left running 5 years later.

There was no planning for the future in place, so whenever integration opportunities came along (which they did quite often, they bought a lot of small companies) they had to kludged into place using what ever technology the dev happened to be good at, and rarely with any real thought to security. Some of my favorite WTFs included:

1) The head of security installing his own devices which introduced huge security holes2) Credit cards being stored unencrypted.3) A hand-built 'web-service' that sent commands in xml into a web page...commands like "issue a store credit"...without any authentication4) A merger meant merging user dbs. There were some overlapping ids that occurred in both user lists -- so the company allowed two different people to use the same account name, differentiating based on password alone...what happens when the passwords get set to the same value?

It goes on, but they get less and less security related.

The attitude there was priceless. "The systems are as good as we could make them, as good as anyone could make them, as good as they could be made." And the fact that they crashed once a week (or more) was just evidence of their perfection, it seemed. Each outage cost the company tens, if not hundreds of thousands of dollars in lost sales, but apparently that was cheaper than admitting their systems were crap and, you know, fixing them.

I once discovered that some existing code with which I had to interface
was performing FTP operations by calling a shell script which took the
site, name and password as command-line arguments. Since this ran
on a Unix system, anyone could see the password by doing a 'ps'.

I suggested that at the very least, the password should be passed in
via standard input, but this was one of those "it's a miracle anything
we've made works at all, so we dare not touch or improve anything"
environments.

The real WTF is that they don't know the .netrc
file where you can store passwords for FTP sites. Or maybe it was a
Unix version that didn't support that?

The destination site (and name and password) was input by the user for
each transfer, so it couldn't be known in advance. Thus the
program would have had to write to the .netrc file on the fly (and, I
would hope, restore it after the transfer). Which probably isn't
the intended use of .netrc. And now that you mention it, the
version of Unix on which this ran might very well be so old that its
ftp program didn't support .netrc at all.

The destination site (and name and password) was input by the user for
each transfer, so it couldn't be known in advance. Thus the
program would have had to write to the .netrc file on the fly (and, I
would hope, restore it after the transfer). Which probably isn't
the intended use of .netrc. And now that you mention it, the
version of Unix on which this ran might very well be so old that its
ftp program didn't support .netrc at all.

I agree that writing the .netrc file on the fly would be just another WTF, just think of the possible race conditions.

I worked for a while at a second-tier e-tailer. Not one of the big names, but big enough.

The whole company was a bunch of hacks built on top of hacks. Clearly code had been thrown at the problem, and whatever stuck was patched and repatched and left running 5 years later.

There was no planning for the future in place, so whenever integration opportunities came along (which they did quite often, they bought a lot of small companies) they had to kludged into place using what ever technology the dev happened to be good at, and rarely with any real thought to security. Some of my favorite WTFs included:

1) The head of security installing his own devices which introduced huge security holes2) Credit cards being stored unencrypted.3) A hand-built 'web-service' that sent commands in xml into a web page...commands like "issue a store credit"...without any authentication4) A merger meant merging user dbs. There were some overlapping ids that occurred in both user lists -- so the company allowed two different people to use the same account name, differentiating based on password alone...what happens when the passwords get set to the same value?

It goes on, but they get less and less security related.

The attitude there was priceless. "The systems are as good as we could make them, as good as anyone could make them, as good as they could be made." And the fact that they crashed once a week (or more) was just evidence of their perfection, it seemed. Each outage cost the company tens, if not hundreds of thousands of dollars in lost sales, but apparently that was cheaper than admitting their systems were crap and, you know, fixing them.

-cw.

Sounds suspiciously familiar, like one of my previous employers... hum, Chuck, is that you?

There's a scary amount of sites out there that happily store plaintext passwords. I notice it every once in a while when using the "lost password" function and having seeing the old plain-text password in the mail.

There's a scary amount of sites out there that happily store plaintext passwords. I notice it every once in a while when using the "lost password" function and having seeing the old plain-text password in the mail.

Just because it's recoverable doesn't mean it is stored in plaintext.

Oooh and tell me how you'd store it to be recoverable then genius?

Encryption? You'd need the key to decrypt it, which'd have to be either in the source or in the DB or in a config file nearby, which are 3 unsafe locations.

Let me repeat. Just because it's recoverable doesn't mean it is stored in plaintext.

I'm not arguing your point that encryption requires the key to be available somehow. I'm also not arguing that the three places you mention are not good places to store the key. I also never said that encrypting rather than one-way hashing passwords is a good idea. However, at least the passwords are "obscured". An intruder still has to do more digging to crack them. And if someone gains that level of access to your system, you've got MUCH bigger problems...

There's a scary amount of sites out there that happily store plaintext passwords. I notice it every once in a while when using the "lost password" function and having seeing the old plain-text password in the mail.

Just because it's recoverable doesn't mean it is stored in plaintext.

Oooh and tell me how you'd store it to be recoverable then genius?

Encryption? You'd need the key to decrypt it, which'd have to be either in the source or in the DB or in a config file nearby, which are 3 unsafe locations.

Which still means that the password is *NOT* in plaintext, however insecure it still may be.

No, MD5_crypt is a hash function. That page even describes it as such.

A hashing function is a one-way function. Given only a hashed output value and the function used to hash it you cannot reconstruct the input value. Salted MD5 is salted so that hashed values can be compared by hashing the test value with the same salt and comparing the result to the original hashed value:

H (salt, secret) = h1 H (salt, test) = h2

If h2 is equal to h1, it's likely that test is equal to secret. But it's not guaranteed; there may be many values of test which produce the same output h2.

An encryption function is a family of functions that go both directions. Given the key, the encrypted value, and the decryption function you can reproduce exactly the original value:

E (key, secret) = e1 D (key, e1) = secret

E and D (encrypt and decrypt) form functional inverses of each other. H (hash) may have no functional inverse.

Just because the function's called crypt() doesn't make it encryption.

If h2 is equal to h1, it's [b]likely[/b] that test is equal to secret. But it's not guaranteed; there may be many values of test which produce the same output h2.

...

Just because the function's called crypt() doesn't make it encryption.

This was new information for me (!= CS scholar). The site referenced above have convinced me to switch hashing algorithm for the passwords I store - to a version that's harder to crack than "standard crypt()".

There's a scary amount of sites out there that happily store plaintext passwords. I notice it every once in a while when using the "lost password" function and having seeing the old plain-text password in the mail.

Just because it's recoverable doesn't mean it is stored in plaintext.

Oooh and tell me how you'd store it to be recoverable then genius?

Encryption? You'd need the key to decrypt it, which'd have to be either in the source or in the DB or in a config file nearby, which are 3 unsafe locations.

Reversibly encrypted passwords with a key in the source are a little better equipped to survive a SQL injection attack. It's harder to get a dump of the users table *and* the source than it is to just get the dump of the users table.

I agree that hashing is preferable -- I don't WANT to know my user's passwords. But sometimes you need to obscure the password, but still have access to it. For example, one project I work on acts as a sort of proxy -- you enter your login for site X on our site, and then we set about doing work on site X for you. Obviously, we have to be able to send your unaltered password to site X, but by encrypting it in the database, we don't end up unintentionally learning everyone's passwords every time we open up a dump of the login info table.

I think site administrators "wanting to know their users' passwords" is a massive WTF itself.

I had to do some integration work with it recently, migrating the users over from it to a dedicated forums system. I logged in to the database console to have a quick look at the tables to see what I could do. I had a look at the users table -- and quickly realised that they were storing cleartext passwords. They weren't even doing MD5 encryption or anything. That's got to be the biggest WTF I've ever seen with this kind of system -- how can it ever be acceptable NOT to encrypt passwords?!

Storing plaintext passwords is not inherently a security vulnerability, or a bad practise. All security is a trade-off between a completely open system and a switched off system, and where to draw the line depends on lots of factors, not just blindly following a list of "this is good security" and "this isn't". At least they don't have admin=true in the URL...

Also, you will never have a piece of software that is completely secure, perfectly bug-free and implementing all the features that all the users want. Being 'more secure' wont get them more users - what good is spending so much effort on security that they go out of business? It might be that they have a long list of security changes to make, and have to prioritise some bug fixes, some new features, some security fixes and some internal redesining for each new release.