Chand,
I understand where you're coming from.
When I was working for financial and security institutions, there were very many such security
protocols and standards. They were usually in a digital form (that I might best explain in
physical form further below):
1. Rotate/change the "salt" on a regular basis.
2. Replace the old "salt" with the new "salt" in a 2-way hash algo every time a
new one is created.
3. Update the password hash (or even encrypted data).
In physical terms, think of it as the bank manager having a master key that must be paired with a
customer key to open a safe deposit box. This master key is changed at a regular interval, along
with all the locks. That way, even if the master key was stolen, it'd be just a matter of time
(hopefully short enough) before a new one is forged. But typically, the master key is replaced the
moment it is found compromised.
The problem with the above is that you need to store the master key SEPARATE from the system (the
bank premises in above example). Actually losing the master key will mean never being able to open
those safe deposit boxes, since you need the master key to reconfigure the locks on all boxes.
In digital terms, that means having a key server (server that stores keys). A very expensive,
highly guarded key server.
Do your installations require such high-end security measures?
As far as costs is concerned, it really is easier to protect just one "salt", and install all
manner of security features to alert you when it is spied. Once the "salt" is compromised, you can
ask everybody to reset their passwords manually (email them a random "initial/bootstrap" key).
If you're asking about adding a "salt" such that my password text of "sneaky" gets encrypted on my
server as "abc123" and on your server as "def456", then I'd say it's a simple 1-line change in the
OFBiz codes.
I haven't looked at your security library yet, so do tell me if there's a new and cheap and
effective security algo in the market. :)
Jonathon
Chandresh Turakhia wrote:
Give a day ; It will try to check the code line by line again. And map the code
with new library with plus and minus.
1 line answer : Configurability. Currently we have smartly create 1 smart
method which does 1 way encryption. But note it is same algorithm and some like
me hacked it :)
We can generalise and use more configurable.
Chand
----- Original Message -----
From: "Andrew Sykes" <[EMAIL PROTECTED]>
To: <dev@ofbiz.apache.org>
Sent: Friday, February 02, 2007 2:11 AM
Subject: Re: How do I decrypt passwords?
Chand,
Why is this better than what we have, what problems does it address that
you have found in OfBiz?
- Andrew
On Thu, 2007-02-01 at 22:26 -0800, Chandresh Turakhia wrote:
Team,
Is it worth looking at
http://www.jasypt.org/faq.html
Jasypt (Java Simplified Encryption) has released version 1.0. Jasypt allows
the developer to add basic encryption capabilities to his/her projects with
minimum effort, and without the need of having deep knowledge on how
cryptography works.
Feature Overview:
* It follows the RSA standards for Password-Based Cryptography.
* It is completely thread-safe.
* Can be both used in an "easy" way, with almost no difficulty, or in a
highly-configurable, power-user way.
* It provides comprehensive guides and javadoc documentation, to allow
developers to better understand what they are really doing to their data.
* It provides a Hibernate integration add-on (jasypt-hibernate) for
persisting fields of your mapped entities in an encrypted manner. Encryption
of fields is defined in the Hibernate mapping files, and it remains
transparent for the rest of the application (useful for sensitive personal
data, databases with many read-enabled users...)
* It can be perfectly integrated into a Spring application. All the
digesters and encryptors in jasypt are designed to be easily used
(instantiated, dependency-injected...) from an IoC container like Spring.
And, because of it being thread-safe, they can be used without worries in a
singleton-oriented environment like Spring.
* It allows a very high lever of configurability: The developer can
implement tricks like instructing an "encryptor" to ask a, for example,
remote HTTPS server for the password to be used for encryption.
----- Original Message -----
From: "Chandresh Turakhia" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <dev@ofbiz.apache.org>;
<[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2007 3:03 AM
Subject: Re: How do I decrypt passwords?
Andrew & Drew,
May I bring to light an different aspect of password generation :
It generates the **same** "encrypted password" every time. e.g
"test" may generate "XYXQ1111" . for the next test as password it will also
generate "XYXQ1111".
I needed to stop user from registering with standard passwords like
"test" ; "test123" ; "bharti" etc. All I had to do is run the program
which checks for these "standard generated passwords" and check with
"generated user entered password" in batch or online. It case string matches
, stop him from completing the process. I admit it was really dirty hack.
This is debatable issues - It is feature or bug :) Ofbiz being
Open source ; it has far more implication.
Can password generation be parameterized so the generated password
is different.
Chand
----- Original Message -----
From: "Andrew Sykes" <[EMAIL PROTECTED]>
To: <dev@ofbiz.apache.org>
Sent: Wednesday, January 24, 2007 8:08 AM
Subject: Re: How do I decrypt passwords?
Drew,
I believe the encryption is asynchronous, i.e. not reversible.
- Andrew
On Wed, 2007-01-24 at 10:33 -0500, Stephens, Drew wrote:
I have a question about decrypting passwords from the User_Login table.
We need to prepare a file of User ID and passwords to an external
system, I think I have found the programming used to encrypt and save
the password to the database but I could find not any logic to decrypt
the password. Obviously, if we can't decrypt we can't provide the
password. I don't want to reverse engineer the encryption logic and
then write a new decryption logic; I want to use something that already
exists.
We are running an old version of OFBIZ, I think 1.1 but I don't remember
exactly how to find out for sure.
Thanks for any help you can provide.
Drew Stephens
Rippe & Kingston Systems, Inc.
[EMAIL PROTECTED]
Phone: (513) 977-4573
Visit us at: www.rippe.com
1077 Celestial Street, Cincinnati, Ohio 45202-1696
========================================================================
=======
--
Kind Regards
Andrew Sykes <[EMAIL PROTECTED]>
Sykes Development Ltd
http://www.sykesdevelopment.com
--
Kind Regards
Andrew Sykes <[EMAIL PROTECTED]>
Sykes Development Ltd
http://www.sykesdevelopment.com
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.18/662 - Release Date: 1/31/2007 3:16
PM
