Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 15 of 15 total
Thread Browser / client identification.
Sat, Aug 15 2015 3:36 AMPermanent Link

squiffy

Telemix Ltd.

Avatar

>> The key with using name/password instead of a token is that it allows
>> any server to respond from a pool

Just read a response on a forum that suggests a reason for *not* sending username/password with every request :

http://programmers.stackexchange.com/questions/57909/sending-username-and-password-in-every-request-from-iphone-app

I'm going to stick with session ID for now.
Mon, Aug 17 2015 12:50 PMPermanent Link

Matthew Jones

squiffy wrote:

> >> The key with using name/password instead of a token is that it
> allows >> any server to respond from a pool
>
> Just read a response on a forum that suggests a reason for not
> sending username/password with every request :
>
>
http://programmers.stackexchange.com/questions/57909/sending-username-and-password-in-every-request-from-iphone-app
>
> I'm going to stick with session ID for now.

Thanks for posting that. I guess it comes down to the application and
the mode of operation as to which is better/worse. Either can be
hijacked...

--

Matthew Jones
Mon, Aug 17 2015 1:23 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com


<< Just read a response on a forum that suggests a reason for *not* sending username/password with every request : >>

Yes, but that scenario *also* includes the nefarious user just sitting down and doing something with the unlocked/logged-in machine/browser.  In other words, what happens if the existing user *doesn't* go to a new machine/browser and start doing something else ?

If you try to base your security design on trying to work around the fact that a user has left a *logged-in* session open in a browser in a publicly-accessible machine somewhere, then you're going to be really disappointed in the results. There are all sorts of security scenarios that break down once you're dealing with a publicly-accessible machine.

The best scenario would be to detect keystrokes at the TForm level (OnKeyDown), and have each keystroke reset a TTimer with an interval of 20-30 seconds (Interval property of 2000-3000).   If the TTimer fires, then clear out the login information from memory in the application and show a modal login dialog.  That way nobody can do anything with the application until re-logging-in, and the login information is gone.  You'll probably also need to detect mouse/touch also to avoid really infuriating the user. Smile In fact, this might be better off left for the EWB run-time to handle because it has global access to such events, and can better cope with them at that level.  I'll see about adding this to the TApplication component.

Tim Young
Elevate Software
www.elevatesoft.com
Mon, Aug 17 2015 1:40 PMPermanent Link

squiffy

Telemix Ltd.

Avatar

It's enough to drive you bonkers, isn't it?

I've settled for accepting that if a user doesn't log off from a public computer, despite being warned, then all bets are off. The token they receive has a TTL of 10 minutes (I may adjust this) so their would be attacker must sit down at the same machine and start hacking about within this time.

Everything is over TLS and I'm reasonably happy now that the token can't reasonably be stolen remotely from the PC the legit user is actively using without some remote control app running, which again means all bets are off. Can't see how you can protect against that.

Every security scenario you can think of has pros and cons. Hopefully that will be enough for general usage.

Always open to suggestions Smile
Tue, Aug 18 2015 5:50 AMPermanent Link

Matthew Jones

squiffy wrote:

> It's enough to drive you bonkers, isn't it?
>
> I've settled for accepting that

A lot of it also depends on what the "hacker" can do or get with the
credentials. Hack an account on my shop, and you can get a download of
some software. But you can't buy anything without providing a new
credit card or paypal account as we don't keep any such details. So the
limits are a free download and changing someone's account details.
Obviously if you are someone like the US government verification
service, you don't need to go to such lengths, but the NSA might want
to beef things up more.

--

Matthew Jones
« Previous PagePage 2 of 2
Jump to Page:  1 2
Image