Slashdot Mirror
Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords
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."
Some actual news for nerds, and from the horse's mouth. And graphs and everything. Love it.
systemd is Roko's Basilisk.
Does this make plaintext password storage an IEEE standard now?
That could save an, er, friend of mine, a lot of work...
Why do we need to learn this from the newspaper?
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.)
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.
I mean, PLAINTEXT passwords AND publicly available on their FTP.
Does he/still have the job?
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
>> 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!)
Well they are normally transmitted plain text so why shouldn't they be logged in plain text too?
Now we just need to figure out why anyone would ever log passwords to a plain text file.
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
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
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? ;-)
One has an uppercase 5. The other is all lowercase.
There is nothing on the list that isn't one of the usual suspects.
this signature has been removed due to a DMCA takedown notice
Gah, slashdot ate my formatting. I was replying to "it's hard to find most information online", when the posted article clearly indicates that some information was rather too easy to find online.
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
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.
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
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
> Please RTFA.
Why should we start now?
Bark less. Wag more.
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...
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.
I noticed that too, any idea what it means? Sun IV? Sambalpur University?
Ok, I put on my robe and wizard hat.
Maybe this ACM vs. IEEE thing is staring to getting out of hand?
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Group password for authorized users at a particular company?
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.
Or FTPS, even.
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...
Now that you've analysed your copy of the data, please delete it.
I just called and got a refund on my $185 dues. I'm not paying money for this kind of incompetence.
After taking a look at the original article (I know, I know) it has an interesting plot about the prevalence of particular browsers. It looks as though there is a clear dip in the use of the site at weekends (at least the two weekends shown), but what's more interesting is that the browser use proportions also seem to change at the weekends, with a drop in the proportion of IE users. Is this a known thing generally?
Korma: Good
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.
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 more secure ...
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.)
I must sadly post AC. I maintain a website which uses plaintext passwords. We know that it's both insecure and also (since so many users re-use passwords) makes the users insecure at other sites.
And yet, AFAIK we never intend to fix our website.
Part of the desired behavior of our site, is that we have to be able to tell users what their password is. I think the boss is convinced that users would be unhappy with having some kind of random password reset thingie. So we the admins need to be able to look up what someone's password is, without changing it, so that we can tell that value to an (unauthenticated!) user.
You can't argue with people when they are completely convinced religiously that their way is the one right way and the other 99.999% of the world is wrong. It's not about difficulty of fixing it; it's that a "fixed" system would be judged by to be inferior.
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.
we all know how easy it is to recover Windows passwords.
While the Windows NT-style passwords database is trivial, and it is trivial to "blank" a password to enable logging into an account with an unknown password, 21st-century versions of Windows have a strong password database. Well, strong from the point of view of "cracking" a Windows password database offline and assuming there are no weak passwords.
like most password-based systems, it is still the "brute force" method if the password is weak or if you have something to go on like "this user always uses a month plus a word out of the dictionary plus the name of a family member." It's also somewhat vulnerable to the rubber-hose/"tell me or you are fired"/intimidation method but only against an adversary who can be intimidated and who believes you can carry out your threat.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
If some future update to Unicode results in oh, say, 70 or 80 unique unicode characters that look like *, you will be able to store and play back most US-typewriter-letter+number+symbol passwords and have them look like * to the untrained eye.
Imagine a hacker taking over a web server so it stored passwords in this format instead of replacing them with *'s, then sent the file containing them back to the hostile intruder at a later date. To a naive human being eyeballing the logs, things will seem normal. Of course, such a change is easily detected, but it is one more thing administrators will have to check for if they suspect intrusion.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
What?!? That's the same combination as my luggage!
Science advances one funeral at a time- Max Planck
Because STWOLF359 was too close to a copyright infringement suit.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'm saddened that it came to this, but I'm happy they were gracious enough to refund your dues.
I have strong faith that they will be spending at least some of everyone else's dues on fixing this problem.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'm wondering if there's a just single user whose password was "SUNIV358", and that user logged in to the system very frequently. These entries are coming from a log, rather than a password database afterall.
Because, obviously, doing the hash in the browser is still a galaxy away. Hey, wait, maybe not. 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.
A successful API design takes a mixture of software design and pedagogy.
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.
A successful API design takes a mixture of software design and pedagogy.
"You IEEEdiots!!"
What if you don't want to be running javascripts on the client ?
That, and "1234567" does not appear on the graph while the remaining strings from "123" to "1234567890" are all present.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
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 than a non-javascript PDF reader.
A successful API design takes a mixture of software design and pedagogy.
Ieee!
I'm not a lawyer, but I play one on the Internet. Blog
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.
After all, you must be a terrorist hacker. I'd keep an eye over my shoulder if I were you.
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.
So you discovered a breach in the IEEE website and for a few days you were uncertain what to do? Maybe call them up and tell them?
they made me change my username and password when I logged in the other day.
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 login database. I pointed out that everyone in IEEE now knows my username, because IEEE uses it to send out email notices and deal with customer support requests.
I also made a comment about how I would not be surprised to find out that they were storing this information in the clear. That was yesterday. Today I read /. and find out that not only is it kept in the clear, it's kept on a publicly accessible FTP site.
Gawd. If you tried, you just couldn't make this stuff up.
Doing the hash on the browser is mostly pointless, because then people can log in merely with the hash, rather than with the actual password. So you aren't making your own site any more secure. (You are making other people's sites more secure indirectly, though, because people using the same password at multiple sites won't be compromised at those sites if your site gets compromised.)
(1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
Oh god the splines! They should not be used for discrete data.
//TODO: signature
Who knew Wichita was such a practical HOTBED of IEEE membership?
I said no... but I missed and it came out yes.
Gah, slashdot ate my formatting.
It's the Preview button's fault!
It is a miracle that curiosity survives formal education. - Einstein
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.
Flash is an extra thing. Javascript comes with every browser.
A successful API design takes a mixture of software design and pedagogy.
It was highlighted correctly in the preview :)
You wouldn't lose access, you would have to tell the browser to use the password generated for the old domain name.
... 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.
"Tongue tied and twisted, just an Earth bound misfit