Passwords stored in plain text about calipso HOT 13 CLOSED

Agreed, I always intended to re-write the whole auth piece once I found a good plugin / approach that worked with external accounts like twitter / facebook etc. - it was just a placeholder pre any real release.

Will leave this open until we get that done!

from calipso.

I figured. I just now came across the cms and just happened to take a look at the auth code. :)

Thought I'd mention it.

from calipso.

+1 this should be fixed asap, it just looks bad to take security this lightly.

from calipso.

Agreed - it was always a placeholder pending a 'proper' user authentication approach, I'll get it fixed today.

from calipso.

Updated in commits:

modified user module: ff0bec8
added crypto util: b7dafe6

Note that as this now introduces password encryption for the first time, it is destructive in that you do need to reset your mongodb database (but I am assuming that as we haven't actually ever 'released' or tagged anything that no one is running anything with it they want to keep just yet!).

Clifton

from calipso.

If you are able to test and confirm I will close the issue.

from calipso.

I recommend using the bcrypt module above (completely biased) but AES allows decryption and your random key is based on JS randomization. Really both of those aren't things you want with passwords. And, ultimately you don't even want to store a password, encrypted, hashed or otherwise, if you can help it.

from calipso.

Ok ... I kind of took the easiest route I could find pending a 'proper' user
auth module that includes oauth etc., plugging a hole so to speak to buy
time to decide how to do it properly.

Clearly you know more about this specific area than I do (which is great and
very glad for the input), what do you recommend in terms of implementation?

On 25 May 2011 19:59, ncb000gt <
[email protected]>wrote:

I recommend using the bcrypt module above (completely biased) but AES
allows decryption and your random key is based on JS randomization. Really
both of those aren't things you want with passwords. And, ultimately you
don't even want to store a password, encrypted, hashed or otherwise, if you
can help it.

Reply to this email directly or view it on GitHub:
#9 (comment)

from calipso.

I doubt I know much more about the topic. I'm more of a hobbyist but have had arguments with crypto people before (who reminded me of how little I actually know on the subject) :).

OAuth would be a very good way to go with this. Twitter, Facebook, etc. all have teams dedicated to security itself, it's better to toss the work onto them. But, in a CMS you can't assume that a project will allow use of those systems. Not to forget the fact that those require accounts on those platforms and you'll be leaving some users out that way.

So, having an alternative where you don't need those platforms is good. The point about not storing the password itself is that if your system is compromised and your DB files are stolen, the attacker could get the data back. The problem there is that if you have passwords in that DB you have left your users open, since most people only use one password for everything anyway. So, if you can store the "random" data and use the password (which can be thrown away) as a throwaway value then you are protecting your users almost as much as possible and making it so that an attacker would get gibberish data.

from calipso.

Ok, makes sense, someone is working on integrating oauth, so will fix the current login process to use a one way hash and store that rather than storing an encrypted password - not sure what I was thinking, should have done more research.

from calipso.

I've worked on content management systems before. I know what kind of workload you have. It's not easy to research everything before implementing. But, thats why github is so awesome right- peer review! :)

Regardless, thanks for being amenable to it.

from calipso.

Ok, this is now 'fixed' - I've used your bcrypt module, incredibly simple - so thanks for the tip. I'm going to close the issue as it looks good to my testing, and I've also closed other holes related to escalation of admin user permissions, so if you are able to quickly check the implementation (particularly utils/crypto) as I'm not 100% confident that the way the salt is generated (?) each time is right, but it works ... I would have expected that I would have had to keep the salt constant for a user?

Thanks for all your input.

Clifton

from calipso.

At a quick glance it looks good. Glad the bcrypt lib was easy enough to use.

The salt that is generated is stored in the hash you get back. More details on the algorithm itself are at http://en.wikipedia.org/wiki/Bcrypt. However, if you find a flaw with my implementation please let me know. I'll fix it asap.

from calipso.