Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

← Back to Stories (view on slashdot.org)

Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

Posted by timothy on Tuesday September 25, 2012 @02:12AM from the pretty-pictures-ugly-facts dept.

First time accepted submitter radudragusin writes "IEEE suffered a data breach which I discovered on September 18. For a few days I was uncertain what to do with the information and the data. Yesterday I let them know, and they fixed (at least partially) the problem. The usernames and passwords kept in plaintext were publicly available on their FTP server for at least one month prior to my discovery. Among the almost 100.000 compromised users are Apple, Google, IBM, Oracle and Samsung employees, as well as researchers from NASA, Stanford and many other places. I did not and will not make the raw data available, but I took the liberty to analyse it briefly."

34 of 160 comments (clear)

Min score:

Reason:

Sort:

Finally! by wonkey_monkey · 2012-09-25 02:17 · Score: 4, Insightful

Some actual news for nerds, and from the horse's mouth. And graphs and everything. Love it.

--
systemd is Roko's Basilisk.
1. Re:Finally! by alphatel · 2012-09-25 02:30 · Score: 3, Funny
  
  It is obvious based on the geolocation data that Greenland is behind all of this.
  
  --
  When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
2. Re:Finally! by Anonymous Coward · 2012-09-25 02:59 · Score: 5, Insightful
  
  Yeah, but the "most used passwords" should really be a bar graph not a line graph. It's not like the midpoint between "ADMIN123" and "IEE2012" makes any sense.
3. Re:Finally! by buchner.johannes · 2012-09-25 03:24 · Score: 2
  
  Someone should do a comparison in password complexity between this user group and the average user group (LinkedIn, Yahoo). Histograms of entropy in bits will show whether we know better or not.
  
  --
  NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Well... by fuzzyfuzzyfungus · 2012-09-25 02:17 · Score: 5, Funny

Does this make plaintext password storage an IEEE standard now?
That could save an, er, friend of mine, a lot of work...
1. Re:Well... by tangent3 · 2012-09-25 03:11 · Score: 5, Informative
  
  Disclaimer: I've RTFA'ed
  The passwords were not stored in plaintext.
  However, the web server access logs logged the passwords entered in plaintext. That was what was downloaded from a publically access ftp folder.
2. Re:Well... by achbed · 2012-09-25 05:32 · Score: 2
  
  However, the web server access logs logged the passwords entered in plaintext.
  So, in other words, they were stored in plaintext.
  No, they were logged as plaintext. This means that all invalid attempts as well as valid ones are stored in the log. The master store that is being used to store and retrieve/compare the final password (or password hash) is not included in the log. There is insufficient data from the breach to determine whether the master store is encrypted or not.
3. Re:Well... by Alef · 2012-09-25 06:47 · Score: 3, Informative
  
  Well, so what? The intention may not have been to have the passwords written in plain text to a file, but they were. It doesn't matter how much you salt and encrypt the "master store" if you f*ck up and write them another file in clear text as well. They are there, readable on the disk. The fact that it was a log file doesn't diminish the error the least. In fact makes it even worse, since the security of a log file is likely not looked after to the same degree as a password database (as we can clearly see in this case, where they left it on an ftp). If you write clear text passwords along with user names to an unencrypted file under any circumstance whatsoever, you fail. If you have a clue about security, you simply never, ever do that!
  And for that matter, what has invalid attempts got to do with it? Security through infinitesimal obscurity? Unless you have something like a million times as many invalid attempts as valid ones, it is of no consequence.
AFAICT IEEE didn't warn its members yet... by Anonymous Coward · 2012-09-25 02:24 · Score: 4, Interesting

Why do we need to learn this from the newspaper?
Who's the network admin? by lsolano · 2012-09-25 02:26 · Score: 2

I mean, PLAINTEXT passwords AND publicly available on their FTP.
Does he/still have the job?
Secure password message falls on deaf ears by Tridus · 2012-09-25 02:26 · Score: 4, Insightful

You'd think that people involved with the IEEE are a group that should know better, and yet the most common passwords according to the analysis reads like the usual suspects list from other breaches. They're still common, easily guessable passwords. Hashing wouldn't have protected them very long, as these are on the short list for any cracking program to test.
It should be a wake up call that our current methods of trying to get users to pick secure passwords are a total failure. We need to go back to the drawing board and figure out a better way to get the message across, including tools to make it easy for people to get it right.

