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

Security

Andrew Young
PLUS
Andrew Young
Courses Plus Student 639 Points
Posted by Andrew Young
Andrew Young
Courses Plus Student 639 Points

Security questions about login

I'm building my own login app, and I'm facing some security issues

1) If the site is like a educational/forum site without taking any personal information (we only takes the email, password, username, and their website URL), do we need to use OV/EV SSL or DV SSL is enough if we're not taking important personal information??

2) What kind of hash should I use when hashing users' password, and as or functionality and info we take provided above do we need to add salt or since it's just a forum we don't really need to add custom salt??

3) Should we use login proccess that others makes or the login proccess build by ourself is fine?

// we actually only need to verify username and it's password

//like the following code

// variable user is a object of users' username and password


var user = { john:{pwd:"123123"}};
if (user[username] && user[username].pwd == requestpassword) {
console.log("logged in");
}

1 Answer

Steven Parker
Steven Parker
231,269 Points
Steven Parker
Steven Parker
231,269 Points

:mailbox_with_mail: Hi, I got your request.

I'm not sure I'd consider email to not be "personal information", but it's certainly not as sensitive as a credit card number. So far non-sensitive low-volume traffic a DV certificate would probably be adequate.

Salt is such a common part of password encryption algorithms, I would probably just use it automatically. But it's value only applies to situations where someone has gotten access to your database. So if you feel your database is secure, and since the risk of a breach is apparently nothing more than forged or deleted blog posts, then it's probably not absolutely necessary.

And I don't see any advantage of using someone else's code over your own unless one has features you want and the other does not (and assuming you trust the 3rd party code)

Now the example code shows a password being stored and compared in unencrypted form, which is not a good idea.

Andrew Young
Andrew Young
Courses Plus Student 639 Points
Andrew Young
Andrew Young
Courses Plus Student 639 Points

Thanks, I'll make sure I hash the password but I still have some question

1) What method is recommend for hashing?

2) What do you mean automatically in the salt part?

Steven Parker
Steven Parker
231,269 Points
Steven Parker
Steven Parker
231,269 Points

New algorithms come out frequently, I think the currently the "best" one is Argon2. But bcrypt, which has been around for quite a while, is still a reasonably good choice.

By "automatically" I mean I would just incorporate salt in the design without really giving it much thought. It seems like "standard practice" to me to always include salt if you're encrypting passwords. But that does mean extra storage. An alternative to a generated random salt would be to use some other field already stored, such as the user's email, as the salt.

Andrew Young
Andrew Young
Courses Plus Student 639 Points
Andrew Young
Andrew Young
Courses Plus Student 639 Points

So will there be a big issue if you don't add salt??

If it's needed any idea for custom salt?

Steven Parker
Steven Parker
231,269 Points
Steven Parker
Steven Parker
231,269 Points

Remember the salt only matters if someone steals your database. It increases the computational difficulty of deciphering the stored passwords. And I updated my previous comment regarding salt source.

Andrew Young
Andrew Young
Courses Plus Student 639 Points
Andrew Young
Andrew Young
Courses Plus Student 639 Points

How about do you know will my code has the risk to be injected?

Something like SQL injection issue will my javascript code facing that issue?

Will some of my code be commented by the value of the login form input?

Steven Parker
Steven Parker
231,269 Points
Steven Parker
Steven Parker
231,269 Points

Injection attacks are only a concern if you use data supplied by a user to build a command and then execute it. "SQL injection" is a specific case of this where the command is passed to the database engine. Proper handling of the data (known as "sanitizing") can prevent this.

Speaking of SQL injection, I can't resist mentioning this XKCD comic strip. :laughing:

Andrew Young
Andrew Young
Courses Plus Student 639 Points
Andrew Young
Andrew Young
Courses Plus Student 639 Points

Also Steven,

I'm watching a youtube video here: https://www.youtube.com/watch?v=8ZtInClXe1Q&t=1s

And after I watched this I have some question:

1) Will adding custom salt (userid) prevent the hacker find out the same password when you have your database bleach?

for example:

The hacker got into your database, then they saw the hashed password, then they saw some users hashed password is same so they thought it should be a common, popular password.

With the example above will adding custom salt prevents this?

Steven Parker
Steven Parker
231,269 Points
Steven Parker
Steven Parker
231,269 Points

You got it. The salt causes hashed versions of the same password to be different.

Andrew Young
Andrew Young
Courses Plus Student 639 Points
Andrew Young
Andrew Young
Courses Plus Student 639 Points

How about encryption is the AES the best currently?

And also when we're building login system do we need to encrypt (not has) username (email) also since they might use the same username in other site and the hacker can prevent something like usernameinmysite';-- in other site

Steven Parker
Steven Parker
231,269 Points
Steven Parker
Steven Parker
231,269 Points

The "hashing" we've been talking about is the same as encryption.

Andrew Young
Andrew Young
Courses Plus Student 639 Points
Andrew Young
Andrew Young
Courses Plus Student 639 Points

But hashing in un-reversible so now I'm asking what's the best encryption currently

I'm using encryption to encrypt some other data

Steven Parker
Steven Parker
231,269 Points
Steven Parker
Steven Parker
231,269 Points

These also come out frequently, but I believe these are all currently considered very secure:

  • RSA
  • AES/Rinjdael 256
  • Triple DES
Andrew Young
Andrew Young
Courses Plus Student 639 Points
Andrew Young
Andrew Young
Courses Plus Student 639 Points

So let me make sure is AES symmetric and TDES and RSA asymmetric?

Also is there any ranking since looks like tdes has more keys then two other?

Steven Parker
Steven Parker
231,269 Points
Steven Parker
Steven Parker
231,269 Points

Those are all symmetric algorithms, I assumed that's what you wanted. I wouldn't worry about relative "ranking", those are just opinions and will differ based on the source.

Andrew Young
Andrew Young
Courses Plus Student 639 Points
Andrew Young
Andrew Young
Courses Plus Student 639 Points

Oh, I see, but why RSA's definition on wiki here has the following sentence

In RSA, this asymmetry is based on the practical difficulty...

And also in Asymmetric's wiki:

Some public key algorithms provide key distribution and secrecy (e.g., Diffie–Hellman key exchange), some provide digital signatures (e.g., Digital Signature Algorithm), and some provide both (e.g., RSA).

Also then what kind of asymmetric encryption would you recommend?

Steven Parker
Steven Parker
231,269 Points
Steven Parker
Steven Parker
231,269 Points

As stated in the wikipedia page, "More often, RSA passes encrypted shared keys for symmetric key cryptography ...".

And any meaningful recommendation for encryption would need to be based on a complete understanding of how it will be applied and the type of content it will be used on.

We seem to have diverged pretty far from the original question. Questions on other topics should have separate posts so people not already following can contribute.