×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted about a year and a half ago | from the pretty-pictures-ugly-facts dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

160 comments

Looks likes... (0)

Anonymous Coward | about a year and a half ago | (#41449009)

Someone got served... ieeeeeeeeeeeeeeeeee

Finally! (4, Insightful)

wonkey_monkey (2592601) | about a year and a half ago | (#41449027)

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

Re:Finally! (5, Insightful)

Anonymous Coward | about a year and a half ago | (#41449517)

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:Finally! (1)

Volanin (935080) | about a year and a half ago | (#41449549)

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:Finally! (1)

wonkey_monkey (2592601) | about a year and a half ago | (#41449747)

Looks like it's been fixed. There is still a minor offence in that a bar graph would be more suitable than a line :)

Re:Finally! (2)

buchner.johannes (1139593) | about a year and a half ago | (#41449897)

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.

Well... (5, Funny)

fuzzyfuzzyfungus (1223518) | about a year and a half ago | (#41449039)

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 (1)

tepples (727027) | about a year and a half ago | (#41449113)

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:Hashing vs. encryption (1)

X0563511 (793323) | about a year and a half ago | (#41449335)

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:Hashing vs. encryption (2)

Garble Snarky (715674) | about a year and a half ago | (#41449417)

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:Hashing vs. encryption (2)

zindorsky (710179) | about a year and a half ago | (#41449785)

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:Hashing vs. encryption (1)

X0563511 (793323) | about a year and a half ago | (#41450455)

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:Hashing vs. encryption (1)

zindorsky (710179) | about a year and a half ago | (#41450595)

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.

Windows password recovery (1)

davidwr (791652) | about a year and a half ago | (#41450533)

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.

Re:Hashing vs. encryption (1)

tepples (727027) | about a year and a half ago | (#41449715)

I agree with you that encrypting the master key for a reversibly encrypted password store with a function of the user's password such as PBKDF2 is fine for a browser that can interact with the user. But a server may still have to store reversibly encrypted authentication tokens and use them without authenticating with its administrator every time. Is there a best practice to protect the master key used to encrypt such tokens on a server running a LAMP stack?

Re:Hashing vs. encryption (1)

X0563511 (793323) | about a year and a half ago | (#41450507)

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 starting the application. This would only protect you from an offline attack (eg a dirty NOC tech looking for info) assuming they didn't have online access to the machine.

Re:Hashing vs. encryption (0)

Anonymous Coward | about a year and a half ago | (#41449647)

You encrypt the password database using a key that is derived from a hash of a master password and a salt. That's how you do it securely. The master password is never stored in plaintext, and the stored passwords are also encrypted.

Re:Well... (5, Informative)

tangent3 (449222) | about a year and a half ago | (#41449711)

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.

Not so fast Re:Well... (0)

davidwr (791652) | about a year and a half ago | (#41450571)

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.

I think you meant to say:

The passwords were not stored in plaintext in the place normally used for storing passwords.
However, the web server access logs logged the passwords entered in plaintext and in doing so, stored the passwords in plaintext. That was what was downloaded from a publically access ftp folder.

OBmeme: There, fixed that for you.

Re:Well... (1)

Alef (605149) | about a year and a half ago | (#41451257)

However, the web server access logs logged the passwords entered in plaintext.

So, in other words, they were stored in plaintext.

For God's Sake (0, Insightful)

Anonymous Coward | about a year and a half ago | (#41449043)

when are we going to all start hashing and salting passwords? It takes virtually no effort to do.

Re:For God's Sake (4, Informative)

xxxJonBoyxxx (565205) | about a year and a half ago | (#41449137)

>> 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 (2, Insightful)

cdrudge (68377) | about a year and a half ago | (#41449173)

Well they are normally transmitted plain text so why shouldn't they be logged in plain text too?

Re:For God's Sake (1)

SecurityTheatre (2427858) | about a year and a half ago | (#41449475)

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:For God's Sake (1)

PIBM (588930) | about a year and a half ago | (#41449507)

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:For God's Sake (0)

Anonymous Coward | about a year and a half ago | (#41451053)

HTTPS is still plain text, it is just the encryption mechanism that is encrypted.

Yes I know that is pedantic but it is what caused a problem here -- the requests should have been HTTP posts with the username and password in the payload, which by default aren't logged unlike HTTP gets

Re:For God's Sake (0)

Anonymous Coward | about a year and a half ago | (#41449953)

They shouldn't be logged at all.
Any decent web framework has methods to replace passwords (which are simple HTTP parameters) with *********** in the log file.

Be careful with those *'s (1)

davidwr (791652) | about a year and a half ago | (#41450661)

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.

Re:For God's Sake (1)

Anonymous Coward | about a year and a half ago | (#41449211)

Now we just need to figure out why anyone would ever log passwords to a plain text file.

Re:For God's Sake (2)

Capt.Albatross (1301561) | about a year and a half ago | (#41449271)

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:For God's Sake (2)

luis_a_espinal (1810296) | about a year and a half ago | (#41450327)

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 (0)

Kozz (7764) | about a year and a half ago | (#41449277)

Virtually no effort, yeah. But then, at least according to this guy [slashdot.org] , the password policy should restrict strlen(password) to be no greater than strlen(hashval). *eyeroll*

Re:For God's Sake (5, Interesting)

teslar (706653) | about a year and a half ago | (#41449423)

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:For God's Sake (0)

Anonymous Coward | about a year and a half ago | (#41449929)

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

Imagemagick.org does this in their monthly email, sent as a "Heartbeat" reminder.

From: mailman-owner mailman-owner@imagemagick.org

This is a reminder, sent out once a month, about your imagemagick.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@imagemagick.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@imagemagick.org. Thanks!

Passwords for (plaintext username)
List Password // URL
magick-announce@imagemagick.org (plaintext password)
http://studio.imagemagick.org/mailman/options/magick-announce/ [imagemagick.org] (plaintext username)
magick-users@imagemagick.org (plaintext password)
http://studio.imagemagick.org/mailman/options/magick-users/ [imagemagick.org] (plaintext username)

There are two other web sites that I deal with that use this automated listserv process in exactly the same way.

Re:For God's Sake (0)

Anonymous Coward | about a year and a half ago | (#41449479)

when are we going to all start encrypting passwords? It takes virtually no effort to do.

Fixed that for you.

Re:For God's Sake (1)

Pinky's Brain (1158667) | about a year and a half ago | (#41449951)

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

It takes infinite effort to persuade (1)

Anonymous Coward | about a year and a half ago | (#41450339)

It takes virtually no effort to do.

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.

small error? (-1)

Anonymous Coward | about a year and a half ago | (#41449073)

I see two labels for "123456789" on the horizontal axis.

posting the most used passwords is probably bad (0)

Anonymous Coward | about a year and a half ago | (#41449095)

in combination of the website it is used for

Re:posting the most used passwords is probably bad (3, Insightful)

Spad (470073) | about a year and a half ago | (#41449221)

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:posting the most used passwords is probably bad (1)

Garble Snarky (715674) | about a year and a half ago | (#41449433)

I noticed that too, any idea what it means? Sun IV? Sambalpur University?

Re:posting the most used passwords is probably bad (1)

davidwr (791652) | about a year and a half ago | (#41450743)

Because STWOLF359 was too close to a copyright infringement suit.

Re:posting the most used passwords is probably bad (1)

pscottdv (676889) | about a year and a half ago | (#41449251)

There is nothing on the list that isn't one of the usual suspects.

AFAICT IEEE didn't warn its members yet... (4, Interesting)

Anonymous Coward | about a year and a half ago | (#41449099)

Why do we need to learn this from the newspaper?

Re:AFAICT IEEE didn't warn its members yet... (1)

Beorytis (1014777) | about a year and a half ago | (#41451355)

Maybe it has already warned those members whose passwords were compromised.

In addition to log file permissions... (1)

xxxJonBoyxxx (565205) | about a year and a half ago | (#41449111)

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:In addition to log file permissions... (1)

causality (777677) | about a year and a half ago | (#41449391)

(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:In addition to log file permissions... (1)

X0563511 (793323) | about a year and a half ago | (#41449399)

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:In addition to log file permissions... (1)

fast turtle (1118037) | about a year and a half ago | (#41449427)

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? (2)

lsolano (398432) | about a year and a half ago | (#41449121)

I mean, PLAINTEXT passwords AND publicly available on their FTP.

Does he/still have the job?

Re:Who's the network admin? (0)

Anonymous Coward | about a year and a half ago | (#41449195)

That.

Why would you even generate a list of plaintext passwords? Why would you use an authentication system with reversible encryption? None of this makes sense.

Re:Who's the network admin? (1)

X0563511 (793323) | about a year and a half ago | (#41449413)

It would make more sense had you actually gone and read.

It was a log not a list.

Re:Who's the network admin? (1)

Anonymous Coward | about a year and a half ago | (#41451061)

Never mind, then. Logging plaintext passwords totally makes sense.

Secure password message falls on deaf ears (4, Insightful)

Tridus (79566) | about a year and a half ago | (#41449131)

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 (5, Funny)

MadKeithV (102058) | about a year and a half ago | (#41449201)

. 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:Secure password message falls on deaf ears (2)

X0563511 (793323) | about a year and a half ago | (#41449431)

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:Secure password message falls on deaf ears (1)

NeverVotedBush (1041088) | about a year and a half ago | (#41449291)

I'd be willing to bet that either some low paid lackey was in charge of the website and built it with no oversight or anyone even asking simple questions about what he/she was doing, or they farmed it out to someone who apparently didn't have a clue, didn't have the time, or simply didn't care.

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 "password" or "123456" should be flogged. But then again, how simple is it to beat the prospective password against cracklib or similar, verify it is at least some minimum length with some minimum of upper case, lower case, and non-alpha characters?

IEEE gets a huge fail on this one. Top to bottom.

Re:Secure password message falls on deaf ears (0)

Anonymous Coward | about a year and a half ago | (#41449539)

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.

You're assuming, though, that there's something worthwhile in there. I don't lock up my kid's $78 wal-mart bike with a $100 kryptonite U Lock. Similarly, I use very, very insecure passwords on lots of sites. Typically, the ones that require you to log in in order to access an article, or whitepaper or something. The reason is exactly the one here. It's difficult/inconvenient to generate secure passwords for the gazillion different sites I access. So I evaluate the site. If I don't really care if my account is hacked, then I use an obvious password. I save the effort of having a secure password for sites with something to lose. Worst case, the hackers get to read an article without registering... But if I use a dicernable pattern, or a program to generate passwords from domain names, etc then IEEE has just released a piece of data that could potentially be used to figure out my login for other sites, even if they're different.

Re:Secure password message falls on deaf ears (0)

Anonymous Coward | about a year and a half ago | (#41449585)

99% of sites I don't care AT ALL about my username, it's just required to read or post information. The only things I care about are banks, e-mails, and any site I purchase stuff on that might store my cc info.. with maybe a few where I semi-care about an account reputation but that's pretty rare these days. I use keepass so strong password management is deadly simple but I still have passwords for "I don't care about your site" sites that would make a security analyst cry tears of blood.

Re:Secure password message falls on deaf ears (4, Interesting)

tlhIngan (30335) | about a year and a half ago | (#41450037)

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

Re:Secure password message falls on deaf ears (1)

Meeni (1815694) | about a year and a half ago | (#41450091)

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 (3, Informative)

wisnoskij (1206448) | about a year and a half ago | (#41450161)

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

Re:Secure password message falls on deaf ears (1)

Alef (605149) | about a year and a half ago | (#41451433)

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.

Not Good.... (0)

Anonymous Coward | about a year and a half ago | (#41449187)

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.

Re:Not Good.... (2)

MadKeithV (102058) | about a year and a half ago | (#41449225)

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:Not Good.... (1)

MadKeithV (102058) | about a year and a half ago | (#41449253)

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.

The left the logs open to public. (3, Informative)

140Mandak262Jamuna (970587) | about a year and a half ago | (#41449217)

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.

Re:The left the logs open to public. (1)

Anonymous Coward | about a year and a half ago | (#41449705)

It's like having a long high entropy randomly generated password for each site you visit -- And keeping them all on a Post-It note stuck to the monitor, so you don't forget them...

It's like wearing a full body condom during sex, complete with respirator so you don't even catch the flu -- And leaving the crotch exposed because it feels better that way...

It's like using a Pen-Test suite, input fuzzing and unit tests to ensure your code is secure -- In your PHP project...

It's like being fully aware of computer security best practices, reading all the pertinent threat news letters, applying all patches and running AV scan -- While using a Windows OS.

It's like only caring about news for nerds that actually matters -- And reading Slashdot.

Re:The left the logs open to public. (0)

Anonymous Coward | about a year and a half ago | (#41450597)

Why the fuck would logs be storing passwords at all? Why? This is not something that should be happening on any computer, ever.

FYI: password hashing doesn't matter when... (4, Informative)

nweaver (113078) | about a year and a half ago | (#41449261)

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.

Who knows... (3)

Cow Jones (615566) | about a year and a half ago | (#41449275)

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?

Re:Who knows... (1)

Guru80 (1579277) | about a year and a half ago | (#41450967)

also from TFA, in fact the very next sentence:

Maybe there are access logs for the FTP so the damage can be assessed.

It appears to be unguareded data not breach (3, Insightful)

140Mandak262Jamuna (970587) | about a year and a half ago | (#41449311)

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.

Re:It appears to be unguareded data not breach (1)

NettiWelho (1147351) | about a year and a half ago | (#41449697)

Whats the difference between breaking into an house and not having to because you find the door is not even locked?

Not bad for a bunch of software engineers... (1)

sticks_us (150624) | about a year and a half ago | (#41449445)

Maybe this ACM vs. IEEE thing is staring to getting out of hand?

Why are passwords needed anyway? (0)

Anonymous Coward | about a year and a half ago | (#41449495)

This may be a case where the *smart* users chose passwords like 123456 rather than a "real" password. That's because people tend to use the same passwords on multiple accounts, let's say for one's ISP email and online shopping accounts. If an attacker gets hold of one of those, chances are they'll try to impersonate the user on other sites.

Release the usernames (0)

Anonymous Coward | about a year and a half ago | (#41449521)

As above, maybe release the usernames so those affected know to change their passwords?

refund of $185 dues (1)

Anonymous Coward | about a year and a half ago | (#41449709)

I just called and got a refund on my $185 dues. I'm not paying money for this kind of incompetence.

Seriously? (1)

davidwr (791652) | about a year and a half ago | (#41450983)

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.

Something for the weekend sir? (1)

biodata (1981610) | about a year and a half ago | (#41449725)

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?

Re:Something for the weekend sir? (1)

Fwipp (1473271) | about a year and a half ago | (#41449895)

Yes - corporate workplaces are one of the last bastions of IE usage.

Before you delete that dataset (1)

Lorens (597774) | about a year and a half ago | (#41449931)

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.

Engineers make poor programmers. (0)

Anonymous Coward | about a year and a half ago | (#41450407)

I remember a particular product created by a co-op student enrolled in an EE program which has the following data structure for the main table: Column1, Column2, Column3 etc.... The resulting code was difficult to maintain. It also had a hardcoded backdoor password.

Not surprised (1)

dbc (135354) | about a year and a half ago | (#41450413)

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.

Re:Not surprised (1)

Thavilden (1613435) | about a year and a half ago | (#41450551)

And it looks like it can't handle the slashdotting. The MyIEEE page seems to be good and busted as I go to try and change my password. Glad it's not reused anywhere.

user notification... (0)

Anonymous Coward | about a year and a half ago | (#41450703)

The least these idiots could have done is to send a short mail and notify IEEE members about this...

Take the money and run (0)

Anonymous Coward | about a year and a half ago | (#41451119)

For all the money an IEEE membership costs, not to mention the ENDLESS reminders they send you about how great it is to be a member, you'd think they could administrate their FTP a little better.

Suddenly enduring 100s of e-mails from an incomplete sign-up attempt a few years ago seems justified.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...