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.

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

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.

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

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

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

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.

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

<< 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

>> 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!