I'm working on a smugmug-related app which is supposed to be a more than Fire-and-forget thing. Hence I need to know whether my sessionid is still valid. This will help to avoid the overhead of sending credentials over and over again and also reduce identity theft risk.
What I'm thinking about is a "ping" method which would send

• String "SessionID"
• String "UserID"
• String "PasswordHash"

i.e. parameters acquired or used during login operation.

The response may either be simply success/fault one, or it can be more intelligent and in case this session has (recently?) expried, try to analyze the information provided and possbly issue a new set of credentials (which would again allow to skip a login).

Anyway, this would allow to keep client active and valid for as long as it is necessary.

What do you think?
Thanks!

Hi Nikolai,

I'm working on a smugmug-related app which is supposed to be a more than Fire-and-forget thing. Hence I need to know whether my sessionid is still valid. This will help to avoid the overhead of sending credentials over and over again and also reduce identity theft risk.

I assue that you're using HTTPS communications, in which case to be honest if the HTTPS stack that you're using is properly engineered, I don't honestly think that it helps reduce ID theft. No-one is going to try and break an HTTPS connection to try and steal a smugmug account. Even with repeated transmission of the same information a HTTPS connection should be computationally infeasible to break.

So the only question remains is how to handle unencrypted connections. Firstly, I have grave doubts about the value of using unencrypted connections, in my opinion it would be superior to always attempt to reconnect over HTTPS and then transfer any information than it would be to try and hold a session open. In Smugmug's case, this is roughly equivalent to the relative complexity of engineering your own security protocol, versus using a pre-engineered one. Experience shows that the former will almost always be superior to the latter.

If HTTPS is not implemented on your target operating system (which judging on your thread on DPReview, seems extremely unlikely) then I think you're on a hiding to nothing trying to retrofit security. [Unless you're a security engineer ;)]

What I'm thinking about is a "ping" method which would send <DIR><DIR>String "SessionID" String "UserID" String "PasswordHash" </DIR></DIR>i.e. parameters acquired or used during login operation. The response may either be simply success/fault one, or it can be more intelligent and in case this session has (recently?) expried, try to analyze the information provided and possbly issue a new set of credentials (which would again allow to skip a login).

This is becoming more dangerous. There are many cases in security API design where it has been shown that the more sophisticated the security API the more difficult it is to secure properly. Hence security API's implemented in places where it really matters tend to be kept as simple as possible. This is general guidance, let me throw a few specific objections:

if you're frightened about people stealing the credentials because they're being used to much, you must be concerned about people snooping on the communications stream, if this is a genuine security problem then we must assume that an attacker could snoop on the communications stream of the ping requests.

We can then assert that the attacker could use this information to hold the connection open for longer than your application intends. If the attacker could use this information to fake requests, then you're attacker has all of the power of the available API is at his command.

So there may be solutions to this, using IP address tracking, using session key exchange etc... but all we are doing by adding such systems is increasing the complexity of the security system, okay so were no longer sending a potentially valuable password around, but we haven't really protected the APIs, all we've done is vastly increased the complexity of the required security system to achieve the same security. As indicated above with the general guidance on security APIs, this generally seems to mean that we have spent a lot of money making the system less secure.

On the face of it your suggestion sounded like a good idea, but one further reflection I'm not so sure that it is useful.

What do you think?

that's just my two cents.

Keep up the good work as an ideas generator

Luke

[font=Arial][/font]

Thank you very much for the detailed answer!
I think I inadvertedly shifted the focus of my own message towards the security/identity theft, to which, I agree, you have very valid points.
However, my primary reason for this request was simply trying to avoid "zomby client" effect and also avoid unnecessary relogins. I asked before about the "session logevity period", but unfortunately didn't get any answers.
So I was thinking of "ping" as a lightweight "are you there? I am here!" message, which would prevent session ID from expiration and allow the app to use it for a prolonged time interval without requesting a new one.

Thanks!

Hi Nikolai,

Originally Posted by Nikolai However, my primary reason for this request was simply trying to avoid "zomby client" effect and also avoid unnecessary relogins. I asked before about the "session logevity period", but unfortunately didn't get any answers. So I was thinking of "ping" as a lightweight "are you there? I am here!" message, which would prevent session ID from expiration and allow the app to use it for a prolonged time interval without requesting a new one.

OK I see where you are going with this, a bit like a NOOP to an FTP server.

I guess the only factor that determines whether it is a good idea is how expensive it is for Smugmug's backend to hold a connection open.

For example in quite a few database setups it's preferable to re-authenticate because the connection pool is quite constrained. I guess we'd need input from Smugmug's engineers on that one.

Luke

and welcome to dgrin, luke nice to have you and your expertise here

Originally Posted by luke_church Hi Nikolai, OK I see where you are going with this, a bit like a NOOP to an FTP server. I guess the only factor that determines whether it is a good idea is how expensive it is for Smugmug's backend to hold a connection open. For example in quite a few database setups it's preferable to re-authenticate because the connection pool is quite constrained. I guess we'd need input from Smugmug's engineers on that one. Luke

Yeah, I guess so. Besides. actually, I already managed to simple "fallback-safe" login code and will add similar logic to all the requests:

1. try post,
2. if not - try login with hash,
3. if not - try login with password,
4. post if success, fail otherwise.

Steps ##2,3 are already in place, now only need to make post fail-smart:-)

That NOOP-like method would give me a good starting point :

1. NOOP,
2. if not - try login with hash,
3. if not - try login with password,
4. post if success, fail otherwise.

I'm churning on with my code, hopefully will be done with manual stuff today, and then to the fun part - asyncronous mass/batch uploads:-). Also figured out how to do some "unofficiall" stuff, I mean actions that are not (yet? ever?) available via RPC-XML, but readily available via simple posts:-)

Stay tumed, it's commmmmming:-)

Cheers

Originally Posted by andy and welcome to dgrin, luke nice to have you and your expertise here

Thanks Andy, happy to be here :)

I saw your email a while back, my hands are improving thanks... Few more months then I should be able to type again properly :)

Originally Posted by Nikolai Thank you very much for the detailed answer! I think I inadvertedly shifted the focus of my own message towards the security/identity theft, to which, I agree, you have very valid points. However, my primary reason for this request was simply trying to avoid "zomby client" effect and also avoid unnecessary relogins. I asked before about the "session logevity period", but unfortunately didn't get any answers. So I was thinking of "ping" as a lightweight "are you there? I am here!" message, which would prevent session ID from expiration and allow the app to use it for a prolonged time interval without requesting a new one. Thanks!

Sessions last for 6 hours of inactivity and are then retired. :)

Don