I'm just a bit curious about website security.

[zerophase]

I'm asking this here since it's my understanding that the FreeBSD community knows some of the most about security. Me and a friend have been having a discussion if we should keep the code handling passwords and user account management (updating passwords, etc) on the server side vs letting Javascript handle. He's convinced we need Javascript running on the client side for the user to login. I was pretty certain that css could accomplish a lot of the pretty ux issues he wants on the page. It's my understanding that pretty much all of the fancy ux stuff that's done with js can be done with css. Is hashing the password as well on the client side necessary or even worthwhile when the site is on https? Is there any reason to not minimize Javascript usage. It just seems like a mess of a language, with rails / ruby being preferable when possible. (if it doesn't effect performance / security)

 

[usdmatt]

Strange place for this question when it's your first post and has nothing to do with FreeBSD...

You both need to read up on what you're doing, because neither of you seem to have any idea.

Because I'm feeling generous, I'll give some pointers.
Do not do any login handling client side. Submit the details over HTTPS and do it server side. Passwords should generally be stored in your DB hashed with a salt. You then hash the user provided password with the same salt on the server and compare the two. Make sure you use a secure hashing function. Some languages these days have built in password hashing libraries, implemented by people who (hopefully) know what they're doing, so use those if available. If any of this doesn't make sense, do more research.

 

[drhowarddrfine]

Me and a friend

A friend and I ...

have been having a discussion if we should keep the code handling passwords and user account management (updating passwords, etc) on the server side vs letting Javascript handle.

The rule is, never trust user input, so always check and verify data submitted to you. Even if you check it client side. I would only check formatting client side.

It's my understanding that pretty much all of the fancy ux stuff that's done with js can be done with css.

A lot of effects, certainly not all or most, can be handled by CSS but you need to check which work in the browsers, and on mobile versus the desktop. Javascript will be more flexible but also slower and will fail if it doesn't get downloaded or corrupted in some way.

 

[zerophase]

Strange place for this question when it's your first post and has nothing to do with FreeBSD...

You both need to read up on what you're doing, because neither of you seem to have any idea.

Because I'm feeling generous, I'll give some pointers.
Do not do any login handling client side. Submit the details over HTTPS and do it server side. Passwords should generally be stored in your DB hashed with a salt. You then hash the user provided password with the same salt on the server and compare the two. Make sure you use a secure hashing function. Some languages these days have built in password hashing libraries, implemented by people who (hopefully) know what they're doing, so use those if available. If any of this doesn't make sense, do more research.

That's what I what I thought we should do. The only other thing I had read was hash the password with Javascript, and then hash that with rails, which I think might cause hash collisions. From my understanding hashing on both ends isn't necessary any more with https.(to prototect against man in the middle attacks) We'll probably run sha256 or sha512. We're using Bcrypt to hash and salt the password.

Again I came here, since the BSD's seem to be focused on security, while Linux favors performance over security. When I build a server or nas I'd be running one of the BSDs on it.

 

[usdmatt]

I'll clarify that I'm in no way a security expert, but I've never come across hashing passwords at the client end.

Let's say someone gets in the middle and retrieves a users' username and client-side hashed password.
What stops them from downloading your login page, modifying the JS so it no longer bothers doing the hash, then just typing the username and hash directly into the login fields? You've not really added any security at all.

I don't think collisions is that much of an issue. I believe hashing multiple times is actually fairly common (number of 'rounds'), as it increases the time taken to hash the password. Say for example your chosen hash function takes 1/3 of a second. If you do 3 rounds it'll take a second. If someone wants to try and brute force one of your passwords by doing exactly what you do with every string possible then comparing to your hash, they can only check 1 per second or 60 per minute. This hashing time is very important in password security as you want a hash time which is quick enough to allow your application to check passwords efficiently, but slow enough to make brute forcing ineffective.

 

[zerophase]

I didn't think there was much point to hashing on the client side either. Here it mentions it's more of an older technique from before https, and you can still do it, but it isn't really necessary. Yeah, https basically handles everything on the secure connection side. Now, we want our web server and database running on different machines right? Does tossing them both in separate jails provide the same functionality?

 

[SirDice]

The rule is, never trust user input, so always check and verify data submitted to you. Even if you check it client side.

This is the most important rule and the most forgotten. Never, ever, trust anything a client sends to you.

 

[beastDemian]

account management (updating passwords, etc) on the server side vs letting Javascript handle.

What do you mean by..."let javascript handle"? Is this a website you are trying to code? This sounds like an issue of having a form inside you page vs using AJAX, but your way to phrase the question is kind of ambiguous.

He's convinced we need Javascript running on the client side for the user to login.

That's not strictly necessary. You can have a form inside you page with fields for the username and password. When the user submits it, you'll get a POST request with all the data you need. You still need the server to check the authenticity of what you are being sent, and you have to do that in the server.

It's my understanding that pretty much all of the fancy ux stuff that's done with js can be done with css.

CSS is a styling tool. It has very little to do with programming (you can do some things in a pseudo-programatic fashion with CSS3, but that's about it).

Is hashing the password as well on the client side necessary or even worthwhile when the site is on https?

It is neither. Doing it in the client won't buy you anything and it poses a security risk. Before you write any mission critical code, I suggest reading about hashing:

https://crackstation.net/hashing-security.htm#normalhashing

I'll quote from that page:

In a Web Application, always hash on the server
If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user's browser with JavaScript, or should it be sent to the server "in the clear" and hashed there?
...
The problem is that the client-side hash logically becomes the user's password. All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user's hash they could use it to authenticate to the server, without knowing the user's password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, they'll have immediate access to everyone's accounts without having to guess any passwords.