Search results

PassWordHash is binary(64) in the table. Just FYI.

Yes. That's it. Thank you! One more question. Why doesn't this work? This is how I would validate the user, correct?

I get what I would expect: 0x24D6EDB8DBE2BCA27CFEFC1B0682BB7C34A0F5AA23EC6EA2724CC0DBFDBB9EB3D6BC90FEA92B84C0820DB784319ED53E6FB5DE74B19C36FEDE0C594D374792CD

The salt in my sproc is commented out. I have two options in the sproc: salt and no salt. I tried them both.

@sonic8 - Below is the sproc. I call it with: exec uspAddUser 'jsmith','joseph','John','Smith','0' USE [Notes_TEST] GO /****** Object: StoredProcedure [dbo].[uspAddUser] Script Date: 7/26/2024 10:06:39 AM ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER PROCEDURE...

@cheekybuddha - The online converter was referenced by the author in the article posted by DocMan. I just wanted to point out the frailties of hashing strings. If someone can use: then all bets are off in so far as validating encrypted passwords is concerned. @sonic8 - I will post that...

From the article: If you type "Let's eat" into the suggested online calculator you will not get the hash that the author claims. However, if you copy and paste "Let's eat" from the article into the calculator it will return the promised hash. The author gives no explanation for this.

Thank you Doc_Man. I will study this right now.

No. I took the salt out of my process for now until I get the basic hash to work. It shouldn't need salt, correct? Salt just adds another layer of security. I will add that back in once I get the basic hash to work.

I replaced @pPassword with 'joseph' in my sproc and got the hash that all of the online converters agree is correct. This means that I cannot trust the passing of the string into the @pPassword parameter of my SqlServer sproc. So, sonic8, your guess is correct. This is most disappointing. What...

Okay. I have everything in my interface working now thanks to all of you! My problem now is that the SHA_512 hash returned by Sql Server is completely different than the SHA_512 hash returned by the online hash calculators. Example: For the string 'joseph' Both https://sha512.online/ and...

This is exactly what I needed to see! I'll take it from here. Thank you to everyone for your time and advise!

I appreciate your time and advice with this sonic8! It is necessary to validate the user again in the app to ensure that he has been permitted access to this specific Access application. Are you suggesting that a login screen along with its validation process is not necessary when using...

Yes. But how is that relevant? I do know how to compute the hash. That's how I was able to encrypt it. But I don't understand how to validate it from my Access front end. I downloaded your bas file (thank you for making this available!) but I must believe that there must be a way simpler way to...

dbGuy - No. They are authenticated through WIndows. sonic8 - How do I ?

Not sure I understand your question DBguy. I need to validate the password that the user enters in the front end interface of my MS Access program - and I don't know how to do that. The password is encrypted SHA2_512 in a back end SqlServer table.

plog - Apparently I use the wrong phraseology. I don't want to decrypt the encrypted password. I just want to validate it. How do I do that? Do I use VBA in my Login form? Is this done on the Access side or the Sql Server side? Can you please clarify?

I finally succeeded in encrypting the user passwords in my back end Sql Server database Login table using SHA2_512. Can someone please point me in the right direction tp decrypt it via my front end Access interface? What would the query look like? Below is what the data in the linked Sql Server...

I'm not hearing of any error messages - but I remoted into the user's machine and saw that something was definitely hogging memory. I'll look more deeply into this on Friday. Thanks for your help!

Yes. Of course.