Verify password hash - error

What can cause this error?

Password-hash: Unsupported algorithm.
It is mentioned in the documentation, but there is no explanation of how to fix it.

Is it possible it won’t work if the call is made from a method that was called via EXECUTE METHOD or a plug-in like Active4D.

[]34658483;“error on Verify password hash command”[/]


4D client and server
Windows Server 2016

I think it is more likely the error is due to the method used encrypt the password. Did you use 4D to encrypt the password? Does the encrypted password look the same as what you get with Generate password hash?

We’re using pure 4D commands. We’ve been using these commands for over a year for our own 4D user login system with no problem.

What’s new is that we were replacing an old TEA based encryption/decryption algorithm with the one-way hash for web users.
The code is all in 4D methods, but called via Active4D. And, the only time we’ve seen it fail is with a particular (insecure) 6 character password - which I can’t post here, but will give to 4D tech support if needed.

<code 4D>

$hashOptions_ref:=New object(“algorithm”;“bcrypt”;“cost”;12)
$0:=Generate password hash($password_t;$hashOptions_o)

// this seemed to make a difference in some cases
$0:=Generate password hash($password_t;New object(“algorithm”;“bcrypt”;“cost”;12))

// and
$boolean:=Verify password hash($password;$hash)

</code 4D>


4D uses standard bcrypt.

You can try your hash by using any bcrypt library (such as PHP or NodeJS), or use one of the many online bcrypt generators. I assume that hash is wrong…

I will log the hash out to disk with success or failure status, then check against an online tool.

But, the hash is generated by 4D, and verified by 4D.
That implies that we changed it when it was stored in a record or retrieved from a record.
The hash is stored in a text field, and other than changing from the old encryption to the new hash, the code has been working for about 15 years.

The error comes up with algorithm not supported, not that the hash doesn’t match.

For example, in order to do a quick test, we made a SuperReport (plugin) and put the code in scripts.
At first, we got algorithm not supported errors.
When we put the Generate password hash code in a single line (object created in line - no variables), it worked.
We put that same code in our web login, it didn’t help.

What would cause the algorithm not supported error?


Can you call a 4D method from Active4D? I expect Active4D is equally limited to SRP and could be it works in 4D, but not in a plugin.
Script execution in SRP is limited by possibilities given: EXECUTE (actually PA_ExecuteTokens & PA_ExecuteTokensAsFunction).

If it fails with EXECUTE METHOD, then sorry for disturbing, I have no idea.

Just FYI…

There is a typo in the sample I posted.

$hashOptions_ref vs $hashOptions_o

(The actual code does not have that typo).

I’m sorry, I cannot tell you about SuperReport.
We tested only inside 4D code.
For security related code I personally think it is more safe to have that in compiled code and not in scripts, but your decision.
If you find cases where the code fails in just 4D methods or need help here, please open a TAOW case to have someone trying to reproduce this.
In our automatic testing and in our own production use we do not saw such cases.

Sorry, I see I wasn’t very clear in my earlier posts.
(And yes, a TAOW case has been opened).

We have been using Generate password hash for our own 4D login system for a couple of years.
We made a 4D method to call Generate password hash, so we would always use the same settings - bcrypt, cost 12.
All native 4D code, no problems to date.

We just began using it for web based users. Our web solution is based on Active4D.
Prior to this we had used TEA encrypt/decrypt code posted to the 4D community many years ago.
Now we don’t want to store decryptable passwords, so we’re using Generate password hash.

We are seeing it fail on a single, short (bad) password, when logging in from the web.
It does not fail if we use that same password for our home-grown 4D login.
The customer wants it fixed, and the customer is always right! :slight_smile:

We had trouble reproducing the error on our own systems, so we were attempting some tests on their system.
One way to do that is to create a SuperReport to call the password hashing and verifying routines.
We also tried it from an execute command utility we have in our 4D app. It also throws an error there.

It seems like it might be related to calling the code indirectly - from execute or from a plugin.

could it be, that the option object is not created, or that the properties “algorithm” or “cost” are somehow not defined? when you use SuperReport or your execute command utility with debug logging, do you see the object content? or, if you call the command via a wrapper method, and trace that method, does it get the expected parameters?