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

House rules Send corrections

This topic is closed for new posts.

Page:

Thursday 22nd May 2014 16:18 GMT JimmyPage

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.

8 1
1. Thursday 22nd May 2014 17:22 GMT Paul Hovnanian
  
  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 7
  1. Thursday 22nd May 2014 17:44 GMT Destroy All Monsters
    
    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.
    
    15 2
    1. Thursday 22nd May 2014 22:26 GMT 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.
      
      4 1
      1. Friday 23rd May 2014 01:40 GMT 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.
        
        12 0
        
        Friday 23rd May 2014 08:17 GMT 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.
        
        5 0
        
        Friday 23rd May 2014 09:44 GMT 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
        
        3 0
        
        Friday 23rd May 2014 11:01 GMT 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.
        
        0 0
        
        Friday 23rd May 2014 09:50 GMT 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.
        
        0 1
        
        Friday 23rd May 2014 11:45 GMT Brewster's Angle Grinder
        
        @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.)
        
        0 0
      2. Friday 23rd May 2014 08:24 GMT 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.
        
        3 0
        
        Friday 23rd May 2014 13:45 GMT 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 0
      3. Friday 23rd May 2014 12:18 GMT 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?
        
        0 0
      4. Friday 23rd May 2014 12:44 GMT 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.
        
        0 0
        
        Friday 23rd May 2014 16:04 GMT Paul Hovnanian
        
        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.
        
        1 0
        
        Friday 23rd May 2014 18:25 GMT Michael Wojcik
        
        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.
        
        2 0
      5. Friday 23rd May 2014 23:42 GMT 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.
        
        0 0
2. Friday 23rd May 2014 09:37 GMT 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.
  
  0 0
  1. Friday 23rd May 2014 12:27 GMT Phil O'Sophical
    
    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.
    
    0 0
    1. Friday 23rd May 2014 18:20 GMT Michael Wojcik
      
      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.
      
      1 0
3. Friday 23rd May 2014 18:30 GMT Michael Wojcik
  
  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 0
Thursday 22nd May 2014 16:36 GMT Daniel B.

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

4 0
1. Friday 23rd May 2014 00:30 GMT Chris 244
  
  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".
  
  6 0
  1. Friday 23rd May 2014 09:56 GMT 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'.
    
    2 6
    1. Friday 23rd May 2014 18:15 GMT Ken Hagan
      
      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".
      
      1 0
    2. Friday 23rd May 2014 18:48 GMT Michael Wojcik
      
      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,¹ 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.
      
      ¹Bonus 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 0
2. Friday 23rd May 2014 18:35 GMT Michael Wojcik
  
  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".
  
  1 0
Thursday 22nd May 2014 16:45 GMT Zmodem

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

0 11
1. Thursday 22nd May 2014 17:53 GMT Ken Hagan
  
  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.)
  
  8 0
  1. Thursday 22nd May 2014 22:48 GMT Anonymous Coward
    
    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?
    
    3 0
    1. Friday 23rd May 2014 00:28 GMT Zmodem
      
      read inbetween the lines of most releases and statements the software world hands out, its mean opensource as well
      
      0 5
    2. Friday 23rd May 2014 11:45 GMT 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 :-(
      
      2 0
      1. Friday 23rd May 2014 23:33 GMT Anonymous Coward
        
        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!
        
        1 0
2. Friday 23rd May 2014 08:25 GMT 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.
  
  5 1
  1. Friday 23rd May 2014 12:23 GMT 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...
    
    2 2
    1. Friday 23rd May 2014 18:17 GMT Ken Hagan
      
      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.
      
      1 0
  2. Friday 23rd May 2014 18:53 GMT Michael Wojcik
    
    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 important¹ as the years of cryptanalysis of the published algorithms, particularly those in wide use like the MD4/MD5/SHA famiily.
    
    ¹Obviously 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.
    
    1 0
3. Friday 23rd May 2014 12:54 GMT Stoneshop
  
  ZModem
  
  Ah, you still haven't learned to write relevant and coherent comments.
  
  Kindly fornicate off and decease.
  
  1 1
Thursday 22nd May 2014 17:20 GMT 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...

0 0
1. Friday 23rd May 2014 15:58 GMT JassMan
  
  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.
  
  0 0
Thursday 22nd May 2014 17:37 GMT Anonymous Coward

Double fail

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

0 0
1. Thursday 22nd May 2014 20:04 GMT 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
  
  0 0
Thursday 22nd May 2014 17:47 GMT Destroy All Monsters

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.

2 0
1. Friday 23rd May 2014 12:31 GMT Phil O'Sophical
  
  sophisticated, proprietary hashing and salting technology
  
  That'll be crypt(1), then?
  
  1 0
Thursday 22nd May 2014 18:13 GMT Kevin McMurtrie

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.

0 0
1. Thursday 22nd May 2014 20:12 GMT Ben Liddicott
  
  Re: Seasoning
  
  Salt should be cryptographically random.
  
  0 0
  1. Friday 23rd May 2014 19:00 GMT Michael Wojcik
    
    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.
    
    1 0
2. Friday 23rd May 2014 18:57 GMT Michael Wojcik
  
  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".
  
  1 0
Thursday 22nd May 2014 18:20 GMT Jan 0

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 0
1. Thursday 22nd May 2014 18:33 GMT Alister
  
  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!
  
  8 0