Topics

Remove PlaintextPasswordHash from API?


Will Hopkins
 

EG:

I'm thinking we should probably remove this from the API. It's trivial for someone to implement if they need to (we could retain the Impl in the RI), but nobody should ever use this in a production setting. It should not be used even for a legacy environment -- if the plaintext for a password is known, it can be converted to a hashed format. Given the frequency with which hackers are able to get access to password databases, storing plaintext hashes constitutes security malpractice and borders on criminal negligence.

Any objections?

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Ivar Grimstad
 

No objections here.

Ivar

On Wed, Jul 26, 2017 at 8:08 PM Will Hopkins <will.hopkins@...> wrote:
EG:

I'm thinking we should probably remove this from the API. It's trivial for someone to implement if they need to (we could retain the Impl in the RI), but nobody should ever use this in a production setting. It should not be used even for a legacy environment -- if the plaintext for a password is known, it can be converted to a hashed format. Given the frequency with which hackers are able to get access to password databases, storing plaintext hashes constitutes security malpractice and borders on criminal negligence.

Any objections?

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

--

Java Champion, JCP EC/EG Member, JUG Leader


Arjan Tijms
 

No strong objections here either. I do absolutely agree that storing passwords in plain text in a production DB does border on criminal neglect.

The only somewhat excuse is that not all usage of Java EE is necessarily production usage.


Guillermo González de Agüero
 

But even for development, having a standard implementation that takes care of generating hashes for creating new accounts seems enough to me.

+1 for complete removal (even for RI). 

El mié., 26 de julio de 2017 20:51, Arjan Tijms <arjan.tijms@...> escribió:
No strong objections here either. I do absolutely agree that storing passwords in plain text in a production DB does border on criminal neglect.

The only somewhat excuse is that not all usage of Java EE is necessarily production usage.


Will Hopkins
 

Thanks, everyone. I'll go ahead and remove it, then.

On 07/26/2017 02:53 PM, Guillermo González de Agüero wrote:
But even for development, having a standard implementation that takes care of generating hashes for creating new accounts seems enough to me.

+1 for complete removal (even for RI). 

El mié., 26 de julio de 2017 20:51, Arjan Tijms <arjan.tijms@...> escribió:
No strong objections here either. I do absolutely agree that storing passwords in plain text in a production DB does border on criminal neglect.

The only somewhat excuse is that not all usage of Java EE is necessarily production usage.

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803