211–220 of 231 posts
Earlier quoted context omitted.
Is that open source too or how would you know about their security? Cannot find it: https://github.com/AgileBits
When you went looking for it, did you try Googling for [1password file format]?
But couldn't the implementation of parts of the service being flawed? (and you cannot know as it is closed source)
Earlier quoted context omitted.
How are they cracking the 40+ char random alpha numeric password on my box? With fail2ban in place, and it's on a random port.
That answer does not inspire confidence. 1) Random port is not helping against a specific attacker. Get a real firewall 2) Fail2ban is not a real firewall 3) Keys only, no passwords. 40chars is nothing compared to a strong rsa key with a 40char password on it
Earlier quoted context omitted.
The array comparison? It's literally the textbook example of a timing sidechannel. Though I won't speculate if it's a real problem here, since I have no idea what data is being compared.
Do you care about that kind of side channel for an offline vault? If your adversaries are on your box while you operate your vault, then you have already lost because they will also have keyloggers, strace, etc.
Earlier quoted context omitted.
>who knows why this message was plastered everywhere when "they" decided to call it quits. Because "they" are no longer updating it and at some point there will be security issues that will go unfixed. Same thing with Windows XP. It didn't immediately fall apart when support ended, but we were pushing so hard for it to go away because it would never see another security update. It's just really, really bad practice t…
Windows XP was not audited, and it's been full of bugs since day one, with new vulnerabilities every month, year after year. And it has a huge attack surface. That's hardly comparable to TrueCrypt. TrueCrypt WAS audited and yes there is a risk of some serious vulnerability being found in the future, but at least we know there's none known for now (not publicly, at least). That same risk, that some serious vulnerabili…
Use TrueCrypt, it's probably pretty secure still. A year from now, I might not be able to say the same thing. Two years from now will be even worse. It will get harder and harder to keep recommending it as time goes on and it hasn't been updated. But if anyone is wondering why they posted that message, it's not cryptic. It's just forward-compatibility. Eventually there will be a vulnerability, and it will not be patched.
Earlier quoted context omitted.
I never claimed or implied that latest design of 1Pass repository is worse or even security-equivalent to KeePass. I simply pointed out that 1Pass team has made their share of mistakes (plural), so I have as much trust in their competence as, likely, in KeePass team. With author trust being a non-issue (humor me in this assumption), we must look at facts & evidence only. Both 1Pass and KeePass repositories are well-s…
You start out in a reasonable place but then rhetorically overplay your hand: I'm pretty sure they do HMAC their IV, (a) because they say they do and (b) because there are open source implementations of their file format that (i) do the HMAC verification and (ii) would not work properly if they weren't HMAC'ing their IV. You can check right now: it took 2 minutes to find the Python code that computes the HMAC. It's a…
I would argue that KeePass and its loyal and vast userbase does not in fact seem to know they need a better cryptosystem (and ideally better implementation). My HN post was intended to bring this to everyone's attention.
"I'd still use KeePass before I used LastPass, though, and would still use KeePass before I used no password manager!" - so would I.
Earlier quoted context omitted.
Considering your background and experience, do you have a recommendation for personal level password management?
I use and like 1Password.
cheers, Paul
Earlier quoted context omitted.
You start out in a reasonable place but then rhetorically overplay your hand: I'm pretty sure they do HMAC their IV, (a) because they say they do and (b) because there are open source implementations of their file format that (i) do the HMAC verification and (ii) would not work properly if they weren't HMAC'ing their IV. You can check right now: it took 2 minutes to find the Python code that computes the HMAC. It's a…
Guilty as charged on the HMAC'ing the IV verification - bad example for a still-valid point. You still don't know whether closed-source code is using the rng properly, sending "debugging information" containing your private data to the mothership when internet is available/stars align, creating plaintext temporary files in %temp% folder (accessible by all other apps), etc, etc. Ie. there is a myriad of things the imp…
As for the other things, like using the rng properly and whatnot, no, you can't really check that stuff. But your implication here is that open-source apps can be trusted because you can verify that stuff, and I don't buy that. Unless you yourself are a crypto expert that's qualified to carry out such an audit, and you have the spare time / inclination to perform a full audit of the app, then there's no reason why it being open-source should make it any more trustworthy. Perhaps if some independent trustworthy third party performed the audit you could then decide to trust it, but closed-source apps can still be audited, it just requires the help of the app developer to do so.
And of course even if the app is audited (whether open- or closed-source), that audit will only really verify the particular version that was audited. Future changes may introduce vulnerabilities again, so unless someone qualified to do so is constantly auditing all future changes, then you can't really trust it anymore, since your trust model is that the source needs to be independently verified to be trusted.
On other hand, if your trust model is that you determine whether you trust the people involved to get it right, then it doesn't matter if the app is open- or closed-source, as long as it's developed by the right people. Granted, it can be hard to determine whether someone can be trusted to get it right without independent audits, but speaking personally, I take tptacek's "I feel like they know what they're doing" recommendation as carrying a fair amount of weight. I certainly would welcome an independent audit of 1Password, but I recognize that I can't really expect a closed-source software vendor to hand the source of their flagship application to a 3rd party.
(if it isn't clear, I'm a happy user of 1Password)
Earlier quoted context omitted.
Guilty as charged on the HMAC'ing the IV verification - bad example for a still-valid point. You still don't know whether closed-source code is using the rng properly, sending "debugging information" containing your private data to the mothership when internet is available/stars align, creating plaintext temporary files in %temp% folder (accessible by all other apps), etc, etc. Ie. there is a myriad of things the imp…
Some of the things you've mentioned here you actually can test for even on closed-source implementations. It's pretty easy to trace the activity of the app to see if it creates temporary files or does network activity so you can you investigate that stuff. As for the other things, like using the rng properly and whatnot, no, you can't really check that stuff. But your implication here is that open-source apps can be…
I have ample factual evidence that both KeePass and 1Pass authors had made multiple crypto blunders. Both score low on my trustworthiness scale.
It's extremely difficult to prove crypto correct, but it's very easy to discover that it's wrong. Open-source software allows one to discover crypto mistakes. It does not allow one to prove crypto correctness.
On the other hand, if you use closed-source software like 1Password, you cannot discover crypto mistakes regardless of your level of crypto expertise.
Once we start making crypto choices based on tptacek's, schneier's, or anyone else's feelings about someone seeming to know what they are doing and getting a 'good vibe', the dark age of crypto will truly be upon us. Many folks trust & use PasswordSafe not because Schneier wrote it (I hope) but because it is open-sourced. Many folks trust & use Tarsnap not because Percival wrote it, but because the client is open-sourced.
That said, the author of KeePass responded to all the discussions here over on the project forum at SourceForge.
Since a lot of people aren't willing to even visit SF anymore, his notable responses were:
The header validation was fixed as of 2.20 in 2012
The singleton safety he was aware of, and it was only instanced prior to any threading of the application, so there could never be a thread safety issue. He has fixed this anyhow as the performance impact was minimal as of 2.30
The installers available via SF mirroring are signed by the author, so SF can not ever mess with them. They have no concerns about SF doing anything to their project.