171–180 of 231 posts
Have you considered submitting this analysis to the KeePass team? Or even better, analysis plus suggested code to fix the problems? As a user of KeePass this would be in your interest.
(And as a user of KeePass myself, it is in my interest to encourage experts to help that project out.)
Earlier quoted context omitted.
"Ferguson and Schneier, in their book Practical Cryptography, have argued the opposite: that MAC-then-encrypt (or MAC-and-encrypt) is the "natural" order and that encrypt-then-MAC is overly complex. The sore point of encrypt-then-MAC is that you have to be careful about what you MAC: you must not forget the IV, or (in case the protocol allows algorithm flexibility) the unambiguous identifier for the encryption algori…
I think Ferguson and Schneier got this wrong. Here's a useful table from Bellare & Namprempre: https://www.dropbox.com/s/f4gpc7shjal1nta/Screenshot%202015-... https://cseweb.ucsd.edu/~mihir/papers/oem.pdf You generally have two options when it comes to authenticated encryption: use a specialized AEAD mode, in which the details of authentication are settled by the mode itself, or use "generic composition" --- encrypt…
What about pass ( http://www.passwordstore.org/ )? No "funky file formats" -- just GPG and a convenient CLI.
There are two things that bug me about pass: * Website names are stored in plaintext filenames and directory hierarchies. No confidentiality and no integrity guarantees for those. * It uses GPG's public-key encryption instead of symmetric-key encription. This integrates well with gpg-agent but it means that you need to carry a gpg private-key file around with you instead of just remembering a passphrase.
Earlier quoted context omitted.
Considering your background and experience, do you have a recommendation for personal level password management?
I use and like 1Password.
Given the type and link to 'hamsterporn.net' I can guess you are a user of some site which may be embarrassing if exposed.
Earlier quoted context omitted.
Been using it for a month now, it's fantastic.
Do you use any syncing mechanism, eg syncing to a repo on Github ? The format should lend to using some remote git repo, but I'm still afraid of the implications of having my passwords in the wild, even encrypted with GPG.
the only people with access to the host are trusted people.
The only way ssh access works without a key is from certain trusted networks. (over a vpn only)
Earlier quoted context omitted.
I use and like 1Password.
And how do you save and sync the passwords across various machines? Edit: The reason I asked is because I wanted to see if 1Password can be more secure than LastPass. However, if you're using 1Password with Dropbox, I'd say this combination doesn't feel any more secure than LastPass. Other more secure options like WiFi sync aren't convenient enough. So, it appears there's no strong reason for me to consider switching…
With 1Password+Dropbox, Dropbox doesn't know your master password. It only ever sees the encrypted vault, and doesn't have any opportunity to intercept any plaintext. (If your password is strong enough, you could probably even get away with posting your vault on a public website.)
I have been a KeePass user for many years and I always used this in conjunction with a TrueCrypt container meaning that I keep my kdbx file inside the container. Yes TrueCrypt isn't "safe" but at this point it will take one highly motivated attacker to steal my "important" passwords. Sadly I am not aware of any audits related to KeePass but I would be happy to read one!
Earlier quoted context omitted.
Well I believe it is safe for my personal purpose but if you read the note the author left on Truecrypt website/software you can clearly read : WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues If I recall the audit was positive but who knows why this message was plastered everywhere when "they" decided to call it quits.
>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…
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 vulnerability could be found in the future, also affects all other existing encryption products, since none have been formally demonstrated to be secure.
If I can migrate today to a different product, then I can just prepare to migrate in the future but stay with TrueCrypt until such vulnerability is found, if it ever is. There is, after all, the possibility that none will be found, and it's more likely that none will be found in TrueCrypt than it is in other non-audited products. Why should I switch now?
And why would it be better today to use a product that has not been audited so far but is supposedly still being supported, instead of using one that HAS been audited even if it has been abandoned? Furthermore, currently supported products could be abandoned tomorrow too, or worse: their support could be deficient in the future.
I acknowledge that your argument has some well known heavyweights backing it. Bruce Schneier mentioned this risk about TrueCrypt recently, and then he went to recommend some closed-source solution based on its creator's good vibes. Tom Ptacek also resorted to this newfangled "vibe" method in one of his comments in this very thread. I fail to see the point in all this. Maybe I'm missing something, but I find such reasonings specious.
Edit: grammar.
Earlier quoted context omitted.
I must admit, I can't immediately see the problem with leaking timing data. The client (that decrypts the password database) runs on your local computer, and typically places clear-text-passwords into the clipboard during normal use. So if your local computer is compromised you have way bigger problems than timing attacks.
It does have a mode that allows you to avoid clipboard sniffers if the program you are targeting supports it. However most attack vectors on the local machine can usually get a hold of both keyboard and clipboard data making it impossible to prevent sniffing, but that does assume a sophisticated sniffer.
So when you submit a form the malware records what was in the form and just as important where that form was submitted to (i.e. what URL).
Without context (the where) the information (the what) is near worthless. Aside from toy malware nobody actually logs keys anymore, the term "keylogger" is just a word, it isn't literal.
Source: I have looked at the leaked source of commercial (in the black market) malware. A core part of this malware is automation for resale, nobody is going to read through hundreds of pages of someone's clipboard and keystrokes to figure out what page they're on, and it is by far a more difficult route than just breaking into the browser, hooking Win32 functions, or hooking into the network stack before encryption occurs.
Earlier quoted context omitted.
I don't buy this "explanation" for the following reason: Even if they could not anticipate an attacker tampering with user data, surely they should've been able to anticipate filesystem corruption? Let's not pretend that MACs and secure integrity checks were a modern marvel just because CCA attacks were seen as theoretical back then.
Can you help me understand what your fundamental argument is here? It seems pretty straightforward that the old, unauthenticated format is bad. Clearly, they didn't take crypto design very seriously when they shipped a product based on it. Is there some deeper subtext here? Whatever that subtext might be: it's especially weird coming from you, since you're the author of the story at the top of this thread, about a cu…