Password does not match when ity should

Wappler General
#1

Hi, Today I have tackled the signon process. All went well until the login page would not recognise a valid password. Here is the story…

I have deliberately left the password box as text rather than password just to see what is going on (a bit). The Signon form creates a user successfully and saves the encrypted password successfully.

image
image602×552 66.8 KB

image

The formula used in the Insert is sha512 with a salt of tempsalt.

image

The Password in the security steps is also on the same formula

image
image359×613 8.2 KB

But when I attempt to log in with a correct password, I still get a 401

image

The Login form has passed the correct values

image

Is there any way to see what the Password encryption results in?

Would any of the other encryption methods be better to use?

#2

From the screenshot, it seems you are not using encryption. What you are using is hashing.
Which is one-way. You cannot un-hash the string to plain text.

But, you if you have the plain text & salt, you can use https://convertstring.com/Hash/SHA256 to find the hashed value & compare it manually with the DB.

#3

Thankyou Sid, I did visit the web site for sha512, and it did generate the same result as wappler, except all the letters were in upper case

C3A19583120687B6401222A9046386636DF9F829B627B978D7F8A688153CC63B5EF520C9CAE0A34733C39DCBF91935BB4317A45C0780D4C92E0E5B67C7DC3EAB.

The problem is, as far as I can tell, that the wappler encryption or hashing when saving the password is the same wappler encryption or hashing when comparing the password during the subsequent login. I do not know why they should not be equal, as per Paul’s very good ‘Create Login’ tutorial on Youtube.

How do I create a login that will work with a valid password?

#4

Are you sure the database field you are storing the password is properly set up to store the length of the sha512 hash?

#5

Hi Teodor, yes, the field is varchar(255), the encrypted password is 128 chars long.

#6

So are you using the same salt and hashing options for the login step? They must be the same as the ones used in the insert user step.

#7

Sure am, you can see that in the screen dumps above.

#8

Something is not correctly setup somewhere. Double check your security provider and the login step again to see if you are using the correct database table and columns for user/password.

#9

I will recreate the login form, because I just tried it without any encryption on the passwords and I still got an 401. So it is not an encryption problem.

I will start over and see where that gets me.

#10

There is one thing that I do not get, because there is some background logic going on here, when I type in the username into the login form, does wappler automatically find the correct User row to compare password to. There was nothing explicit in Paul’s tutorial to do this, but he only had 1 row in his user table at that stage, so it worked for him.

Should I be using single get to align onto the correct row in the User table? If so do you have a procedure for that?

#11

Well when you setup your global security provider options you select a database table which stores your users info as well as the login and password columns.

Screenshot_2
Screenshot_2766×578 57.1 KB

You can have as many users as you need in your database table.

#12

Hi Teodor, I did find the problem. Way back in the security documentation there is a chapter on Argon2, and in that procedure there is a tick box, ‘Use Password Hash Verify’. That was still ticked on. Untick it and everything works for sha512 etc.

So the last question in this is, Argon2 is different, is it better and why?
Which is the most secure of the encryptions available in wappler?

#13

Yes it is better and no that doesn’t make sha512 insecure :slight_smile:

It’s the Argon2.

And there’s a tutorial explaining how to use it:

#14

Thank you

#15

Hey @BruceX,
Argon is better however…
Before you dive into Argon, I got caught out recently because I used it on a PHP project and then wanted to transfer it to a new NodeJS one. At the moment, NodeJS in Wappler does not support Argon which means having to revert back to SHA512. The difficulty is then authenticating and saving passwords in that format to allow people to log in to the new system when they were stored using a mechanism not supported within NodeJS.

I would say that if you are considering NodeJS at all - currently I would stick to SHA512. It is easier to change it later to Argon than starting with Argon and trying go the other way. And as @Teodor says, it is secure, just not quite as secure as Argon.

1 Like
#16

Hi bpj, thanks very much for the hint. The NodeJS is on my ‘to-do’ list but way down the track. But it is worth taking this into account.

#17

Can you quickly explain what the ‘Use Password Hash Verify’ actually does? And why that’s only available for Argon2 and not any other hashes? Finally, if it’s a requirement of Argon2 but should not be used with the others, why is it an optional checkbox and not just automatically implemented when Argon2 is chosen?

Sorry, I’m just a little unclear on this.

#18

The password hash verify is only used for Argon2 algorithm. It cannot be used with SHA- hashing methods.

#19

But what does it do?

#20

It verifies the password of the user who is logging in. With Argon2 method you don’t compare the hash of the user logging in with the hash stored in the database. You use the password hash verify option. It’s already explained in the tutorial I linked to.