Any advice on storing passwords securely?

[andrewducker]

I'm currently adding Wordpress support to my link poster. And I've hit a hitch with passwords.

LJ's security means you pass the username and MD5(LJChallenge+MD5(Password)) - where LJChallenge is retrieved for each call you make. This means that I can store the MD5 of the user's password rather than storing it in plain text. While I am completely trustworthy, it's nice that I can browse the datastore and check things look ok without accidentally seeing people's passwords.

Wordpress, on the other hand, uses the MetaWeblog API for posting. Which takes the user's password in plain text.

Which means I can't hash the password when it's submitted, I have to store it in a way that I can return it back to its true value when required.

Anyone got any suggestions for what to use for this that's reasonably secure?

(I'm working in Java, which seems to have libraries for just about everything, if that helps.)

Edit: I've submitted a suggestion to DW and LJ to support OAuth. Can't see it happening this week though.

Comments

[matgb]

DW has every intention of supporting OAuth, it's on The List. They just need a willing volunteer to code the support, and it's way beyond my coding skills.

S, y'know, if it'd help this project along anyway ;-)

[simont]

LJ's security means you pass the username and MD5(LJChallenge+MD5(Password)) - where LJChallenge is retrieved for each call you make. This means that I can store the MD5 of the user's password rather than storing it in plain text.

But that also means that the MD5 of the password is all an attacker needs to steal in order to authenticate as the user, of course. You only need the real password if you're authenticating via the real client – but a bent client could bypass that stage and directly use MD5(Password) just as your own code is doing. So the same care you're intending to apply to the plaintext Wordpress passwords should also have been applied all along to the hashed LJ ones!

[andrewducker]

At the moment nobody else has access to that database, which requires you to both have my Google Accounts password and my two-factor authenticator (or "mobile phone") to access it.

Obviously all security is ephemeral, so the question is, how do I encrypt/decrypt this stuff as necessary, while making sure that someone else running off with the contents of the database can't use it?

[andrewducker]

The problem, as I see it, is this.

I need to store the data, the method of encrypyting it, and the key in the same place, or it can't work automatically. It seems impossible to me that you could actually have security in this case.

Hence me wanting advice :->

[skington.livejournal.com]

That's why the commonly-accepted solution is: don't do that. OAuth and similar things work because you can generate a token, give it to some third party process, let it do a limited number of things (so not e.g. access your billing records), and you can either revoke it or it'll expire after a certain time anyway.

At work we encrypt credit cards using PGP, and the public key is available to any code, but the private key is only available to one user (and root, obviously), on a very locked-down box that only talks to the credit card company. That works because we sometimes want to say "charge that card again" (in which case we pass the encrypted version to the payment gateway, which decrypts it before passing it on), and we sometimes want to say "was this card ever used?" (in which case we look at an MD5 hash we also store), but we never need to know "what's the plaintext version of this credit card?" so we're safe.

[fub.livejournal.com]

But with the MD5 of the password, you can not change the password or change the associated e-mail adress. So while yes, you can post or delete entries, add or remove friends with the MD5 of the password -- you can't take ownership of the journal.
But by the time you've deleted every single entry, I guess it doesn't matter anymore who has control...

But notice that the MD5 of the password itself is never sent. So an attacker must have control of one of the endpoints to get that information.

[andlosers.livejournal.com]

Jesus. This is why OAuth is good (or at least, better). And wait, does this mean Livejournal isn't salting passwords?

[andrewducker]

I can't see how they can be, otherwise they wouldn't be able to compare it to MD5(authenticator+MD5(password)). They pretty much have to be storing just the plain hashed version.

And yes, OAuth would make my life harder, but would be more secure.

Still better than MetaWeblog, which takes plain text, of course.

[andlosers.livejournal.com]

Yikes.

