Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

KeePass [keepass.info] is really the best tool for handling passwords. Open source, crypted database, easy to use (CTRL+B for username to clipboard, CTRL+C for password), contains grouping and generates safe different passwords for every site. It's actually a great example of a well done open source project.

Using an online service for something like your passwords is just incredibly stupid. It's a really well known place to hack for someone who wants lots of passwords. Backup your encrypted password container to your own place, but never something like this.

Simple - the only repository that exists for Chrome OS is the Google Web Store. It only supports Chrome applications or extensions, and Keepass has not been implemented as a Chrome application or extension. You don't need to use the Web Store, but Chrome OS still only runs Chrome applications or extensions.

Looks like you just found out the big problem with Chrome OS. You barely run Linux then, in the sense of being a distro that has WILDLY different build requirements from all other desktop distros. It's almost like saying, "Sure I run Linux, the DD-WRT distro, just give me a link".

IMHO, it's better to never write them down and just generate them algorithmically based on the site's domain or a memorable keyword. Several years ago I just kept a tabula recta [lifehacker.com] in my wallet. Nowadays, you can use something like SuperGenPass [supergenpass.com].

Personally, I wrote my own equivalent of SuperGenPass that addresses some of the security concerns [stackoverflow.com]. That said, I use PassPack [passpack.com] with a tediously strong password to keep a backup in case I inadvertantly break compatibility, and a copy of the generator on my website.

They will only get lots of passwords from people who are foolish enough to select a brute forcible password as their master. Picking a simple master password is stupid. Storing encrypted data on the internet isn't necessarily stupid.

Not to mention, if you generate random passwords for every service, it's not much labor to just go ahead and generate new ones when situations like this occur. All LastPass clients automatically update to use the new passwords, no big deal.

I've used both pwsafe and KeePass... I never cared for KeePass, and had just moved all my passwords back to pwsafe when I found out about LastPass, got convinced it was "secure enough" by Steve Gibson, and never looked back.

The big deal for me at the time, once past the "secure enough" thing, was that pwsafe was Windows only. KeePass did not have a means of syncing passwords that might be changed on multiple machines. Even with pwsafe, I had to carry my database around and sync it with my other machines

I use Password Gorilla [github.com]. Written in Tcl/Tk, has standalone downloads for Linux, Mac OS X, Windows. Been using it for the last few years, works well for me.

From the wiki:Password Gorilla is a Tcl/Tk application which can run on Linux, Windows and Mac OS X. The source files written are supposed to be compatible between platforms. They are tested to run on Linux kernel (less than or = to) 2.6.30.5, Windows XP, Windows 7 and Mac OS X 10.6. So it is possible to work with this password manager in heterogenous en

I'm very happy with KeePass. It enabled me to have a poor man's authentication token:

Instead of using a password to unlock the database, I use a key file stored in an SD card. I mapped one of my laptop's multimedia buttons to the hot key that triggers the global auto-type feature, so that when I need to authenticate somewhere I just have to press that button and hit enter to unlock the database. The authentication is done automatically and the database stays unlocked for 5 minutes. When I leave the computer

"Using an online service for something like your passwords is just incredibly stupid. It's a really well known place to hack for someone who wants lots of passwords. Backup your encrypted password container to your own place, but never something like this."

Hey, retardo, don't you think the people who made it know this? All of your password are stored on their system ENCRYPTED. They are encrypted on YOUR computer, with a password only YOU (not them) before

I use KeePass primarily because it's the only one I've found for Android that works cross-platform anywhere the way I'd like to use it.

There are quite a few that do this. mSecure (from mSeven software) works on Android, iPhone, Windows, Mac, and allows you to sync all your devices with your own computer.

It will also support backup and restore to any regular file, and the database is encrypted. So your drop box plan continues to work.Its is password protected rather the key-file protected. You may argue the wisdom of that, but too often the keyfile approach fails because those get stored on the same device.

I guess the main benefit of the GP's method is that you won't actually need a "safe" to store your passwords. You can re-generate the same password anytime, anywhere, as long as you remember the master password and "reason."

However, a problem with this implementation is that generated passwords will be hexadecimal only. Not really much entropy per character there (4 bits vs. 6.5x bits for all ASCII printable chars). Just extend the generated password length, I guess.

Well on windows (and perhaps linux as well), any character put into the keyboard message loop is widely available to any application. Key loggers can get these as well, because they are simply messages, which every process can eaves drop on. (Which is how key-loggers usually work, even the hardware ones).

