Drupal 7 Port

Is it really? I will have to pull down a copy.

I have been experimenting with Drupal 7 Beta 3 (I think). At the moment, I will be honest, I do not have a solution to porting Safer Login to D7. As discussed toward the bottom of this issue: #967904: Can you offer support for SHA256?, D7 has changed the way Drupal stores passwords in the database, making it impossible to re-create it client-side, which is required in order to get Safer Login to work. Unfortunately, D7 is still submitting passwords in the clear. It's just storing them in a much better system.

One option comes down to finding a way to encrypt a user's password client-side in JavaScript, and then decrypt it in PHP. I have spent many an hour on Google trying to find a way to do this, but have so far been unsuccessful. If anyone out there in the Internet knows of a way to accomplish this, please don't hesitate to write in! I have considered creating my own original encryption/decryption scheme, but as I am not an expert in public-private key cryptography, I would always worry that my algorithm might be easily hacked.

Another option is to scrap the way D7 handles its passwords, and actually have it go back to using MD5 (probably salted for extra protection). This way, Safer Login would be able to work with it without much modification to the algorithm. However, I feel uneasy about creating a module which replaces a superior method of storing passwords, in exchange for the old method, just so Safer Login can work with it.

I am going to open this up to the community: what do you guys think would be a good approach to this situation? Option #1 (not yet proven possible), or Option #2 (possible, but is it unwise)?

Thanks,
Richard

heyho richard,

you might wanna take a look at this, js and php examples included:
http://www.jcryption.org/

best
axel

Wow-- that looks fantastic! I will do some testing with it. If it works reliably, then I could see making a D7 and D6 version that use it, instead of the current method in d6. In fact, I could almost see trying to create a generic drupal module which uses jcryption for any arbitrary form submission. Not sure how feasible that would be, though.

Thanks for the link!

Richard

Unless I'm mistaken, without the entire user's session being encrypted, encrypting the authorization request can't protect them, as they'll immediately start making requests that send their session id in plaintext. Grab that session id, start sending requests with it, and you're now them.

Even without the possibility of session hijacking, if you don't have SSL to solve the problems of key exchange and verification of identity of the server, there's no way to do a secure authentication request, any possible scheme can either be trivially decrypted or subverted by a simple man-in-the-middle attack.

If I understand correctly, the D6 version of this module also can't possibly be solving either of these problems.

No, you are not mistaken. Without an SSL cert, the user's session ID is not encrypted, and therefore a determined hacker can assume the identity of the user in question. This is why the module is called "safer login" instead of "safest login." ;)

This is also why on the project page I state "Of course, this is no substitute for an SSL certificate on your server" and also "if you cannot afford an SSL certificate (or only require basic protection from hackers) this module is for you." Though maybe I should amend it to be more clear.

What this module DOES do is prevent a someone in Starbucks or a hotel with a laptop & free packet sniffer from seeing your users' plain text passwords which might also be their facebook, twitter, or online bank password. It is "safer" than Drupal's default method, which is to submit passwords in plain text. But of course, as has already been stated, only SSL can give you bullet-proof security.

Going back to something you said, I do not understand how either a randomly-salted MD5 hash or a 256-bit RSA encryption (jcryption default) can be "trivially decrypted." If you can point me to an example or article of either being trivially decrypted, please let me know, so I can adjust the module to circumvent it. Or, its possible of course that I misunderstood your meaning.

Thanks for your input,
Richard

To better clarify the SSL certificate/Safer Login limitations, I changed the verbage on the project page to this:

Of course, this is no substitute for an SSL certificate on your server, as that would protect all form submissions, as well as prevent other types of attacks. This module is intended for those who desire password security, but either cannot afford a certificate, or only need basic protection from hackers during login.

Hopefully that will keep novice users from misunderstanding that this is no replacement for SSL.

The "trivially decrypted" remark was toward any possible symmetrical encryption scheme that might be employed which doesn't solve the issue of key exchange. Hashes don't have this weakness.

However, If you are allowing users to send the hash of their password for authentication, then an attacker can replay the authentication with the hash that they've intercepted. No need to decrypt them.

Also, if an unsalted hash is intercepted, it could be reversed by anyone with a sufficiently large rainbow table (this becomes easier for simpler passwords). Even a salted hash or one which isn't present in the rainbow table could be brute-forced if given the time to do so.

I suppose obscuring the plaintext password does have some merit, as you've said, users tend to make the mistake of reusing passwords across multiple sites, some of which aren't SSL.

I see. Well, the module as it stands for D6 uses a randomly-generated 32-character salt per login attempt, so a replay attack isn't possible. And as I said, what is transmitted is well-salted, so it is impervious to rainbow-table lookups, at least until yottabyte drives are commonplace ;)

I don't mean to sound defensive about the module-- if there are any weaknesses in the current method, I want to know so I can either (a) fix them, or (b) warn people about the weakness.

Thanks,
Richard

@richardp to respond to #1, option 2 is a BAD idea! The argument for why drupal 7 uses phpass is long and complex but it basically boils down to "md5 is a really fast algorithm and therefore really easy to crack md5 hashes using brute force". Changing back from using phpass to md5 invalidates all of the wisdom in #29706: More secure password hashing

+1 for #967904: Can you offer support for SHA256? but lotyrin is (disturbingly) correct in #7 (above) - even if public key encryption was used on the client side, the ciphertext is transmitted in the clear, so an attacker could use that to gain access to the user's account anyway. The only way around this is to use a one-time salt per login attempt - any ideas how that could be possible?

Oh wait, the one time salt is already a feature in your module - w00t! Nicely done - I'd like to look into how that works.

Right about option 2, I've abandoned that idea ;).

I think the best way to handle it is to use jCryption to do an encryption of the password before it's sent. As I pointed out in #5, this module isn't trying to be a replacement for an SSL cert. It isn't even about keeping a hacker from gaining control of someone's account, though that is a partial side-effect. It's about keeping a site's user's passwords from being sent in the clear, as those users might have the same password for their bank accounts, facebook accounts, etc.

I am currently close to creating a D7 dev release of another module of mine, Arrange Fields. Once that is complete, I will begin an attempt to create a D7 version of Safer Login. Hopefully within the next couple of weeks.

Thanks
Richard

Sounds good - any plans to backport the D7 Safer Login + jCryption to D6?

Yes, I will try to do that, in order to make everything set up about the same. In fact, as I am more familiar with D6 module development, I might do that one first. I should be able to start working on it some time this week.

Richard

Actually-- after checking just now, jCryption requires jQuery 1.4.2, which I believe is impossible with Drupal 6, even with the jQuery Update module. So I believe this approach will only work with Drupal 7.

Okay, after much tinkering and experimenting, I have created a module for Drupal 7 which accomplishes the same goal as Safer Login, but works on any form submission:

http://drupal.org/project/encrypt_submissions

D7 users, please try this module out, and write any issues relating to it on that module's issue queue.

Thanks!

To reply to #14: "jCryption requires jQuery 1.4.2, which I believe is impossible with Drupal 6" - what if jQuery 1.4.2 was loaded *just* on the user login page? That way it wouldn't have to break drupal. Would there be any problems with this approach?

Possible, but I honestly don't know enough about how Drupal uses its included jQuery functions to say for sure.

Richard

@Roger:

I know this is an old post, but I do have an alpha version of Encrypt Submissions for D6 now, which does true encryption of form data, and you can indeed limit it to just one form:

http://drupal.org/project/encrypt_submissions

Thanks richardp - will check it out :)