Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords 160
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."
Finally! (Score:5, Insightful)
Re:Finally! (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
It is obvious based on the geolocation data that Greenland is behind all of this.
I dunno... it looks like there's a town in central Russia where the secret cabal hides. That "109" data point north of Mongolia... there's nothing there on Google Maps...
Re:Finally! (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.
Re: (Score:2)
AEMEN022, you insensitive clod!
Splines! (Score:2)
Oh god the splines [wikipedia.org]! They should not be used for discrete data.
Re: (Score:2)
Not so fast! There is a problem with the analisys. Check the first graph: The 123456789 password appears twice (in the 4th position and in the last shown position). This is a blasphemy to my true nerd beliefs.
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
And graphs and everything. Love it.
Go Here:
http://www.reddit.com/r/GraphPorn/ [reddit.com]
Have an orgy :P
(there must be some cosmic rule, just like there is an xkcd comic for everything, there is a subreddit for everything...)
Well... (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...
Hashing vs. encryption (Score:2)
I was going to make a joke between IEEE and Internet Explorer, but I couldn't think of one. But web browsers do store users' passwords for various sites, which got me thinking:
For passwords used to authenticate users to this system, hashing should be the standard. But for passwords used to authenticate a system to another system, such as authenticating an online store to its payment processor, the password has to be encrypted reversibly and the key stored somewhere.
Re: (Score:2)
Which is why real browsers like Firefox support the idea of a "master password" - the key is not stored, you have to enter it. Either that, or the key is itself encrypted and the password unlocks it for use.
Re: (Score:3)
Re: (Score:3)
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.
Re: (Score:2)
If I were to use ntpasswd to zap the password, would the DPAPI protected data still be accessible? Or would it be in effect gone, since the password was used to protect it?
(ntpasswd zapping is effectively the same as removing the hash from /etc/shadow)
Re: (Score:2)
Sure you can go around Windows' back and directly change the password hash, but the data is still effectively encrypted with the old password, so yeah, it's gone.
Re: (Score:2)
Re: (Score:2)
File permissions and, if possible, some kind of MAC such as SELinux will go a long way in protecting that data. Still, if one were to compromise the web server application itself, the application could access it (as it has to have access to function). You can only really protect it from other applications/users on the system.
You might further protect it by storing this data in a loopback LUKS volume, though this means you'll have to manually (or automatically, thus defeating the purpose) mount this prior to
Re:Well... (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.
Re: (Score:2)
However, the web server access logs logged the passwords entered in plaintext.
So, in other words, they were stored in plaintext.
Re: (Score:3)
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.
Re:Well... (Score:4, 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.
What do you say when you're hacked? (Score:2)
Ieee!
AFAICT IEEE didn't warn its members yet... (Score:4, Interesting)
Why do we need to learn this from the newspaper?
Re: (Score:2)
In addition to log file permissions... (Score:2)
In addition to setting correct permissions, there are several FTP servers that suppress passwords in their logs. (e.g., Serv-U: Server Limits | Password | Mask received passwords in logs)
Even on anonymous FTP servers, you should hide passwords in the logs; otherwise someone who gets the logs can mine email addresses. (Anonymous users frequently sign on as "anonymous" and are asked for their email address as a password.)
Re: (Score:2)
(Anonymous users frequently sign on as "anonymous" and are asked for their email address as a password.)
Which is always root@the.ftp.server's.hostname.com, right?
Re: (Score:2)
I generally just slap the keyboard and supply whatever results as the password. Using your email as the password was always stupid. Why do you even require a password!?
Re: (Score:2)
Using your email as the password was always stupid. Why do you even require a password!?
Back in the distant past, people ran FTP servers which let anyone grab stuff off them "for the common good" (eg., tsx-11.mit.edu). You logged in as username "anonymous" and password "your email address." It was just the polite thing to do for someone letting you use their ftp server to get neat stuff from them.
I'm not surprised this's foreign to anyone these days.
Re: (Score:2)
Yea! I'm one of those that tend to use anonymous ftp access and give my email, which is "Test@example.com". Seems to work quite well for most anonymous access. Of course, the few servers I use no loger require an email address for anon ftp access.
Who's the network admin? (Score:2)
I mean, PLAINTEXT passwords AND publicly available on their FTP.
Does he/still have the job?
Re: (Score:2)
It would make more sense had you actually gone and read.
It was a log not a list.
Re: (Score:2)
Oh don't get me wrong, it's stupid - but not nearly as stupid as storing them in plain...
Secure password message falls on deaf ears (Score:5, 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.
Re:Secure password message falls on deaf ears (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.
Re: (Score:3)
Reference. [xkcd.com]
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)
Re: (Score:2)
it's in my short list to test
Re: (Score:2)
It's unbelievable to me that so many don't check their work or verify security settings, or even ask what could possibly go wrong.
Embarrassing breaches are inevitably the result.
And yep - whoever uses "passwo
Re:Secure password message falls on deaf ears (Score:5, Interesting)
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".
Re: (Score:2)
Nobody cares about having is IEEE account compromised, so everybody uses a bogus password. Rightfully so, it seems.
Re:Secure password message falls on deaf ears (Score:4, Informative)
I agree, but the graph scale shows that only 300 out of the 100,000 people used those most common passwords. .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).
I am not sure what the average perentage of users that use horrible passwords are, but
Re: (Score:2)
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.
To be fair, there seem to be at most a few percent having lousy passwords. The other 98% or so of users deserve better protection, wouldn't you say?
Also, if you think about it, looking only at which passwords are the most common isn't a terribly useful metric of anything. If almost everyone choose very strong passwords (meaning few collisions) and 3 people choose "12345", then that would still be the most common password. In part precisely because the rest used strong passwords.
Re: (Score:2)
It should be a wake up call that our current methods of trying to get users to pick secure passwords are a total failure.
You're trying to change human nature. Any time we can get away with being lazy, we will be lazy. It's the law of entropy. You need to come up with something miraculous to get us to stop following it. Good luck with that.
Re: (Score:2)
keepass is difficult and/or inconvenient. I get it. Oh, wait.
The left the logs open to public. (Score:4, Informative)
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.
Re: (Score:2)
The mistake they did was to allow public access to the log files of their web server.
It looks to me that the mistake they did was to not peruse their log files. Had they, they'd have noticed that their webserver was logging logins, failed logins, yada, that it shouldn't have been.
Logs are not kept just because the authoritays may come looking for them. They're also (initially primarily) kept for confirming your software configuration isn't fscked up. IMHO.
However, having worked with web hosts in the past which were spitting out > 200k errors/day, I can understand they may have been re
Re: (Score:2)
My personal guess is this:
Re: (Score:2)
Re: (Score:2)
It's like only caring about news for nerds that actually matters -- And reading Slashdot.
Now that's cruel. It's Infotainment! :-|
ACK on the rest.
FYI: password hashing doesn't matter when... (Score:5, 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.
Re: (Score:2)
One of the reasons why sensitive data should *never* be sent over HTTP using using GET, even over encrypted connections. Although in theory GET is no less secure than POST, in practice URLs (and therefore GET parameters) are commonly logged, while HTTP request bodies (and therefore POST parameters) almost never are.
Who knows... (Score:4)
You could, you know... look in the logs to find out?
Re: (Score:3)
Apparently they logged http access but not ftp access....
Re: (Score:2)
You could, you know... look in the logs to find out?
Who reads log files?!? Boring!!!111 :-P /s
It appears to be unguareded data not breach (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Not bad for a bunch of software engineers... (Score:2)
Maybe this ACM vs. IEEE thing is staring to getting out of hand?
Now do the right thing (Score:2)
Re: (Score:2)
Now that you've analysed your copy of the data, please delete it.
I think you've a shallow definition of "analyse." Analysis can go on forever. Yet another reason to protect your data.
Something for the weekend sir? (Score:2)
Re: (Score:2)
Yes - corporate workplaces are one of the last bastions of IE usage.
Before you delete that dataset (Score:2)
Out of the 100k passwords how many were unique? Could we have a graph of how many passwords were used how many times? Something that could be analysed to say that in your case about 85% of people used a unique password and 10% used a password in the top 10 or top twenty whatever. This could be used to compare to other datasets to extract a level of cluelessness/cluefulness.
Not surprised (Score:2)
The IEEE web site has annoyed me for 15 years... it is the lamest, backwardest, hardest to use, most idoidocally designed web site of any of the professional societies involved with computing. It is an embarrassment. Perhaps now the morons that are resposible will be seen for the morons that they are. Or not. I'm not holding my breath. This is the IEEE.
Ren Hoek (Score:2)
And IEEE helps the black hats... (Score:2)
This was done, according to them, to be more secure. Even before I found out about this nonsense, I told them that tieing a password to a specific identifiable person, using a tag that was nearly publicly accessible, was absolutely less secure than letting someone pick a username that appeared noplace except in the lo
Who knew? (Score:2)
Who knew Wichita was such a practical HOTBED of IEEE membership?
Re:For God's Sake (Score:5, 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: (Score:3, Insightful)
Well they are normally transmitted plain text so why shouldn't they be logged in plain text too?
Re: (Score:3)
It always upsets me when I see logins used for plain FTP.
SFTP people! It's not hard!
Re: (Score:2)
Or FTPS, even.
Re: (Score:2)
They SHOULD NOT be transmitted in plain text.
This is just as big...no, this is a BIGGER problem than storing them in plain text.
If you know anyone still endorsing the use of HTTP and FTP for credential submission, please hit them (or fire them).
This is very 1996.
Re: (Score:2)
They most probably used HTTPS for the login process, but the password itself is retrieved in pure text on the server, then hashed, then compared to the hashed value. Then, to know what's happening, they stored every request as received past the HTTPS decryption, which meant pure text password, into a shared folder...
Re: (Score:2)
Because, obviously, doing the hash in the browser is still a galaxy away. Hey, wait, maybe not [github.com]. The cleartext password isn't supposed to leave the browser, no matter what connection-level encryption you're using. If it does, you're doing it wrong.
Re: (Score:2)
What if you don't want to be running javascripts on the client ?
Re: (Score:2)
Why stop there. Just don't run the browser at all. The idea that there is any point in not running javascript is silly. I wouldn't consider "non-javascript" users very important these days. It's their choice not to use javascript, and their choice not to be my customers. Good riddance I say. If all you want is static HTML, then it's your choice, but be aware that you might as well be reading PDFs or word processor documents. Those have hyperlinks too, you know. The point of the browser is to be a bit more t
Re: (Score:3)
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: (Score:2)
Flash is an extra thing. Javascript comes with every browser.
Re: (Score:2)
Re: (Score:2)
No web services I've ever seen actually log the content of HTTPS POST requests. That's strictly against every best practice and security recommendation for exactly this reason.
Re: (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.
Re: (Score:3)
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 relevan
Re:For God's Sake (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 [xkcd.com] too.
Re: (Score:3)
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.
Re: (Score:2)
Listservs do that, but if you had actually read what's said on those listservs: those are low-security passwords. You're not supposed to use that password anywhere else.
Re: (Score:2)
Why the fuck has a major browser not adopted RFC2617?
Why the fuck has a major browser not adopted the method of hashing a master password with the domain name? (http://crypto.stanford.edu/PwdHash/)
Both of these are almost invisible to the user (when a website changes domains it might cause a few issues, but meh) so the argument that security introduces too much hassle for the user doesn't fly ... if I was into conspiracies I would say that there are forces intentionally sabotaging efforts to make the web mo
Re: (Score:2)
You wouldn't lose access, you would have to tell the browser to use the password generated for the old domain name.
Re:posting the most used passwords is probably bad (Score:4, 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: (Score:2)
Re: (Score:2)
Group password for authorized users at a particular company?
Re: (Score:2)
Re: (Score:2)
That, and "1234567" does not appear on the graph while the remaining strings from "123" to "1234567890" are all present.
Re: (Score:2)
There is nothing on the list that isn't one of the usual suspects.
Re: (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: (Score:2)
Gah, slashdot ate my formatting.
It's the Preview button's fault!
Re:small error? (Score:5, Funny)
One has an uppercase 5. The other is all lowercase.
The most popular password is 123456 (Score:2)
Re: (Score:2)
... Column1, Column2, Column3 etc...
You've never worked with scientists? Think fortran variables: a, b, c, ... some of which are naturally $anything, some of which are naturally floats, ...
I liked fortran, which is not to say it's not psychotic.