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

160 comments

  1. Looks likes... by Anonymous Coward · · Score: 0

    Someone got served... ieeeeeeeeeeeeeeeeee

    1. Re:Looks likes... by Reverand+Dave · · Score: 0

      You need to put on your sunglasses first.

      --
      I got here through a series of tubes
    2. Re:Looks likes... by Anonymous Coward · · Score: 1

      Ok, I put on my robe and wizard hat.

  2. Finally! by wonkey_monkey · · 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 · · 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 · · 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 Volanin · · Score: 1

      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.

      --
      If I clone myself, can I call it a thread?
      If a girl winks to us, can I call it a race condition?
    4. Re:Finally! by wonkey_monkey · · Score: 1

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

      --
      systemd is Roko's Basilisk.
    5. Re:Finally! by buchner.johannes · · 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.
    6. Re:Finally! by Beorytis · · Score: 1

      The map geolocation data would be more meaningful on a population cartogram.

    7. Re:Finally! by ryzvonusef · · Score: 1

      And graphs and everything. Love it.

      Go Here:

      http://www.reddit.com/r/GraphPorn/

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

      --
      I am an ACCA student. Got a query on Accountancy/Finance? Maybe I can help!
    8. Re:Finally! by Anonymous Coward · · Score: 0

      This is an act of cyberwar, let's nuke them!

    9. Re:Finally! by samkass · · Score: 1

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

      --
      E pluribus unum
    10. Re:Finally! by dskoll · · Score: 1

      It's not like the midpoint between "ADMIN123" and "IEEE2012" makes any sense.

      AEMEN022, you insensitive clod!

  3. Well... by fuzzyfuzzyfungus · · 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 · · 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 Alef · · Score: 1

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

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

    3. Re:Well... by achbed · · 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.

    4. Re:Well... by Alef · · 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.

  4. For God's Sake by Anonymous Coward · · Score: 0, Insightful

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

    1. Re:For God's Sake by xxxJonBoyxxx · · 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!)

    2. Re:For God's Sake by cdrudge · · Score: 2, Insightful

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

    3. Re:For God's Sake by Anonymous Coward · · Score: 1

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

    4. Re:For God's Sake by Capt.Albatross · · 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.

    5. Re:For God's Sake by Kozz · · Score: 0

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

      --
      I only post comments when someone on the internet is wrong.
    6. Re:For God's Sake by ubrgeek · · Score: 1

      > Please RTFA.

      Why should we start now?

      --
      Bark less. Wag more.
    7. Re:For God's Sake by X0563511 · · 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...
    8. Re:For God's Sake by teslar · · 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.

    9. Re:For God's Sake by SecurityTheatre · · Score: 1

      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.

    10. Re:For God's Sake by Anonymous Coward · · Score: 0

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

      Fixed that for you.

    11. Re:For God's Sake by Fallingcow · · Score: 1

      Or FTPS, even.

    12. Re:For God's Sake by PIBM · · Score: 1

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

    13. Re:For God's Sake by Anonymous Coward · · Score: 0

      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/ (plaintext username)
      magick-users@imagemagick.org (plaintext password)
      http://studio.imagemagick.org/mailman/options/magick-users/ (plaintext username)

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

    14. Re:For God's Sake by Pinky's+Brain · · Score: 1

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

    15. Re:For God's Sake by Anonymous Coward · · Score: 0

      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.

    16. Re:For God's Sake by luis_a_espinal · · 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.)

    17. Re:For God's Sake by Anonymous Coward · · Score: 0

      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

    18. Re:For God's Sake by tibit · · Score: 1

      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.
    19. Re:For God's Sake by tibit · · Score: 1

      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.
    20. Re:For God's Sake by PIBM · · Score: 1

      What if you don't want to be running javascripts on the client ?

    21. Re:For God's Sake by tibit · · Score: 1

      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.
    22. Re:For God's Sake by PIBM · · 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.

    23. Re:For God's Sake by SCHecklerX · · 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.

    24. Re:For God's Sake by ais523 · · Score: 1

      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"
    25. Re:For God's Sake by Anonymous Coward · · Score: 0

      Why the fuck has a major browser not adopted RFC2617?

      Good question.

      Both of these are almost invisible to the user (when a website changes domains it might cause a few issues, but meh)

      Good answer to your own question, since the "few issues" would be, you know, losing access to the site.

    26. Re:For God's Sake by SecurityTheatre · · Score: 1

      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.

    27. Re:For God's Sake by tibit · · Score: 1

      Flash is an extra thing. Javascript comes with every browser.

      --
      A successful API design takes a mixture of software design and pedagogy.
    28. Re:For God's Sake by Anonymous Coward · · Score: 0

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

      How would that have fixed this problem? Why even salt or hash?
      You are just trying to waste everyone's time aren't you?

    29. Re:For God's Sake by Anonymous Coward · · Score: 0

      So the answer is, when the PHP application recieves it. And after apache logs the POST data.

    30. Re:For God's Sake by Pinky's+Brain · · Score: 1

      You wouldn't lose access, you would have to tell the browser to use the password generated for the old domain name.

  5. posting the most used passwords is probably bad by Anonymous Coward · · Score: 0

    in combination of the website it is used for

    1. Re:posting the most used passwords is probably bad by Spad · · 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

    2. Re:posting the most used passwords is probably bad by pscottdv · · Score: 1

      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

    3. Re:posting the most used passwords is probably bad by Garble+Snarky · · Score: 1

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

    4. Re:posting the most used passwords is probably bad by NothingWasAvailable · · Score: 2

      Group password for authorized users at a particular company?

    5. Re:posting the most used passwords is probably bad by davidwr · · Score: 1

      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.
    6. Re:posting the most used passwords is probably bad by Beorytis · · Score: 1

      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.

    7. Re:posting the most used passwords is probably bad by steelfood · · Score: 1

      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."
  6. AFAICT IEEE didn't warn its members yet... by Anonymous Coward · · Score: 4, Interesting

    Why do we need to learn this from the newspaper?

    1. Re:AFAICT IEEE didn't warn its members yet... by Beorytis · · Score: 1

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

    2. Re:AFAICT IEEE didn't warn its members yet... by Anonymous Coward · · Score: 0

      It might sound strange but the original notification of IEEE.org being hacked was sent out to 'academics' (like me) on 5th of Sept. Dunno if this relates to the same hack, but here is the link the Univ forwarded to us on the 5th: http://pastebin.com/PkFPhYtA
      *Maybe was unrelated to this article?*

    3. Re:AFAICT IEEE didn't warn its members yet... by Anonymous Coward · · Score: 0

      They have NOT been up-front with this. I recently used their site, and it required me to "update" username and password to new values. No mention of a data breach. BAD, BAD organization. Moreover, the membership renewal system seems to be broken as well (keeps telling me I'm not a member for reasons unknown), and they aren't responding to support requests on that. Methinks they're a bit swamped just now...

    4. Re:AFAICT IEEE didn't warn its members yet... by Anonymous Coward · · Score: 0

      Probably not. I'm pretty sure I logged into IEEE in the last month and I haven't gotten an email.

  7. In addition to log file permissions... by xxxJonBoyxxx · · Score: 1

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

    1. Re:In addition to log file permissions... by causality · · Score: 1

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

      --
      It is a miracle that curiosity survives formal education. - Einstein
    2. Re:In addition to log file permissions... by X0563511 · · Score: 1

      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!?

      --
      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:In addition to log file permissions... by fast+turtle · · Score: 1

      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.

      --
      Mod me up/Mod me down: I wont frown as I've no crown
    4. Re:In addition to log file permissions... by tqk · · Score: 1

      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.

      --
      "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
  8. Hashing vs. encryption by tepples · · Score: 1

    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.

    1. Re:Hashing vs. encryption by X0563511 · · Score: 1

      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.

      --
      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...
    2. Re:Hashing vs. encryption by Garble+Snarky · · 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.

    3. Re:Hashing vs. encryption by Anonymous Coward · · Score: 0

      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.

    4. Re:Hashing vs. encryption by tepples · · Score: 1

      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?

    5. Re:Hashing vs. encryption by zindorsky · · 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.
    6. Re:Hashing vs. encryption by X0563511 · · Score: 1

      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)

      --
      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...
    7. Re:Hashing vs. encryption by X0563511 · · Score: 1

      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.

      --
      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...
    8. Re:Hashing vs. encryption by zindorsky · · Score: 1

      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.

      --
      If the geiger counter does not click, the coffee, she is not thick.
    9. Re:Hashing vs. encryption by Anonymous Coward · · Score: 0

      Other poster referenced Chrome on Windows (which seems pretty similar to what I'm about to point out)...

      In Kubuntu, Chrome uses KWallet. Which is... well, it's ok. I put in that password when I boot up (for wifi) and then allow Chrome to access KWallet, and I'm good. So there is the master password obscuring the stored passwords, but it's more that Chrome is using a function of the operating system available to it to do that instead of writing their whole own thing (which also makes it easier, and there's worse problems if the OS's security is subpar on that...). Downside is, if I leave my computer up, it rarely asks me for that KWallet password after first boot up, so it's not hard to get around that if you can access my computer after I've already put that up (might be a setting to make that more strict, but who's going to do that on a system you don't have anything critical on?)...

      CAPTCHA: discrete

  9. Who's the network admin? by lsolano · · Score: 2

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

    Does he/still have the job?

    1. Re:Who's the network admin? by Anonymous Coward · · Score: 0

      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.

    2. Re:Who's the network admin? by X0563511 · · Score: 1

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

      It was a log not a list.

      --
      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:Who's the network admin? by Anonymous Coward · · Score: 1

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

    4. Re:Who's the network admin? by X0563511 · · Score: 1

      Oh don't get me wrong, it's stupid - but not nearly as stupid as storing them in plain...

      --
      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...
  10. Secure password message falls on deaf ears by Tridus · · 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 · · 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 NeverVotedBush · · Score: 1

      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.

    3. Re:Secure password message falls on deaf ears by X0563511 · · 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...
    4. Re:Secure password message falls on deaf ears by Anonymous Coward · · Score: 0

      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.

    5. Re:Secure password message falls on deaf ears by Anonymous Coward · · Score: 0

      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.

    6. Re:Secure password message falls on deaf ears by tlhIngan · · 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".

    7. Re:Secure password message falls on deaf ears by Meeni · · Score: 1

      Nobody cares about having is IEEE account compromised, so everybody uses a bogus password. Rightfully so, it seems.

    8. Re:Secure password message falls on deaf ears by wisnoskij · · 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.
    9. Re:Secure password message falls on deaf ears by Alef · · Score: 1

      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.

    10. Re:Secure password message falls on deaf ears by tibit · · Score: 1

      keepass is difficult and/or inconvenient. I get it. Oh, wait.

      --
      A successful API design takes a mixture of software design and pedagogy.
    11. Re:Secure password message falls on deaf ears by Anonymous Coward · · Score: 0

      I half expected second sentence to read: "Fast forward a week or two and "correct horse battery staple" became one of most commonly guessed passwords"

    12. Re:Secure password message falls on deaf ears by Swave+An+deBwoner · · Score: 1

      I'm pretty sure that IEEE accounts have an associated IEEE email address, so knowing the accountname and password sets up the user for having his (or her) email hijacked both sending and receiving. So it's not just being able to read an article without paying for it.

    13. Re:Secure password message falls on deaf ears by Amouth · · Score: 1

      it's in my short list to test

      --
      '...if only "Jumping to a Conclusion" was an event in the Olympics.'
    14. Re:Secure password message falls on deaf ears by tqk · · Score: 1

      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.

      --
      "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
    15. Re:Secure password message falls on deaf ears by Anonymous Coward · · Score: 0

      That's easy. Make "hacking" accounts by guessing passwords 100% legal. ;)

      Seriously though -- what are the alternatives that any normal human would master better than passwords?

  11. Not Good.... by Anonymous Coward · · Score: 0

    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.

    1. Re:Not Good.... by MadKeithV · · 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? ;-)

    2. Re:Not Good.... by MadKeithV · · Score: 1

      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.

    3. Re:Not Good.... by causality · · Score: 1

      Gah, slashdot ate my formatting.

      It's the Preview button's fault!

      --
      It is a miracle that curiosity survives formal education. - Einstein
    4. Re:Not Good.... by MadKeithV · · Score: 1

      It was highlighted correctly in the preview :)

  12. The left the logs open to public. by 140Mandak262Jamuna · · 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
    1. Re:The left the logs open to public. by Anonymous Coward · · Score: 1

      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.

    2. Re:The left the logs open to public. by Anonymous Coward · · Score: 0

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

    3. Re:The left the logs open to public. by 140Mandak262Jamuna · · Score: 1
      To do any kind deep debugging of the web server, under high load conditions, there will always be flags and switches available to log everything coming from the pipe. Usually these flags create such a torrent of info and fills disks like gang busters, they are used only in serious debugging or load testing scenarios. And the flags are reset, and logs are reduced to sane things very quickly. Further under no circumstances they would send these logs to a publicly available folder.

      My personal guess is this: Some naive, inexperienced, newbie IT techie did this. Probably violated to policies of the site admins. The scenario I imagine is something like an emergency in a weekend, and the techie sent the logs to disk he/she to fix some issue. It probably involved the authentication servers. So he/she sent them to a public open location instead of a secure location behind a password because he/she was debugging the authentication issue. The first rule is, you can never debug authentication issues from the WAN side. Must always do it from the LAN side. This was probably violated.

      --
      sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    4. Re:The left the logs open to public. by 140Mandak262Jamuna · · Score: 1

      Reading it back, I know what you guys are thinking. So let me issue the disclaimer: I have never worked as an IT techie for ieee.org. :-)

      --
      sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    5. Re:The left the logs open to public. by tqk · · Score: 1

      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 reluctant to go anywhere near their log files. Sucks to be a web admin. :-P

      --
      "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
    6. Re:The left the logs open to public. by tqk · · Score: 1

      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.

      --
      "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
  13. Re:small error? by nedlohs · · Score: 4, Funny

    One has an uppercase 5. The other is all lowercase.

  14. FYI: password hashing doesn't matter when... by nweaver · · 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
    1. Re:FYI: password hashing doesn't matter when... by cbhacking · · Score: 1

      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.

      --
      There's no place I could be, since I've found Serenity...
  15. Who knows... by Cow+Jones · · 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 · · Score: 2

      Apparently they logged http access but not ftp access....

    2. Re:Who knows... by Guru80 · · Score: 1
      also from TFA, in fact the very next sentence:

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

    3. Re:Who knows... by tqk · · Score: 1

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

      Who reads log files?!? Boring!!!111 :-P /s

      --
      "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
  16. It appears to be unguareded data not breach by 140Mandak262Jamuna · · 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
    1. Re:It appears to be unguareded data not breach by NettiWelho · · Score: 1

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

    2. Re:It appears to be unguareded data not breach by 140Mandak262Jamuna · · Score: 1

      All that we know is the house was left unlocked. We don't know if anyone entered, went to the den and copied all the passwords stuck on post-it notes on the monitor. Yet.

      --
      sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  17. Not bad for a bunch of software engineers... by sticks_us · · Score: 1

    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
  18. Why are passwords needed anyway? by Anonymous Coward · · Score: 0

    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.

  19. Release the usernames by Anonymous Coward · · Score: 0

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

  20. Now do the right thing by robably · · Score: 1

    Now that you've analysed your copy of the data, please delete it.

    1. Re:Now do the right thing by tqk · · Score: 1

      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.

      --
      "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
    2. Re:Now do the right thing by robably · · Score: 1

      Keeping it because it might be useful is trumped by deleting it because it might be used maliciously. Every extra copy of the data makes it more insecure. Is his copy encrypted? Who else has access to his computer? Can he be trusted with it?

      If you see someone's diary lying open you do not take photographs of it. If you find someone's data exposed you do not copy the data. It is not yours to keep.

    3. Re:Now do the right thing by tqk · · Score: 1

      Now that you've analysed your copy of the data, please delete it.

      I think you've a shallow definition of "analyze." Analysis can go on forever.

      Keeping it because it might be useful is trumped by deleting it because it might be used maliciously. Every extra copy of the data makes it more insecure.

      I'm a bit of a history buff. I recoil from deleting anything. The Arabs saved precious texts while the Xtians were burning books. Thanks to them, we know of Aristotle and Archimedes.

      Yes, it's hard to trust anyone to be competent enough to "do the right thing" these days, but we have to hope they will try, yes?

      I don't automatically assume the worst from anyone; nowadays I probably should. I *really* hate that I should have to do that. That's my fatal flaw.

      --
      "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
  21. refund of $185 dues by Anonymous Coward · · Score: 1

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

  22. Something for the weekend sir? by biodata · · Score: 1

    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
    1. Re:Something for the weekend sir? by Fwipp · · Score: 1

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

  23. Before you delete that dataset by Lorens · · Score: 1

    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.

  24. It takes infinite effort to persuade by Anonymous Coward · · Score: 1

    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.

  25. Engineers make poor programmers. by Anonymous Coward · · Score: 0

    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.

    1. Re:Engineers make poor programmers. by tqk · · Score: 1

      ... 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 ..." -- Pink Floyd.
  26. Not surprised by dbc · · Score: 1

    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.

    1. Re:Not surprised by Thavilden · · Score: 1

      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.

    2. Re:Not surprised by cusco · · Score: 0

      I think they studied web design at the same place as the HP web site designers.

      --
      "Think about how stupid the average person is. Now, realise that half of them are dumber than that." - George Carlin
  27. Windows password recovery by davidwr · · Score: 1

    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.
    1. Re:Windows password recovery by Anonymous Coward · · Score: 0

      Yeah, it's great that you can't boot a Windows Vista/7 machine from a live CD to recover passwords. Oh, wait...

  28. Not so fast Re:Well... by davidwr · · Score: 0

    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.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  29. Be careful with those *'s by davidwr · · Score: 1

    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.
  30. user notification... by Anonymous Coward · · Score: 0

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

  31. The most popular password is 123456 by Cryacin · · Score: 1

    What?!? That's the same combination as my luggage!

    --
    Science advances one funeral at a time- Max Planck
  32. Seriously? by davidwr · · Score: 1

    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.
  33. Take the money and run by Anonymous Coward · · Score: 0

    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.

  34. Ren Hoek by ThatsNotPudding · · Score: 1

    "You IEEEdiots!!"

  35. important findings by Anonymous Coward · · Score: 0

    Now we know that firefox users wake earlier, and chrome users go to bed later.

  36. What do you say when you're hacked? by Compaqt · · Score: 1

    Ieee!

    --
    I'm not a lawyer, but I play one on the Internet. Blog
  37. Has the FBI picked you up yet? by EmagGeek · · Score: 1

    After all, you must be a terrorist hacker. I'd keep an eye over my shoulder if I were you.

  38. Discovered a breach, didn't know what to do? by Swave+An+deBwoner · · Score: 1

    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?

  39. Now I know why... by Stu_28 · · Score: 1

    they made me change my username and password when I logged in the other day.

  40. And IEEE helps the black hats... by Obfuscant · · Score: 1
    Not only this, but IEEE recently change from a system where you had an arbitrary username to go with your password, to a system where you are required to use an email address as your username.

    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.

  41. Splines! by Talennor · · Score: 1

    Oh god the splines! They should not be used for discrete data.

    --

    //TODO: signature
  42. Who knew? by Panaflex · · Score: 1

    Who knew Wichita was such a practical HOTBED of IEEE membership?

    --
    I said no... but I missed and it came out yes.
    1. Re:Who knew? by radudragusin · · Score: 1

      Who knew Wichita was such a practical HOTBED of IEEE membership?

      Very good point. Actually, some IPs could only be located at country level, i.e. USA. Wichita seems to be right in the center of USA. Radu Author of the report from ieeelog.com

    2. Re:Who knew? by Panaflex · · Score: 1

      Ah, that makes good sense! Thanks for the clarification.

      --
      I said no... but I missed and it came out yes.
  43. Michael kors handbags by Anonymous Coward · · Score: 0

    Michael kors handbags are among the most sought after bags in the market today. This is mainly because of the high quality material and the unique style that they portray. The fact is quite evident in the increased sales of the bags among fashion icons, movie stars and celebrities. The umichaelkors companyhas invested its resources towards meeting customer needs as is the trend nowadays.