Security quotes of the week

Posted Sep 27, 2012 20:16 UTC (Thu) by tx (guest, #81224)
In reply to: Security quotes of the week by robert_s
Parent article: Security quotes of the week

MS stated that they've always only used the first 16 chars (http://windows.microsoft.com/en-US/windows-live/microsoft... ), so as funny/sad as it would be to state they were storing passwords in plaintext, it's far more likely that they were just silently truncating them all along. Contemplating the reasoning behind that choice is left as an exercise for the reader.

Security quotes of the week

Posted Oct 9, 2012 18:02 UTC (Tue) by elanthis (guest, #6227) [Link] (3 responses)

I've even seen banks do this, who theoretically have highly paid security consultants looking over all these decisions.

At the end of the day, 99% of programmers suck at their job, and those folks have landed jobs at just about every tech company on the planet, big and small. Not much to do besides shake you head and move on with life.

... and remember to use different passwords for different sites/services.

Security quotes of the week

Posted Oct 11, 2012 10:38 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Likewise. Heck, I was involved in rewriting a system which was originally careful to use AES and everything to protect stored passwords (this was a system which was trying to store them so that users didn't need to repeatedly type passwords to authenticate themselves to a database, so one-way-hashing them was not possible). The private key? Oh, why do we have to have one of those when we have something secure like AES? Just call getuid(), that's unique, that will do.

(The rewrite pulled strong random numbers out of /dev/random and wrote them to a mode 0600 file in ~, then used that as the key. I pointed out that this was as secure as we could make it without external key storage on a more secure medium or a requirement for users to type in passphrases, but that the security of the whole system was still no better than the security of the random key file, rendering all the password-protection pointless since we could just have stored the passwords unencrypted in the users' home directories mode 0600 and got exactly the same level of security. But, no, the spec said encryption so encryption we must have.)

Security quotes of the week

Posted Oct 11, 2012 15:43 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

I've seen that kind of system for PCI compliance where a QSA interpreted the standard to mean that database passwords at rest on the disk couldn't be stored in the clear. We obfuscated them using some library that would read a key from an environment variable that was sourced by the startup script so it would be inherited when the app started.

It was clear and understood by the QSA and management that this only prevented accidental disclosure due to shoulder surfing, printing or copying of config files and would not prevent disclosure to anyone with access to the host. That was fine and understood to be the risk, obfuscating sensitive config values turned out not to be that big a deal in practice.

Security quotes of the week

Posted Oct 11, 2012 18:58 UTC (Thu) by nix (subscriber, #2304) [Link]

You got a threat model? You lucky sod. I was never able to get the same threat model out of anyone more than once, and never any explanation as to how their stated (often bizarre) threat models would be defended against by the spec they insisted on. But, hey, they were paying the bills...