--
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
1. Re:Secure password message falls on deaf ears by MadKeithV · 2012-09-25 02:32 · Score: 5, Funny
  
  . We need to go back to the drawing board and figure out a better way to get the message across, including tools to make it easy for people to get it right.
  Maybe it would work if we could get a battery-powered horse to staple the correct message to people.
2. Re:Secure password message falls on deaf ears by X0563511 · 2012-09-25 02:50 · Score: 2
  
  Reference.
  Amusing anecdote: on the GW2 forums people kept getting password-guessed. I pointed this strip out in a few places as a recommendation.
  Fast forward a week or two and the Arenanet president sends out an email talking about various things... and provides said strip as a suggestion for crafting good passwords! Kudos XKCD! (and possibly myself, as I had not seen anyone else point it out to them)
  
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
3. Re:Secure password message falls on deaf ears by tlhIngan · 2012-09-25 03:32 · Score: 4, Interesting
  
  You'd think that people involved with the IEEE are a group that should know better, and yet the most common passwords according to the analysis reads like the usual suspects list from other breaches. They're still common, easily guessable passwords. Hashing wouldn't have protected them very long, as these are on the short list for any cracking program to test.
  It should be a wake up call that our current methods of trying to get users to pick secure passwords are a total failure. We need to go back to the drawing board and figure out a better way to get the message across, including tools to make it easy for people to get it right.
  The question becomes though - what benefit does it do me to have a strong password on sites I don't value?
  Like say, /. - why not use "password" or "123456"? If someone breaks in, BFD.
  Likewise, many forums and blogs require registration to do basic things - seems like "password" or "123456" is useful for a one-time throwaway account.
  The IEEE has a similar problem. Sometimes it protects great assets (member-only access to papers/journals/standards), othertimes, it's used because some guy wanted the 802.x spec (available for free, registration required), in which case they'd just pick some throwaway password because so what if it's compromised?
  And that's the thing - I've seen websites host some files I wanted require changing passwords every 30 days with upper case, lower case, numbers AND symbols. Secure, sure, but everytime I used it (every few months), I needed to reset it. In the end I just ended up using their temporary password, remembered in browser. To me, it wasn't terribly important files (they still needed a license key, available separately). Hell, if I looked, I could've found the same files off a torrent site.
  Oh, and "value" of a site is a personal judgement - if you asked a bunch of websites, you'd find they'd value their content "above average".
4. Re:Secure password message falls on deaf ears by wisnoskij · 2012-09-25 03:38 · Score: 3, Informative
  
  I agree, but the graph scale shows that only 300 out of the 100,000 people used those most common passwords.
  I am not sure what the average perentage of users that use horrible passwords are, but .3% is below what I would expect (and you have to think that all of those people probably know better, but just have nothing on their account worth protecting).
  
  --
  Troll is not a replacement for I disagree.
Re:For God's Sake by xxxJonBoyxxx · 2012-09-25 02:27 · Score: 4, Informative

>> when are we going to all start hashing and salting passwords?
Please RTFA. The exposure wasn't in password STORAGE, it was in password LOGGING. (The stored passwords may already have been hashed and salted for all we know, but the FTP server was writing them to log files out in clear text!)
Re:For God's Sake by cdrudge · 2012-09-25 02:30 · Score: 2, Insightful

Well they are normally transmitted plain text so why shouldn't they be logged in plain text too?
The left the logs open to public. by 140Mandak262Jamuna · 2012-09-25 02:32 · Score: 3, Informative

The password, log in and authentication methods are secure it looks like. The mistake they did was to allow public access to the log files of their web server. Dumb mistake. And among the log is the log for the authentication request. It contained the user names and passwords in plain text, because that is how the log in data gets "posted" to the web site.
It is like having super duper security behind the passcode access panel. But leaving a security camera looking at the people using the panel recorded and making it public.

--
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Re:posting the most used passwords is probably bad by Spad · 2012-09-25 02:33 · Score: 3, Insightful

Well with the exception of "SUNIV358", which is something of an outlier, the rest are all pretty standard passwords that you'd expect to see in any dataset like this
Re:Not Good.... by MadKeithV · 2012-09-25 02:34 · Score: 2

As a member of the IEEE I have to admit we have the worst web site you can imagine. It constantly asks for login information as you try to browse and it is hard to find most information online.
Are we reading the same article here? ;-)
Re:small error? by nedlohs · 2012-09-25 02:34 · Score: 4, Funny

