AwareIM Security best practices.

nlarson

Based on the side track which started in this threadhttps://forum.awareim.com/d/3554>

Have Aware generate and accept persistent cookies. If the cookie is valid, the user is logged in, if not they are shown the login screen. There is a ton of info on the web, but here is a good write up.

http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/

Change Aware Links to support the persistent cookie model. I.e. after the login the user is then forwarded to the specified URL even if they had to log in.
Aware devs would then be responsible for setting up appropriate access option to keep users from seeing things they should not be allowed to see. (requires no programming changes)

nlarson

Based on the side track which started in this thread #3554>

Have Aware generate and accept persistent cookies. If the cookie is valid, the user is logged in, if not they are shown the login screen. There is a ton of info on the web, but here is a good write up.
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/
Change Aware Links to support the persistent cookie model. I.e. after the login the user is then forwarded to the specified URL even if they had to log in.
Aware devs would then be responsible for setting up appropriate access option to keep users from seeing things they should not be allowed to see. (requires no programming changes)

hpl123

I don´t know that much about this/security measures etc. but here are my thoughts. Security is a top priority I think and the security features outlined in this post sounds like good security measures for Aware IM applications.

First of all, in the other post (obfuscation post; step 1 "cloak" solution & step 2 encryption solution). This is 1 thing that enhances the security options of Aware IM and will be great to have. When it comes to the https feature, this is an important feature and it´s possible to configure this today but require some custom work after every Aware IM update. It would be nice/useful if this could be a native function set in the application configuration that also stays current (i.e still configured) even after an update.

Regarding the additional features e.g. cookies etc. , I don´t know that much about these security measures and how big a security concern not having this in an application actually is. When looking around at the different available frameworks etc. for building web applications. Is this something typically used or is this "added security"? If we have the step 2 encryption solution mentioned above and the native https functionality, my thought is that this would go a long way to enhance the security in Aware IM.

Nevertheless, when it comes to getting all of the security measures, I am interested in all of them and would gladly pitch in.

Thanks

aware_support

I am not sure what you mean by point 4.

If the idea is that the user doesn't need to login into Aware IM when he clicks on the link if he is already logged in, then it's already supported. Aware IM does use cookies that are persistent for the life of the user browser session. All you need to do is specify "dynamic=true" in your link.

nlarson

In point 4, a separate 'remember me' cookie should persist indefinitely (not just through the session) which has the users hashed login info, details are provided in the link above on how this is accomplished. This is how Facebook, Google, linked in yahoo, most other web apps handle login. If anyone uses linked in, they will likely notice they rarely have to enter their credentials, but to be honest it is more of a convenience for users as it is simply allowing them to by-pass the login if they have enabled 'Remember me'.

This link has a good summary of the method and some ideas to make it even tighter. http://jaspan.com/improved_persistent_login_cookie_best_practice

In terms of the Aware links, IMHO they should NEVER contain Login parameters (even if obscured), there are too many ways this info can be easily hijacked. What I am suggesting is to have any link coming into the app interrogated for credentials (but those credentials should not be parameters). So the incoming link would be checked first as Guest, if no, then via cookie method above, failing that - manual prompt. Only once a valid session is established the URL parameters are processed.

Perhaps that happens already? However, my understanding is that if the link UID/PW is not valid the user is pushed to the login screen (which is good), but if they then login the link parameters are not processed? Is my understanding incorrect? (I meant to test this today, just ran out of time).

Does that help?