Encrypted password help/advice

I'm creating a new admin system and I'd like to find out more about encrypted passwords...

There will obviously be a user table in the MySQL database - what type should the password field be? VARCHAR, or is there a specific encryption/encrypted type?

Will SecurityAssist automatically deal with encryption?

I tried running through the SecurityAssist Wizard but when I choose to remove the Registration page, which I don't need, it crashes Dreamweaver (CC 18.2 10165 Build).

Thank you.
NJ

EDIT: Just watched a wee video series on Salting and Hashing...urggh. :( Does SecurityAssist do this for you?

It depends on the type of encryption you are using. What do you want to encrypt and what hashing or encryption algorithm are you trying to use? It is possible to do, but some types require some hand coding.

I was able to run the wizard without the registration page, but you can always run the wizard with it and just delete it afterward.

I'm storing usernames and passwords, along with user contact and account information. The article I read mentioned sha512?

I would usually just use the MySQLi Log In User and Restrict Access to Page etc, but passwords are stored in database as plain text which is just awful.

I started digging online about what standard procedure is for storing passwords in a database and found an article about 'hashing' and 'salting' and basically saying that you really need to things that way to offer any kind of security should your database get hacked.

I'm not clear if SecurityAssist does either.

SecurityAssist supports encrypted passwords with sha512. The latest version in DataBridge V2 supports hashing and salting in the libraries, but that would require some hand coding.

The thing that SecurityAssist wouldn't help with is going through and encrypting or hashing the existing records since they have already registered. To do that you would probably use the DataBridge update server behavior to loop through the entire database and update the passwords. This would require some hand coding and is dangerous since any mistakes might leave you with a database of users that can't log in. Make sure you back up your database before attempting this.

I'd start by encrypting or hashing a single user's record (yours) and create a separate login page to make sure you have all of the kinks worked out. Then build the page to encrypt everyone's record once everything works properly, making sure to back it up in case you make any mistakes.

Consider how necessary this really is. Do you store sensitive data in your database that you are worried about a hacker getting access to? The level of encryption should match the application and what data is being stored. If you have credit card numbers and social security numbers, then hashed passwords and encryption on those fields is necessary, but if you are just maintaining a member directory, then it might be overkill.

I think I can handle the hand coding, I just wondered if SecurityAssist did this by default or not.

My concern is that any system that stores a username and password, as plain text, is problematic because it's very likely that people will have registered using a username/password combination that they use elsewhere too. So it becomes a question of liability, if a system we've developed is hacked and the profiles are used to gain access to other systems - Internet banking etc.

In an era of increased GDPR I think it's sensible to remove as much potential liability as possible. I agree that it might be overkill but if we build every system like this when we won't have that concern PLUS we're only building one version of this system as opposed to two.

I appreciate what you're saying about existing registered members/customers - that does sound like a headache.

Thanks Ray.
NJ