Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security

LastPass Reporting a Security Breach, Including Authentication Hashes and Salts 206

Posted by samzenpus from the one-password-to-rule-them-all dept.
hawkeyeMI writes: LastPass, the popular password manager, has been hacked. The company says that the “vast majority” of users are safe, and has posted a notice which begins: "We want to notify our community that on Friday, our team discovered and blocked suspicious activity on our network. In our investigation, we have found no evidence that encrypted user vault data was taken, nor that LastPass user accounts were accessed. The investigation has shown, however, that LastPass account email addresses, password reminders, server per user salts, and authentication hashes were compromised."
This discussion has been archived. No new comments can be posted.

LastPass Reporting a Security Breach, Including Authentication Hashes and Salts More

LastPass Reporting a Security Breach, Including Authentication Hashes and Salts

Comments Filter:

  • KeePassX (Score:5, Informative)

    by smutt ( 35184 ) on Monday June 15, 2015 @06:36PM (#49917429)

    I'd like to take this time to recommend an excellent open source project called KeePassX.

    https://www.keepassx.org/ [keepassx.org]

    It's a password vault application. Remember local applications, they run on your computer, that you physically have to be at to use(usually).

    • Why not the real Keepass?

    • Re:KeePassX (Score:4, Interesting)

      by kosmosik ( 654958 ) <kos AT kosmosik DOT net> on Monday June 15, 2015 @07:31PM (#49917735) Homepage

      > https://www.keepassx.org/ [keepassx.org] [keepassx.org]

      > It's a password vault application. Remember local applications,
      > they run on your computer, that you physically have to be at to use(usually).

      Usually Keepass and alike are used to store passwords for network services. So the computer storing your passwords in KeepassX is still networked and susceptible to attacks. Also people tend to use multiple machines (sometime even not own) so in order to use KeepassX you still need to transfer its data file somehow. You could keep this file on a pendrive probably with portable version of the app.

      So KeepassX in my opinion is less convinient to use than Lastpass - with the latter I just login to service (using two factor authentication) and access my passwords. But mind you I use Keepass only for not-so-sensitive accounts like 100+ eshops, forums and crap like thant (not financial, medical, otherwise sensitive, essential internet authentication account hubs like Google or Facebook).

      So for me in order to use Keepass would be to carry a medium with data file (which can be lost, stolen, copied) or to share the data file via some kind of authenticated network service like SFTP, HTTPS, Dropbox etc.

      I know the Keepass/local pass file way would be probably slightly more secure but Lastpass method is just more convinient.

      Oh and if I were to use password manager I would not go Keepass way - what for? Passwords are just some lines in text file. I would just use encrypted text file, shell utilities like grep and have access to it via SSH with two way authentication (I love Google Authenticator with PAM module for my private use).

      My point being that if used correctly (only for not sensitive accounts, two form authentication enabled) a trusted service like Lastpass (I find them very concerned about security - they are targeted all the time) is quite secure and more convinient that Keepass.

      Also I would love to have some offline device for my sensitive stuff like financial, medical and so on - I lone for something in form of small ipod-like MP3 player that can be fed with data and when prompted for authentication I could choose my credentials from it and display it would generate QR code with token that could be scanned via webcam to authenticate. Of coure it would be suspectible to MITM attacks and physical loss but in my opinion it would be the most secure way for using password store without sharing it via network.

      • Re: (Score:2)

        by dissy ( 172727 )

        Also people tend to use multiple machines (sometime even not own) so in order to use KeepassX you still need to transfer its data file somehow. You could keep this file on a pendrive probably with portable version of the app.

        and

        Also I would love to have some offline device for my sensitive stuff like financial, medical and so on - I lone for something in form of small ipod-like MP3 player that can be fed with data and when prompted for authentication I could choose my credentials from it and display it would generate QR code with token that could be scanned via webcam to authenticate.

        The other day I went to portableapps.com to rebuild a new toolstick when I remembered they sell pre-loaded flash drives also. Seeing as part of that purchase would support portable apps I figured I would check out the prices in their shop.

        It was then I saw they have a new (to me) encrypted flash drive that looks and reads to be pretty impressive.

        Flash drive #2, the Carbide:
        http://portableapps.com/shop/h... [portableapps.com]

        Or if you just want the drive from the source without the portable apps involvement:
        http://worldsbe [worldsbestflashdrive.com]

      • Re: (Score:2)

        by AmiMoJo ( 196126 )

        There are plug-ins for Keepass that allow you to sync your database file with a cloud service. I use Google because they support 2FA, and even if the file was somehow stolen it's encrypted.

        Keepass has one major advantage over Lastpass's encryption, which is that you can use a keyfile as well as a password. I keep the keyfile locally on my machines and my phone, and it's innocuous so even if one of them was hacked it's doubtful anyone would bother stealing it. Even if they did, how would they know which of t

      • Everything is a security/convenience consideration.

        KeePass is more secure than LastPass, if you are careful with how you store your database.
        Having your passwords as similar but reasonably strong password is more convenient, but less secure.
        Setting your password to 12345, is even more convenient but... idiots and luggage...

    • I tried it, but it was such a pain to get working on OSX and iOS that I think I eventually gave up. It seems like a great solution if you are Windows centric.

      • I've been very happy with STRIP from Zetetic. I have nothing to do with them except being a happy customer from back in the Palm days. The only thing I don't like is that they charge for their iPhone and iPad versions so I just run the iPhone version on my iPad and it works fine.

    • It that because it's a password vault, not just a simple password safe?

    • Re: (Score:3)

      by rtb61 ( 674572 )

      I would recommend that people install network alarms. All networks will have a particular set of data transmission patterns, that are accept and normal. The very first time a data packet contains a binary signature of an undesirable pattern (instruction, unexpected data transmission), that connection should be blocked at the router, a signal sent to a monitoring station and the connection either allowed to continue or blocked. There are quite simply some data packets, with their embedded binary signatures

  • Hash and Salt (Score:5, Interesting)

    by psyclone ( 187154 ) on Monday June 15, 2015 @06:38PM (#49917447)

    We are confident that our encryption measures are sufficient to protect the vast majority of users. LastPass strengthens the authentication hash with a random salt and 100,000 rounds of server-side PBKDF2-SHA256, in addition to the rounds performed client-side. This additional strengthening makes it difficult to attack the stolen hashes with any significant speed.

    Salting is nice, but when the attacker gets both the hash and the salt, they can attack specific users. Still, the 100k rounds of SHA256 seem decent.

    Would bcrypt [wikipedia.org] be any better than PBKDF2 [wikipedia.org] here?

    • Re: (Score:2)

      by dwywit ( 1109409 )

      But do they use ROT-13 as well?

    • Comment removed based on user account deletion

    • Re:Hash and Salt (Score:4, Informative)

      by blueg3 ( 192743 ) on Monday June 15, 2015 @08:33PM (#49918105)

      Salting is nice, but when the attacker gets both the hash and the salt, they can attack specific users.

      Of course they can. The entire purpose of salting is to make it so that the same password, hashed two different times, produces completely different hashes. This has two important consequences. First, it makes it basically impossible to precompute password hashes. That's a big deal compared to the "without salt" case, where rainbow tables make checking against precomputed hashes very easy. Second, if two users on a system have the same password, you can't tell without computation. Said another way, it means you need to crack passwords individually rather than in bulk. This isn't game-breaking, but it's significant when you have million-user breaches.

      All of the typical ways of storing password hashes store the salt alongside it. It's expected that an attacker that obtains the hash will obtain the salt. It's within the design.

      If you want the password hash separate from a piece of key password-validation data, at that point the extra piece of data is a secret and what you're basically making is a message authentication code. But, it's very difficult to argue that this is ever really more secure.

      Still, the 100k rounds of SHA256 seem decent.

      Would bcrypt [wikipedia.org] be any better than PBKDF2 [wikipedia.org] here?

      100k rounds of SHA256 is decent. The longer SHA2 variants are better, sure. More rounds is always better, of course. 100k is better than what most people use. But, if the decryption is always happening client-side (which it should), then ideally you can afford and should use many more rounds of SHA1. Maybe if they're using JavaScript, that limits how high they can jack the number of rounds up and still get reasonable performance on low-end devices.

      I don't know that bcrypt is necessarily much better than what they're doing. It may be, but at a "details" level, not a "major benefit" level. Both bcrypt and PBKDF2 support many rounds and prevent precomputation, which are major features.

      What would be better, if the devices they want to support can run it, is something like scrypt, which is resistant to hardware acceleration and thus much harder to crack in practice.

      • p>All of the typical ways of storing password hashes store the salt alongside it. It's expected that an attacker that obtains the hash will obtain the salt. It's within the design.

        If you want the password hash separate from a piece of key password-validation data, at that point the extra piece of data is a secret and what you're basically making is a message authentication code. But, it's very difficult to argue that this is ever really more secure.

        The hash, salt, and user name are all considered to be not secret. In a properly-implemented crypto scheme, having all of those will allow not help you to gain access to the account or crack the password.

        • Re: (Score:2)

          by blueg3 ( 192743 )

          Yes, that's what I was saying. Salting uses a non-secret nonce. You could set up some system with a secret nonce, but then it would be a different construction than "salt" (and hard to argue that it's better).

          Having access to the salt does make it much easier to crack the password. In fact, it's basically necessary to crack the password. It is still considered non-secret, though.

      • A hacker could go through all that trouble to reverse a hash but if the user changes the master password, then there's no compromise. So...the race is to have the user change passwords before the hacker hacks the hash. Should be easy to win, no?

        Also, use two-factor. Seriously. No reason you shouldn't be using two-factor.

      • Re: (Score:2)

        by AmiMoJo ( 196126 )

        Salting helps but not as much as you might hope. The cracking process usually goes like this:

        1. Try the top 100 common passwords on every user, with a few simple variations. That will net you maybe 50-60% of accounts.

        2. Check if any users are also in other, weaker or already cracked databases. Often they will be using the same password, or a simple variation of it. That gets you to maybe 80%.

        3. Sort the remaining targets by value. Users with .gov addresses at the top, then email accounts that don't support

        • Re: (Score:2)

          by blueg3 ( 192743 )

          That situation is partially the result of more widespread use of salt. It doesn't magically make bad password hard to crack (as you point out). But it used to be the case that, with rainbow tables, you could crack even moderately difficult passwords very quickly. It also adds a pretty substantial slowdown for large password breaches -- even though all the easy passwords will be cracked anyway, a factor of hundreds of thousands slowdown starts changing the "easily crackable" threshold.

        • Re: (Score:2)

          by tlhIngan ( 30335 )

          1. Try the top 100 common passwords on every user, with a few simple variations. That will net you maybe 50-60% of accounts.

          2. Check if any users are also in other, weaker or already cracked databases. Often they will be using the same password, or a simple variation of it. That gets you to maybe 80%.

          3. Sort the remaining targets by value. Users with .gov addresses at the top, then email accounts that don't support 2FA. Run more comprehensive dictionary attacks against them. Maybe use Amazon to speed the pr

    • Re: (Score:2)

      by N1AK ( 864906 )
      I always assumed the per user salt was purely to make using a hash table much harder (effectively impossible), in which case it would still be effective.
  • "We’ve commissioned a write only off-site aggregated log server which can only be accessed via the console. This will allow us a guarantee that any logging is intact." ref [lastpass.com]

  • It's a strange idea to store passwords in the cloud anyway. I use these simple scripts in Ubuntu. Could work on Mac too, and I had a Windows/Perl/batch-file version long ago:

    $ cat `which p`
    #!/bin/bash

    [ -d /media/truecrypt1 ] || t on

    # accept up to 3 arguments, and filter on all 3
    if [ -z "$2" ]; then
    grep -ni "$1" /media/truecrypt1/p
    else
    grep -ni "$1" /media/truecrypt1/p | grep -i "$2" | grep -i "$3"
    fi

    $ cat `which padd`
    #!/bin/bash
    [ -d /media/truecrypt1 ]

    • There is a bit missing in the post above:

      $ cat `which t`
      #!/bin/sh

      file=$HOME/timecode
      tcvol=/media/truecrypt1

      do=$1

      case "$do" in
      "on")
      if grep -q /media/truecrypt1 < /proc/mounts ; then
      logger -t truecrypt "$0 Starting tc: already mounted"
      exit
      fi
      logger -t truecrypt "$0 Starting

  • People need to settle down... (Score:5, Insightful)

    by gbcox ( 868098 ) on Monday June 15, 2015 @08:32PM (#49918095) Homepage
    LastPass of course is going to be a target; but if you used the product as recommended with 2nd factor authentication and not reusing your master password elsewhere you don't have anything to worry about. LastPass is handling this in a measured, logical, efficient manner - and as always, they err on the safe side. Of course, this being the internet, you have the usual suspects crying chicken little, the sky is falling.

    • Re:People need to settle down... (Score:5, Insightful)

      by j-turkey ( 187775 ) on Monday June 15, 2015 @09:51PM (#49918455) Homepage

      ...Of course, this being the internet, you have the usual suspects crying chicken little, the sky is falling.

      They're also smugly saying "I told you so" - and doing so seemingly without understanding the situation. The situation hasn't changed since the beginning: don't use the service if you don't trust the encryption. If the service is breached and the (open source, peer reviewed) encryption stands up to attack, then the threat is astronomically minimal.

  • backdoor into the encryption. It's only a matter of time before hackers locate it and fling it open to let the animals in.

    There are no secrets. There is no privacy.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Close