The data stored on LastPass is, with the exception of the salt and email address (neither of which are sensitive), encrypted. The only risk is to those who used weak "master passwords", and then the bad guys would need to identify which of the encrypted data blobs they got (assuming they actually got any) are weakly secured. This is not exactly easy.

From the LastPass announcement:

In this case, we couldn't find that root cause. After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server). Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed. We know roughly the amount of data transfered and that it's big enough to have transfered people's email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn't remotely enough to have pulled many users encrypted data blobs.

In short:- Not many, if any, encrypted data "blobs" were taken. This means that the odds of an offline attack on the encry

***f****f****f******f******f**f**f*f*******f******f*f**f******f******f********We noticed an issue yesterday and wanted to alert you to it. As a precaution, we're also forcing you to change your master password.

We take a close look at our logs and try to explain every anomaly we see. Tuesday morning we saw a network traffic anomaly for a few minutes from one of our non-critical machines. These happen occasionally, and we typically identify them as an employee or an automated script.

In this case, we couldn't find that root cause. After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server). Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed. We know roughly the amount of data transfered and that it's big enough to have transfered people's email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn't remotely enough to have pulled many users encrypted data blobs.

If you have a strong, non-dictionary based password or pass phrase, this shouldn't impact you - the potential threat here is brute forcing your master password using dictionary words, then going to LastPass with that password to get your data. Unfortunately not everyone picks a master password that's immune to brute forcing.

To counter that potential threat, we're going to force everyone to change their master passwords. Additionally, we're going to want an indication that you're you, by either ensuring that you're coming from an IP block you've used before or by validating your email address. The reason is that if an attacker had your master password through a brute force method, LastPass still wouldn't give access to this theoretical attacker because they wouldn't have access to your email account or your IP.

We realize this may be an overreaction and we apologize for the disruption this will cause, but we'd rather be paranoid and slightly inconvenience you than to be even more sorry later.

We're also taking this as an opportunity to roll out something we've been planning for a while: PBKDF2 using SHA-256 on the server with a 256-bit salt utilizing 100,000 rounds. We'll be rolling out a second implementation of it with the client too. In more basic terms, this further mitigates the risk if we ever see something suspicious like this in the future. As we continue to grow we'll continue to find ways to reduce how large a target we are.

For those of you who are curious: we don't have very much data indicating what potentially happened and what attack vector could have been used and are continuing to investigate it. We had our asterisk phone server more open to UDP than it needed to be which was an issue our auditing found but we couldn't find any indications on the box itself of tampering, the database didn't show any changes escalating anyone to premium or administrators, and none of the log files give us much to go on.

We don't have a lot that indicates an issue occurred but it's prudent to assume where there's smoke there could be fire. We're rebuilding the boxes in question and have shut down and moved services from them in the meantime. The source code running the website and plugins has been verified against our source code repositories, and we have further determined from offline snapshots and cryptographic hashes in the repository that there was no tampering with the repository itself.

Again, we apologize for the inconvenience caused and will continue to take every precaution in protecting user data.

In this case, we couldn't find that root cause. After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server). Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed. We know roughly the amount of data transfered and that it's big enough to have transfered people's email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn't remotely enough to have pulled many users encrypted data blobs.

Gotta be honest here: Even if this WASN'T anything, if I had trusted my passwords for everything to some other party like this, I'd very well want them to be more than a bit paranoid in protecting it. So I say, kudos.

This is really exemplary action; they're not entirely certain that there even is a threat to customers' data, but they take all the precautions they can and inform their users of the possiblity of a threat. We can only wish other companies were as careful!

They're re-encrypting (or hashing) the password 100,000 times (basically a big loop) before they end up with the version they store for the user.

This makes it very computationally expensive to try and crack passwords. In the big scheme of things, it might only take a second or so for a modern CPU to perform this operation 100,000 times, however if someone is cracking passwords automatically, going from potentially tens of thousands of cracking attempts per-second to only one or two per-second makes a brute

Either you have an excellent memory or you're reusing the same password on multiple sites. If you're a mere mortal, like me, and you don't want to reuse a few passwords over and over again, you need a password manager.

Or you could use the same password-salt on multiple sites, with a unique, easy-to-remember base for each site. For example, my base could be "RjZg#sl1", which would produce RjZslshg#sl1 for slashdot, RjZgglg#sl1 for gmail, RjZtwttrg#sl1 for twitter, etc.

You need to memorize eight characters, and one process (remove consonants from service name), and you've got a secure, unique password for each website. It's not perfect - if someone is specifically targeting you, and gets two or three of your passwords in c

I have a slightly different approach. I have one password with 2 variations I use for most sites, but I have a third password that I only use for my e-mail account. Thus even if I lost access to one of the other sites I could still reset the password via e-mail and then I'd proceed to change the passwords on all the other sites I use, too.

Either you have an excellent memory or you're reusing the same password on multiple sites. If you're a mere mortal, like me, and you don't want to reuse a few passwords over and over again, you need a password manager.

Or, If you're a code like me, you wrote a javascript:sha1( salt + get_master_pw() + host );bookmarklet [ubuntu.com] which enables you to use the same password everywhere, but generate a site specific hash that you enter into the PW field.

Note: I would use someone else's PW hasher plugin, but I can re-code my own system from scratch in any URL bar, text editor, command shell or programming language to re-gain access to my codes in a worst case scenario...

"...advised its customers to change the password they use to access the service..."

Wow, I only have to change one password? Whew, that's a relief! For a minute there, I thought I had to change them all. (/sarcasm)

Consolidated password management works, as long as YOU maintain 100% control. Use Truecrypt locally for securing your password file. Sync the encrypted file to the cloud of you want an "online" backup.

Consolidated password management works, as long as YOU maintain 100% control. Use Truecrypt locally for securing your password file. Sync the encrypted file to the cloud of you want an "online" backup.

LastPass is basically the exact same thing. It's encrypted locally and sent to them AFTER encryption. They don't store the plaintext passwords. The danger is the same either way if a user doesn't use a strong enough password.

LastPass is basically the exact same thing. It's encrypted locally and sent to them AFTER encryption. They don't store the plaintext passwords. The danger is the same either way if a user doesn't use a strong enough password.

The problem I have with their site is that they use the same password to encrypt your password database that you use to log into the site. So, if somebody puts the equivalent of a keylogger on their server they get everything.

They should have one password to authenticate to the server, and another password to encrypt the passwords that get uploaded to the site. In fact, you'd only need both when logging in from a client that doesn't use Lastpass, since the latter could safely store the former.

1. Get root on webserver.2. Edit login page. New login page has the user enter their password into a box, and send the password in the clear to the server (fully protected by SSL of course).3. Send copy of password to wherever.4. Do whatever the previous secure implementation did with the users's password and pass that into the authentication routine so that the app works fine.

SSL/TLS only protects you against attacks to data in-transit. Now, SSL client certificates would completely preve

If you go with LastPass - you get great integration/ease of use and you can access your passwords from any place with internet access. For that ease of use, you run the risk of LastPass's servers being hacked and hoping that the encryption they use is strong enough and that your password isn't vulnerable to a dictionary-type attack.

If you take your approach - you get limited integration/ease of use and you can only access your passwords from any place where you can access gpg.

No, because if you encrypt your own material you hold the keys. If you let someone else do it, they hold the keys. And who knows how good they are at keeping them safe.

You always know how good you are (or, how bad you are) at keeping your own keys safe.

Keepass(x), gpg encrypted file backup with the gpg keys backed up on a CD in a bank safety deposit box. (and if you're daring, a copy of the key on a usb jump drive you keep on your person at all times)

Don't forget the copy you keep in your head and enter whenever you need to access the safe; you're vulnerable at that point to a key logger.:)

With LastPass, you encrypt your own material, LastPass never holds the keys. LastPass works exactly the same as KeePass: there's a binary blob that is kept on an Internet-accessible server, and you download the blob and decrypt it locally. All they have is an encrypted version of your key, just like in your Linux/Mac/Windows desktop system. Yeah, maybe they could

Seriously. I can't stand the thought of someone else having every password I use for everything. I use a system to generate passwords in a semi-hard-to-predict fashion for services I don't really care about, and have a number of 'strong' passwords for things that are important. Those passwords (and the information on where to use them) gets stored in a TrueCrypt container that I periodically update and sync with my VPS and my Dropbox. The TrueCrypt volume key isn't recorded anywhere - it's in my head, which

Its just like anything else, be smart about it. It doesn't force you to use it for every site so don't. I use it for all my forums, some email, some social sites, basically anything that if stolen, doesn't matter, well over 100 sites. I don't use it for anything connected to any part of my finances, credit cards, or my big selling or buying sites (ebay,amazone,etc), a much smaller 10-20 sites. Using it this way is worry free and does simplify things. You still have multiple passwords, but at least the

It isn't as bad as it seems, and kudos for them to be upfront and open about it:

