Asked  7 Months ago    Answers:  5   Viewed   36 times

As I understand it, the best practice for generating salts is to use some cryptic formula (or even magic constant) stored in your source code.

I'm working on a project that we plan on releasing as open source, but the problem is that with the source comes the secret formula for generating salts, and therefore the ability to run rainbow table attacks on our site.

I figure that lots of people have contemplated this problem before me, and I'm wondering what the best practice is. It seems to me that there is no point having a salt at all if the code is open source, because salts can be easily reverse-engineered.




Really salts just need to be unique for each entry. Even if the attacker can calculate what the salt is, it makes the rainbow table extremely difficult to create. This is because the salt is added to the password before it is hashed, so it effectively adds to the total number of entries the rainbow table must contain to have a list of all possible values for a password field.

Tuesday, June 1, 2021
answered 7 Months ago

There are some points that can be improved, but first i would recommend to use PHP's new function password_hash(). This function will generate a safe salt and includes it in the resulting hash-value, so you can store it in a single database field. There exists also a compatibility pack for earlier versions.

// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_BCRYPT);

// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);

Some thoughts about your code:

  1. You generate a BCrypt hash with crypt(), so the salt will be part of the resulting hash. There is no need to store it separately.
  2. The generation of the salt can be improved, use the random source of the operating system MCRYPT_DEV_URANDOM.
  3. If you would change the cost factor to 9, the format would become invalid, because crypt expects two digits.
Wednesday, March 31, 2021
answered 9 Months ago

A public salt will not make dictionary attacks harder when cracking a single password. As you've pointed out, the attacker has access to both the hashed password and the salt, so when running the dictionary attack, she can simply use the known salt when attempting to crack the password.

A public salt does two things: makes it more time-consuming to crack a large list of passwords, and makes it infeasible to use a rainbow table.

To understand the first one, imagine a single password file that contains hundreds of usernames and passwords. Without a salt, I could compute "md5(attempt[0])", and then scan through the file to see if that hash shows up anywhere. If salts are present, then I have to compute "md5(salt[a] . attempt[0])", compare against entry A, then "md5(salt[b] . attempt[0])", compare against entry B, etc. Now I have n times as much work to do, where n is the number of usernames and passwords contained in the file.

To understand the second one, you have to understand what a rainbow table is. A rainbow table is a large list of pre-computed hashes for commonly-used passwords. Imagine again the password file without salts. All I have to do is go through each line of the file, pull out the hashed password, and look it up in the rainbow table. I never have to compute a single hash. If the look-up is considerably faster than the hash function (which it probably is), this will considerably speed up cracking the file.

But if the password file is salted, then the rainbow table would have to contain "salt . password" pre-hashed. If the salt is sufficiently random, this is very unlikely. I'll probably have things like "hello" and "foobar" and "qwerty" in my list of commonly-used, pre-hashed passwords (the rainbow table), but I'm not going to have things like "jX95psDZhello" or "LPgB0sdgxfoobar" or "dZVUABJtqwerty" pre-computed. That would make the rainbow table prohibitively large.

So, the salt reduces the attacker back to one-computation-per-row-per-attempt, which, when coupled with a sufficiently long, sufficiently random password, is (generally speaking) uncrackable.

Tuesday, June 1, 2021
answered 7 Months ago

I got the following links


