How does Hybris salt its MD5 password hashes? - sap-commerce-cloud

Hybris (version 5.1) can store user passwords in the clear (the default), or using MD5. The MD5 option is not a straight MD5 hash of the password, so i suspect some kind of "salting" is involved. But what? My goal is to be able to write a password reset application that can write new random passwords to the hybris database in MD5 mode (not in the clear).
Getting a little closer: I know that my configuration is using core.saltedMD5PasswordEncoder, and that the value of the salt is set in hybris/bin/platform/ext/core/resources/core-spring.xml
Still, without the source for saltedMD5PasswordEncoder, i may not get very far.

Hybris supports more than one password encoding schema. Which schema or strategy is actually used depends on your configuration.
You will have to look up the documentation for your password encoding strategy to see how the fields are mapped.
Usually a salt is randomly generated for each user and stored together with the password in the same object (database row).
Furthermore MD5 should not be used anymore. It is broken beyond repair and a salt will not fix it.
Please consult the hybris documentation on password encoding https://wiki.hybris.com/display/release5/Password+Storage+Strategies
and stack overflow for password storage best practices.

Related

Longer password salts stored locally or shorted password salts not stored locally?

I have an offline application that encrypts local file (using aes-356-gcm) and it uses scrypt for password hashing (both from the node.js crypto library). Because the application is offline I can't prevent the user from being locked out after x attempts like a web app.
My question: Is it more secure to use a really long salt that is shared between all instances of the application, or would it be better to ask the user to remember a 6-8 byte salt that is not stored anywhere?
My initial thought would be that the 4-8+ byte salt that is not stored in a config file would be more secure because it would act almost as a second password. On the other hand, a 32bit salt is quite short (but would it even be considered a salt in this case?).
My current implementation uses a default hash for if the user just doesn't want to worry about remembering another pass phrase. Then, they can either specify their own salt or have a random one generated based on the number of bytes they want the length to be. The salt is not stored anywhere in any type of config file or anything along those lines.
The other idea I had was to generate a longer salt and prepend it to each encrypted file. Would this be overkill?
I also want to say: This is not an application that will be used in production. I am simply a student who's trying to learn on a personal app. I've already received all the "you shouldn't be implementing this if you don't know anything about encryption" comments. I understand your concern so let me just put it to rest now.

Can salted passwords be reversed?

I have just pressed 'forgot password' on hosting24.com, only to have my password emailed to me in plain text (see image below). I contacted their technical support to question this and they have told me:
We are using Salt encryption on our website, passwords are not stored
in plain text. Please let us know if you have any concerns regarding
the security of your data.
The way I understand it, is that once a password is 'salted' it cannot be reversed back to plain text. I am also very concerned, considering their partner company 000webhosting was victim of a massive hacking incident recently, which exposed that their security was sub-par.
Thanks.
EDIT:
After a few heated emails I finally got this response:
Our passwords are encrypted with a secure encryption method in the
database. Although we do have a decryption method in place (that is
used to prevent fraud), all this is going to change as we are
re-designing the project and updating the code to adhere to new age
standards. We are sorry to have let you down on this one.
Please contact us with any additional questions. Happy holidays!
'New age'. Amazing.
EDIT:
I sent the website this link to prove a point, so I anticipate a load of down votes from their tech support.
Salted hashed passwords are not directly reversible—that's the point of hashing. However one can always try to recover them through brute force, trying all possible/likely passwords to see if the hash matches.
How expensive that is to do depends on the strength of the hash used, but you would never build a system that stores and decrypts passwords that way. If they said they were storing only salted hashes, and still were able to send you the password you originally set yourself, they're clearly lying.
They don't mention hashing though:
We are using Salt encryption on our website, passwords are not stored in plain text.
“Salt encryption” isn't a thing, but let's be as generous here as we can.
It is possible they mean they're using reversible encryption with some randomised element (variable IV, or extra data in the encrypted message) which would ensure two passwords don't get matching encrypted versions (ie the same purpose as the ‘salt’ in a hashing operation).
It's also conceivable that there could be some valid reason why they need reversible passwords, for example if they need to use the passwords to authenticate to another separate system. It's possible to build reasonable systems with reversible passwords, but compared to Good Old Bcrypt it's a whole lot more effort to manage this way (eg keys on the application server; wide-ranging internal policies to manage that; HSMs; and watertight code auditing).
Let's say we accept that this is what they've done and they've implemented it solidly (which is highly doubtful—much more likely they've got plaintext passwords or a hacked-up and vulnerable AES). Even then, they've then blown it by sending you the reversed password in a mail over the unencrypted public SMTP infrastructure.
There are things you can do to mitigate the untrustworthiness of the mail channel, such as sending a single-use token or temporary password that requires a new password to be set afterwards. But there is never a good reason to send an existing password, that will continue to work on the target site and which you might have used to secure other services. User-set passwords should never touch SMTP.
No, they can't without astronomical computing power. I'd bet large sums of money that they have a second database of plaintext passwords.

Keeping passwords secure during transmission

