[Info-vax] Python 2 support ends 1-Jan-2020

[Stephen Hoffman]

On 2019-01-07 19:13:27 +0000, Arne Vajhj said:

> It is obvious that SYS$GETUAI can not store a 32 bit hash in an 8 byte buffer.

A 32 bit hash can easily be stored into eight bytes, of course.  But 
you knew that.  And I wouldn't bet that future password hashes will be 
constrained to 32 bytes.

> So programs will be broken.
> 
> But a logic in SYS$GETUAI like:
> 
> if uaf[UAI$_ENCRYPT] = UAI$C_MODERN then
>      if item.buflen < 32 then
> ....
> end if
> 
> would allow old programs to work as long as the user does not upgrade 
> password and would make it relative easy to update old programs.

Which does not address what's involved with using $getuai with the 
$hash_password in conjunction with the current eight-byte buffers and 
the salt as part of verifying a password against a password hash, nor 
with the data storage involved behind some implementations that save 
the hashed password values locally and not in SYSUAF, or the other 
sorts of incidental references to that eight-byte buffer.

(Here excluding those tools which directly access SYSUAF as that's 
undocumented and unsupported, though that access is necessary in some 
cases given there's no documented means to perform certain common 
operations.  I prefer to perform just the index key scans using RMS 
calls, and to "decode" the rest of the SYSUAF record using $getuai.  
But I know of folks that don't bother with $getuai calls and access the 
records directly, and that code will break when the size of the 
password hash is increased, and that irrespective of the multiple 
different ways that hash size increase could be implemented...)

This particular proposed $getuai algorithm also hasn't learned from the 
earlier design mistakes, but itemlists do classically lead folks into 
this particular design trap.  Here, I'd ponder using and requiring a 
128 byte buffer and zeroing any "unused" portion of that from within 
the system call, or (preferably) a dynamically-sized buffer in 
conjunction with two calls and each with its own itemlist.  But there 
are trade-offs, and multiple-calls and dynamically-sized buffers are 
more complex and—depending on the particular approach chosen—then 
somebody has to deal with the memory management.  And what does $setuai 
do?  Key off the user's input buffer size to determine the hash that's 
being written?

And PBKDF2, bcrypt, Argon2 and other schemes all prefer a larger salt 
size than the two bytes that OpenVMS presently offers. OWASP is 
recommending a 32 or 64 byte salt.  And yes, apps necessarily refer to 
and have buffers for the salt, as part of calling $hash_password.  And 
at times, the OpenVMS salt/nonce wasn't even particularly random.  But 
I digress.

LDAP adds a whole 'nother layer into this discussion, as the passwords 
are necessarily replicated.

TL;DR: App code will break.


-- 
Pure Personal Opinion | HoffmanLabs LLC