Re: How to validate passwords without storing them anywhere.

I think the idea using a password to encrypt and decrypt a string has
merit, however as with all security measures there seem to be tradeoffs.
You're using standard SQL procedures to encrypt and decrypt a "common"
string; By common, I'm referring in this case to your use of the word
"VALID" in ENCRYPT_TDES() and DECRYPT_CHAR() procedures. What happens when
that common string "VALID" becomes generally known?

Also, since the encrypted value is stored in a database, what would prevent
someone from using SQL SELECT with DECRYPT_CHAR() in a brute-force attack
to find out all the passwords?

On Wed, Mar 17, 2021 at 12:46 PM Calvin Buckley <calvin@xxxxxxxxxx> wrote:

This sample is really concerning without any attention to salting... or
cryptography. Not only is 3DES very busted, it's also not the
appropriate algorithm assuming it's secure. You'd want one-way hashing
(the archetypical example is MD5, but it too is old and busted), plus
salting so someone can't just precompute a bunch of hashes.

Ideally, you'd want password hashing algorithms designed special-
purpose, like bcrypt (disclaimer: I have an ILE port of bcrypt, all
open source). Those are specifically optimized for password hashing by
being expensive to hash, whereas MD5/SHA are designed to be cheap
(because they're designed for general integrity).

On Wed, 2021-03-17 at 17:29 +0000, Rob Berendt wrote:

-- How to verify passwords without ever storing passwords.
-- Thanks to Darren Strong of Dekko.

-- The basic concept is that you do not store the password.
-- Instead you store a common string encrypted by the password.

-- As a war on 5250 tools the "short names" are obscured.

set current schema = 'ROB';
CREATE OR REPLACE TABLE Security_table for system name T000000001
(
Security_id for column C000000001 varchar(100) ALLOCATE(10) not
null constraint Security_table_primary_key PRIMARY KEY,
Security_name for column C000000002 varchar(100) ALLOCATE(25) not
null,
Password_Encryption for column C000000003 varchar(256) FOR BIT
DATA
)
RCDFMT T00000001R
;
-- Let's say the password is Budweiser#01.
-- So you encrypt the word VALID with that as an encryption key and
all you are really storing is VALID.
insert into Security_table (
Security_id, Security_name, Password_Encryption)
Values('ROB', 'Rob Berendt', ENCRYPT_TDES(varchar('VALID'),
'Budweiser#01'));
-- Now when they enter their password you pass that as a decryption
key to see if it is valid.
Select DECRYPT_CHAR(Password_Encryption, 'Budweiser#01')
from Security_table
where Security_id = 'ROB';
-- Test to see if the user 'ROB' was found'
-- Test to see if the encryption key was valid by checking the value
returned.
-- If the value returned was not the word VALID the person entered an
invalid password.
-- Or don't let the user know they guessed the userid and return
generic error if either is invalid.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com