Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
premsai kandagatla
Courses Plus Student 5,142 PointsIs it recommended to pass sensitive info like Passwords/CreditCard Plain Text without encrypted over HTTP/HTTPS?
- What is the recommended way to pass password over HTTP with encryption or without.
- What is the recommendation for validating encrypted passwords like comparing encrypted ones or compare the decrypted with plain text
- If we use encryption logic and secret key in javascript are those will be visible to hackers using developer console of browsers.
- How we need to tackle passwords sending over https using Angular/AJAX/ any front end technologies.
- Do we need to trust 100% on HTTPS and SSL that are safe to pass sensitive information like passwords, credit card numbers.
1 Answer
Fletcher Cutting
Web Development Techdegree Student 1,463 PointsIf you're dealing with passwords, always use HTTPS. Never use HTTP. In fact, always use HTTPS regardless of what you're doing, especially if you're dealing with sensitive information. This is because HTTPS will encrypt the traffic between the browser and the web server for you, so you don't have to change anything. Send the password as "plain text" in the POST request and as long as it is using the HTTPS protocol and is secured, the traffic will be encrypted for you.
When passwords are stored in a database, they are not encrypted, they are hashed. The difference between the two is that "encryption" infers that the information can then be decrypted. Whereas once a value has been hashed, it cannot be "unhashed". So even if a threat actor did somehow get access to your database, all they would see are password hashes and aren't able to see what the password actually is. Another key aspect of a hashing algorithm is that if you are given the same input, the algorithm spits out the same output. So when checking if a user's password is correct, hash the input password and compare the output hash with the hash stored in your database.
Technically, yes. If the secret key is at all sent to the browser (even over HTTPS), it can be read by the person using the browser. But as I said before, don't bother with encryption on the user side. Trust the HTTPS protocol and send the password in "plain text" in the POST request, hash it on the server, and then compare the hash with the hash stored in the database.
If the password is being sent via a secure protocol, such as HTTPS, then you don't need to worry about it as I've already explained. However, as I said at the start, never send data over an unencrypted protocol. Last time I checked, AJAX is also an encrypted protocol.
If you plan on implementing a login system yourself, please do lots of research on best practices when it comes to password hashing and storing the hashes. Also make sure to use a modern and secure hashing algorithm, like SHA-256 and not MD5. MD5 is an old and weak hashing algorithm and should not be used anymore.
If you're not comfortable implementing your own login system, then I would suggest looking into third-party APIs you could implement, such as Google Firebase. Google Firebase is very well known, secure, and has lots of documentation on how to use it with common front-end and back-end frameworks.