1+ for thisnlarson wrote:Did this feature ever make it in? I just stumbled upon the thread and would be happy to chip in. Although security being a ever growing concern I really think Aware needs a more official support for https certificates & persistent session cookies.
1. the string is protected from 3rd party snooping @ 128bit
2. the app login is protect by either recycling a session token or forcing the user to login if no cookie exists.
3. the data would be protected from second party 'curious' user by what ever privacy rules you have put on the business object.
If that happened you have solid security, not just camouflage. That is something I would put some real money towards.
Obfuscation of url LINKS - Pitch in ?
Henrik (V8 Developer Ed. - Windows)
-
- Posts: 2392
- Joined: Mon Jul 02, 2012 12:24 am
- Location: Ulaanbaatar, Mongolia
This concept eventually went dead because of the concern that Base64 was not a good solution .
There seems to be enough parties interested to chip in, so lets try and pursue this
Is there anyone out there that can drive a solution ?
Nlarson,
You seem to have an idea on a way forward, maybe you could pick up on this and present it to support for consideration
There seems to be enough parties interested to chip in, so lets try and pursue this
Is there anyone out there that can drive a solution ?
Nlarson,
You seem to have an idea on a way forward, maybe you could pick up on this and present it to support for consideration
Not a whole lot to document from a concept stand point,
1. Should make SSL support more seemless. The steps to do it manually are documented in this post, but it's a lot of work which will get crushed by every upgrade.
http://www.awareim.com/forum/viewtopic. ... hlight=ssl
2. Aware needs to generate and accept persistent cookies. If the cookie is valid, the user is logged in, if not they are shown the login screen. If applicable, after the login the user is then forwarded to the specified URL. There is a ton of info on the web, but here is a good write up.
http://fishbowl.pastiche.org/2004/01/19 ... _practice/
4. After the login the user is then forwarded to the
5. 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)
If that gets done it would:
1. allow all traffic to be encrypted, so any transmission of data is secure (like id + password). Typically all Aware data is transmitted in plain text.
2. allow notifications to be sent with URLs which are not based on a guess login and/or do not include an id/password string but still logs in the user and takes them to the specified record.
3. allows data security to be put in place based on a specific user.
1. Should make SSL support more seemless. The steps to do it manually are documented in this post, but it's a lot of work which will get crushed by every upgrade.
http://www.awareim.com/forum/viewtopic. ... hlight=ssl
2. Aware needs to generate and accept persistent cookies. If the cookie is valid, the user is logged in, if not they are shown the login screen. If applicable, after the login the user is then forwarded to the specified URL. There is a ton of info on the web, but here is a good write up.
http://fishbowl.pastiche.org/2004/01/19 ... _practice/
4. After the login the user is then forwarded to the
5. 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)
If that gets done it would:
1. allow all traffic to be encrypted, so any transmission of data is secure (like id + password). Typically all Aware data is transmitted in plain text.
2. allow notifications to be sent with URLs which are not based on a guess login and/or do not include an id/password string but still logs in the user and takes them to the specified record.
3. allows data security to be put in place based on a specific user.
I agree Tom, there is a convenience factor which is slick, but even beyond that anyone storing personally identifying information for users in the US or EU should use these features. There are many Laws which have sharp teeth going on the books about personal data. I am sure that applies else where too.
For example, I noticed one of our members has a debt collection app. If that has info like SSNs, account numbers, etc. stored in it for any resident of Massachusetts and said data it gets transmitted without encryption the businesses using and/or providing the service could face fines of up to $25,000 per incident with no damage cap thanks to MA 201 CMR 17 (http://www.mass.gov/ocabr/docs/idtheft/ ... 700reg.pdf). While it is unlikely to be noticed, the risk if detected is huge!
That's just one simple example, it is easy to come up with many more. IMHO security best practices need to be a high priority on any software roadmap.
For example, I noticed one of our members has a debt collection app. If that has info like SSNs, account numbers, etc. stored in it for any resident of Massachusetts and said data it gets transmitted without encryption the businesses using and/or providing the service could face fines of up to $25,000 per incident with no damage cap thanks to MA 201 CMR 17 (http://www.mass.gov/ocabr/docs/idtheft/ ... 700reg.pdf). While it is unlikely to be noticed, the risk if detected is huge!
That's just one simple example, it is easy to come up with many more. IMHO security best practices need to be a high priority on any software roadmap.
That's the thing, login strings are a red herring, unless you are forcing https the login data (and all subsequent data) is being transmitted plain text...
Here is the RAW post from the login form. I partially obscured my info before posting, but this goes out for anyone to grab.
[/code]
Here is the RAW post from the login form. I partially obscured my info before posting, but this goes out for anyone to grab.
Code: Select all
POST http://69.64.XX.XXX:8080/AwareIM/logonOp.aw HTTP/1.1
Host: 69.64.65.235:8080
Connection: keep-alive
Content-Length: 69
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Origin: http://69.64.65.235:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://69.64.65.235:8080/AwareIM/logonOp.aw
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: JSESSIONID=46A4FAE2756B4164AD085F22A3420E60
userName=njXXXXXXXoal.com&password=JaXXXXXX0&domain=%3Cdefault%3E
Ideal or cloak
I am also in on this as I have stated before. The advanced security features would be IDEAL and we could possible ask Awaresoft for a quote?
Nevertheless, the "cloak" solution is better than nothing and if the ideal solution doesn´t go anywhere in the nearest future, the cloak solution could be a good start.
Nevertheless, the "cloak" solution is better than nothing and if the ideal solution doesn´t go anywhere in the nearest future, the cloak solution could be a good start.
Henrik (V8 Developer Ed. - Windows)
-
- Posts: 7523
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
There seem to be quite a few issues raised here, so let's stay focused and not discuss persistent cookies and making SSL setup easier here (separate topics can be raised for this if necessary).
As far as security is concerned, there seem to be two issues here:
1) Aware IM links are not secure enough. Fair point.
2) Communication between the client and server is not secure.
Regarding 2). If you want this communication to be secure then you must use https and SSL - this is what it is for. So unless I am missing some important point here, let's not discuss 2) here, either.
Regarding 1). The "cloak" solution which involves Base64 with XOR shifting is fairly easy and can be included in 5.7. You will have a function that will encode all the information in the link:
http://locahost:8080/AwareIM/logonOp.aw?e=abdrrjafdee....
where everything after e= will be an encrypted representation of the proper link parameters like:
domain=Blah&userName=blah&password=blah&firstCommand=blah
To achieve the encryption you will use this function in your configuration when generating the link:
ENCODE_LINK ('domain=....')
Aware IM will automatically decrypt the encrypted link.
Later on we can increase strength of encoding to use 128-bit DES encryption with parameter e2=... and the function ENCODE_LINK2
Please provide your comments ASAP. 5.7 is nearly ready. If this is something that you can live with, it will be included in 5.7 straight away.
As far as security is concerned, there seem to be two issues here:
1) Aware IM links are not secure enough. Fair point.
2) Communication between the client and server is not secure.
Regarding 2). If you want this communication to be secure then you must use https and SSL - this is what it is for. So unless I am missing some important point here, let's not discuss 2) here, either.
Regarding 1). The "cloak" solution which involves Base64 with XOR shifting is fairly easy and can be included in 5.7. You will have a function that will encode all the information in the link:
http://locahost:8080/AwareIM/logonOp.aw?e=abdrrjafdee....
where everything after e= will be an encrypted representation of the proper link parameters like:
domain=Blah&userName=blah&password=blah&firstCommand=blah
To achieve the encryption you will use this function in your configuration when generating the link:
ENCODE_LINK ('domain=....')
Aware IM will automatically decrypt the encrypted link.
Later on we can increase strength of encoding to use 128-bit DES encryption with parameter e2=... and the function ENCODE_LINK2
Please provide your comments ASAP. 5.7 is nearly ready. If this is something that you can live with, it will be included in 5.7 straight away.
Aware IM Support Team
I dont understand how this would work with users logging in with the various login types that are currently available but I admit I know very little about this stuff. I can see how it works if I sent a URL to a user say via an email as I use the function in a process to encode it but logging in with the standard login scripts with their various parameters? How does that work?
So I leave it to others who know more about this.
Cheers Rod
So I leave it to others who know more about this.
Cheers Rod