Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I have tried to cover everything that I could think of from a high level perspective, given that you said your application isn't a high security app, and you want the basic security controls in place.</p> <p>The authentication flow, and the mechanism that it is using seems fine to me. The only point of concern I see here is the session management itself. Generating a session token using MD5 is fine (depending on whether you are using the correct pseudo random functions, which are seeded the correct way), though SHA1/SHA256 might be better choices if anyone ever tries to create a collision for your tokens.</p> <p>I see a few things missing here - they might be omitted, or they might not be there, so I will mention them all. The first thing - you have not mentioned whether you ensure that there is a match between the user, and the cookie that you received. You need to make sure those two match, so that one user cannot steal a second user's session.</p> <p>The second thing I see missing here is validation that the cookie is NOT stolen from the user that it was from. For example, if I managed to steal the session cookie from a user, and replayed it on my own computer from a different place, I would still be able to login, with the current session handling mechanism. </p> <p>You need a way to uniquely identify which computer the request is coming from - one way to do it (and the way that a PHP framework called CodeIgniter does it) is by verifying the IP address, as well as the User Agent that the request is coming from. The latter is easy to spoof, but the former is much harder. This makes your session more resilient to attacks - unless the application is used in a internet cafe on a public machine, and the user has not logged off.</p> <p>That brings me to my final point - I don't see a log out mechanism mentioned here, and how the log out is performed. The basic assumption would be that you would invalidate the session cookie as soon as the user logs out, and you don't accept that session cookie again. If you haven't done this already, that is something else you can do to ensure your session's security.</p>
    singulars
    1. This table or related slice is empty.
    1. POAuthentication model of a javascript app using ajax
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USKarthik Rangarajan
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POAuthentication model of a javascript app using ajax
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COA session is connected to a user on in the backend. There is no mechanism in place to prevent the SessionID if users cookies are compromized and re-used on another client. But if I have sessions connected to ip-address then dhcp lease expiring would invalidate the session too, right? Is there another way of doing that? Like some 'Browser ID'? Logout function exists and basically deletes the cookie and the session in the backend.
      singulars
      1. PO
      1. USTimo Wallenius
    2. COThe possibility of this is not high with the more popular ISPs, but its always there. I am a more paranoid security person, so I would say invalidate the session if the IP changes and have them reauthenticate - however, that's not user friendly and might not be what you want. A unique Browser ID is hard to create, and easy to spoof. A good (and a little harder) solution would be to have short lived session IDs that keep updating themselves. So if old session ID is valid, create new session ID, invalidate old one. So even if a cookie is stolen, its short lived, so it will have expired already.
      singulars
      1. PO
      1. USKarthik Rangarajan
    3. COOk, I'll apply the ip-restriction and if no problems are reported by the users I'll leave it there. I don't think there will be much more feedback on this. Seems like with the few changes the solution is "safe enough" so I'll close the Q for reference to others.
      singulars
      1. PO
      1. USTimo Wallenius
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload