Note, however, that the Android version can only read KeePass 2 databases, not write them. The limited processing power of mobile phones also means that it takes much longer to decrypt a database than on a computer.

That said, KeePass is a fantastic application. Your database can also be easily synced with Dropbox, or a similar tool.

Keepass2 defaults to 6000 rounds of "key transformation" on your .kdbx file to slow down brute-force attacks. This parameter is tunable on a per-file basis. (see also: keepass docs), but is high enough to make brute-force more expensive but still cheap enough for really, really weak devices.

If you're syncing a kdbx between a pc and a reasonably powerful smartphone (eg: with dropbox), you can safely turn this up quite a bit! I've found that at a million, it takes about 2 seconds to load the kdbx on my htc incredible (much less than it takes to enter the password!), and is still imperceptible on a pc. The brute-force resistance you get doing that is probably worth using!

I should have mentioned that it varies depending on the number of transformation rounds your KeePass database is set to. I boosted mine from the default to 7722240, which takes 6.3 seconds to open on my desktop computer, but 30+ seconds on my mobile.

1.) No. Not at all. Please never do this. The chance of forgetting to log out is too high. I would recommend just browsing to the online vault at lastpass.com and then logging in with 2-factor.

2.) Lastpass won't come between your phone and your google account. Assuming you're using 2-factor on the latter, which I hope you are, you will simply need to generate a new app-specific password for your phone if switching ROMS. Lastpass is only remembering your standard google password.

3.) That's up to you. Lastpass is 256AES encrypted and no employee has access to your vault. Do you trust your banking website with your info? If so, lastpass should be comparable. That being said, be sure to a.) enable 2 factor b.) disable log-ins via TOR c.) disable log ins via every other country but yours d.) have a fucking strong master password

4.) Yes. Your backup can be exported in plaintext for a full listing. I would just dump that in a truecrypt container and call it a day.

5.) Because the mechanics of consumer segmentation and demographic insight generation have incentivized the proffering personal data in return for a marginal discount in price and time. Either that or we're lazy.

1.) What do you mean by logging with 2-factor? I'm assuming that means I'll have to get Premium? I've been reading up on the long manual on LastPass and I can basically do a copy + paste or something along those lines if I login to the vault if I'm on a public computer right? How does the One-Time-Pass work if I'm on the public computer already?

2.) I know LastPass is only remembering my standard google password, but if I don't know it because it's complicated, wouldn't I need access to my password in order to login every single time I reinstall a new ROM?

3.) What's disabling logins via TOR do? Disabling logins via every country except mine sounds amazing. How strong is strong lol? My KeePass Master Password was like 30 characters long with only symbols numbers and letters, but it was incredibly hard to remember.

4.) That sounds fantastic.

5.) <_<

6.) What would be the easiest way to login to Windows Applications? I know premium has the application, but would the easiest way basically be to go into the vault and copy + paste?

7.) Sorry for all the questions. You've been incredibly helpful. How long have you been using LastPass?

Check out using a Yubikey with the Lastpass account for 2-factor login. No need to carry around onetime use passwords on a paper, you have a never ending supply of them on your keyring with it. It can also store long static passwords, good for encrypting laptop drives.

Google offers Google Authenticator. A smartphone app for 2-factor-authentication. You insert your regular password which should not be in Lastpass and a PIN generated by the app. You can use Google Authenticator for 2-factor-auth with other services as well. You can use it with Lastpass for example (the app will display a second PIN for lastpass). Or you can use it on your linux desktop/server. You don't need premium to use Google 2-factor with lastpass.

Use 2-factor on your Google account and your password doesn't need to be that strong. Also.. just stay with a ROM that works ;)

Here is the background on the TOR option (especially this comment). A strong password contains upper- and lowercase letter, numbers and symbols and is long.. very long. I'd go for more than 12 chars, more than 20 even. There is a relevant xkcd on password strength.

For #2, an application specific password will not work for the gapps package. It will make you log in using two factor authentication through a web portal. You'll need to either have the code sent to another number or use an authenticator app on another phone than the phone you're flashing the ROM to, or you'll need to make sure you have a list of the current backup codes available. I keep a list of backup codes in my wallet and on me at all times, and I cross them out as I use them.

2.) I know LastPass is only remembering my standard google password, but if I don't know it because it's complicated, wouldn't I need access to my password in order to login every single time I reinstall a new ROM?

If you're using 2-factor on your google account (which you should be), then you'll need to log in with a computer and generate an app-specific password for the phone. So you use lastpass to remember the password, and log in via computer.

2 factor is the Google Authenticator.... look up details on how it works, and if you're often resetting your phone, you'll want to have a paper backup. Remember to cross the numbers off the paper as they'll each only work once.

A good "intro" to LastPass is Leo Laporte and Steve Gibson's "Security Now" podcast #256. That will give you an idea of what you can trust and why.. then if you're paranoid like me I suggest looking into it on your own as well.

Specific answers:

Don't install the plugin on machines that aren't yours, use their website or use your phone to look up the password you need.

You should be using a one-off google two-factor password there, not your main Google password, anyway.

LastPass only ever receives, stores, and supplies encrypted data. They don't have the keys. The answer to your question lies in whether you feel their encryption is good enough that your data is safe - I do.

You can store an encrypted offline backup or a plaintext one, it's up to you.

Yes. :)

About being confused - It's not that complicated, really. If you want to keep all your passes on hand and never have them encrypted and stored in the cloud, use KeyPass or Password Safe. If you are okay with an encrypted blob living in the cloud, use LastPass + Google Two factor or a Yubikey. LastPass has some features above and beyond just storing passes.. for instance, I like using their audit tool that scores you on a number of criteria, like if you are reusing passwords and if you've generated random passes for all your accounts. If you're on the fence, try listening to the SN podcast I mentioned and make your choice from there.

TL;DR: Use LastPass + two factor, and additional two factor wherever else you can (paypal, ebay, Google, etc.) Use Keypass if you don't want to put encrypted data into the cloud for some reason.

It's funny that you mention Security Now. I'm watching it as I read your comment right now. BTW, I've read this a few times, but for #2, what do you mean by one-off? Does that essentially mean have a different Google Email for Security purposes?

No, when you enable two factor on Google accounts, for devices that don't support two factor you have the ability to generate a 16 character random password just for use on that device. You can then revoke the password from your Google account if you want/need to. So, that was really a two part recommendation - you should be using Google's two factor, which means you should be using that special password for your Android, which means you don't have to remember it and neither does LastPass. You just revoke the old one and generate a new one when you reload your phone.

I use the chrome plugin, and the IOS app and I like it a lot. All my passwords are now complex and unique. I highly recommend it.

I don't know about security of the application, but I was impressed with how they handled the issue they had a tear ago. I,e. full disclosure early and assurance that things were safe. (and I believe them!)

No, that's pretty much exactly what LastPass is. If you want to use KeePass and Dropbox this way, then you are making two assumptions: 1. you are using version 1.x (an out-dated version) of KeePass, and 2. you are trusting Dropbox not to leak your KDB file to others, and leaving it open to offline attacks, which is something Dropbox has a much worse track record at than LastPass.

If you do decide to use Dropbox and KeePass, you absolutely positively must go to Settings and up the number of AES rounds until it takes 1-2 seconds to open the KDB file, to make it harder to brute force the master password if somebody gets their hand on the KDB file.

The great thing about KeePass is, that it is not coupled to a browser. But with the auto-hotkey feature you can fill anything (forms, prompts, etc.). So you can also use it for SSH, software licenses, authentication in games (eg. Diablo III), and so on.

Yeah, I agree. That's quite nice. You can only really get to copying the password to the clipboard with LastPass for those applications.

What I meant with version 1.x is that if you want any kind of cross-platform support, you have to use that. There are no 2.x packages for many devices yet. As long as they release such, or keep the 1.x series up to date, that's not a problem, but they won't do that forever.

i tried using version 2 on linux, as i had recently switched from windows, where version 2 works really great, however it is just a port, it has no integration at all with the rest of the OS and was very clunky (similar to trying to use the gui app for GPG on windows).

so then i just did a bit of research and found keepassx, which works great, however it can not use version 2 databases, so i was fucked and had to manually copy over dozens of passwords.

You're keepass password is not known by any server, although your lastpass password is known by the lastpass server. They both have their advantages, but security-wise, I like the idea of not providing my master password to a computer that is not mine.

Lastpass could have been owned too, but nobody noticed (the files aren't as directly accessible), which is probably the only reason we know that dropbox was compromised (twice). Just playing devils advocate.

If your password is strong enough, you wont need to stretch the rounds. This is good advice, just not something you have to do in all circumstances.

If your password is strong enough, you wont need to stretch the rounds. This is good advice, just not something you have to do in all circumstances.

This is also not really correct. You would need at least 128 bits of security, which is really impossible to get with a master password unless you write it down on paper, or use a really long sentence (like two random sentences.)

Sorry for the late reply. For me it used the password I input when I registered. How does lastpass know who is authorized to login as you, if it doesn't store your password? Is there a server and a separate local password that I didn't notice? For the sake of this conversation, i'm calling hashes "passwords" too.

This is also not really correct.

Stretching rounds and increasing password complexity both increase the difficulty to crack. So brute forcing a 10 char with a few thousand rounds may be as difficult as an 11 char with 1 rounds. Keepass uses a 256-bit encryption btw. I think you don't understand or are taking into account how many bits are in a character, but that's besides the point. A 16 char (128-bit) of all 1's with 1000 rounds, is still not a strong password. It's not the bit length that matters; the guessability of the password is paramount.

The LastPass authentication process works kind of in reverse from what you're used to. Instead of you transferring your password over the wire, the LastPass server sends you an encrypted file over a TLS connection. The LastPass client then derives a (stretched) master key from your password, and tries to use the derived key to decrypt the file. If it succeeds, the file contains the master key used to encrypt your "blob", the file containing all of your LastPass data. This file is also sent to you. LastPass servers or anyone listening in never gets access to anything that isn't cryptographically infeasible (i.e. practically impossible) to break, and they never see your password, derived master key, or blob master key.

Keepass uses a 256-bit encryption btw

Completely beside the point. It wouldn't matter if it used 2048-bit symmetric encryption if the key only contains 40 bits of entropy. You also seem to be confusing bits of security with the size of a block cipher.

I think you don't understand or are taking into account how many bits are in a character, but that's besides the point. A 16 char (128-bit) of all 1's with 1000 rounds, is still not a strong password. It's not the bit length that matters; the guessability of the password is paramount.

I don't know what you are talking about. What is "bit length"? A bit is by definition either 0 or 1. I challenge you to find anyone who uses passwords with more than 128 bits of entropy. (To get estimates of information entropy in characters from English text, look for works related to Shannon Entropy.) It just doesn't happen. That's why we use memory-hard/stretching algorithms to make it take longer to reverse the process, as 128 bits of security is the minimum of what's necessary to be able to withstand offline attacks, and therefore to be able to say, "If your password is strong enough, you wont need to stretch the rounds. This is good advice, just not something you have to do in all circumstances"

Thanks for the information about lastpass. You've prompted me to do some googling and I found a number of good responses (mostly on superuser). So basically lastpast uses client-side javascript to derive a hash to login and obtain your encrypted passwords. So the master password is not sent, but the hash is. It appears that a decryption key is also generated (which also may be used to generate the hash) and kept in local storage. Attack scenarios for this are interesting to think about. Usually implementations similar to this are flawed, and the site itself stores and returns sensitive data (so all you need is access to the hash to compromise the account). It seems like this is a sound solution. The only attack I can think of is exploiting a vulnerability in the site (e.g. XSS to keylog master password), or somone with control of the webserver could modify the site to compromise your plaintext password (this would get noticed over a large scale, but is very feasible for targeted attacks). Based on this, I'd say that last pass is secure enough for ~99% of web usage (e.g., facebook), but maybe not secure enough for high-value targets (admin creds for a important website or server).

I agree that 256 bit is beside the point. I was just mentioning that as a minor correction that because you said 128 bit earlier.

By "bit length" I meant the number of bits. So each regular ASCII character has 7 bits of entropy, so that'd mean you'd have to use 19 random characters to use the full entropy. Sentences add characters, but the characters and letters are much more predictable, and I have no idea what the approximate odds of brute forcing a English sentence is. I agree that nobody remembers passwords utilizing the full entropy. I think we're roughly in agreement on all the complexity stuff: Passwords are almost always weaker than the full strength of the algorithm, but many rounds make any password harder to crack.

My description was correct. All encryption/decryption is performed locally. If a hash digest is transferred, it is only to validate you are who you say you are before the blob is sent to you and the MK is derived. It is not the MK.

I agree that 256 bit is beside the point. I was just mentioning that as a minor correction that because you said 128 bit earlier.

You need at least 128 bits of security to reach a level where breaking encryption is infeasible using silicon-based computers. The master key for a (symmetric) cryptographic cipher is usually what provides these bits of security. This has nothing to do with KeePass (or any other password manager, for that matter), but the information content of the key. You were correcting something I never said. That KeePass uses 256-bit AES is completely irrelevant.

Sentences add characters, but the characters and letters are much more predictable

I don't know how to be clearer: Passphrases with equivalent information content to passwords are easier to remember by humans, therefore you should always focus on making your password a passphrase, and to make it longer, not harder to remember (i.e. changing letters to symbols, which adds a ridiculously small amount of information entropy unless it is done completely randomly, which it never is.) The composition of the phrase should be random, like I said.

My only question was about how lastpass doesn't send the master key. I agreed with everything you've said. A productivity tip for you would be to not take correct statements on tangents on how they may not be correct in some instances. I'm sure you're familiar with cryptanlaysis and realize there are patterns in the English language (e.g., Q is almost always followed by U). It's not hard to pick apart a statement. No need to reply (no question here).

True, it's less secure to brute force should the data leak. But this assumes that 1, dropbox leaks my account/file, 2 someone finds that file and 3, has the time/energy/know-how to program something to do this. While there's always better file security, higher encryption, etc etc, it's still a crap shoot. It's easier to hijack individual accounts directly from the vendor through simple phishing on a phone than to hack into things. At this point, the only reason I use Dropbox is because it's universal. If there was a better way to store the safe so I could hit it from anywhere, I'd totally do that. Some sort of truCrypt mobile app would be awesome, but I just don't have the programming skills to pull it off.

Lastpass is more of a browser based pw manager. As I understand it, it's a snap in or add/on for things like Firefox or Chrome. It's great, but for a Systems Engineer like me I'm using 4 different computers between the office and home, plus my iPad and iPhone. Just from my personal accounts I have a few hundred records, and adding in anything for work and I'm doubling that. I simply have to have something with me on a mobile device, for systems that I don't have a browser. It is true, I have to use an older version of the database, but that doesn't really make a difference to me. It's more important to have secure passwords that are constantly up to date on every single device I have than to worry if it's version 1 or 2. For me it's been the solution for a few years and through two jobs. It may not be the best, I'm always looking for better. Hell I had to convert from PassSafe to KeyPass because Password Safe didn't have a mobile application a few years ago. You can't be totally obsessed with the encryption levels and personal security, because you're only as secure as your vendors. Case and point: Mat Honan's recent hack story. It's a balance between convenience, efficiency, and security, in all senses. There's no right/wrong way.

Lastpass has free standalone apps that can be used instead of the browser (if you just want to look at the passwords or add stuff). I use Lastpass Pocket on my Linux desktop. For my mobile devices I use bookmarklets. Whenever I need to log in somewhere, I go to the bookmarks and pick "lastpass". Done. These bookmarklets also work with unsupported browsers, of course.

Contrary to popular believe, Lastpass works offline. It only tries to sync your password-database with lastpass.com when there is an internet connection. This goes for the browser plugins and the apps.

With Lastpass Pocket I regularly create securely encrypted backups of my passwords. The support for Google Authenticator (on- and offline) is another bonus for me.

Hmm well from my research so far there are iphone and android apps for Lastpass (subscribers only) which takes care of most mobile devices. There are plugins for most browsers to automate logging into sites and generating passwords etc, but the website itself is very similar to Keepass' interface once you've logged in. Add in the fact that it supports 2 factor authentication and I'm actually leaning more towards using Lastpass to cut out the hassle of having to manage the Keepass files myself.

Good to know, I was unaware that they'd come out with apps. I'll certainly check it out now. I'm not totally crazy about Dropbox since they will give up your file contents with a warrant and their data isn't encrypted (even though my db is).

FWIW, I too was interested in potentially simplifying my password management process by switching from Keepass to LP. Unfortunately, it did not.

LP, as you said, is primarily browser based. If you are storing accounts for various systems, application, etc that aren't websites, then, for me at least, I found the LP safe to be very cumbersome. It was awkward to manage accounts that weren't added automagically by the browser plugin.

With the release of LP2, they added the ability to store attachments to entries. It has limited support for storing non-account data such as SSL pfx files or scanned images of passports, due to everything being stored on their servers. At least that is the statement they are offering.

One MAJOR limitation I ran into was the ability to associate a single account to multiple sites. While the help says to use equivalent URLs, it didn't work in my experience. I am sure to some degree that was my unwillingness to "make it work", but I shouldn't have to kludge my way around. Keepass's ability to do references is king and a necessity for me.

Perhaps my bias comes from being used to Keepass's behavior, but with the inability to associate multiple sites to a single account, such as a domain account, and the LP WebUI being very unfriendly, I couldn't get LP to work for me.

It could, but that's a hell of a lot of work. It's easier to spoof support at gmail or other probable contained password vendor sites. I was just told LastPass now has mobile apps, so I may switch, I'm not a huge fan of Dropbox's unencrypted give your crap to the feds style.

Depends on your expectation. The password db is encrypted with a base password. But you can also use a password file to open your DB which would provide 2-factor, or store it inside something like a TruCrypt file, providing two password levels, but that seems like a pain in the ass.

I used to use lastpasss but when I recevied this email last year in May I imediately wiped my account and never went back.

Dear LastPass User,

On May 3rd, we discovered suspicious network activity on the LastPass internal network. After investigating, we determined that it was possible that a limited amount of data was accessed. All LastPass accounts were quickly locked down, preventing access from unknown locations. We then announced our findings and course of action on our blog and spoke with the media.

As you know, LastPass does not have access to your master password or your confidential data. To further secure your account, LastPass now requires you to verify your identity when logging in. You will be prompted to validate your email if you try to log in from a new location. This prompt will continue to appear until you change your master password or indicate that you are comfortable with the strength of your master password.

This incident and the way they handled it are actually the reason why I use lastpass. Plus, we verified its security at my department. It is doin exactly what they say and they are jumping through hoops to secure the whole process. Because of the way lastpass works, there never was any actual danger for the users through this anomaly.
Edit: Here's a comment from a lastpass employee answering the same question.

Exactly. They were upfront about it, before they had confirmed what had happened, whereas with the Dropbox email leak thing they were like "uh, someone will get back to you in a while..." plus they had the whole any password will work to login thing. So given in both cases that either Dropbox+KeePass or LastPass are storing heavily encrypted (they don't have access to the key), I'll take LastPass' paranoid full disclosure response over Dropbox's questionable handling of security. I would not keep critical sensitive files on Dropbox without encrypting them.

Keep in mind, however, that in either case, someone getting access to the encrypted archive just gives someone a heavily encrypted blob that they then have to brute force. If you're entrusting your passwords to anyone without encrypting it and not providing the keys to anyone else, you're asking for it.

Please back up this assertion. Dropbox has a horrible security track record, and an offline attack on a KDB file with a less than optimal password (which is what 95%+ of people have) is much, much worse than an online attack on a service that employs exponential backoff.

Additionally, LastPass only authenticates you and sends you your encrypted blob; it never decrypts your blob on the server side. To do something like what you're suggesting, they would have to update the browser add-on to intercept your password, which is certainly possible, but highly unlikely. They have a very good argument for resisting requests from law enforcement since their product can't currently do what they would be asking.

Well, if you go that far that you want to use KeePass, the for goodness' sake use a strong password. I like to use twitter messages as password. So mine is 48 characters and easy to remember (eg. "@kateperry: you're a bad, bad singer. please stop!!!!")

That is not a cryptographically secure password, though. (Also the complexity is irrelevant compared to the length -- it's better that you ditch symbols and case completely if it means you can remember another word.) You absolutely have to be sure the number of AES rounds in your KDB file is so high that it takes too long to perform a dictionary attacks, because sentences that make sense have inherently less information entropy than ones that don't. Yours only protects you against naive brute force attacks, not language-based dictionary attacks. It's better than a sentence straight out of a piece of literature, but not by much.

"corner classroom football bigger which chest" (which is a collection of words picked truly randomly from a wordlist or dictionary) would be a much more secure passphrase because an attacker has to try every possible combination of words. The difference in information entropy is astounding -- something like 90 bits of security vs. 40. Diceware is a great site for this -- please check it out.

No, quite the opposite: you are getting an inflated and false sense of security from its length, for very similar reasons that people think their 7 and 8, or even 10-character passwords are secure just because they substituted some of the characters for symbols. In reality it makes almost no difference.

Passphrases consisting of random words are surprisingly easy to remember, especially compared to random passwords. Try it! The randomness, or entropy, is what really matters.

This is nothing new. Diceware has existed for decades, and it builds on Shannon's information entropy. It has nothing to do with paranoia, and everything to do with actual security. These things, not the encryption algorithms, are the reasons people get owned.

Alternatively, if you don't like random passphrases, then the best thing you can do is to write down a relatively long (20-25 chars) totally random string of lowercase characters, and keep it in your wallet. If you're thinking about adding uppercase characters or symbols, then you should be making it longer instead.

I agree there is more entropy with 8 random words than 8 words in a phrase. I'm just saying the amount of phrases, including punctuation and symbols and the difficulty of developing an algorithm that could generate a dictionary of all the possible phrases using common phrase structures is still secure enough.

Comparing to a 8 character password. With numbers and caps there are about 62 possible characters. Using a dictionary attack narrow that down to variations of those characters for the 172,000 words. This significantly reduces the space of 628.

Now take a 8 words in a password phrase. If it was random it would be 172,0008. Then reduce it down to all of the possible phrases? How many phrases can you make out of a space of 127,0008 (it's actually much larger than that if you include symbols, numbers, and capitalization)? How many phrase structures are there? Incorrect capitalization, incorrect grammar, incorrect punctuation, multiple sentences, run-ons, substituting symbols for letters, using names, acronyms, etc.

If you use standard phrases with simple sentence structure like the quick brown fox jumps over the lazy dog then you might have something to worry about. But someone dictionary attacking the OP's password with today's computer systems I find it unfeasible.

Then also consider the attack would most likely start out with a standard dictionary attack before even trying a password phrase attack of phrases with 2-7 words.

Now take a 8 words in a password phrase. If it was random it would be 172,0008.

Except those aren't randomly chosen from a list of 172,000 words. "a", "you" and "are" are three of the 50 most common English words. "bad" and "stop" are two of the 1000 most common words and singer is one of 5000 most common.

Yeah, I was trying to explain how large the key space would be if it wasn't reduced by using phrases. I guess that distracts from my point because I can't calculate the size of what the key space would be if I were using a phrase for comparison. But the starting key space is enormous.

I don't disagree with you that it's stronger than a shitty password; I am just arguing the same point you are. By not sampling randomly from the key space, you are drastically reducing the number of guesses somebody has to make. This is the reason entropy is so amazingly important in every aspect of cryptography. A passphrase consisting of 5-6 randomly-chosen words is significantly more secure than a real sentence consisting of 8-9, even if you add symbols and make it "complex," just the same as dj4cbawdJE is significantly more secure than ||1ghtr1der2012#

I agree that you have less chance of being owned with your phrase than a password, but that is only because the most commonly-used tools employ a naive brute force technique -- so this is closer to security through obscurity than security. You are hoping that nobody has or builds a tool that tries common phrases with common symbol pre- and suffixes. (When you were presenting the figures, you were assuming that you'd need to test the whole character set naively, e.g. for every position, but this is almost never necessary: it's almost always something you've app- or prepended to the password itself, or a common substitution, e.g. a -> @, or s -> 5, so the space of possibilities is reduced significantly. An attacker can try the most likely possibilities first and the more unlikely ones later.)

As for infeasibility: in cryptographic terms, something is only considered infeasible (for now) if it grants more than 128 bits of security today, or 256 bits when quantum computers become viable. For something like AES you'd need a 128-bit key, at least, which none of the passwords we've been discussing even come close to --but such a password is clearly impractical. That's where the key strengthening and derivation comes in -- in KeePass it uses the AES block cipher to iterate over the master key (which is 256 bits IIRC) a user-definable amount of times, e.g. 100,000, so that it takes much longer to brute force the master key, which isn't by itself infeasible (again in the cryptographic sense.) Others may use similar or stronger approaches. LastPass, for example, uses PBKDF2-HMAC-SHA256 with a user-definable iteration count. Tarsnap, a "backup solution for the truly paranoid," uses Colin Percival's memory-hard derivation function scrypt, which is extremely hard to parallelize.

On a related note, I find this table from the scrypt paper (PDF) to be extremely enlightening. It too touches upon random chars vs. random text vs. non-random phrases.

I agree that you have less chance of being owned with your phrase than a password, but that is only because the most commonly-used tools employ a naive brute force technique -- so this is closer to security through obscurity than security.

I'm not saying it's security through obscurity. I'm saying it might not be a trivial problem, like solving CAPTCHAs aren't trivial, or like integer factorization is not trivial.

Even then, if it was a trivial problem the point I'm trying to make is that it's secure enough even if it significantly reduces the key space, it's still large enough. At least for me.

I'm saying it might not be a trivial problem, like solving CAPTCHAs aren't trivial, or like integer factorization is not trivial.

I agree. I just think it's important to distinguish between impractical and infeasible. By the way, "integer factorization isn't trivial" -- for now! The quantum prophecies bode of much entertainment!

At least for me.

I guess that depends on what your definition of secure enough is. For most purposes I tend to agree, but not for disk encryption. If you're expecting the data you're encrypting to be secure in 10-30 years, which isn't an uncommon requirement at all, then you may end up disappointed.

Diceware is a nice site, but I find it easier to remember fewer uncommon words than many common words. So I took the aspell list for my language, converted it to lowercase and removed duplicates. That way I got a list with half a million words in it. Then I randomly selected words from it, using /dev/urandom as a rng.

Yeah, that works. Only note is you should use /dev/random, not /dev/urandom, but that is probably just me being over-paranoid. (urandom seeds itself with previous high-entropy input and behaves like a normal pseudo-random generator when it can't generate enough entropy from device timings, etc., to avoid blocking, possibly for a long time.)

Okay, if that's not enough for your purpose, just mention some other twitter account in your message. I don't think twitter handles (of your friends) are in dictionaries ... Or you could add some hash tag like #unconfhh2012 (-> "unconference hamburg 2012").

Nothing stops me from making one. This is security through obscurity, not security, something that can only be obtained by choosing the key randomly. You don't need to think about who has a dictionary and who doesn't--it's a simple numbers game. The more information entropy you have, the harder it will be, guaranteeably (lest for some unforeseen technological advance), to guess the key.

Sorry. I thought OP was asking if they should choose Dropbox+KeePass or LastPass, but that combo was just mentioned elsewhere in the thread. Of course you're right, if LastPass' blobs are compromised and your KDB isn't, it's safer. I'd argue that LastPass strikes a better balance between secure and convenient for most users.

Tin hats aside, can someone explain why storing a KeePass database on Dropbox as a means to synch is secure, while encrypting passwords in the LastPass add-on and sending that blob to a LastPass server (as a means to synch) is a problem? Both DropBox and LastPass have had security breeches recently. Thanks

I use 1Password on OS X (and KeePass on Windows), but REFUSE to store the database on any 'cloud' drive. If I really need to get into my passwords remotely, I will use LogMeIn with a strong password (and some other defensive measures I won't discuss here) via my phone to access the software remotely.

DropBox is NOT secure, and I personally will never trust online services such as LastPass with this much sensitive material (maybe use it for a few non-critical services if you really need something).

I also don't store any sensitive data on my smartphone (maybe I'm too paranoid, but I know I never have to worry when I read about the latest password breach etc).

Regardless of everything else, if you're really intent on being secure in your digital life, you won't be disclosing any sensitive information to a machine that's not yours.

Don't login on public machines; don't login on borrowed machines; don't login on rented machines (this probably exists). If you don't own it and have full control over everything that's been done on it and everyone that's used it, it's not safe (at least by the paranoia standards of this community).

I use keepass. It's great. The database is encrypted (obviously) so you can just put copies wherever you need them. Once you've got your passwords in, it just a matter of re-copying the database around every once in a while when you change the passwords. It even has a merge feature if you get out of sync. I was worried about it not having any sort of automatic way to pass the database around, but honestly, it hasn't been a big deal at all.

On number 3 and 4:

Frankly, I wouldn't trust LastPass. If you have to send your password to LastPass, then LastPass has your password. Period. And LastPass is a company, under United States influence, which basically means you can't trust them at all. I always think "What if my future ex-girlfriend works at the FBI?"

On number 5:

It's so awesome not having to remember (more than one) passwords anymore. Hell, I could randomize usernames too if I felt like it. I've got the confidence of knowing that every single site I use has a different password based largely on their maximum length and complexity allowances.

Frankly, I wouldn't trust LastPass. If you have to send your password to LastPass, then LastPass has your password. Period.

Oh look, someone else making claims on the Internet without actually doing research.

LastPass does not have your password. Here's how the process works:

You generate your authentication key by taking your username, concatonated with your password, doing a SHA-256 hash of it locally, and sending it to LastPass. This is used to authenticate you and prove you are who you say you are.

However, this only gets you your encrypted blob of data. You see, the key that is actually used to encrypt and decrypt your data is never, ever sent to LastPass. You take this previous hash, and concatenate your password again, then hash this. This hash is the hash that is used to decrypt your vault, make additions to your vault, etc. When you send data back to LastPass, it is encrypted with this key, that again, LastPass doesn't have. All hashing and decryption/encryption is done locally in your browser with magic (JavaScript).

So, what do we have? If someone hacked LastPass, and gained full access to their database, all they have is your encrypted data, and your auth key. They can only use this auth key to get your encrypted data, so let's look at that. They have to take auth key, concat a password to it, and brute-force until they crack the encrypted blob of data. By using the auth hash as a prepend, (again this is email+password) we are inherently providing a unique salt to each key, and thus a hacker would be forced to brute force or dictionary attack SHA-256 for each individual key. They cannot simply rely on SHA-256 rainbow tables or what have you.

If I went over anyone's head, please reply and I can clarify some more.

EDIT: For those curious, LastPass's biggest vulnerability is if you don't use two-factor authentication. A single bad computer signed into LastPass and keylogged user:password, and suddenly somestupidsite.com you wanted to access isn't the only thing owned, they can go sign in as you and get your PayPal too. D:

All hashing and decryption/encryption is done locally in your browser with magic (JavaScript).

Ah, yes, everything is done very securely in my browser, with code that LastPass sends me each time I go to use their service.

So, what do we have? If someone hacked LastPass, and gained full access to their database, all they have is your encrypted data.

This isn't at all the attack vector that people are concerned about. The concern lies with the fact that you're putting all your faith in the Javascript that LastPass is sending you. Let's examine a few different scenarios:

LastPass is untrustworthy: Just yesterday, I was reading how anonymizer and other similar services were owned by a company that turned out to be behind the TrapWire surveillance system.

LastPass is being forced to silently comply with government directives: See: HushMail.

LastPass is incompetent: Their Javascript tackles a lot of very difficult crypto. They implement their own AES and SHA. They refuse to use a common library for this, and they insist on implementing it themselves. The risk for having vulnerabilities in how they implemented it is astronomical - there's a reason most programs use an SSL library - this is really hard stuff.

I just pulled up their main Javascript library (even in just going to sign up, there were 6 other Javascript files that they were using, but most functions all live in one file). That file is over 10,000 lines long. And, like I said, full of incredibly complex code. Here's an example:

That's a really simple function, but a PITA to code-review. The best part? The version I was looking at was last modified 2 weeks ago. Even if they're not being malicious, code-reviewing their code is a gargantuan task.

LastPass would help to assuage many concerns by taking a few simple steps:

Using a well-known crypto library, or at least moving their crypto code to a separate file. That file should rarely need to change.

Following the code review, having the outside firm publish and maintain a list of hashes for the code that it's reviewed.

LastPass has steadfastly refused to submit their code to a code review, despite the fact that people have repeatedly asked this. Not only that, but when people have started doing research on their code, they've blocked them from the service. They've had a history of vulnerabilities, as well as a suspected intrustion. The vulnerabilities were basic issues, and somehow we assume that they implemented AES correctly!?

tl;dr LastPass is a shit company, that fails to obey industry best-practices, promises an independent review of their code only after they've been hacked, and then fails to deliver on that.

I knew about their suspected intrusion, but coding your own AES in javascript? That's horrible.

AES is a well-known algorithm, with thousands of test patterns to verify the correctness of an implementation. There is absolutely no risk in writing your own AES implementation, assuming you are a competent program, and that you test your code; it just makes code review longer (compared to using a third-party trusted library), but that's it.

When people say "don't write your own crypto" they really don't mean "don't implement AES". They mean "don't design your own crypto protocols", "don't combine algorithms in funny way", "don't believe that using AES on a UDP packet is enough for being secure". That's totally different than rolling up your own AES.

The real problem with crypto is designing the correct protocol, not writing a bug free implementation. Some algorithms might be harder to get right, but you usually get thousands of test patterns, and you can even have an openssl-based alternative implementation to produce an endless set of patterns to verify your implementation against.

I'm not specifically suggesting that you should always write your own AES; I did it several times but I play a lot with crypto and security, so I think it's normal. Using OpenSSL (that, minds you, is not available in Javascript) is a good option most of the times.

My point is that you shouldn't infer anything about the security practices of LastPass by the mere fact that they have a hand-made AES implementation. You must consider that, whoever LastPass hired, should have far higher crypto skills than being able to write a AES implementation, so that thing by itself contributes nothing to a discussion where we evaluate whether LastPass is to be considered secure or not.

Ah, yes, everything is done very securely in my browser, with code that LastPass sends me each time I go to use their service.

Again, users are meant to install a browser plugin, so the code is stored in your computer. It's updated every time the plugin is updated, not every time you access last pass. For instance, when you access the lastpass vault through the browser plugin, you're decrypting and browsing the local decrypted copy of your vault. You can verify that you can do it without an active Internet connection.

LastPass would help to assuage many concerns by taking a few simple steps:
1. Using a well-known crypto library, or at least moving their crypto code to a separate file. That file should rarely need to change.
2. Hiring an independent, outside firm to perform an in-depth code review.
3. Following the code review, having the outside firm publish and maintain a list of hashes for the code that it's reviewed.

I agree with these points.

Not only that, but when people have started doing research on their code, they've blocked them from the service[1] .

You are being disingenuous. They blocked an IP from which they saw activity trying to find XSS vulnerabilities. I think this is just normal maintenance; it is exactly the same that running an automatic service (ala fail2ban) to ban SSH bruteforcers, or running snort to block people trying to blindly exploit known wordpress vulns. There is absolutely nothing wrong in having a security policy in place to block possible abusers of your service, including those trying to exploit vulnerabilities. They even de-blocked the IP after a short exchange of emails.

Your sentence was written in a way to imply that someone was reading and studying the javascript source code and his account was terminated because of this, which would be a terrible action, had it been done.

Again, users are meant to install a browser plugin, so the code is stored in your computer.

Users aren't "meant" to do anything. LastPass' browser plugins are a recent development, designed for convenience and not for security. Their bread and butter is the web interface. You can't tell me that someone at LastPass went "We should do this as a browser extension, so users will have to do a code review less frequently."

You are being disingenuous. They blocked an IP from which they saw activity trying to find XSS vulnerabilities. I think this is just normal maintenance; it is exactly the same that running an automatic service (ala fail2ban) to ban SSH bruteforcers, or running snort to block people trying to blindly exploit known wordpress vulns. There is absolutely nothing wrong in having a security policy in place to block possible abusers of your service, including those trying to exploit vulnerabilities. They even de-blocked the IP after a short exchange of emails. Your sentence was written in a way to imply that someone was reading and studying the javascript source code and his account was terminated because of this, which would be a terrible action, had it been done.

This is the article that I read, I just linked to the longer version, but only skimmed it. You're right, the version I read wasn't very accurate and was much more sensational.

That being said, I'm still not thrilled with the way they handled that. I'm also worried that this is something that they implemented the day after they got a black eye in the press for XSS vulnerabilities. I get the feeling that they care more about their public image than any actual security.

Are you really suggesting that using a browser plugin is not LastPass primary usage? Because there is a big download button on the main page, that brings you to the plugin download. I think it's obvious that a program meant to save website logins integrates with your browser, so I maintain that users are meant and well happy to download LastPass browser plugins.

LastPass' browser plugins are a recent development,

Source? The oldest LastPass changelog entry avilable online already mentions a browser plugins, and I would say that it's at least 2008.

designed for convenience and not for security.

That might be true, but it's irrelevant since it also brings security.

Their bread and butter is the web interface.

I'm not sure why you think so. I never use their web interface... actually, I use it only to change settings of my account. Otherwise, I really never use it, because there is no reason for doing it.

You can't tell me that someone at LastPass went "We should do this as a browser extension, so users will have to do a code review less frequently."

I won't, but it's irrelevant, because it still has that effect. Notice that it's not just "less code review" but it's a night-and-day thing. The fact that it's a browser plugin with auditable releases and updates makes it on par with any piece of software in your Linux distro of choice, for instance. When you run security code on Ubuntu, for instance, you are fully trusting Canonical because you download their signed binary code, including eg. openssl. You do not know whether they put a backdoor, were forced to do so, or a single employee was corrupted to insert it. You're trusting both them and a third-party security experts to audit the code and make sure there's nothing wrong. It's exactly the same with the LastPass extension, it's just the for-profit company behind it that changes.

Were LastPass a web interface, it would be totally different, because it would be an order of magnitude easier to attempt a targeted attack. But it's not the case.

My point is that the level of trust you need to have with LastPass is exactly the same of what you have with a linux distro. You are free to decide whom you trust, but you just shouldn't think that a browser plugin is inherently more insecure and/or inherently requiring an unacceptable level of trust.

I think it's obvious that a program meant to save website logins integrates with your browser

I think I just have a different way of thinking about things. That statement right there makes my skin crawl. Personally, the last thing I want my password manager to do is integrate with my browser. I really don't trust my browser. I don't have plugins enabled or any extensions. Hell - I don't even allow Javascript to run on any site by default. I'm perfectly happy copying and pasting my passwords in.

You're trusting both them and a third-party security experts to audit the code and make sure there's nothing wrong. It's exactly the same with the LastPass extension, it's just the for-profit company behind it that changes.

Well, no, that's exactly it. LastPass refuses to submit to a third-party code audit. OpenSSL has had this audit done. Chrome has a half-decent bounty program encouraging audits. It's LastPass' stance against the third party code review that I have an issue with.

My point is that the level of trust you need to have with LastPass is exactly the same of what you have with a linux distro.

I completely agree. Personally, I use KeePass. I had to do a code review of it at my previous job, and I haven't updated in the several years since then. I'm fine with that because I don't need to update it. If I were using the LastPass extensions, however, I would need to update, since the browsers seem to keep breaking compatibility with it, and they keep releasing new versions.

I think it's obvious that a program meant to save website logins integrates with your browser
I think I just have a different way of thinking about things. That statement right there makes my skin crawl.
Personally, the last thing I want my password manager to do is integrate with my browser.

I respect your choices. I'm just saying that whoever uses LastPass will have an extension in their browser, and thus you must evaluate the security of LastPass by taking this into account. The argument "but they can serve you tainted javascript just in one request" doesn't apply.

You're trusting both them and a third-party security experts to audit the code and make sure there's nothing wrong. It's exactly the same with the LastPass extension, it's just the for-profit company behind it that changes.
Well, no, that's exactly it. LastPass refuses to submit to a third-party code audit. OpenSSL has had this audit done. Chrome has a half-decent bounty program encouraging audits. It's LastPass' stance against the third party code review that I have an issue with.

My point is that OpenSSL is trustworthy, but you don't download, compile and run OpenSSL from openssl.org; you run a binary shipped to you by Canonical. So you're trusting Canonical not to patch OpenSSL (or rather, to patch it correctly, because they do patch it), which is totally different from trusting OpenSSL as an open source project. I maintain that trusting Canonical Inc. and trusting LastPass Inc. isn't any different from a security perspective; you're welcome to trust either or none, but I don't think that either is inherently more secure.

Really, I'm not pushing for LastPass; I respect whoever decides to have different security trusts than mine. I just think that we should shoot down arguments where LastPass is inherently more insecure than running KeePass over OpenSSL shipped by Canonical. I concede that it's somehow more insecure because of a smaller level of openness and auditing, but I think it is well possible to change the way LastPass is politically run. Cloud isn't insecure by design; you just need to pay attention, as always.

My point is that OpenSSL is trustworthy, but you don't download, compile and run OpenSSL from openssl.org

Well, I do, because I run Linux From Scratch, but while OpenSSL might not be an issue, the other things I've installed don't have the same audit trail.

Really, I'm not pushing for LastPass; I respect whoever decides to have different security trusts than mine.

I agree, of course. It's just that I consider /r/netsec to have a different trust requirement than other subreddits. The debate I usually have with my peers is if you should even use a password manager; suggesting using something like LastPass would just be a joke. So yes, different security trusts, I just assume that other security professionals on /r/netsec would have a similar range of trust - that's why I was so surprised to see anyone actually advocating LastPass.

If cloud backup can be done securely (see tarsnap), I don't see why a password manager couldn't. Technically, it's exactly the same thing. I think LastPass comes relatively close to it, they would just need to come opensource with their browser plugins and they would be damn close, because the basic structure of the system does hold water under multiple points of views.

I understand your comments about trusting them to provide you with Javascript. However, isn't this the case for everyone? Google could start sending specific users passwords on GMail accounts due to government intervention. PayPal as well, or any other site that accepts a password. When is the last time you viewed the code before signing into PayPal, or similar, to ensure that the developers hadn't slipped in a "drop the password into a var and send it to us" piece of code? Did you read the source for the last KeePass update? It only has one major developer, if not one developer period.

At some point we have to trust someone

and somehow we assume they've implemented AES correctly

giovannibajo has an excellent point below me on this

Overall you have some good points, but I don't think it's possible to be completely "trust no one" online anymore. Pretty much any password based authentication service can be owned if the developers want to. I keep my tinfoil hat off myself.

I'm not overly concerned about security for my online accounts. Like you said, they're online, so I don't keep my sensitive data there.

I just think that people should be aware of the risks. Yes, anyone could do this for online accounts. But when you start storing corporate account information there, it's a different story. Working on that side of security, I couldn't care less if a user's GMail account gets popped. Luckily they were using a password manager, and they had different passwords for each site, right? But if they're storing corporate credentials off-site, we need to have a talk.

see hushmail. They also did client side encryption, even with java instead of javascript. Then some government agency told them they needed access to someones email, so the next time they logged in they got a special java applet which sent his password back. Same could easily be done with javascript.

Not exactly, because with lastpass you login though a browser plugin, whose code is fixed and stored in your computer (not served in every request). It's not that easy to do a targeted attack because they would have to push a new plugin release to all lastpass users and some might notice. I do know of a friend who audit all updates to the lastpass plugin, for instance.

Obviously if you login on their website, all bets are off; just don't do it, if you have a trust issue.

From a security perspective, it doesn't really matter if it gets updated automatically or with user intervention. It's still a single, reproducible, auditable, world-wide release, that makes it impossible to run a targeted attack by serving different code to different users, or different code in any different request.

LastPass' extension has the whole javascript source code in clear. There is an (optional) small binary blob that implements secondary features not exposed to the javascript API.

Interesting. That does make it a lot more secure but, ultimately they can change the code on you and capture your password. I'm not saying it's likely, just possible. I'm thinking that if the authorities really wanted to and had the warrants they (or a 1337 h4x0r) could take advantage of the silent updating to change just your extension, capture what they want, change it back, and you would be none the wiser. Again, this is highly unlikely to be used against the average user and a hypothetical that I just dreamt up, but personally I want full control over that much (potential) personal information.

It's impossible for them to silent-update just your extension. Especially once Chrome starts enforcing that all extensions must be shipped and updated through the Google Web Store (they're getting there). And even before that, they don't have a way to know that it's your browser that it's checking for updates.

Much of the source code is available even if it's not open source. It's the same for most/all JavaScript-based browser add-ons. The only component that would be hard to audit is the binary blob, but that is optional.

It is a fact that LastPass doesn't send your password over the wire. It works similarly to the Secure Remote Password protocol, although it does expensive key derivation on the client side (which you can and should tune in your Account Settings until it takes a few seconds to log in) using PBKDF2-HMAC-SHA256.

KeePass is open source/free software but is not an open project. There is only one developer who works on the project on his harddrive and tosses a source tarball online when he feels like it. Having no transparency in its development process is very bad and locks out anyone from contributing to the project without having to fork it in its entirety.

I haven't, many have with Wireshark and by analysing the Javascript code. They also have a page on their website where it will show you every step in the hashing process, allowing you to see what is going on, and even generate a hash by hand and use that to decrypt your database rather than giving a password (spoiler: it works).

Are you concerned that they will change the Javascript to suddenly send your secret hash over to them as well, and not just use it locally?

I wasn't being a dick, I just don't appreciate when people in/around the field of computer security dismiss something (or advocate it) without doing a bit of research. Many, many security companies have looked into LastPass and posted blogs on it, they also have full disclosure on their site (though arguably this is harder to find).

In my last reply I also missed mentioning they add their own random salt on the DB side too.

Yes, you can see your passwords on their website. Again, you've done the decryption of your password vault locally with JavaScript and hashing of your master password/email address.

EDIT: Directly from their site:

We use firewalls and best practices to protect the servers and service, but our best line of defense is simply not having access to data even if someone got in. If LastPass can't access it, hackers can't either. A large number of PBKDF2-SHA256 rounds are utilized to create your key, with the ability to increase the number of rounds over time to render brute forcing your master password impossible.

A hash is a one-way function, it's easy to go one way, but hard to go the other way.

As I explained, a hash is sent to the server that matches a hash they have in their database (after they do some fancy stuff to make it harder to crack your password from this hash). However, this hash CANNOT DECRYPT YOUR PASSWORDS. All they do is send your password vault, still encrypted, back to you. You then make a different hash and locally decrypt it. This different hash is never sent to LastPass.

Imagine a bank with safety deposit boxes, where each person's box had a private room all to itself. Feel free to imagine whatever you want in this room, waterfalls with dolphins and shit would be my preference.

The key you give to the bank gets you into that room. The bank has one too, they need to get in there sometimes. Inside the room is the deposit box, still locked. Only you have the key to this, the bank can't open it. Even if someone showed up at that bank with a gun, they could swim with the dolphins, but they can't get into your box without lockpicking it.

I'm aware of what a hash is, and I'm perfectly willing to accept your explanation for normal operation when you have local software installed, be it a plugin or whatnot.

HOWEVER, when viewing your passwords ON THEIR WEBSITE, in an internet cafe as they put it, are the passwords still decryption locally and then injected into the page you're looking at or are they sent from their server?

OK. I made a test account and looked at it, and yes, it does look like they are doing everything locally in Javascript. Fair enough. That leaves the only disadvantage as essentially re-downloading and re-confirming your trust in the software every time you visit the site.

They used to have a webpage where you can go step by step through the process, showing where the hashes are, etc, and you can input a SHA-256 hash of your email+password by hand instead of the password to verify this is what is being used to authenticate you. You can also test this hash against the encrypted blob you get back to see it won't decrypt it, and you can go ahead and manually generate your next hash (that has concat password again rehash sha256 on your own, use that hash) and you can see that it will decrypt your password DB.

It's a bit burried on their site, try Google, I'm at work and I've spent enough time on reddit today.

I've also seen blog entries where security researchers got their hands dirty with Wirehsark + looking at the js code.

A few things I found about KeePass that was really annoying was that sometimes I would try to use the hotkey to autofill and it would autofill in the wrong place and it was just awful (one time my brother was behind me).

I really did like that I could easily copy + paste onto applications on my platform, but I think LastPass can do it too.

I tried to use the firefox plugin, but it wasn't very intuitive. There were some sites that just refused to autofill.

I've only used it as copy and paste, no autofilling or stuff like that. I tend to want to know where the password is, be able to clear the clipboard, that kind of stuff. Copy and pasting is a lot faster than typing it out, and it doesn't add any of that complexity.

It's pretty simple: Don't login in front of someone else the first time you use a service with KeePass. Login forms don't change every day, so you can just adjust the autofill options for this entry and it will work in the future.

Going between different roms can have unexpected consequences with backing up and restoring system settings. I have never had a good experience with backing up system settings with TiBu. I let google handle that.

Application settings (no system apps) are usually okay to be backed up.

You can decompile LastPass and use a kernel mode debugger on it too. Unless you build KeePass youself don't have any guarantee the files installed with the installer they offer are built from that source.

In the abstract sense, nothing. In reality, all of the keepass code is opensource and easily reviewed. Also, you can validate it isn't making network connections through a variety of basic monitoring techniques.

Just because the code is open source doesn't mean that is the version they use to build the exe in the installer. Also network monitoring techniques wont do any good if the installer puts a rootkit on your computer to hide network connections.

I also checked on their site, the hashes they have for the files are for the zip and the setup.exe. I couldn't find a hash to compare the installed exe vs the exe built from the open source code.

And someone wouldn't notice if LastPass was insecure? You can decompile and debug LastPass too. Sandboxing and building from the source code will only protect people who do that, which is the a very small number of people. If you don't build the source code your self you don't have a guarantee that the source code was used to build the executable you are using.