back to article EBAY... You keep using that word 'ENCRYPTION' – it does not mean what you think it means

Confusion reigns over whether or not the 145 million "encrypted" user account passwords swiped from eBay can be practically cracked by crooks. A day has passed since the online tat bazaar admitted its customer database was hacked back in February, and the method of encryption is still not known. We do know what wasn't …

COMMENTS

This topic is closed for new posts.
  1. JimmyPage Silver badge
    Unhappy

    Sigh ...

    Hashing was know about 30 years ago (at least - that's when I discovered it as a fresh faced computer science undergrad). Yet I still see designs where passwords are stored either in plain text, or reversibly encrypted (with routines which *de*crypt the password to compare with the supplied).

    I still gets looks of "huh" when I suggest one-way hashing.

    1. Paul Hovnanian Silver badge
      Facepalm

      Re: Sigh ...

      "Yet I still see designs where passwords are stored either in plain text, or reversibly encrypted"

      Because the PHB has mandated that passwords be changed every 30 days. And that software be added to the password change function to ensure that people aren't just changing from "password1" to "password2".

      1. Destroy All Monsters Silver badge
        Holmes

        Re: Sigh ...

        That doesn't make sense as you can just keep the N last hashes, then proceed as usual.

        No need to encrypt or have any possibility to tunnel back from entropy land.

        Changing passwords every M days is also an Antipattern. I think it originates from some obscure team working in an IBM Big Iron terminal room back when Tron was fresh.

        1. Fuzz

          Re: Sigh ...

          you can't just keep the last N hashes, if someone decides that your passwords have to be dissimilar then there is no way to test for this. The has for password1 is completely different to the hash for password2 so there is no way to tell from the hashes that the user has just changed the number on the end of the password.

          Also some systems, banks for example, ask you to enter the 3rd and 7th characters of your password. Again this isn't possible with a one way hash unless you hash each character individually and then rainbow tables are going to be pretty quick to construct.

          1. Michael Heydon

            Re: Sigh ...

            >Also some systems, banks for example, ask you to enter the 3rd and 7th characters of your password. Again this isn't possible with a one way hash

            How does this system of making you enter the 3rd and 7th characters improve security or convenience over having you just enter your password? Most people know their banking password, but I suspect a great many would need to at least count on their fingers if not write it down in order to find the <x>th character. It doesn't seem like this sort of system offers enough benefits to warrant crippling your hash algorithm to make it work.

            1. Anonymous Coward
              Anonymous Coward

              Re: Sigh ...

              "How does this system of making you enter the 3rd and 7th characters improve security or convenience over having you just enter your password? "

              It makes shoulder surfing somewhat more difficult.

              1. Anonymous Coward
                Anonymous Coward

                Re: Sigh ...

                "How does this system of making you enter the 3rd and 7th characters improve security or convenience over having you just enter your password? "

                It makes shoulder surfing somewhat more difficult.

                And man in the middle attacks

              2. Thomas Whipp

                Re: Sigh ...

                its not so much shoulder surfing as Trojan software which is the threat, if I have a Trojan installed on your PC (probably including a browser plug in) that can identify target bank sites and then capture both key strokes and a screenshot of the login page, then at least with the partial characters the attacker needs to observe a number of attempts before they can guarantee access.

            2. DragonLord

              Re: Sigh ...

              These systems usually also have a second password that is hashed normally. It's basically so that if someone's looking over your shoulder they can't get 1 password, and if they hack the database they can't get the other one. It's still not as secure as having an out of band (second factor) 1 time password generated. Either through a dongle or via a text message.

            3. Brewster's Angle Grinder Silver badge

              @Michael Heydon

              "How does this system of making you enter the 3rd and 7th characters improve security..."

              I always assumed this was protection against keyboard loggers since it stops them seeing the whole password. And even with screenshots, that would make life harder. However it also caused me to shorten my password ("what's the 12th character?") so reducing my overall security.

              (And for those who don't have a Natwest account: both your PIN and your password are handled in this manner, and there is no other password.)

          2. Anonymous Coward
            Anonymous Coward

            Re: Sigh ...

            > if someone decides that your passwords have to be dissimilar then there is no way to test for this.

            Yes there is but only on the client side. Changing passwords usually involves entering both the old and the new so the client could check for similarity before being hashed and passed to the server. Admittedly, having the client enforce this restriction isn't ideal but it is slightly better than nothing.

            1. Tom 13

              @Condiment

              That only works for the current password. Sometimes the bozos writing the security rules want you to set a password unlike any of the last 48 you've used, with at least one from each of the 4 standard categories except no database field delimiter characters, plus you can't use an dictionary words, reversed dictionary words, frequently used passwords from security studies, reversed frequently used password from security studies, simple number patterns or common keyboard patterns.

              I'll confess as someone who creates new accounts and reset passwords on a daily basis I've gotten pretty good at throwing together crap that usually meets the requirements. But there was one site where the rules were so arcane I finally said 'fuck it. generate one for me that meets you goddamn rules.'

          3. Anonymous Coward
            Anonymous Coward

            Re: Sigh ...

            "Also some systems, banks for example, ask you to enter the 3rd and 7th characters of your password. Again this isn't possible with a one way hash unless you hash each character individually"

            Actually that's a very good point! At least one of my financial providers do this: think I might look to move elsewhere soonish?

          4. bigtimehustler

            Re: Sigh ...

            Errr, no. You would hash each letter along with a particular salt which is always used on that Nth letter, along with another customer specific detail, which always changes, the salts not being kept anywhere near the data. Then you just do the same process against each letter at login. It is no less secure than hashing the entire password.

            1. Paul Hovnanian Silver badge

              Re: Sigh ...

              "You would hash each letter along with a particular salt which is always used on that Nth letter,"

              So, 'password', '1password', '22password', '333password', until we knew that we had exceeded N for the last N passwords stored. And PHB wanted this caught as well.

            2. Michael Wojcik Silver badge

              Re: Sigh ...

              You would hash each letter along with a particular salt which is always used on that Nth letter, along with another customer specific detail, which always changes, the salts not being kept anywhere near the data. It is no less secure than hashing the entire password.

              Like hell. You're basically running an 8-bit block cipher in ECB mode. You have lousy entropy; you have lousy avalanche behavior; you're making the salt part of the key (so you've just given it all the problems of keys: protection, scheduling, etc); your hashes leak information about the length of the password; etc.

              You can work around some of those by tweaking this scheme, but not the avalanche one, so it's always going to be inferior to the best protocols that hash the entire secret.

              This is why non-experts shouldn't create cryptographic protocols.

          5. Anonymous Coward
            Anonymous Coward

            Re: Sigh ...

            you can't just keep the last N hashes, if someone decides that your passwords have to be dissimilar then there is no way to test for this. The has for password1 is completely different to the hash for password2 so there is no way to tell from the hashes that the user has just changed the number on the end of the password.

            An alternative, hash the password, store that and use that for authentication. At the same time, encrypt a file with that password which stores that, and previous passwords.

            At the time of password change, the user must authenticate with the current one, so you'll be able to use that password to decrypt the old password blob and see what was used before. If the new password is good enough, add in the old password to the decrypted blob and encrypt it with the new one.

            If someone steals the blob, they'll have to figure out the salted hash before they can get at old passwords.

            Also some systems, banks for example, ask you to enter the 3rd and 7th characters of your password. Again this isn't possible with a one way hash unless you hash each character individually and then rainbow tables are going to be pretty quick to construct.

            Don't know about you, but my memory for passwords works like a linked-list. I call it "muscle memory", and it can only be traversed in one direction from start to finish, not indexed like an array or iterated in reverse. So I wouldn't have the foggiest clue what was the 12th character or the 6th.

            So this means of "protection" will only help those who have written down passwords. A behaviour the IT industry has been trying to discourage for a long time.

            That said, nothing stops you from picking select characters at random, and storing those separately, if you really want to make your users suffer in this manner.

    2. Anonymous Coward
      Anonymous Coward

      Re: Sigh ...

      "Hashing was know about 30 years ago (at least...)"

      I'll raise that to 42 years, as I remember an experienced commercial programmer in the City of London telling me all about hashing in 1972. And he and his colleagues had been using it as a matter of course for several years.

      1. Phil O'Sophical Silver badge

        Re: Sigh ...

        I'll raise that to 42 years

        46. First described in "Time-Sharing Computer Systems" by MV Wilkes, published 1968. Page 91, according to the Bell Labs paper "Password Security: A Case History" by Robert Morris and Ken Thompson that I happen to have on my bookshelf.

        1. Michael Wojcik Silver badge

          Re: Sigh ...

          46. First described in "Time-Sharing Computer Systems" by MV Wilkes, published 1968

          If you're talking about hashing a password to create an authenticator, then yes (probably). Using hash functions for more general IT purposes goes back at least to the early '50s (when the term was used by Luhm). See TAOCP3.

    3. Michael Wojcik Silver badge

      Re: Sigh ...

      I still gets looks of "huh" when I suggest one-way hashing.

      "One-way hashing" is redundant; if your hash function is a bijection (or even an injection), it's compression, not really hashing. I know, "perfect" hashing is an injection and so is reversible (generally with a greater time or space cost to find the preimage than to find the image), but it's also a misnomer. Certainly in the context of security authenticators there's no reason to qualify it with "one-way".

      Of course, passwords are terrible authenticators, and cryptographically-strong hashing is inferior to ZKP-based authentication methods, for example, that never leak the user's identity proof. We're still using the weak authentication schemes forced on us by the limited resources and knowledge of the 1960s, because we're too damn lazy to use anything better.

  2. Daniel B.
    Boffin

    Ah, encryption and hashing

    A lot of people, and a couple of places do not seem to know the difference between encrypting and hashing. I still remember someone talking about how their password database was very secure because they used "MD5 encryption" on all passwords. The usage of "secure", "MD5" and calling a hashing function as "encryption" almost caused an embolism on our security expert.

    And then there are a lot of people who insist on using decryptable password encryption mechanisms for "password recovery" situations. Oh dear...

    1. Chris 244
      Boffin

      Re: Ah, encryption and hashing

      The irony here is that apparently you may not know the difference between embolism and stroke or aneurysm. An embolus is a piece of material (clot, tumour, air, amneotic fluid, metal fragment, anything really) that travels somewhere in the body then gets stuck. Usually bad (clot to the lungs or brain or retina) but sometimes good (glue injected into a bleeding vessel, coil into a cerebral aneurysm). Not associated with high blood pressure.

      I think you were looking for "stroke" (of the hemorrhagic variety) or maybe "blew an aneurysm".

      1. lurker

        Re: Ah, encryption and hashing

        The fact that a software geek isn't also medically knowledgeable actually isn't as ironic as your misuse of the word 'irony'.

        1. Ken Hagan Gold badge
          Headmaster

          Re: Ah, encryption and hashing

          It is ironic if someone mis-uses a word whilst pulling someone else up for mis-using a word. However, it is probably *more* ironic if the word is "ironic".

        2. Michael Wojcik Silver badge

          Re: Ah, encryption and hashing

          as ironic as your misuse of the word 'irony'

          Doctor, heal thyself.

          The use of irony in the post in question is perfectly in keeping with the word's normal denotation as a term of art, as well as its popular usage.

          Irony is one of the four master tropes,1 and it refers to any situation in which the explicit meaning of an utterance or the circumstances of an event are at odds with a reasonable expectation for that utterance or event. Chris 244's use of "irony" can be understood as referring to an expectation that, as Daniel B. was complaining about one person's misuse of a technical term, a naive audience might have expected Daniel to himself use another technical term appropriately. Since he did not do so, that was ironic.

          The real irony of "irony", of course, is the number of Internet pedants who think they know what it means but apparently have never bothered to read so much as an introduction to rhetoric, and so erroneously scold others about its use.

          1Bonus points to anyone who can name the other three without looking them up. The list is usually attributed to either Burke or Vico, but can be derived from the work of any number of rhetoric scholars in the European tradition, as well as some of the structural linguists such as Jakobson.

    2. Michael Wojcik Silver badge

      Re: Ah, encryption and hashing

      The usage of "secure", "MD5" and calling a hashing function as "encryption" almost caused an embolism on our security expert.

      MD5 is a perfectly suitable cryptographic hash for computing password verifiers under many reasonable threat models, though in some cases it should be used in conjunction with a random salt to increase the work factor for brute-forcing. MD5 is broken for many digital-signature and message-authentication purposes, but password verifiers are a constrained case where the digest function does not have to be so resistant to collisions or preimage discovery (because the system generally limits the preimages that can be used anyway).

      As for referring to MD5 as "encryption": Sure, that's a shibboleth for anyone in the industry, but all it means is that whoever came up with that particular turn of phrase doesn't understand the difference. It doesn't say much about the people who actually implemented the system.

      In any case, user-authentication security failures are rarely due to the choice of cryptographic hashing algorithm, and pretty much never to calling it "encryption".

  3. Zmodem

    proprietary algorithm also means opensource, where you can just change 1 line of code and have your own custom algorithm

    1. Ken Hagan Gold badge

      In the hands of tech-illiterate PR hacks, "proprietary" doesn't mean anything. It's just a word they insert into press releases because they think it sounds impressive. I'd be surprised if eBay's IT staff have done anything "proprietary" rather than simply switch on the options that came with their system. (Let's hope they actually did the latter.)

      1. Anonymous Coward
        Joke

        I'd be surprised if eBay's IT staff have done anything "proprietary" rather than simply switch on the options that came with their system. (Let's hope they actually did the latter.)

        Such as the "use ROT26 encryption instead of AES-256" option?

        1. Zmodem

          read inbetween the lines of most releases and statements the software world hands out, its mean opensource as well

        2. theblackhand

          Re: Such as the "use ROT26 encryption instead of AES-256" option?

          I read "proprietary" to mean they developed ROT12 or ROT14 instead of ROT13.....

          Unfortunately, reality is likely to be even worse :-(

          1. Anonymous Coward
            Joke

            Re: Such as the "use ROT26 encryption instead of AES-256" option?

            I read "proprietary" to mean they developed ROT12 or ROT14 instead of ROT13.....

            Yes, but the sales people tell me bigger is better, and 26 is twice 13, so therefore ROT26 must be twice as good as ROT13!

    2. Ian Yates

      Proprietary means "we think we're more clever than the uncounted number of people that have reviewed the open source implementations for years". So they're probably relying on the obscurity of their implementation... which is ridiculous.

      1. Anonymous Coward
        Anonymous Coward

        Open source reviews

        Proprietary means "we think we're more clever than the uncounted number of people that have reviewed the open source implementations for years".

        Yes like all those OpenSSL scrutinisers...

        1. Ken Hagan Gold badge

          Re: Open source reviews

          In fairness, some of those OpenSSL bugs *had* been spotted and were entered into the Bugzilla database. The reason they weren't fixed was because the development team wasn't open enough.

      2. Michael Wojcik Silver badge

        Proprietary means "we think we're more clever than the uncounted number of people that have reviewed the open source implementations for years".

        In this case (a possibly "proprietary" cryptographic hash algorithm or protocol for deriving an authenticator from a user's secret proof of identity), implementation scrutiny isn't as important1 as the years of cryptanalysis of the published algorithms, particularly those in wide use like the MD4/MD5/SHA famiily.

        1Obviously that's something of an overstatement; they're both important. But bad design is generally harder to fix than bad implementation, and often easier for an attacker to find.

    3. Stoneshop
      FAIL

      ZModem

      Ah, you still haven't learned to write relevant and coherent comments.

      Kindly fornicate off and decease.

  4. Mark Allen

    Which Ebay?

    Is there any comment as to which EBay has been hacked and therefore how wide this is? US, UK, FR, DE?

    Have they got *every* Ebay user's details, or just a select few from a single country?

    Just curious as to how soon someone will knock at my door as no one has yet phoned me on 01111-111111.

    I have seen my ebay specific email address get a flood of messages. Which is no different to any other day as that address has been sold on by so many EBay sellers over the years. And\or those sellers who get their mail accounts hacked and viral spam sent out to all. At least this password change gives me an excuse to change my email address at the same time...

    1. JassMan
      Trollface

      Re: Which Ebay?

      I think you'll find there is only one eBay. The different URLs are used to determine which user interface and language to display but all authentication and account detail is held in the US in order to make it easier for the NSA to keep tabs on all those for'n tererists.

  5. Anonymous Coward
    Anonymous Coward

    Double fail

    Anyone with a less than stellar feedback score now has the perfect excuse to dump their account and start again.

    1. tomRR

      Re: Double fail

      OK so now I know how my partner's eBay account got compromised 2 months ago. Yes we shut it down but eBay make you wait 6 months to make sure any charges due to them can be settled

  6. Destroy All Monsters Silver badge
    Holmes

    Spokeswoman Amanda Miller broke radio silence to say eBay.com ran passwords through some sort of mystery one-way encryption, aka hashing.

    Was that Wehrmacht radio "guaranteed originally from Rommel's Greif: Make a Bid" finally delivered?

    She insisted the website used "sophisticated, proprietary hashing and salting technology to protect the passwords"

    Also, peppering and grilling. The result is sautéed.

    1. Phil O'Sophical Silver badge

      sophisticated, proprietary hashing and salting technology

      That'll be crypt(1), then?

  7. Kevin McMurtrie Silver badge

    Seasoning

    Salting can be done wrong too. It works best when the salt token refers to a large table of semi-secret codes stored elsewhere: salt_id + hash (saltOf(salt_id) + pass). The usual n + hash (n + pass) doesn't work so well if n is a 0..9 but it is good with big codes. In too many cases I've seen the salt as a hard-coded constant, which does nothing at best. At worst, a hard coded salt constant makes finding login code as easy as searching for that constant.

    1. Ben Liddicott

      Re: Seasoning

      Salt should be cryptographically random.

      1. Michael Wojcik Silver badge

        Re: Seasoning

        Salt should be cryptographically random.

        A meaningless claim outside the context of a threat model, and under reasonable models for the typical web authentication protocol it looks over-strong to me. A decent non-cryptographically-strong PRNG should be perfectly suitable for generating salt values in most cases. Even a relatively weak PRNG would not significantly reduce the strength of the salt component, since it doesn't take many bits of entropy in the salt value to expand the storage requirements for a precomputed dictionary beyond what's cost-effective for nearly all targets. And for relatively rare occurrences like setting user passwords, that entropy is easy to come by.

    2. Michael Wojcik Silver badge

      Re: Seasoning

      In too many cases I've seen the salt as a hard-coded constant, which does nothing at best.

      Not nothing - an attacker who wants to use an offline precomputed dictionary attack has to determine the salt value before building the dictionary. The judges would have accepted "does very little at best".

  8. Jan 0 Silver badge

    Is it time to get out more and use paper money?

    Thanks to this gaffe, I've discovered another shortcoming. I can no longer specify my own "secret question". Instead I can only chose from one of their questions with easily traceable answers, e.g. "What is your mother's maiden name?". That leaves me in a dilemma. Shall I assume that my secret question, with an answer that nobody else knows, is still safe? Or shall I throw it away and choose one of eBay's questions for Dummies? What worries me about this gaffe is, just how intertwined are eBay's databases and software with Paypal's?

    1. Alister
      Facepalm

      Re: Is it time to get out more and use paper money?

      Instead I can only chose from one of their questions with easily traceable answers, e.g. "What is your mother's maiden name?".

      What, you mean you would answer that truthfully?

      Blimey!

      1. Cliff

        Re: Is it time to get out more and use paper money?

        Easily traceable answers

        My mother's maiden name was 'Hitler', bless.

        1. Michael Wojcik Silver badge

          Re: Is it time to get out more and use paper money?

          Ironically, my mother's maiden name is "bestjetpilot".

    2. Anonymous Coward
      Anonymous Coward

      Re: Is it time to get out more and use paper money?

      You answer that with the right answer? Don't be a pillock!

      I have several fake details for my Mother's name, my birthday, first pet, first car and first school! I use them at random, logged of course in a software safe with the website login. The bank, insurance company ( and ironically the government depts! ) are the only one's who have the correct details.

      Websites for buying dirt cheap knick-knacks like eBay do not deserve my real details as they will no doubt abuse or lose them.

    3. NogginTheNog
      Happy

      Re: Is it time to get out more and use paper money?

      Regarding questions like "Mother's maiden name", "Place of birth", or "First pet", there's no law that says you have to answer truthfully. Mine are "Betty Swollocks", "Asgard", and "Muttley".

  9. Anonymous Coward
    Anonymous Coward

    You would be surprised at where proprietary hashing algorithms are used...and once you've started using them, it's very hard to decommission them because you can't decrypt everyone's passwords and recrypt them using SHA-2 or something sensible - that's the whole point, you can't decrypt them at all. I have personal experience of this; when carrying out a security review of the IT system I couldn't believe they'd actually been so silly, but they wouldn't change as it would have involved issuing all customers with a new password and that would have cost them about half a million quid.

    You could, I suppose, just have double-hashed older passwords (proprietary then SHA-2) provided they're flagged as such, but that's a faff to program so the firm just carries on with the crappy non peer-previewed proprietary method.

    AC for obvious reasons.

    1. JimmyPage Silver badge
      FAIL

      @AC

      how did you work out issuing customers with new passwords would cost £500,000 ?

      Are you interested in a bridge ?

      1. Anonymous Coward
        Anonymous Coward

        Re: @AC

        You'd have to mail an absurdly large number of people at a cost of more than £1 per item, using some kind of secure stationery (LaserTab etc). You do not have all their e-mail addresses, nor are you allowed to send cleartext passwords by e-mail anyway.

        (it's actually way, way more than £500,000; I munged the figure so you can't work out the application from the size of the customer base).

        The other option I suggested was to force a password change at next sign on after the hashing algorithm change, but this was considered customer-hostile too.

        1. Mark Allen

          Re: @AC

          Silly question, but surely it would be possible to create a new password system alongside the old? Let people login with their old password, but request they change it. Then pop that into your database in the newly salty hash version instead.

          Yeah, this means users who don't login often will still have less secure passwords in your database, but surely this is a step in the right direction to protect your users who are accessing the data more often?

          Eventually you'd have the current users all updating to nice new secure passwords, secure in your newly secured salty hashed system, leaving you with a much smaller group to contact. Or just plain suspend those old accounts until they contact you?

        2. Ken Hagan Gold badge
          Unhappy

          Re: @AC

          "The other option I suggested was to force a password change at next sign on after the hashing algorithm change, but this was considered customer-hostile too."

          Whereas getting hacked isn't customer-hostile, I suppose.

          Yeah, your story has the ring of truth.

    2. Fuzz

      ummm, it's easy enough to get the old passwords, the users give them to you when they log in.

      user logs in check password using old hashing method if correct hash password using new method and store as people log in their hashes are updated nobody needs a new password, sure it's not as secure as changing everyone's passwords but it's going to be a lot cheaper.

      1. Anonymous Coward
        Anonymous Coward

        They don't...for security only certain characters of the password are requested. See the difficulty? Customers have been repeatedly educated not to trust a site that requests the whole password.

        1. Brewster's Angle Grinder Silver badge

          Shit. I suspect we now know which site, and I bank with them. However the good news is at least they are hashed... (See discussion above.)

    3. Jon 37

      Django has a nice way of handling changes of hashing algorithm:

      The database entry for a user holds their hashed password, in a format that specifies the hash algorithm that was used.

      When users log in, if their passwords are stored with an older algorithm, Django will automatically upgrade the stored password hash to use the preferred algorithm. (It can do this because the user just typed in their password, so this is the only time the system knows the plaintext password).

      This means that old installs of Django will get automatically more secure as users log in, and it also means that you can switch to new (and better) storage algorithms as they get invented, without breaking compatibility.

    4. Anonymous Coward
      Anonymous Coward

      Changing encryption method

      I changed from MD5 to mcrypt, when they signed in I would try md5 and if successful convert the password to mcrypt. It took a few weeks but they are now all mcrypt. Of course the users didn't know.

      1. Anonymous Coward
        Anonymous Coward

        Re: Changing encryption method

        I changed from MD5 to mcrypt

        mcrypt is symmetrical, so fairly useless for passwords. As this article is trying to point out, you should hash them, not encrypt them.

        1. Michael Wojcik Silver badge

          Re: Changing encryption method

          mcrypt is symmetrical, so fairly useless for passwords

          You can create a one-way function suitable for password verification from a symmetric encryption algorithm. See UNIX crypt for an example. (crypt is not a strong password digest by modern standards, and the construction is also dated, but it demonstrates the basic concept.)

  10. Paratrooping Parrot
    FAIL

    So, a company that is earning loads of money isn't spending much on security?????? They should be severely punished by all the information watchdogs around the world who would be affected by this lack of care. It makes me worry about the security of Paypal.

    1. Tom 13

      Re: isn't spending much on security?

      Probably but not necessarily.

      They could be spending boatloads on security but it is still crap because they aren't using the right concepts or focused on the wrong areas.

      Look, Ebay have been compromised for at least 2 months, probably with employee credentials. Once you have a copy of legitimate employee credentials the system is much more vulnerable to escalation attacks. If you've got a month to trawl around, you can probably find the salt and the hash algorithm even if programmers followed the best theoretical practices possible. Hell at that you might just do what they did with Target: install a logger that captures credentials as they are being passed for authentication.

  11. Anonymous Coward
    Anonymous Coward

    It looks password lenght is limited...

    ... at around 20 character. That's funny, because if you hash password they become all the same size, and thereby it's pretty stupid to set such a limit that looks like a classic VARCHAR(20) database field size, while hashing a 20 or 200 character long string doesn't change much.

    The real issue is most developers stubbornly refuse to understand good security practices, they have old habits and don't want to change them.

    1. Zog The Undeniable

      Re: It looks password lenght is limited...

      Oh yes...remember Windows LanMan hashes and the 7 character problem? Despite this, many organisations insisted on 8 character passwords and left LanMan compatibility on, which made them much easier to break.

  12. Anonymous Coward
    Anonymous Coward

    Better to not disclose.

    I know it means no stories, but I would rather ebay didn't disclose to the world (and the hackers) details about what that data is and how it was encrypted.. It's giving them help in reversing it.

    1. Jon 37

      Re: Better to not disclose.

      It's one of the basic principles of crypto algorithm design: You should be able to tell the attacker your crypto algorithm, but not the key, and your algorithm should still be secure. Some hashing algorithms have "pepper", which is a secret key. If EBay is using such an algorithm, it could state the algorithm without revealing the "pepper".

      If EBay are using a standard secure algorithm, such as PBKDF2, they can say so, and that would reassure a lot of people, and it won't help the attackers much.

      If EBay are using a crap algorithm, then revealing it might help the attackers. But in that case, EBay deserve to be prosecuted by regulators and sued by consumers, if that's the only way to make them take security seriously.

      If EBay are using a proprietary algorithm, then it's probably crap. There's a lot of history here - most proprietary algorithms get broken very quickly when they're published. (Lots of crypto algorithms are published and then promptly broken; the algorithms we use, such as AES, are the result of "survival of the fittest").

      If EBay refuse to say what they're using, then it's probably crap.

  13. Bradley Hardleigh-Hadderchance

    I only registered with ebay yesterday, afer avoiding it my whole life. I needed some stuff I couldn't get anywhere else coz they have a monopoly on the second hand market.

    I was thinking to myself 'how safe is this? - better make a good password - imagine if ebay got hacked and all those passwords got into the wild', as you do.

    Little did I know that half an hour later I would see on the front page of the BBC - ebay accounts hacked.

    I am assuming I am safe. But they give no time frame from when people were vulnerable to when they were safe. What a piss poor organisation. A monopoly. And they abuse it as such.

    1. Roland6 Silver badge

      Re: better make a good password ...

      You can largely ignore all the stuff about making your user password ultra secure, this hack was on the DB where eBay stored the password (and other account details). So it doesn't matter how secure your password is, if eBay aren't using best security practise and so aren't protecting access to their systems and storing the password in an easy to read format.

      No the only way to make your eBay (and other website) password secure is to:

      1. Make it different to the passwords you use elsewhere - and yes do pay attention to sensible measures to make it hard to guess.

      2. Regularly change passwords eg. every month or so.

      Additionally, don't directly link any account (eg. eBay, Amazon etc.) to your bank account - always leave them requiring a user supplied password (which naturally should be different to the one used to gain access to the merchants website) to proceed with the transaction. This is where PayPal is very handy as it also hides the details of your actual payment cards from the merchant.

  14. mr.K

    What I do not get is that how somebody with staff level access were able to download the whole database, or whatever large part of it it was. Shouldn't there be mechanisms in a system like this that searches for abnormal user behaviour and reports it somewhere where somebody human is on watch. Checking out one or two, or a few hundred accounts a day is one thing, downloading the whole thing is another. It seems to me that the security was mostly on keeping the perimeter secure, but once you are across the fence you could do whatever you wanted.

    Then again, this is somewhat far from what I do, so please enlighten me if I there is something I have missed here.

    1. Roland6 Silver badge

      Re; Download the whole database...

      I agree there is much that eBay aren't saying about both how the hackers got in and how they were able to gain table access the DB. Also what logging were they running - because they should know from the audit logs which user accessed the DBMS, the queries they performed etc.

      Also was the access on the 'live' DB or on one of the many off-line mirrors/snapshots/backups.... Don't tell me the developers test against a full copy of the live DB...

  15. ukgnome
    FAIL

    I am going to wait 3 months before commenting on this, and even then I will let the BBC do the commenting for me.

  16. Nifty Silver badge

    The users' personal info database should be stored in a distributed way, so that the distributed pieces can only be stitched together in an interactive session that takes a certain amount of time. This way any purloining of personal info would have to be done painstakingly and interactively one-by-one, not by a bulk download that in Ebay's case seems to include all users' data neatly packaged.

    Actually I am beginning to think there's a inside job element to this.

  17. Major Ebaneezer Wanktrollop

    If you have chosen the option to 'link' your eBay account with your PayPal account (as they prod you to do every time you purchase something) then you don't have to login in to PayPal at all and you can go on a right old spending spree with just the eBay login.

    Their statement of credit card details not being at risk, partly true as you can't recover your card number or CVV from your own PayPal account but the hard fact that the hackers could easily empty your card is not being banded around is it?

  18. Anonymous Coward
    Anonymous Coward

    Can't paste in your password

    I noticed you can't paste in a new password, they have disabled paste so you have to have a fairly simple password. I guess they don't understand password managers. If they can't get this sort of thing right I think their security design is probably very poor.

  19. Anonymous Coward
    Anonymous Coward

    The eBay hash method

    SHA-512(RSA-Encrypt(RSA-Encrypt(Password + Username) + Password))

    See how the password and username is first encrypted to create a "unique" salt (change your username and you will be required to enter your password, although the intention was to use a one-time alternate hash using previous username), originally it was an MD5 hash, but several years ago it changed to SHA-1, passwords are silently rehashed on successful login when the hashing method changes, it's moved to SHA-512 now, if you have a dump of the hashes you'll see four different lengths (older, unused accounts have not been rehashed). The RSA encryption key is unusual as it was calculated randomly (and blindly), then the private key portion was discarded (simply deleted), as it was only ever to be used for hashing (therefore, more secure if it remains unknown).

    1. Michael Wojcik Silver badge

      Re: The eBay hash method

      Hmm. Offhand that construction looks OK, though slow - but slow is a virtue when digesting passwords, provided the system is still fast enough at normal verification. Kind of looks like cargo-cult crypto, though, and I'd like to see a real cryptanalysis of it.

      1. Anonymous Coward
        Anonymous Coward

        Re: The eBay hash method

        As you say slow is good, also, it has been properly analysed, and in fact the first round was changed as a result (it's not quite a simple addition because of the 7 bit nature of ascii), then a rainbow was created from every single registered username and a small dictionary, the final hashes checked for collisions.

        Definitely not cargo cult, comparisons were made with other password hash methodologies, a random salt with the same password would lead to collisions so using the username as a base was chosen this further perturbed by the password, and by encrypting twice (using an asymmetric cypher with no possibility of recovering half of the key) before hashing with a robust hash is very secure, and those Sun 4000 accelerators means it was very fast (they're not used now).

  20. OliverJ

    Who cares about the passwords?

    It's the - or more to the point, MY - personal data which I do care about! Passwords, after all, can be changed in a whiff, while my d.o.b. can't! How can I sue those guys for criminal negligence?

    Also, it is absolutely incredible and won't do AT ALL that, this thing going on for two days now, I got ZERO email or message at all from ebay, explaining to me what happened, telling me if my personal data was affected, or not. This is very unprofessional and makes me wonder about the people at eBay who, after all, run this PayPal scheme as well, which in Europe at least is a BANK.

  21. DaddyHoggy

    @AskeBay are still insisting that Personal Details were also "encrypted" which is at least 'different' from what their actual statement online says which specifically says that the passwords were encrypted but makes no such claim over my personal details.

    ***

    AskeBay: @DaddyHoggy There is no evidence of any unauthorized access to personal or financial info, as it's stored separately in encrypted formats ^E 11:47am, May 22 from Attensity Respond 6

    ***

    They have so far ignored my follow up tweet asking to clarify that my personal details were 'encrypted' too - and if they were why does their statement only mention encrypted passwords.

  22. bigbob

    Encrypt personal data?

    Can someone explain why it's suggested to encrypt the other personal data? Surely the web application needs the key to access the encrypted data, so you'd store the key on the same system as the db. So any attacker that can get at the encrypted data can get the key too, making the encryption worthless?

  23. Anonymous Coward
    Anonymous Coward

    Spaces and certain symbols (< >[ ]//) are not allowed in password.

    Seriously… I tried changing it to a 20 character password, with the intention of shutting down the account, and those are the rules.

    These people are not serious about security.

This topic is closed for new posts.

Other stories you might like