Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 10 of 15 total |
Browser / client identification. |
Wed, Aug 12 2015 11:56 AM | Permanent Link |
squiffy Telemix Ltd. | When the server is verifying a token that is sent from my application, what information apart from IP and User Agent data can be used to help verify that the token is coming from the same browser each time?
Note that I don't use cookies. I generate my own tokens on successful log in on the server side and include them with each AJAX request as POST data (all comms is over SSL). Tokens are well managed with TTL and are destroyed if any rules are violated. Just need to make sure I have enough rules. |
Wed, Aug 12 2015 2:14 PM | Permanent Link |
Raul Team Elevate | On 8/12/2015 11:56 AM, squiffy wrote:
> When the server is verifying a token that is sent from my application, what information apart from IP and User Agent data can be used to help verify that the token is coming from the same browser each time? > Note that I don't use cookies. I generate my own tokens on successful log in on the server side and include them with each AJAX request as POST data (all comms is over SSL). Tokens are well managed with TTL and are destroyed if any rules are violated. Just need to make sure I have enough rules. I assume you're just referring to SSL as a term - these days you should use strong versions of TLS as bare minimum (i.e. 1.2) and make sure your cipher suites are as secure as you can make them (you limit legacy browsers as you remove the protocols and usch from cipher suite). Otherwise you should be fine - HTTPS connection ensures security of your login and token from somebody trying to snoop on connection. If you want an even stronger option then client side certificates is next logical step but now this gets into lot more cert management and web server setup. Raul |
Wed, Aug 12 2015 2:31 PM | Permanent Link |
squiffy Telemix Ltd. | Hi Raul,
yes I was using SSL for secure comms in the way we English use the term "Hoover" for vacuuming I've been racking my brain thinking of ways that my token could be transferred to another computer maliciously, and the only way I can think of is if someone recreates my User-Agent data on a machine on my LAN (so the same IP gets presented to my server) and gets given the token or looks at the Firebug data on a logged in browser to get it. Then they could recreate me, I suppose. Is that correct, do you think? Are there other ways? Just trying to lock down all things within my power. Thanks. |
Wed, Aug 12 2015 3:29 PM | Permanent Link |
Raul Team Elevate | On 8/12/2015 2:31 PM, squiffy wrote:
> I've been racking my brain thinking of ways that my token could be transferred to another computer maliciously, and the only way I can think of is if someone recreates my User-Agent data on a machine on my LAN (so the same IP gets presented to my server) and gets given the token or looks at the Firebug data on a logged in browser to get it. > Then they could recreate me, I suppose. > Is that correct, do you think? Are there other ways? Just trying to lock down all things within my power. AFAIK this would be the only way. This assumes PC does not have key loggers or similar malware already running that would grab the login or token info. In general if they have unsupervised access to the physical computer with active browser session then most bets are off. You said you have aggressive TTL so that might protect you to some degree or at least limit how long they can use the token. You could do things like track inactivity in the EWB app itself and automatically log out the user (invalidating the token) - it's really depends on acceptable risk and how much you want to inconvenience regular users of your app. Raul |
Thu, Aug 13 2015 4:25 AM | Permanent Link |
Matthew Jones | squiffy wrote:
> and gets given the token or looks at the Firebug data on a logged in > browser to get it. WiFi packets sniffing is what people used to do to grab Facebook logins, using the tokens and cookies etc. Hence using SSL (TLS now). The most likely issue you will face is someone opening another tab on the browser to the same site - if the browser is storing the token, then both can see the same token. If it is staying in the javascript, then each is independent. FWIW, if you want to get really secure, the way that the card processors do it (and some others) is that you return a new token with each response. That stops someone using a grabbed token more than once, and if they do, then the main application breaks too so they know something happened. It's only a little harder to implement. Want it really secure? Then the returned token is a nonce or some such (the technical terms escape me) and you have to hash that token with the known secret for the account and pass that back, and thus it proves you are legitimate each time. -- Matthew Jones |
Thu, Aug 13 2015 4:28 AM | Permanent Link |
Matthew Jones | Oh, the other thing is that you could just do away with tokens
completely. You are secure, so can't be eavesdropped. So just pass in the account name and password each time. A colleague and I pondered this for a long time. A token is a representation of the account that lives separate to it and causes hassle. Why not just send the account every time? Particularly so for REST, as it is then truly RESTful, unlike REST with a token. Just a thought - our use was for an app mainly so no browser tools to review the data flow. But even with that, you get the password which you just entered... -- Matthew Jones |
Thu, Aug 13 2015 5:59 AM | Permanent Link |
squiffy Telemix Ltd. | Thanks. All good stuff, and I shall investigate it all. There's copious amounts on the web about all this, and you can go snow blind - and mad - reading it all.
I too wondered what the difference was between sending a username/password once on login and sending it subsequently with each request. The most expressed reason I could find was that with each send you increase the chances of someone finding it on your history (whatever form that takes). Not convinced that someone who is capable of looking would not find the original, and someone not capable of looking would find any of them. I suppose you could argue that no lock in the world will save you if you leave the house without bolting the door (logging out in this case). My only remaining curiosities are whether someone can read my POST data directly from my JS console or something remotely, and whether there was some way to send tamper proof fingerprints of the PC/Browser to the server to help identify the original user should a live token move to another PC. Appreciate al the feedback so far, especially as some of my thoughts might be nonsense. |
Thu, Aug 13 2015 6:03 AM | Permanent Link |
Matthew Jones | squiffy wrote:
> My only remaining curiosities are whether someone can read my POST > data directly from my JS console or something remotely, and whether > there was some way to send tamper proof fingerprints of the > PC/Browser to the server to help identify the original user should a > live token move to another PC. If someone has physical access, then they have your data. Also, if someone allows HTTPS proxy via a certificate, then they can inspect it too. The sysadmin shouldn't be using the data for such purposes. The key with using name/password instead of a token is that it allows any server to respond from a pool, without having to share back-end information about tokens. Truly stateless operation for each action. That may not be a good thing in some cases, but might be for others. The main thing is you are considering these things. I'm always amazed at the breaches that are occuring when basic steps would fix most of them. -- Matthew Jones |
Thu, Aug 13 2015 8:08 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << I too wondered what the difference was between sending a username/password once on login and sending it subsequently with each request. The most expressed reason I could find was that with each send you increase the chances of someone finding it on your history (whatever form that takes). Not convinced that someone who is capable of looking would not find the original, and someone not capable of looking would find any of them. >>
If you're using a TServerRequest (AJAX), then there *isn't* any history anywhere, except maybe the developer tools, if you have the network tracing turned on. But, again, this is on the same user's machine, and is not accessible outside of the machine without confirmation by the user (Chrome remote debugging, for example). http://stackoverflow.com/questions/16306839/should-data-in-an-https-request-appear-as-encrypted-in-chrome-developer-tools Tim Young Elevate Software www.elevatesoft.com |
Thu, Aug 13 2015 10:10 AM | Permanent Link |
squiffy Telemix Ltd. | >> If someone has physical access, then they have your data.
Yeah, that's pretty much the bottom line, isn't it. >> The key with using name/password instead of a token is that it allows >> any server to respond from a pool That's something I hadn't thought about, but am now. >> If you're using a TServerRequest (AJAX), then there *isn't* any >> history anywhere, except maybe the developer tools, Which I am. The token just stays in the app (and therefore memory). Thanks everyone for your input. Feel a lot better about what I'm doing now! |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |