Security quotes of the week [LWN.net]

We hope that a news about one billion users of Oracle Java SE software being vulnerable to yet another security flaw is not gonna spoil the taste of Larry Ellison's morning...Java.

-- Adam Gowdiak

Still, this is the oldest bug that Trinity has found so far. I got pretty excited last month when it found a VM bug that dated back to 2.6.32, but this one.. It almost predates my own involvement in Linux.

-- Dave Jones finds a hole in kernels going back to 2.1.8

Inviting a bunch of people who can't see the text to comment on what might be in the text might be considered some weird form of "hearing from the public" but transparency is not about hearing from the public -- it's about showing the public what you're doing.

-- Mike Masnick

Microsoft account passwords can contain up to 16 characters. If you've been using a password that has more than 16 characters, enter the first 16.

-- Helpful note from Hotmail

to post comments

Security quotes of the week

Posted Sep 27, 2012 14:20 UTC (Thu) by robert_s (subscriber, #42402) [Link] (5 responses)

"Microsoft account passwords can contain up to 16 characters. If you've been using a password that has more than 16 characters, enter the first 16."

Huh. So for this to work I guess that means either:

1. Hotmail has been silently truncating passwords to 16 characters before hashing all along.
or 2. They've got the passwords stored in plaintext somewhere.

Which do we think is more likely?

Security quotes of the week

Posted Sep 27, 2012 20:16 UTC (Thu) by tx (guest, #81224) [Link] (4 responses)

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...

Security quotes of the week

Posted Sep 27, 2012 23:12 UTC (Thu) by nix (subscriber, #2304) [Link]

I was just watching Yes, Minister tonight. It's good to see that the spirit of Sir Humphrey Appleby is alive and well in the USTR.

(By 'good' I mean 'blackly amusing, please tell me this is fiction', of course. Not that Yes, Minister was fiction either, except in the most strictly literal of senses...)