Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people, just like you, are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
Solved

Is 'hashed password salting' applicable to Android, C#, .Net & Java coding ?

Posted on 2016-08-14
2
79 Views
Last Modified: 2016-08-14
"Hashed password should be salted to prevent rainbow table attack. The salt value should be unique and have reasonable length for each user" :
I saw the above secure coding standard being proposed by our apps development vendor.
I've always thought salting is for database stored items/passwords, so is the above standard
applicable to apps coding?
0
Comment
Question by:sunhux
2 Comments
 
LVL 30

Assisted Solution

by:Alexandre Simões
Alexandre Simões earned 80 total points
ID: 41755371
Encryption strategies have nothing to do with platform or logical area they are being used.
All efforts to prevent something that is encrypted from being decrypted by an unauthorized party should be welcome.

For me, the question is always related to the confidentiality of what is being encrypted versus the encryption method complexity.
The platform should be pretty much transparent.

In your case, you're speaking about passwords anyway. Isn't this related to the storage of the passwords?

Cheers,
Alex
0
 
LVL 63

Accepted Solution

by:
btan earned 420 total points
ID: 41755378
Salting on top of hashing is to add deterrence from hash cracking. Any application requires use of password should ensure strong password hash created prior to storing like in the DB or other form of directory store. It is not only pertaining to DB though it is the common main store of user account details for applications. Some even use the salt (as per in PBKDF2(PRF, Password, Salt, c, dkLen) scheme) to derive a key for user specific encryption or the concern account use case. In the latter case, salts are closely related to the concept of nonce.

System storing simple non-salted password hash will not slows down the attacker, hashes are commonly cracked by Dictionary Attacks, Brute Force Attacks, Lookup (pre-compute), Reverse Lookup (w/o pre-compute) or Rainbow (time-memory trade-off ) Tables.

Specifically, lookup tables and rainbow tables only work because each password is hashed the same way. So users with same password will have same hashes - easily discovered and revealed. Therefore, randomising each hash even with same password has introduced a random string, and called salt (as you may know already). Of course, this does not fully deter, an important part is to also adopt a slow hash functions
To make these attacks less effective, we can use a technique known as key stretching.

The idea is to make the hash function very slow, so that even with a fast GPU or custom hardware, dictionary and brute-force attacks are too slow to be worthwhile.
Key stretching is implemented using a special type of CPU-intensive hash function. Don't try to invent your own–simply iteratively hashing the hash of the password isn't enough as it can be parallelized in hardware and executed as fast as a normal hash.
These algorithms take a security factor or iteration count as an argument. This value determines how slow the hash function will be.
and choosing a "random" unique salt e.g.
Salt should be generated using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). CSPRNGs are very different than ordinary pseudo-random number generators, like the "C" language's rand() function.
The salt needs to be unique per-user per-password. Every time a user creates an account or changes their password, the password should be hashed using a new random salt. Never reuse a salt. The salt also needs to be long, so that there are many possible salts. As a rule of thumb, make your salt is at least as long as the hash function's output. The salt should be stored in the user account table alongside the hash.
http://www.codeproject.com/Articles/704865/Salted-Password-Hashing-Doing-it-Right

Do see the OWASP password strategy
Use a cryptographically strong credential-specific salt

A salt is fixed-length cryptographically-strong random value. Append credential data to the salt and use this as input to a protective function. Store the protected form appended to the salt as follows:

[protected form] = [salt] + protect([protection func], [salt] + [credential]);
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

and also catch EE article for choosing strong passphrase in specific to 2FA
6.Many online accounts offer something called two-factor authentication, also known as two-step verification or 2FA. This is where you need more than just your passphrase to log in, such a passcode sent to your smartphone. This option is much more secure than just a passphrase by itself. Whenever possible, always use these stronger methods of authentication.
https://www.experts-exchange.com/articles/18309/Choosing-an-easy-to-remember-strong-password.html
1

Featured Post

Master Your Team's Linux and Cloud Stack

Come see why top tech companies like Mailchimp and Media Temple use Linux Academy to build their employee training programs.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

OnPage: Incident management and secure messaging on your smartphone
Most MSPs worth their salt are already offering cybersecurity to their customers. But cybersecurity as a service is wide encompassing and can mean many things.  So where are MSPs falling in this spectrum?
The viewer will learn how to dynamically set the form action using jQuery.
Learn how to create flexible layouts using relative units in CSS.  New relative units added in CSS3 include vw(viewports width), vh(viewports height), vmin(minimum of viewports height and width), and vmax (maximum of viewports height and width).

808 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question