Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 11 to 15 of 15 total |
Browser / client identification. |
Sat, Aug 15 2015 3:36 AM | Permanent Link |
squiffy Telemix Ltd. | >> 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 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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. 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 PM | Permanent Link |
squiffy Telemix Ltd. | 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 |
Tue, Aug 18 2015 5:50 AM | Permanent 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 Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Monday, April 29, 2024 at 05:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |