Coffeehouse Thread

57 posts

Conversation Locked

This conversation has been locked by the site admins. No new comments can be made.

Apparently the IPO didn't fund Linkedin enough to hire decent programmers

Back to Forum: Coffeehouse
  • User profile image
    01001001

    http://www.businessinsider.com/linkedin-hacked-2012-6

    All your passwords are belongs to Elite Hacker Group. Sony, repeat.

    The passwords were shared via a Russian hacker site

    Thanks LINKEDIN !!! That's just what 6.5 million people needed this morning. And just think of the savings!

    That's what you get for buying Ferraris instead of staffing your company and then bragging about the ROI per employee, then eating an entire Dunkin Donuts to boot.

  • User profile image
    cbae

    Generic Forum Image

  • User profile image
    01001001

    Generic Forum Image

    You lookin' at me? Are you lookin' at me???

    You know it.

  • User profile image
    blowdart

    You can check if your password was one on http://leakedin.org/

    Of course who knows if that's saving passwords and hashes ....

  • User profile image
    JuanZamudio

    @blowdart:It would be genius if the hackers put that site to get the passwords they couldn't crack.

     Edit: changed hack for crack.

  • User profile image
    Charles

    unsalted Sha-1.... That's pretty lame.

    C

  • User profile image
    cbae

    , JuanZamudio wrote

    @blowdart:It would be genius if the hackers put that site to get the passwords they couldn't hack.

    It wouldn't be really useful if they couldn't tie it to a specific email address.

  • User profile image
    JuanZamudio

    @cbae:well for what i heard they dumped just the passwords, but if they hacked the site I'm sure they already have the emails and more personal data.

     

  • User profile image
    magicalclick

    Didn't read it, but, they didn't salt each password? Hard to imagine why didn't they do it.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    JoshRoss

    , Charles wrote

    unsalted Sha-1.... That's pretty lame.

    C

    Even if the passwords were hashed with salt, if you have six million of them, you could likely guess the salt from the distribution. If you took the most common passwords, and compared it to a histogram of common passwords, you could leverage that knowledge to guess the salt. Or maybe not.

    -Josh

  • User profile image
    blowdart

    , magicalclick wrote

    Didn't read it, but, they didn't salt each password? Hard to imagine why didn't they do it.

    No they didn't *faceplam*

     

  • User profile image
    blowdart

    , JoshRoss wrote

    *snip*

    Even if the passwords were hashed with salt, if you have six million of them, you could likely guess the salt from the distribution.

    Not really, salts should, ideally, be unique. Even if they used the email address you're going to have a slow old time with rainbow tables, or precomputing.

    Even if they used a single salt it's not really guessable as far as I can see.

     

  • User profile image
    01001001

    If they used a single salt, you would take one of the accounts you know the password to and run it through a Sha1 + concat w/dictionary.

    But lets face it, for 6.5M+ leaked auth info with passwords likely duplicated across services like banks, paypal, ect... it would be way more cost effective to pay off a former employee who it can't be traced back to. Tell him he'll get a million, then right before he turns it over tell him 10k and if he doesn't turn it over, you'll give him up to the FBI.

    Especially if you're some dude in Russia. Then 10 years later when you free your jailed Lukoil/Cayman island buddies from today's generation of black hat internet degenerates, you can fund the next Mark Zuckerberg and have Silicon Valley ignore all the horrible sh1t you did and treat you like a hero. "This guy made it out of the slums of St. Petersburg (clap) by the might of his keyboard alone"

  • User profile image
    magicalclick

    , blowdart wrote

    *snip*

    Not really, salts should, ideally, be unique. Even if they used the email address you're going to have a slow old time with rainbow tables, or precomputing.

    Even if they used a single salt it's not really guessable as far as I can see.

     

    I wonder if anyone use "lossy" encryption. This may sound dumb, but, if you simply crap out the original password, like say, when user supply the password, you do some stupid

    foreach(char c in stringValue)    total += (int)c;

    And use "total" as the new password and run it through encryption. So, even if they managed to hack the entire thing. All they get is garbage password, LOLz.

    Obviously my example is bad because "PASS" and "ASSP" can both login, and the encoding is too lossy. But, basically if you can do this with balanced encoding quality, you are able to protect the user password as the encoding is lossy.

    It is not the same as typical file encryption because you don't care about getting perfect binary back. You want to make sure after you decrypt the password 100%, it is still useless.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    Sven Groot

    @magicalclick: What you're doing here is basically double hashing, and using a homegrown algorithm with no known security guarantees as the first hash. It's a terrible idea.

    Additionally, the only reason that would be any more secure than just hashing the passwords is if the hackers don't know that you're doing it. This is security by obscurity, which is also a terrible idea.

    Just salt the damn hashes, problem solved. Wink

  • User profile image
    JoshRoss

    @Sven Groot: Initially, I was thinking the salt would be small, like 64 bits, or 8 chars. Something like that wouldn't be too bad to unhash with a known password and a pile of GPUs. But if the 64bits of salt had cryptographic quality randomness or was just significantly larger, that would be more difficult.

    Either way, I wouldn't want to roll my own crypto system. If security was important enough to warrant something compute intensive, like PBKDF2, then they should have the backend system strong enough to handle the authentication load.

    -Josh

  • User profile image
    Blue Ink

    , magicalclick wrote

    *snip*

    I wonder if anyone use "lossy" encryption. This may sound dumb, but, if you simply crap out the original password, like say, when user supply the password, you do some stupid

    1
    foreach(char c in stringValue)    total += (int)c;

    And use "total" as the new password and run it through encryption. So, even if they managed to hack the entire thing. All they get is garbage password, LOLz.

    Obviously my example is bad because "PASS" and "ASSP" can both login, and the encoding is too lossy. But, basically if you can do this with balanced encoding quality, you are able to protect the user password as the encoding is lossy.

    It is not the same as typical file encryption because you don't care about getting perfect binary back. You want to make sure after you decrypt the password 100%, it is still useless.

    That's not dumb at all... what you call "lossy" encryption is just a form of hashing, including the problem with collisions.

    It's always nice to see a mind click. Impressed.

  • User profile image
    ManipUni

    The "quality" or size of a salt doesn't increase security. Salts can be stored alongside the password, they key is that they must each be unique between passwords but even one byte of unique-ness is unique enough.   

    The ONLY reason salts exist is to break/combat rainbow tables.    

    Let's go back to basics: 
     - We take a plain text password.
     - This works fine for authentication but if our database is stolen then the thief can use all of those passwords without delay. 
     - Logic dictates that what we store MUST be 1:1 equivalent with the original password so the thief will eventually be able to get a list of plain text passwords. 
     - Perhaps we can delay the thief from using the passwords in order to give our users more time to change them?  
     - Suddenly appears: One way hashing algorithms. These require computation to generate and therefore are either expensive or time consuming to compute. 
     - So we turn our passwords into a one way hash.
     - Problem: Most of our passwords are 5-8 characters long and made up of a small number of characters (A-Z,a-z,0-9). 
     - So now people start generating lists of generated one-way hashes. These lists or "rainbow tables" turn a previously expensive and slow operating into an instantaneous lookup.    
     - How do we combat these lookup tables?
     - 1: Make our passwords longer
     - 2: Add unique information for our domain (site salting)
     - 3: Add unique information per each password (user salting)
     - 4: Do 1, 2, and 3.  
     - So let's say our users look like this:
     USERNAME: BobSmith
     PASSWORD: Yellow Submarine
     UID: 10302
     - We can store their password like this:
     Hash(USERNAME + UID + PASSWORD)   
     - This accomplishes all three of our anti-lookup requirements above (length, site salt, and user salt). Which means calculating our hashes continues to be computationally expensive.
     - But keep in mind even with the salt passwords will still eventually get turned back into plain text.  

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.