Totally agree with you @ben I have one I’m working on where I could do with hashing the address and surname of the member.
All I can assume is that people tend to use the same password for multiple things, so I guess thats the reason they recommend hashing it.
Yeah, for me, I agree with what you are saying, however my goal is not to protect the user on their journey through the entire web, and rather only on my single website.
If I hash their password for my site and my database gets hacked, the hacker can not see the password, so they can not login to my site with their password to do more damage.
If on the other hand the hacker now has enough information on the user to steal their identity or hack their DMV records or something hollywood style then im sorry for them.
Maybe if it were a website i was creating for my closest friends and family I would do it different I suppose.
But, yeah, mind blown, never really thought about it to be honest, I am still busy dealing with this so im a little behind the curve here.
Luckily Dave has given me some pointers, but to be honest none of my sites kind of protect against this.
@ben, @Hyperbytes do either of you already have a solution in Wappler for this.
We utilise separate DB’s that hold access credentials then use various measures to relate back to data across our networks. All registration data is hashed (the bare minimum, a recovery E-Mail and sometimes telephone number for 2FA), both username and password are encrypted. If a threat hits our registration tables they then still have to back track to the data located on a different box on another network. We regularly enforce User password changes and we generate the passwords not the User (we have been strict about this for years). Usernames can not match E-Mails, simple things really. Still doesn’t matter has have many a time seen even the best get breached. Can only do what you can, then you need to consult the experts and open the wallet up. A lot more restrictive with certain Clients who already have data protection mechanisms enforced. We then abide by those but always advise if we feel they are not up to capacity.
1 Like
Oh and always delete the silly test accounts which developers tend to create and forget to delete! AMAZING how many people don’t clean up. All starts with good house-keeping!
If you want to encrypt data other than passwords which of course will need to be decrypted then you can use the Encrypy/ Decrypt with Password formatters to encrypt/ decrypt any data such as names and addresses
1 Like
My recommended read for the day…
The definitive guide to form-based website authentication
N.B. you may need the day to read it!
This article also nicely explains other factors that should be considered when designing a login system.
I’ve started to switch from SHA512/256 to Argon2 for hashing passwords.
It would be nice for Wappler to include this within the UI. You can vote for it here.
Last piece of advice, consider outsourcing your authentication system. Systems such as Firebase Authentication (Google), Auth0 and Okta exist solely for this purpose. They have some very smart people working full time on this.
2 Likes
I have only read the first 30% and I never want to make a form again, hahahaha, what a pain, I see why it may be quicker and easier to sometimes outsource this type of thing, certainly if your site has a wide audience or if any money is involved.
Thanks for the extra info (I think)… @max_gb
Ignorance is bliss I tell you.
1 Like
Having spent today reading The definitive guide to form-based website authentication , I can understand Paul’s reaction after digesting an article that was written nearly 12 years ago.
Skipping all of the hype, a password has 3 states (2 if ‘remember me’ is not utilised), namely
- sending
- storing
- remembering
Sending
This is what the article states:
Unless the connection is already secure (that is, tunneled through HTTPS using SSL/TLS), your login form values will be sent in cleartext, which allows anyone eavesdropping on the line between browser and web server will be able to read logins as they pass through. This type of wiretapping is done routinely by governments, but in general, we won't address 'owned' wires other than to say this: Just use HTTPS.
In other words, when using a secure protocol, there is no need for a hashed password.
Storing
This is what the article says:
This may finally be common knowledge after all the highly-publicized hacks and user data leaks we've seen in recent years, but it has to be said: Do not store passwords in cleartext in your database. User databases are routinely hacked, leaked or gleaned through SQL injection, and if you are storing raw, plaintext passwords, that is instant game over for your login security.
If the database has already been hacked, the password should be if least concern. Who cares about login security when the data has already been exposed.
Remembering
This is what the article says:
Persistent Login Cookies ("remember me" functionality) are a danger zone; on the one hand, they are entirely as safe as conventional logins when users understand how to handle them; and on the other hand, they are an enormous security risk in the hands of careless users, who may use them on public computers and forget to log out, and who may not know what browser cookies are or how to delete them.
I used to think that the cookie would be a security risk and have even verbalised this in a previous topic (can’t find it). In that discussion @patrick advised me that the cookie was perfectly safe to use when using the Wappler procedure.
12 years ago when public computers were the go, logging out would have been a concern. Fast forward, with the advent of mobile devices, public computers are a rarity. Even so, this should not be a reason to not utilise a remember me function and has nothing to do with password hashing.
Conclusion
The only reason for password hashing is to stop hackers from using the password to access the data that has already been compromised. Makes no sense.
This reminds me of the bloke running from a clinic wrapped in toilet paper. When asked why the wrapping, he replied ‘I am full of shit’.
The question that arises from reading your post, why take all of these security measures when the database has already been hacked.
The hacker is not interested in login information, they already have access to the data.
Sorry to be so polarised, I am playing the devil’s advocate with the aim to obtain real reasons for hashing passwords.
To help disrupt just that. If we can see persistent activity hitting a database we know to act. If the data is of no use to the threat and hashed what is it worth Ben? Are you saying don’t protect your sensitive information? You know in Europe we have data protection, storage, and integrity laws?
I don’t get the point of this discussion? I mean I understand the question but what answer are you seeking?
I think there is a HUGE difference between what some of us do. Basic design and development is fine and dandy but enterprise is entirely different. We use a lot of MySQL functionality and other methods to protect our clients data, we do not rely solely on the capabilities of Wappler to do this.
That’s my problem, I do not know the answer that I am looking for. Actually, I do especially when I read, with which I totally agree.
What I am getting at is the futility of password hashing when the rest is there to see in plain text. @Hyperbytes (Brian) has hinted at encryption/decryption, but if a person is clever enough to hack a database, they are clever enough to decrypt the data.
I read that you are using separate databases, which makes sense. Are these databases on the same server as the website?
Edit: I see that they are on different networks,.
This is not a common practice. If the password is truly secure it is incredibly difficult to break the hash. Really really really difficult, well unless a really poor algorithm is used, the password is short, contains only characters, or is re-used elsewhere. The thrill of the chase is dumping the entire DB to pastebin, hashes and all! If your DB gets compromised the integrity of your hashes is the last thing on your mind! 
No never. They are located on white listed networks with specific requirements to connect (specific IP address). Each DB User is caged and can only perform the actions required by that User. All data is replicated to multiple offsite locations. If in doubt about anything we will drop the server and redirect traffic to another location while colleagues investigate any attack, positive or false. We will then resume normal service. If the data is super sensitive we always seek the advice of DBAs and security professionals, usually at great cost. We host all of our services.
Thank you for the explanation, Dave, much appreciated. I am all for security and will do my utmost to facilitate same.
Coming back to earth, how can I interpret the security that you have in place for a large organisation back to a modest website for a local retailer wanting to sell their wares online. The database consists of Products, Orders and Customer information. I am not too worried about the first two tables, it is the customer information that needs protecting. Does this mean that it is better to use a 3rd party to hold that data? This, of course, would increase the costs for the retailer. Or would it suffice to do as I have been doing and hash the passwords in a database on the same server as the website.
I’ll be honest Ben I’m a parasite for listening in on conversations between the ‘experts’ and then harvest these discussions and implementations and then try in a poor mans world to replicate them. We also inherit policy’s from the Client whereby they already have procedures in place either for conformity purposes or dictated by necessity (financial information carries with it certain inherent responsibilities). I’m by no means any kind of expert on this but I’ll try to answer…
Transitioning from your current situation really depends on the complexity and volume of the data you wish to manipulate. A degree or two of separation is always a good thing and doesn’t have to be too complicated. Hosting is cheap these days so you can just PPM for a relatively decent database service and move over the registration side to the new provision. Then adapt your current platform to integrate with the offsite services. With regards to the data you have already collected this can be difficult and time consuming depending really on how far you wish to go. The essential part is obscuring the sensitive side. Not everything needs so much attention. We secure first name and last name, E-Mail, Telephone, and Mobile. And quite obviously the password and username. You could also look at using solutions like OAuth and allow them to take care of the overly complicated side for example, other similar offerings are widely available whereby your access credentials are stored and managed by an offsite provider etc…
Like I said I’m not an expert Ben. Just some ideas we have implemented or have been required to do so.
1 Like
Thank you Dave, I have learnt a lot from this discussion. It has made me think more in depth about site and data security.
For the moment I’ll stick with hashed passwords (to make me feel better) and shall do more homework regarding the rest.
Thanks from the up and coming parasite 
1 Like
You’re more than welcome Ben. If you happen to find anything interesting I’m always interested in devouring more input. These days we are fortunate to have some deep pocket Clients with crazy scaling and security. Sometimes I’m so far over my head listening to these folk chat it’s literally like sitting in a room full of Arabic speakers when the only language you understand is English!
1 Like
Hi @ben,
I think Dave has already answered some of the points in detail but just my two cents,
In other words, when using a secure protocol, there is no need for a hashed password.
I have to disagree. Passwords should always be stored as a unique hashed value in the database, never plain text. As a systems administrator you should never want to see what a users password is. What this point refers to is that data in transit should always be sent over an encrypted network such as SSL. This is to prevent a man in the middle attack and your clients data being stolen before it’s even reached your database.
If the database has already been hacked, the password should be if least concern. Who cares about login security when the data has already been exposed.
Again I have to disagree. A large proportion of users across the internet use either the same password or similar variants of that password for various services. If your user uses the same password as their bank and you also store their email address and other personally identifiable information within the same schema, you’ve both got a problem. Not only that but these days users information is sold in packs across the dark web. Admittedly for not a lot per user but this information is then used for phishing, identity theft and other criminal activities. It’s more than likely that some of our personal information is already being sold somewhere on the internet.
The only reason for password hashing is to stop hackers from using the password to access the data that has already been compromised. Makes no sense.
Would my users trust my app and myself if I put this statement on my signup form?
4 Likes
Do you not feel a sense of duty to protect your user’s data, including their password?
Do you fear the repercussions of a data beach that leads to bad press and includes the fact that you stored passwords in plain text?
Are you an organization that has multiple systems where users tend to use the same password, where a breach in one could lead hackers to have credentials to access other systems?
I think you have missed the point @kfawcett
What Ben is saying is that he has been using password hashing for years already, and always does, however in the case of a hacker breaching his database and seeing a list of passwords all already hashed as they would now, surely more than just the password should be encrypted, such as the users private details, like their name, address, telephone number, etc.
Ben feel a sense of duty to protect his users passwords, and all their other details too, which is more than most of us do.
1 Like