I have stored (and encoded) an email password. I have used PasswordEncoder (Spring security).
passwordEncoder.encode(password);
Now I need to decode it in order to use it in javax mail. (the password is used to connect to the email provider(yahoo, gmail, etc).
Is there a way to decode this password?
Thanks in advance.
PasswordEncoder interface support only encoding and matching which is the best way to deal with password as others too have suggested. You can use StandardPBEStringEncryptor provided by Jasypt library as this library had transparent integration with Spring Security. Else you can roll out your own using Java Cryptography Extension's Password Based Encryption (PBE) however before trying what you want to achieve with regards to password encryption you must definitely read this.
Related
I am trying to use the SAML adaptor provided by Spring Security (https://docs.spring.io/spring-security/reference/servlet/saml2/index.html). The library takes in credentials by Saml2X509Credential, which requires certificate of X509Certificate type. However for the project I am working on, the cert provided to me is an endpoint URL. I am wondering what is the workaround for this?
In addition to this, in the project I need to obtain some user information (such as user email) back from the SAML response. But it seems that the provided UserDetailsService doesn't have a way to grab information other than
String getPassword();
String getUsername();
boolean isAccountNonExpired();
boolean isAccountNonLocked();
boolean isCredentialsNonExpired();
boolean isEnabled();
I am wondering is there any way to customize this?
I had done lots of research but didn't find useful info.I am really new to security and saml, sorry if these questions repeated.
Based on documentation:
The configured UserDetailsService is needed because DigestAuthenticationFilter must have direct access to the clear text password of a user. Digest Authentication will NOT work if you are using encoded passwords in your DAO
So this means that DigestAuthenticationFilter forces us to use NoOpPasswordEncoder which is deprecated in spring security 5.
Is there another way to configure digest authentication and avoid using deprecated encoder? Or I missing something?
It is stated as a foot note:
It is possible to encode the password in the format HEX( MD5(username:realm:password) ) provided the DigestAuthenticationFilter.passwordAlreadyEncoded is set to true. However, other password encodings will not work with digest authentication.
I'm building an application with Rails and will be pulling timesheets from Harvest, a timetracking app. I'm using an API wrapper called harvested. To be able to interface with their API, I need to provide a subdomain, username and password.
Right now, I'm just storing the passwords as plain strings and have not done any encryption. Would like to encrypt them before storing in the DB. If I encrypt the passwords before storing, can I still use the encrypted password for authenticating with the Harvester API?
OAuth exists for this very reason. Storing plaintext is obviously a bad idea, but storing something encrypted that you then decrypt is ALSO a bad idea.
Modern password flows use one-way encryption: encrypting the password and then comparing it an already encrypted value in the database. This allows use of algorithms that can encrypt easily but are essentially impossible to decrypt. Using an algorithm that allows your application to easily decrypt database fields will also allow an attacker to do the same.
With a one-way flow (encryption only), even if a user gets ahold of your encrypted passwords, they are unusable since anything entered in the password box will be passed through the encryption again before testing for validity.
TL;DR
Use OAuth as someone else pointed out: https://github.com/harvesthq/api/blob/master/Authentication/OAuth%202.0.md
I need to encrypt an NSString before sending to a WebAPI.
What are the best practices for this? I've been looking at different articles but haven't found what I'm looking for.
The whole hash/salt with date thing seems like the best approach as of this writing.
ANyone know how to do this in iOS?
Then, do I just store it in the DB as varchar(50)?
And for subsequent logins just do a text compare?
Thanks all.
Encrypt and authenticate the connection to the server with HTTPS. This counteracts eavesdropping and MITM attacks. Be sure to verify server certificates on the client side.
On the server, hash the password with a randomly generated salt.
Store the hash and the salt in a database. Yes, you can use something like a text or varchar(50) to store the hash and salt.
This has been covered in a few other questions before: see Best way to store password in database
I am implementing an API in rails and would like to use HTTP digest authorization as it is more secure than basic authorization. How would one achieve this if my passwords are stored in the database as a one way cryptographic hash.
Honestly? Don't bother. If you're going to use Digest over HTTP, you might as well be using forms or basic auth. HTTPS is the solution. Using Digest is still totally insecure (it uses weak hashing and it provides no defense against MitM attacks).
HTTPS is not hard and without it you are going to have a very hard time securing your application.
The only way to use digest authorization with hash values stored on the server is to duplicate the hash algorithm on the client to turn the user's password into the hash, which then basically becomes the new password (shared secret key).
If you used a salt when generating the hash values, you'll need to use the same salt on the client, which may prove difficult.
As others have suggested, consider using HTTPS instead. You can then send the passwords in plain text from the client to the server and rely on HTTPS for the end-to-end protection. HTTPS provides both encryption and authentication, which closes the loop.