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.
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 have an asp.net web API. I implemented a token authentication that I am trying to validate user name and password from the database. I am new to JWT so I need your advice.
Here are my questions;
Should I encrypt username and password in my database?
The client sends the username and password in the request body, Should the client send them in the header? And should they be encrypted?
Best Regards.
You should absolutely encrypt your password in the database. Even better if you hash it with "salt" (hashing will let you implement the log in logic, but the original password will be unrecoverable even if you know the hash).
Sending the password in the request body is fine if the connection is protected by TLS (HTTPS). There's no gain in putting it in the headers.
Usernames are often stored in plain text.
P.S. Your question has nothing specific to JWT, it is just general password management.
I have working on jhipster.but i am unable to decrypt password in jhipster and Spring.PasswordEncoderClass only provide encode and Match password function.can you help to decrypt password in jhipster.
Thanks in advance
We are using Spring Security's StandardPasswordEncoder, I do hope you can't decrypt it :-)
We are indeed storing hashed passwords: as you say, you can encode a password, and validate (match) if a specific String is the correct password, but you can't decrypt it. This means that if your database is stolen by a hacker, he would have a very hard time to figure out your users' passwords.
So this is a very good idea if you want to keep your users' password secure.
If, however, you want to have your passwords in plain text, you can change the encoder in your SecurityConfiguration class: you need to change the "passwordEncoder" bean, and probably use Spring Security's "NoOpPasswordEncoder" class. Of course, I have never done it, as I care about my users' data :-)
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)
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.