Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Proposed Web Service: Login

  1. #1
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783

    Proposed Web Service: Login

    In order to accomplish the goals of scalable and secure I propose logins be handled by a single server and session keys be used for client identification. The login query would be made over an HTTPS connection for security and ideally use a salted hash.

    service[] getServices()

    string login(string username,string password)

    struct service:
    • string ServiceType
    • string mirrorURL

  2. #2
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494
    So this would create a session key to be used by the client for all subsequent calls to the server? I'm assuming this sessionKey would expire after some amount of time?
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  3. #3
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Exactly...probably a 24hour session key would do the trick. This way all future queries that require an authenticated user aren't sending the users password (even in a hashed form). Its also a lot safer for a separate server (or a mirror) to check a session key then be dealing with a users credentials directly.

  4. #4
    fka - Nextabyte_Matt ioi8's Avatar
    Join Date
    Apr 2006
    Location
    Cleveland
    Posts
    125
    What would cause the 24 hour timeout? Would it be the client calling any function and the function checking for credentials and noticing that the time is expired? Or would there be a CRON job in the background being called every 5 minutes to make those keys invalid?

    Also, we could call a function such as NoMoreLogons at shutdown to make the session key invalid for future attempts.

    BTW... the getServices function should be in its own service itself. I dont see secure logons and listing services as relatable functions.

  5. #5
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    No need for either one... each sessionKey has an issue time associated with it, after 24 hours past that time it becomes invalid. We could have a cron job that clears old keys but really just replacing old keys with new ones should keep db size manageable.

    edit:
    Yea I couldn't remember why i put those two together and just realized its because I had originally envisioned them being one query. login should have a return type thats a sessionKey and an array of mirrors.

  6. #6
    fka - Nextabyte_Matt ioi8's Avatar
    Join Date
    Apr 2006
    Location
    Cleveland
    Posts
    125
    Quote Originally Posted by justchat_1 View Post
    No need for either one... each sessionKey has an issue time associated with it, after 24 hours past that time it becomes invalid. We could have a cron job that clears old keys but really just replacing old keys with new ones should keep db size manageable.
    But what is making the session key invalid? Even with a timestamp on there, what exact piece of code will be making the session invalid?

    Is it the client realizing that the timestamp is invalid and thus needs to logon again? Not very practical since the client cannot be trusted with this security risk.

    Is it when the client makes a function call and when the function checks for authentication, it then marks the key invalid? This could work since every/most functions should check for authentication.

    Or a 3rd option is a CRON job running every 5 minutes, checking each session key that is valid, and marking them invalid or deleting them if over the time limit? We have more control over this option.

    Yes the session key goes invalid, but your not really explaining how/when this key goes invalid. Something has to check and make the switch for each session key. Personally, option #2 would be the easiest to implement and would put the least strain on the server.

  7. #7
    FLAC SFiorito's Avatar
    Join Date
    May 2004
    Posts
    1,364
    why not just use basic http auth over SSL? Then you don't need to worry about expiring session keys, or of passing them to each service call and validating the keys in each service. you would only need auth on services that have user-specific data like playlist mgmt, front end settings, etc. the other services like POI DB would be public.
    EWF, HORM, MinLogon on XP.

    Zotac ION Atom N330, 2GB low-profile RAM, M3-ATX
    Win Embedded Std 2011 RC
    OCZ Vertex Turbo 30GB SSD
    Lilliput 629 Transflective, WRX Screen Mount
    BlueSoleil BT, i-Blue GM-2 GPS, DirectedHD Radio, Andrea Mic
    VoomPC 2

  8. #8
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Option 2 seems to require the server to mark the key invalid -which sounds like it makes the most sense. So, when the service is activated, a session key is generated and checked each time the service is called?
    Quote Originally Posted by ghettocruzer View Post
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  9. #9
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Quote Originally Posted by Nextabyte_Matt View Post
    But what is making the session key invalid? Even with a timestamp on there, what exact piece of code will be making the session invalid?

    Is it the client realizing that the timestamp is invalid and thus needs to logon again? Not very practical since the client cannot be trusted with this security risk.

    Is it when the client makes a function call and when the function checks for authentication, it then marks the key invalid? This could work since every/most functions should check for authentication.

    Or a 3rd option is a CRON job running every 5 minutes, checking each session key that is valid, and marking them invalid or deleting them if over the time limit? We have more control over this option.

    Yes the session key goes invalid, but your not really explaining how/when this key goes invalid. Something has to check and make the switch for each session key. Personally, option #2 would be the easiest to implement and would put the least strain on the server.
    You keep treating this like the only way to know a session key is invalid is if it is specifically marked invalid. Each session key has to be validated with each use, so realistically the authentication server has a function called getUserID(string sessionKey) which checks that the sessionKey both exists and is still valid before returning a userID number. The userID number is a constant number that allows a users personal info to be saved without anything but the authentication server knowing the users actual identity.
    Quote Originally Posted by SFiorito View Post
    why not just use basic http auth over SSL? Then you don't need to worry about expiring session keys, or of passing them to each service call and validating the keys in each service. you would only need auth on services that have user-specific data like playlist mgmt, front end settings, etc. the other services like POI DB would be public.
    Well that certainly would be the easy way, but theres a few reasons. The biggest one being data security, every server that a users personal info is stored on becomes a potential security risk. By using sessionKeys we know that only a single authentication server will ever be storing a users credentials (and it will be using https auth) or even any personally identifiable information. The second issue is that not every server hosting a service may have https (and not requiring it saves costs). The third issue, while not a large one now, is the overhead that https causes. You will notice many high usage web services use an authentication key over all https coms due to the CPU requirement of a large number of https connections and the extra bandwidth required by the encryption.

  10. #10
    FLAC SFiorito's Avatar
    Join Date
    May 2004
    Posts
    1,364
    I agree that SSL will incur a bandwidth hit, but I wouldn't trust a service that passes my credentials in the clear. since the token is used authenticate the request and it may be passed to a service without transport security it will be susceptible to replay attacks especially with a 24 hour timeout. That's why I was assuming only certain services would require authentication over SSL. since the token is actually a credential in this case, i'm not sure what that buys you over using standard auth mechanisms provided by the app server. you could encrypt the token with a nonce and sign it, but then you're talking about seriously increasing the complexity for clients, which is overkill for the type of functionality exposed by these services.
    EWF, HORM, MinLogon on XP.

    Zotac ION Atom N330, 2GB low-profile RAM, M3-ATX
    Win Embedded Std 2011 RC
    OCZ Vertex Turbo 30GB SSD
    Lilliput 629 Transflective, WRX Screen Mount
    BlueSoleil BT, i-Blue GM-2 GPS, DirectedHD Radio, Andrea Mic
    VoomPC 2

Page 1 of 2 12 LastLast

Similar Threads

  1. Proposed Web Service: DTC and VIN Lookup
    By justchat_1 in forum OSDash - Web Services
    Replies: 5
    Last Post: 01-01-2010, 03:35 AM
  2. Proposed Webservice - Proximity Web Control
    By ioi8 in forum OSDash - Web Services
    Replies: 7
    Last Post: 12-29-2009, 05:54 PM
  3. Proposed Web Service: Notifications
    By justchat_1 in forum OSDash - Web Services
    Replies: 13
    Last Post: 12-29-2009, 04:12 AM
  4. Proposed Web Service: Online Playlist Management
    By justchat_1 in forum OSDash - Web Services
    Replies: 11
    Last Post: 12-26-2009, 07:05 PM
  5. Proposed Web Service: Simple Online/Offline Status
    By tripzero in forum OSDash - Web Services
    Replies: 5
    Last Post: 12-22-2009, 03:41 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •