Setting up a password repository

July 12, 2005 5:55 AM

Let's say I wanted to create a simple web app to store my various usernames and passwords. The app and database would be hosted externally (by Dreamhost). I would use a secure connection for any HTTP stuff going back and forth, and I would encrypt all of the passwords before going into the db, and I can only extract and decrypt a password after entering a pass phrase that exists only in my brain. What would it take for someone else to get at my passwords?

Dreamhost just added Ruby on Rails support, so I thought this would be a good project to get my feet wet with it. Does Ruby have nice encryption modules ready to go? Would there be more secure options going with PHP or Perl?

[Alternatively, does anyone know of a web app like this? My searches turn up lots of junky-looking Windows programs.]

posted by patgas to computers & internet (9 comments total)

from just a crypto point of view, the problem these days is that any password you can keep in your brain is small enough to be guessed.

in practice, the easiest way to get anything is usually social engineering (in broad terms). so, for example, tricking you into entering your password at a fake page would be more likely than someone bothering to brute force your password (particularly since the same attack can be used against many, while cracking your password can be used only against you).

the easiest technical crack i can see to your system is hacking the server it's hosted on and then altering the code so that it grabs your (global) password (at the client dialogue) and reports it back to the server. that's quite interesting, in that it suggests that anyone with access to the server is in a position to know your passwords, so encrypting the passwords on the server, while certainly best practice, is giving you a false sense of security.

(i'm assuming you intend to do the decryption on the client, right?)
posted by andrew cooke at 6:11 AM on July 12, 2005

I hadn't thought of that, but I suppose I could do the encryption/decryption on the client. It seems like there's at least one library available for this.

Is the risk significantly reduced by using something like this on my USB drive?
posted by patgas at 6:33 AM on July 12, 2005

i was going to suggest the usb solution. i think that's the standard way to do it, but (1) it doesn't give you a cool web project and (2) doing it on (inside) the client (browser) you might be able to automate the form-filling (so you don't need to copy + paste to get the info from the database into the browser).

i think it's a cool project, but it's only as secure as your web host against a determined attacker. in practice, if the project remained small, it would probably be fine. if it became popular, then someone bothering to mod the code and hack a server to use the modded code becomes more likely.

hang on - how would this work anyway? you'd download the javascript from your server, not from the site whose password you wanted to store. so they would be in different pages and not be able to access each other (see previous discussions here on javascript security). hmmm. in that case, i don't see any advantage to doing this via the web, just disadvantages.

sorry - it did seem like a cool idea. maybe someone else will correct me.
posted by andrew cooke at 7:09 AM on July 12, 2005

andrew cooke - you'd put the Javascript in a bookmarklet that can access the current page, like my password-generator bookmarklet does.
posted by nicwolff at 9:38 AM on July 12, 2005

Whoops - that link is to the Web-page Javascript application - here's the bookmarklet version that scans the current page for password fields and fills them in.
posted by nicwolff at 9:40 AM on July 12, 2005

You might want to take a look at how hushmail.com works. With hushmail your data is stored encrypted on the server, you go to the webpage and a java program grabs the data and decrypts it in the client. They use digital certificates so that if the java program is altered the certificate would change (I'm not sure on how these are obtained and the feasability of a fake lookalike signature).

There's nothing wrong with this system in theory... I guess the primary attack would be getting a keylogger on the client machine.
posted by bobo123 at 9:47 AM on July 12, 2005

if you did it the bookmarklet way, then you wouldn't be able to contact the remote server, i believe (i'm not an expert on browser security, at all, but there was a discussion on this a while back that concluded, iirc, that browser security makes it hard to mix information from more than one server on a page using javascript).

hushmail's java solution works (i think, after a very brief look), because the java security model is more flexible - you can grant extra permissions. with hushmail you may be vulnerable to the same attack i described earlier - if someone cracks the hushmail server and replaces the code then they can get your password. however, since the java code is probably signed (as part of the java security model i just mentioned) that is significantly harder to do than in the javascript case - you also need the hushmail secret key used for signing, which they hopefully do not keep on their server.

so java is a better solution because of the more complex security model. again, this is just a guess (i do this kind of thing for a living, kind-of, but check with people smarter than me, and spend more time at it when i'm being paid).
posted by andrew cooke at 10:43 AM on July 12, 2005

I wrote a program like this, although it didn't have a web interface. What I ended up doing was having a set-length file (mine was 512KB I think, although it might have been a meg) that username/password pairs were scattered into based on a hash. I kept two versions, one local & one remote, and when I'd add a pair, I'd make a patch file to the local one, then upload the patch & apply it remotely. If the timestamps were off, I'd have to download a new one, but using patchfiles cut down on bandwidth. The patchfile is a security vunerability, because it's being transmitted and stored temporarily on the remote machine, and if the remote machine was compromised, rewriting the patch utility could give them the password. I only had 100mb/mo, and that seemed like a pain in the ass for the password to my Hotmail account, so I didn't bother.

(For what its worth, I've never written down any of my UNIX root passwords, only trivial web ones)
posted by devilsbrigade at 11:01 AM on July 12, 2005

schneier is advocating that you write passwords down.
posted by andrew cooke at 12:38 PM on July 12, 2005