One has an uppercase 5. The other is all lowercase.
FYI: password hashing doesn't matter when... by nweaver · 2012-09-25 02:37 · Score: 4, Informative

Password hashing doesn't matter when the login password is conveyed in a URL and the URLs fetched are logged.
From the article, its clear that this is what happened: the login process creates a URL with the username & password in it, and since the URLs were logged and accessible, the login passwords could be obtained in the clear.

--
Test your net with Netalyzr
Re:For God's Sake by Capt.Albatross · 2012-09-25 02:37 · Score: 2

The exposure wasn't in password STORAGE, it was in password LOGGING.
This case shows that in the context of security, that is a distinction without a difference.
Who knows... by Cow+Jones · 2012-09-25 02:38 · Score: 3

From TFA:

On these logs, as is the norm, every web request was recorded (more than 376 million HTTP requests in total). It is certainly unfortunate this information was leaked out, and who knows who got it before it got fixed.

You could, you know... look in the logs to find out?

--

Ah, arrogance and stupidity, all in the same package. How efficient of you. -- Londo Mollari
1. Re:Who knows... by tangent3 · 2012-09-25 03:14 · Score: 2
  
  Apparently they logged http access but not ftp access....
It appears to be unguareded data not breach by 140Mandak262Jamuna · 2012-09-25 02:41 · Score: 3, Insightful

Breach gives the connotation, some one or something broke into something that was protected. Here it looks like IEEE, quite stupidly, left valuable data unguarded.

--
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Re:For God's Sake by X0563511 · 2012-09-25 02:44 · Score: 2

It always upsets me when I see logins used for plain FTP.
SFTP people! It's not hard!

--
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Re:Hashing vs. encryption by Garble+Snarky · 2012-09-25 02:48 · Score: 2

Do you understand why Chrome doesn't allow a master password that actually obscures the stored passwords? I can't figure it out. I can't use a browser that doesn't do that. That's the only thing holding me back from Chrome.
Re:For God's Sake by teslar · 2012-09-25 02:49 · Score: 5, Interesting

I'm a scientist. I write papers that are published in academic journals and I review such papers for journals. Journals use editorial managers to, well, manage, the entire process and you'd be surprised how often those send out automated e-mails that, helpfully, contain my login and password IN PLAINTEXT, just in case I might have forgotten (even if I did not request the password).
In general terms, if you use a website that is able to remind you of your password if you forgot, consider that password known to the world and all other accounts that use the same or a similar password at high risk of being compromised.
Oh and I have an Obligatory XKCD too.
Re:posting the most used passwords is probably bad by NothingWasAvailable · 2012-09-25 02:52 · Score: 2

Group password for authorized users at a particular company?
Re:Hashing vs. encryption by zindorsky · 2012-09-25 03:16 · Score: 2

On Windows, Chrome protects its password database with Windows' Data Protection API. The DPAPI has several layers, but at the end its security rests entirely on the Windows account password. So .... you do have a master password in a way, but we all know how easy it is to recover Windows passwords.

--
If the geiger counter does not click, the coffee, she is not thick.
Re:For God's Sake by luis_a_espinal · 2012-09-25 03:47 · Score: 2

The exposure wasn't in password STORAGE, it was in password LOGGING.
This case shows that in the context of security, that is a distinction without a difference.
There is a difference since, in the context of security, one would have to prescribe a corrective/preventative measure (that will be different wrt storage or logging.) Yeah, we can say "no passwords in plain text" in general terms, and then yes, there is no difference.
But that is the same mentality that drive people who think the problem was in storage and not logging. Everybody thinks ZOMG the former, but completely ignore the later. So, then, that supposedly insignificant difference becomes very relevant in the context of security.
Chances are the same people - had they not RTFA - will pretty much commit the same mistake (securing the storage and "yay we are done", forgetting completely the rest of the attack surface/leaky areas/whatever.)
Re:For God's Sake by PIBM · 2012-09-25 06:37 · Score: 2

This is the same as saying that flash is required, yet how many ipod/ipads could not access flash content ? I do run tons of js, but I can at least acknowledge the choice of those who won't.
Re:For God's Sake by SCHecklerX · 2012-09-25 07:49 · Score: 2

If a website is able to send you your actual password, it is time to stop using that website. They are storing your credentials in the clear.