We noticed an issue yesterday and wanted to alert you to it. As a precaution, we're also forcing you to change your master password.
We take a close look at our logs and try to explain every anomaly we see. Tuesday morning we saw a network traffic anomaly for a few minutes from one of our non-critical machines. These happen occasionally, and we typically identify them as an employee or an automated script.
In this case, we couldn't find that root cause. After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server). Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed. We know roughly the amount of data transfered and that it's big enough to have transfered people's email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn't remotely enough to have pulled many users encrypted data blobs.
If you have a strong, non-dictionary based password or pass phrase, this shouldn't impact you - the potential threat here is brute forcing your master password using dictionary words, then going to LastPass with that password to get your data. Unfortunately not everyone picks a master password that's immune to brute forcing.
To counter that potential threat, we're going to force everyone to change their master passwords. Additionally, we're going to want an indication that you're you, by either ensuring that you're coming from an IP block you've used before or by validating your email address. The reason is that if an attacker had your master password through a brute force method, LastPass still wouldn't give access to this theoretical attacker because they wouldn't have access to your email account or your IP.

This is a good story, but the story isn't that they were definitely hacked. It's entirely possible that the anomalous data transfers they mentioned were caused by internal testing and not properly documented, based on the limited information we have available.

I'm a LastPass user and last night I was forced to change my master password. Initially I was a bit suspicious about the request, so I took all the measures to make sure it was a genuine request from LastPass.com. When I was sure it was a safe request, I changed my master password to something even stronger than it was.
I'm a paying user for their premium services, and in my opinion I must admit that their reaction to that casualty and possible data breach has been very open and reasonable. I would be very

Maybe you store your passwords in your huge brain, but if you're using something like KeePass or 1Password on your computer, you're still storing your passwords on the internet. Granted, they're not in an amalgamated "hack me" target like LastPass, but it's not like they're securely offline, taped to your monitor.

They weren't "hacked", they saw a tiny anomaly in their network traffic (which honestly, most companies wouldn't even have noticed), and decided to notify you about it and handle it in the most paranoid way possible. It's such a small thing that I wouldn't have expected most companies to even tell anyone it happened.

But somehow them behaving in a very commendable way for a security company has blown up into an absolute PR nightmare for them, with sites lik

If you haven't the vast majority of you will be logged in using 'offline' mode so you can still use LastPass like normal and get back to your day, only syncing of new password should suffer (and you'll see the bar)

Fuck the PSN hack, who gives a shit about that, 99.9999999% of the time banks will allow me to simlply refute credit card fraudulent purchases. It costs me NOTHING but inconvienience.

I was a loyal foxmarks user, then xmarks, then they told me I had to use lastpass.Well look how this has worked fucking out then, I am PISSED - jesus fuck is there some important passwords in my account.

Being that your passwords haven't been compromised (at least based on the most recent information they've posted), I don't see how this is remotely an issue.

As they state on their site, "We know roughly the amount of data transfered and that it's big enough to have transfered people's email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn't remotely enough to have pulled many users encrypted data blobs."

It's so secure, I might not even know the password i use. I like it better that way, don't have any written down passwords, don't have any "cloud" storage of a password vault, don't have an encrypted file/database of passwords i use.

Sure, on the occasion I have to retype in passwords till I get the right one, but not that often.

Using a program for passwords, reminds me of this little true story:

My buddy kept all his phone numbers on his Atari 130XE, which I said, "What if you don't

Of course not. IT departments have been cut to the bone and the budget to hire an outside security auditor is now the CEO's bonus for cutting IT costs. The few SysAdmins left working in most IT departments are too frazzled to pay much attention to security and management mostly looks at any spending on IT security like buying insurance - we won't spend that money until after the house has burned down because before then there's we don't care.

The company admits they had 'unexplained' traffic with more data coming from the database than going to the database. They were unable to track down the source of the traffic and have started some password changing strategy for the users.

My climbing gym web site was hacked recently and used for a phishing scam and general fun for the script kiddies. The annoying part is that, even with absolutely nothing critical to lose (other than site up-time due to our host taking the site down), there is still a lot of work to do just to make sure they didn't leave another back door. I know this because...I missed the backdoor. They dropped a nice PHP script on the server that gave them unrestricted access.

Anyway, the point is that just thinking one has been breached is shitload of work for someone, and probably a good reason to beat the bad publicity of a full breach with a press release that at first sounds worse than it well may be.

In olden times that was probably reasonable, but I've got well over a hundred passwords on file. It's hard enough to get around and change more than a few from time to time, but trying to actually remember them? Good luck without some sort of utility.