Java Source - Open Source ERP & CRM Software

  • Hipergate - Intranet CRM, sales automation, customer service, email marketing, content management, bug tracker, project manager, groupware, calendar, forums, file sharing, directory. Based on Java /JSP for PostgreSQL, Oracle, SQL Server.

  • OFBiz - The Open For Business Project is an open source enterprise automation software project licensed under the MIT Open Source License. By open source enterprise automation we mean: Open Source ERP, Open Source CRM, Open Source E-Business / E-Commerce, Open Source SCM, Open Source MRP, Open Source CMMS/EAM, and so on.

  • Ohioedge - Ohioedge CRM Server is an online CRM application designed for $2-500M organizations requiring centralized, multi-functional, enterprise-wide coordination of sales generation (contact management) & fulfillment (business process/workflow management) activities.

  • Compiere - Smart ERP+CRM solution for Small-Medium Enterprises in the global marketplace covering all areas from customer management, supply chain and accounting. For $2-200M revenue companies looking for "brick and click" first tier functionality..

  • CentricCRM - Centric CRM is a mature, fully featured, Java-based, Web-delivered CRM with contacts, pipeline, accounts, and campaign management, project management, help desk, and admin modules.

  • CentraView - CentraView delivers browser based Contact Management, Salesforce Automation (SFA), and Customer Relationship Management (CRM). CentraView is an Enterprise Java (J2EE) application, that runs on Apache Tomcat, JBoss, and uses the MySQL database by default.

  • Daffodil CRM - Daffodil CRM's features include integrated email campaigns, customizable views, powerful filtering and automatic mail attachment facility. The One$DB Open Source database provides its back-end.

  • openCRX - Features include account management, complex legal entities, leads/opportunities tracking, quotes/sales orders, invoices, territory management, complex product catalogs, product pricing/discounting and activity/task management.

  • SourceTap - SourceTap's CRM application is a highly flexible Sales Force Automation (SFA). In supports standard SFA functionality such as lead, account and opportunity management. In addition it includes Sales Management providing sales reps the capability to develop accurate forecasts, seamlessly share information across sales teams, and configure products and services. Based on OFBiz components.

  • Cream - A CRM designed specifically to meet the needs of media organizations. Cream is designed to meet the unique demands publishers have, including features that allow subscription management, support for multiple products (print subscriptions, advertising, online subscriptions, books, etc.), customer communications (both incoming and outgoing), and easy-to-use reporting and analytical functions.

  • Queplix - QueWeb Customer Care solution that focuses specifically on the portion of the Customer Relationship after the Customer has been acquired. The solution is a J2EE application that uses Google Web Toolkit (GWT) for its UI.

  • Openbravo - Openbravo includes all functionality you would expect of an ERP solution, as well as basic CRM and Business Intelligence. Most of the Openbravo code is automatically generated based on a Data Model Dictionary. The Data Model Dictionary is an extension of Compiere.

  • Loopfuse - LoopFuse is a marketing and sales automation suite providing organizations the ability to generate leads from their website, score and route leads, marketing campaign capabilities, full web analytics support. LoopFuse also offers the capability to measure ROI within marketing and sales department initiatives. Loopfuse is built on Hibernate, Quartz, JSF and JAAS. It provides plugins for, SugarCRM and CentricCRM

  • JFire - JFire is a customizable ERP and CRM that is based on J2EE 1.4, JDO 2.0 and Eclipse RCP 3.2

  • Eberom - Eberom is a CRM and Project Management solution is built using Tomcat and MySQL. It uses Hibernate, Spring, Struts, Jasper Reports and POI HSSF

  • Adempiere - The Adempiere project was created in after a disagreement between Compiere Inc., the developers of Compier, and the community that formed around that project

Sunday, August 8, 2021
answered 4 Months ago

In OpenSSL, the salt will be prepended to the front of the encrypted data, which will allow it to be decrypted. The purpose of the salt is to prevent dictionary attacks, rainbow tables, etc. The following is from the OpenSSL documentation:

Without the -salt option it is possible to perform efficient dictionary attacks on the password and to attack stream cipher encrypted data. The reason for this is that without the salt the same password always generates the same encryption key. When the salt is being used the first eight bytes of the encrypted data are reserved for the salt: it is generated at random when encrypting a file and read from the encrypted file when it is decrypted.

The documentation suggests that a salt always be used with a password, except if compatibility with earlier versions that do not support a salt is neccessary.

Saturday, October 9, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :