How do I encrypt stored passwords in rails' source code? These are not passwords of the users, but passwords used by the app to access other external services; for SOAP, REST api etc. I can't one-way hash it because the app has to send a text pass to authenticate to other services. Base64 encoding/decoding isn't the best option since it can be copied from the source code and reversed.
Related
I have default auth implemented in Laravel 7 and works like a charm.
However, I have a very peculiar requirement wherein, the password shouldn't even travel in plain text although SSL is implemented on network.
One way would be to handle it via javascript on login page wherein I encrypt the value of password and send the same to server and then decrypt the same in php before handing it to laravel attemptLogin method.
However, I am not so sure about this approach.
Any help would be awesome.
Solution:
On client side, used crypt.js/aes.min.js and encrypted the password using a key and iv.
In login controller, overrode credentials method and decrypted using openssl_decrypt before passing on to hash check.
This is already discussed on this answer:
It is standard practice to send "plaintext" passwords over HTTPS. The
passwords are ultimately not plaintext, since the client-server
communication is encrypted as per TLS.
And this one:
If you hash on the client side, the hashed password becomes the actual
password (with the hashing algorithm being nothing more than a means
to convert a user-held mnemonic to the actual password).
This means that you will be storing the full "plain-text" password
(the hash) in the database, and you will have lost all benefit of
hashing in the first place.
You may also read this answer for more security options.
I solved it as below:
On client side, used crypt.js/aes.min.js and encrypted the password using a key and iv.
In login controller, overrode credentials method and decrypted using openssl_decrypt before passing on to hash check.
I need my users to use their laravel's account password in another nginx server (for http authentication) which uses crypt encription. How can I do this conversion? Is that even possible?
Encrypting passwords is bad practice since it's reversible. Always store them in an irreversible format, e.g. hashes.
If you still want to encrypt the passwords, you should write a custom user provider.
How to use password encryption function of magento at the time of login in admin panel using java-script so that nobody can see the real password in HTTP headers of different browser?
You cannot do this.
Usually attacks on web-sessions include active / man-in-the-middle attacks. That means that even if you send a secret or public key to the JavaScript in the browser that that key may be replaced by an attacker. So the best thing you can achieve in JavaScript is obfuscation.
What's missing is a trust framework (for now anyway, there are several crypto API's under development). As the certificates of the browser are not available to JavaScript, there is no good method to establish trust with the webserver. So in the end you cannot authenticate the other party.
This is why TLS is a strict requirement for any browser based security; TLS can make use of the certificates stored with the web-browser and it is therefore possible to know which server you are communicating with. The encryption and authentication of the data within TLS allows the password to be send in plain at the HTTP level in HTTPS.
I wrote a small webserver which currently uses basic auth over ssl. So far everything works great. Now I want (need) to switch to digest auth. But I can't figure how out to make this work with passwords that are not stored as cleartext in the database? I only have the password digest (generated using bcrypt) of my users' passwords stored. Is http digest auth possible at all?
Was just looking into this just now. First, I read through RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication to get some insight into the specification and see how it can be adapted for a REST API authentication.
Ran into the same question as you did—Does digest authentication mean the server needs to store the user's password in plaintext?
This Stack Overflow answer makes it clear: No. The server doesn't store the plaintext password—it should store the hash of (username|realm|password).
That would've been fine except for one thing—the canonical spec only supports using MD5 as the hash function.
Of course you could store both the bcrypt hash and the MD5 hash but doing so only undermines the security of the bcrypt hash effectively rendering it useless (since an attacker can shift his efforts into brute forcing the MD5 hash instead).
So, I took a step back and thought, why not disregard the spec and use bcrypt on both sides as the hash function (bcrypt(username|realm|password))?
Well, aside from being purposefully slow, bcrypt has a maximum password length which makes it unsuitable for use as a general digest algorithm.
Whew, by now my head was swimming but I still thought to give it another go. Some of the suggestions were to use TLS with SRP or authenticated encryption, specifically EAX, but I felt that maybe those were taking things just a step too far for a simple Web service.
To put it simply, if you're really bent on doing this you can work around bcrypt's character limitation by using a preliminary hash.
Long story short it seems that you can do:
bcrypt(sha256(username|realm|password))
And use that in place of H(A1) in a bastardized version of the spec.
The question now becomes—was all that added complexity really worth it? Did we get any added layer of security over Basic auth over HTTPS?
The question now becomes—was all that added complexity really worth it? Did we get any added layer of security over Basic auth over HTTPS?
I can see one, when you use basic auth, your HTTP client sends the Authorization header as a base64(password)
So, if you leave your web browser open, and someone opens the browser web console, he can base64 decode your password.
Whereas, with digest auth, the Authorization header is a md5 hash (and a nonce hash is included to prevent replay attacks)
I need to decode a password that was encoded using the org.springframework.security.authentication.encoding.PasswordEncoder.encodePassword method. Basically, application "A" maintains the encoded/encrypted password in its database. Application "B" makes a RESTful call to application "A" to get the userid and password (passes password as encoded/encrypted) and then application "B" needs to view the clear text version of the password, how would it decode it?
The mentioned class "org.springframework.security.authentication.encoding.PasswordEncoder.encodePassword" seems to use digest function to encode the password. Because all the digest function are mentioned to be one way only it is easy to make encoded password from the clear text but almost impossible to obtain unencrypted version from the digest.
If you want to authenticate user just encrypt the password and compare it to it's stored encrypted version.
Other option can be reseting the password (replacing value stored in application "A").
If you insist on unencrypted password in application "B" from the digest, you have to crack it, which can be time consuming operation...