Login Register






CryptoJS? filter_list
Author
Message
CryptoJS? #1
It hasn't been updated since 2013, is it still okay to use CryptoJS.AES???
I mean it's going CryptoJS to openssl_encode on php so it should be fine?

Just a very short question :I

Reply

RE: CryptoJS? #2
I have read somewhere that a new maintainer should take over the development, but I didn't see any updates.
Is it still safe? IDK, I still use it. I mean AES is still AES, it hasn't changed.

Reply

RE: CryptoJS? #3
If the AES implementation was verified as cryptographically secure initially and hasn't been tampered with, I don't see why its status would change.

On a slightly unrelated note, are you encrypting browser-side or in backend with node or something? Because I really wouldn't recommend the former.
It's often the outcasts, the iconoclasts ... those who have the least to lose because they
don't have much in the first place, who feel the new currents and ride them the farthest.

Reply

RE: CryptoJS? #4
(10-25-2016, 03:56 PM)Pikami Wrote: I have read somewhere that a new maintainer should take over the development, but I didn't see any updates.
Is it still safe? IDK, I still use it. I mean AES is still AES, it hasn't changed.

Hm, good point I mean it's just so that users feel more safe sending me information, I mean it's encrypted before it's saved anywhere but it still goes through a server so people could be afraid of the "possibility" of me being able to decrypt and read it.
So my plan is to do this:
Username -> server -> gets email
Password -> local machine -> encrypt via username and email -> password to server -> openssl_encrypt -> save to DB
That's just for registering that way it's dual encrypted and the server only sees the encrypted password and nothing else.

(10-25-2016, 04:03 PM)Ao- Wrote: If the AES implementation was verified as cryptographically secure initially and hasn't been tampered with, I don't see why its status would change.

On a slightly unrelated note, are you encrypting browser-side or in backend with node or something? Because I really wouldn't recommend the former.

Sorry, please read one message above.
(This post was last modified: 10-25-2016, 04:04 PM by ProfessorChill.)

Reply

RE: CryptoJS? #5
(10-25-2016, 04:03 PM)ProfessorChill Wrote:
(10-25-2016, 03:56 PM)Pikami Wrote: I have read somewhere that a new maintainer should take over the development, but I didn't see any updates.
Is it still safe? IDK, I still use it. I mean AES is still AES, it hasn't changed.

Hm, good point I mean it's just so that users feel more safe sending me information, I mean it's encrypted before it's saved anywhere but it still goes through a server so people could be afraid of the "possibility" of me being able to decrypt and read it.
So my plan is to do this:
Username -> server -> gets email
Password -> local machine -> encrypt via username and email -> password to server -> openssl_encrypt -> save to DB
That's just for registering that way it's dual encrypted and the server only sees the encrypted password and nothing else.

I see why you would want to do this. The most important thing is that SSL should be correctly configured to avoid anyone else from sniffing the password.
+ Remember this, while the password of the user is encrypted, if an attacker gets that piece of encrypted text, they don't need a password to login to that user, they just need the encrypted password

Reply

RE: CryptoJS? #6
(10-25-2016, 04:03 PM)ProfessorChill Wrote: Hm, good point I mean it's just so that users feel more safe sending me information, I mean it's encrypted before it's saved anywhere but it still goes through a server so people could be afraid of the "possibility" of me being able to decrypt and read it.
So my plan is to do this:
Username -> server -> gets email
Password -> local machine -> encrypt via username and email -> password to server -> openssl_encrypt -> save to DB
That's just for registering that way it's dual encrypted and the server only sees the encrypted password and nothing else.

I'm a bit confused as to why you would bother with all the extra steps and memory overhead when you could just use OpenSSL on your server and not have to think about it. If it's a matter of reassuring users, it should be enough to satisfy anyone that isn't a crazy conspiracy theorist.

As well, if your users are worried about you reading it, bcrypt the data you receive even if it's already protected by SSL.
(This post was last modified: 10-25-2016, 04:23 PM by Inori.)
It's often the outcasts, the iconoclasts ... those who have the least to lose because they
don't have much in the first place, who feel the new currents and ride them the farthest.

Reply

RE: CryptoJS? #7
(10-25-2016, 04:18 PM)Pikami Wrote:
(10-25-2016, 04:03 PM)ProfessorChill Wrote:
(10-25-2016, 03:56 PM)Pikami Wrote: I have read somewhere that a new maintainer should take over the development, but I didn't see any updates.
Is it still safe? IDK, I still use it. I mean AES is still AES, it hasn't changed.

Hm, good point I mean it's just so that users feel more safe sending me information, I mean it's encrypted before it's saved anywhere but it still goes through a server so people could be afraid of the "possibility" of me being able to decrypt and read it.
So my plan is to do this:
Username -> server -> gets email
Password -> local machine -> encrypt via username and email -> password to server -> openssl_encrypt -> save to DB
That's just for registering that way it's dual encrypted and the server only sees the encrypted password and nothing else.

I see why you would want to do this. The most important thing is that SSL should be correctly configured to avoid anyone else from sniffing the password.
+ Remember this, while the password of the user is encrypted, if an attacker gets that piece of encrypted text, they don't need a password to login to that user, they just need the encrypted password

Hm, I never thought about sniffing. That is a good point. And yeah, I was just thinking about that. but to be honest that's on my side and on the firewalls side which I don't think my projects would get that large :I
If someone gets to the MySQL I'm sure I would need to do some other key measures to prevent hacking.

(10-25-2016, 04:21 PM)Ao- Wrote:
(10-25-2016, 04:03 PM)ProfessorChill Wrote: Hm, good point I mean it's just so that users feel more safe sending me information, I mean it's encrypted before it's saved anywhere but it still goes through a server so people could be afraid of the "possibility" of me being able to decrypt and read it.
So my plan is to do this:
Username -> server -> gets email
Password -> local machine -> encrypt via username and email -> password to server -> openssl_encrypt -> save to DB
That's just for registering that way it's dual encrypted and the server only sees the encrypted password and nothing else.

I'm a bit confused as to why you would bother with all the extra steps and memory overhead when you could just use OpenSSL on your server and not have to think about it. If it's a matter of reassuring users, it should be enough to satisfy anyone that isn't a crazy conspiracy theorist.

As well, if your users are worried about you reading it, bcrypt the data you receive even if it's already protected by SSL.

I was using just OpenSSL however it was a complaint a user sent me that the server sees his password in plain text (despite having logging off) I will however look into bcrypt, I've never heard of that.

Reply