There's a bunch of libraries out there for OAuth, so I shouldn't imagine it'd really make your life too much harder. Once the handshake's done, you just sign your request with the token, which amounts to a similar sort of situation. But yeah, beggars can't be choosers.

Do they at least do it over SSL ..?

[andrewducker]

LJ's end point is http://www.livejournal.com/interface/xmlrpc

Wordpress use http://andrewducker.wordpress.com/xmlrpc.php

So, no.

[andrewducker]

Currently browsing through their repositories but I have no idea where the bit is that stores the password, which is making it tricky to see how it's done...

[andrewducker]

Aha! They're rolling out OAuth2 support:
http://en.blog.wordpress.com/2011/07/07/oauth2-support-developer-resources/

[skington.livejournal.com]

There's no way to do it. Any data you encrypt needs to be decrypted by the same code (or near as dammit the same code), so no matter what the encryption algorithm, if the box your code is running on gets compromised, all passwords can be decrypted.

I assume you need to provide their username and password for each API call? So effectively their plaintext password is going to be easily available from pretty much everywhere in your code? Yeah, you're fucked.

If you want to claim the stuff's encrypted, you could use e.g. PGP, and that might help if the encrypted passwords are in a database, the private key's somewhere else, and only the database gets hacked. It's a long shot, though.

[andrewducker]

The database is BigTable, and it's all on Google App Engine, with me as the only person who has access. So I'm not actually too worried about security here.

Someone on Twitter already suggested just running it through ROT13 (and back when I need it) :->

And yes, I agree, fucked. It would be better if they supported OAuth (as andlosers mentions above).

[andrewducker]

Aha! They're rolling out OAuth2 support:
http://en.blog.wordpress.com/2011/07/07/oauth2-support-developer-resources/

[pete stevens (from livejournal.com)]

http://bvernoux.free.fr/md5/index.php

Just brute force the MD5 passwords back to the original text and store that, it'll save you time later when you have to adapt to them using salts and other such things to compensate for not using bcrypt2 properly in the first place.

[andrewducker]

The user is already passing me their password - I'm then hashing it myself, so if I wanted to steal it I'd do it then...

[momentsmusicaux.livejournal.com]

Just don't?

WP is yet again demonstrating that it's a POS that doesn't consider security properly *sigh*

[andrewducker]

I'd like to be _slightly_ less rubbish than them :->

How does Drupal do clients/remote posting?

[andrewducker]

A quick google shows that Drupal also supports the MetaWeblog API, or the Movable Type API and those both pass passwords in plaintext.

(Unless I'm misunderstanding this: http://drupal.org/node/295 )

[momentsmusicaux.livejournal.com]

No, that's incoming into Drupal -- lets you use an OS client, same way you can with LJ.

Also it's been pulled :)
A 3-digit page ID on d.org though... wow. That's ancient.

[momentsmusicaux.livejournal.com]

Oh wait yeah.
There's an Oauth module for Drupal.

[andrewducker]

It's incoming that I'm talking about - using a client to post stuff to the site.

Glad it's been pulled, what do clients use nowadays instead?

[momentsmusicaux.livejournal.com]

Not sure TBH. Blog module in Drupal is rather neglected, simply because if you want a blog there are much simpler, more comprehensive tools.

[andrewducker]

Gotcha, so Drupal doesn't really support using clients to write/upload/etc. stuff, you're supposed to just use the web interface?

That does make things simpler.

[momentsmusicaux.livejournal.com]

The BlogAPI's purpose was to support clients, and in fact that was the reason Drupal core got an XMLRPC library bundled. But that dates back from ages ago, and then wasn't maintained much.

Part of the problem with Drupal is that features like that were still kicking about in Core, but totally untouched by Core devs who are off busy building sites for Sony and the White House and so do more hardcore stuff. Hence wither away and because they're in core it's hard to work on them.

BlogAPI was pulled for D7 IIRC, and Blog itself was pulled recently, so it now lives as a contrib module where it should get more attention from interested parties.