Quick question: Authorization.

[NubPro]

Hello!

This question has been stumbling upon me for quite some time, pass few days actually. I'd kinda managed to implement Google Plus Sign In oAuth 2.0 into my login page, where user can simply sign in to my site through their Google's account. The great pros about this is, I won't be needing to create a registration page and messing with bunch of passwords etc, but here's the problem.
I have a form that submit through client sided JavaScript with AJAX and it only allows those who are logged in to view the form, so basically the question is, if the user where to submit the form, how can I justify the legitimacy of the user credential and login state since everything is passed to the server through a client sided AJAX script. The odds are, it can be brute forced and be modified to trick the script that may disguise himself/herself as one of the logged in user.

I have very minimum experience with credentials and logins, so please enlighten me.
Thank you.

 

[Dave]

Be sure only logged in users can see the page and only logged in users can send a request to server end of the page.
Also make use of a CSRF token to prevent brute force scripts.

 

[Taiga]

On login you create a unique session in your own database and you use this one to validate if the user is logged-in. You can set this in the session or in the cookies by using an unique session id which is linked to their account.

Dave already mentioned it how to do it for the form, make sure you use a CSRF token (

You must be registered to see links

) which is a key you generate to avoid cross-site scripting and unwanted actions (such as spamming a form), the keys expire after an x amount of time and can be cached inside an encrypted session variable (recommended) or inside a database. You have to generate a new key for each new request and form to maximize security.

 

[NubPro]

Thank guys, I will see where I can go about this.

 

[s-p-n]

Assume there is an attacker with the following:

1. Eavesdropping - The attacker can read all traffic exchanged between the client and server. To protect against eavesdropping, a SCRAM client never sends her password as plaintext over the network.
2. Replay - The attacker can resend the client's valid responses to the server. Each SCRAM authentication session is made unique by random nonces, so that the protocol messages are only valid for a single session.
3. Database Compromise - The attacker can view the contents of the server's persistent memory. A database compromise is mitigated by salting and iteratively hashing passwords before storing them.
4. Malicious Server - The attacker can pose as a server to the client. An attacker is unable to pose as server without knowledge of the client’s SCRAM credentials.

Pretend to be that attacker and hack your own system. Odds are, you have more knowledge of your system than a real attacker, and you can make your site pretty secure by playing cat and mouse with yourself. A real attacker will think of things you don't think about, or don't even know about. For example, you may have the most secure site in the world, but the attacker may find another way into your server.

If you already assume the attacker has access to your database, (practicing "Database Compromise" scenarios), then you're one step ahead. Make sure only a trusted client can use a database to extract any sensitive information.

Make copies of your server- exact copies. Make it so the client has a key, and the server has a key, and only the client may unlock the server's key, and only the server can unlock that client's key. Use SSH in production, but when testing for vulnerabilities, be sure to pretend like you can bypass any security SSH provides- eavesdropping.

The link where I got that quote has information on how MongoDB tries to ensure authorization. Authentication is simply getting a username and password that match up. Authorization is the act of determining whether the source which provided such username and password is actually the owner of the account. Achieving true authorization is much harder (theoretically impossible) to accomplish, but it's worth trying.

At a certain point, you have to assume certain attacks are acceptable. For example, the user walks away from his computer and the attacker sits down, and has access to the user's username and password. You can use the webcam to verify the user's eye, or a fingerprint scanner- even a DNA test. Next you assume the attacker has a picture of the user, and cut off the user's finger. You can go on and on forever, and the hypothetical attacker will eventually win if you keep increasing her level of access.

In general, the more you hack yourself, the better you get at security.