In my web application, I'm implementing a blacklist of passwords that user's won't be able to select. As mentioned in Jeff's God Login post, this is because some passwords are very commonly used and exist in readily available wordlists used by brute forcing tools.
I had planned to store the blacklisted passwords in a database table (in the clear), with an MD5 hash of it as a Functional Index. So, when the query is sent to the server, it looks like this:
SELECT 1
FROM blacklist AS a
WHERE MD5(a.password) = 'MD5stringOfPasswordSubmitted';
I don't think the "in the clear" storage of these passwords is an issue since the passwords are blacklisted. No user can set it to one of these.. so who cares if passwords in this table are stored in the clear.
But, is the transmission of this query to the database server a problem I should worry about?
If my user is trying to set their password, at the moment the app will MD5 the password, send that to the database to query this blacklist table. If no result is returned, the app will allow them to have it as their password (as long as other validation requirements are also met).
Is this something I should worry about?
Could this be implemented another way so passwords users are trying to set are kept secure still? Is it really necessary to resort to storing a salted hash via Bcrypt (like is in my user table) even just for this blacklist usage? Would using a YAML file in the local directory structure of my app have any of this same risk?
The aim is to prevent users choosing a password that's common, and checking that in a very fast way (hence MD5) as part of the validation process.
I don't see how the transmission of the query could be a problem. If your web application does the MD5 encoding and an attacker intercepts the communication with the database, there is no way he can get back the user's password from it.
MD5 is not safe for storing passwords as attackers may be able to find passwords that result in the same hash value (collisions), but there is no way to convert a hash value back to the clear text from which it originated.
If you're worried about leaking other sensitive data when querying the database, you could consider encrypting the communication channel.
I wouldn't worry about the transmission of passwords since they are hashed using a one-way algorithm (as user18044 pointed out) however expanding more on the weaknesses of MD5 - I wouldn't use that algorithm at all especially if you aren't using a salt. The reason why is because MD5 rainbow tables have been created for a very large set of possible combinations of passwords. In fact it's very likely that the password lists that you are referring to have been generated after searching MD5 tables or using online services that will give you a password by submitting an MD5 hash (if the password has already been cracked previously or is in some table). I would recommend using a salt or using another algorithm like SHA-256. Security is my specialty and I have a rig that is capable of cracking MD5 hashes at hundreds of billions per second however if there is a salt involved it either slows me down or stops me all together (if the salt is not known). That same rig can crack SHA-256 but it takes much longer for it to crack each one because SHA-256 iterates over itself enough times to make each iteration slow enough to make cracking less feasible.
As was already mentioned I would certainly use SSL either way to better protect all data that is transmitted.
But, is the transmission of this query to the database server a problem I should worry about?
This depends on your network topology. e.g.
Is the database server on the same private local network? Then this is low risk.
Is the database server on the same network, but shared with other machines and users. Then this is medium risk (you need to trust all the other machines and users).
Is the database server across the internet? Then this is high risk.
Depending on your accepted risk level, you may want to protect the connection to the database with SSL/TLS.
Even though you are hashing with MD5, MD5 is considered a weak hashing algorithm so if a MITM grabs the password as it is queried on your database, they could run it through a tool such as John the Ripper using a word list and intercept any password set by your users.
You could try and hash the password using another algorithm for this lookup - however this means implementing a "static salt" (called a pepper) on your system to avoid any hash comparisons of intercepted data. It may be much easier to simply connect with SSL/TLS to avoid this completely.
For storage of the password itself (once it has passed your check), definitely use a secure algorithm here such as bcrypt or scrypt.

Encryption algorithm for encypting sensitive-data - AES-256?

In one of my applications, I am to store user credentials and tokens. As the credentials are used directly on third-party services, I cannot hash them and thus need to store them as-is.
As I am not an expert on encryption, I googled and found that AES 256-bit key size-is a good idea to encrypt such data.
I would like to know the opinion of the SO community on the same, before I make a final decision.
Thanks!
Edit: Thanks to all for discussion, I am moving ahead using AES256 as the encryption mechanism for now, which seems like a good choice.
if you ask user for credential every time, then why do you need to store them in db? just keep it in memory and pass to external system. you can even ask user once and keep their password in memory for the whole session. if, for some reason you have to store them in db, them of course encrypt it. as far as i know, current standard is AES256. but still somewhere you have to keep unencrypted key.
to sum up: if you want to authenticate users and then use their password only for the time of session then you don't have to store it in database. keep salted hash for authentication purpose and keep user provided password in session for external systems
btw. is your swap encrypted?

Salt location , salt hiding

i have a question regarding the following scenario:
I want to use jasypt to encrypt my password and use a certain salt for encryption.
Does it make sense(or is there any security implication) if :
I use password based encryption to encrypt the salt with a password that I get from an environment variable, that way i can have the encrypted value of the salt in a property file, get it from there , decrypt it via the password i get from the environment variable (actually i am going to have a EnvironmentStringPBEConfig object which in turn gets the environment variable from EnvironmentStringPBEConfig object and delete the environment variable once the EnvironmentStringPBEConfig is created) and finally use the salt.
Thank you.
Edit: please note that i would want to know if "hiding" the salt as described above is a good practice, i am not implementing such solution right now.
EDIT: Also please note the following recommendations from OWASP.
Recommendation: Make it hard to steal the entire salt
There are a number of additional recommended enhancements to the basic salting mechanism for consideration:
Have an additional 'system' salt that is a fixed value for the entire system. This should be stored in a configuration file somewhere. This fixed value would not have to be included every backup, making it even harder for an attacker to compromise all elements required to calculate the hash value properly.
Embedding a portion of the system salt in the source code. This wouldn't be that helpful for open source code, but for custom applications, having part of your system salt in the code would be yet one more item required by an attacker to calculate the hash value properly.
Generating a new salt for an account each time that user's password is changed.
Recommendation: Salt Isolation
An additional password storage defense mechanism involves storing the salt in a different location than the password hash. Use of the server's filesystem is one commonly used mechanism for salt isolation, assuming the password hashes are stored in different location such as a database or LDAP server. This defense mechanism reduces the risk of password theft when the database file is stolen, since the salts will not be included with the database data. Be careful to ensure that both the password hashes and the salts are not backed up together, they should also be backed up in isolation.
Why do you want to encrypt a salt? Salts are normally public information - they only exist to prevent pre-computed "rainbow-table" offline attacks on databases of passwords. I think you need to be clearer about what you are attempting to do and why.

Resources