Announcement

Collapse
No announcement yet.

Proposed Web Service: Login

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    openMobile - An open source C# Front End (why choose openMobile?)
    - Always Recruiting Developers -
    Like what you see? Donations are always welcome

  • #2
    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.

    Comment


    • #3
      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.
      openMobile - An open source C# Front End (why choose openMobile?)
      - Always Recruiting Developers -
      Like what you see? Donations are always welcome

      Comment


      • #4
        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.

        Comment


        • #5
          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.
          openMobile - An open source C# Front End (why choose openMobile?)
          - Always Recruiting Developers -
          Like what you see? Donations are always welcome

          Comment


          • #6
            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.

            Comment


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

              Comment


              • #8
                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?
                Originally posted by ghettocruzer
                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

                Comment


                • #9
                  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.
                  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.
                  openMobile - An open source C# Front End (why choose openMobile?)
                  - Always Recruiting Developers -
                  Like what you see? Donations are always welcome

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      There are actually a few options for a login. Luckily using the web we have https and sessions as normal services. So data could be stored securely in the cloud and you would authenticate the service just as you would any secure website. Associated with a session is an expiration time which shouldn't be automatic but settable by the user. That way a client can determine weather their session is valid for 1 day or 1 week. Not to mention the only thing to identify you as a client is that session id. IMO

                      Comment


                      • #12
                        Originally posted by SFiorito View Post
                        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.
                        Well credentials would never be passed in the clear but you do have a good point about the possibility of replay attacks. The issue though is to what gain...even with secure authentication for each service, data is still passed as clear text which is susceptible to sniffing. The session key was to prevent each service from requiring access to a users credentials (in my opinion server side security is usually where most products screw things up). We could require the sessionKey to be passed over an https connection though, and after authentication the connection would drop back to standard security, unless its very personal data. Does that sound better?
                        openMobile - An open source C# Front End (why choose openMobile?)
                        - Always Recruiting Developers -
                        Like what you see? Donations are always welcome

                        Comment


                        • #13
                          Well credentials would never be passed in the clear but you do have a good point about the possibility of replay attacks. The issue though is to what gain...even with secure authentication for each service, data is still passed as clear text which is susceptible to sniffing. The session key was to prevent each service from requiring access to a users credentials (in my opinion server side security is usually where most products screw things up). We could require the sessionKey to be passed over an https connection though, and after authentication the connection would drop back to standard security, unless its very personal data. Does that sound better?
                          in this case i'm considering the username/password as well as the session key as credentials since they're both used to identify or authenticate the user. so they should not be sent as part of the URL in a GET request and not in the body of a POST request without using SSL. With SSL the message body will be encrypted so the data being sent/returned will not be susceptible to interception (under normal circumstances).

                          optikalefx makes a good point that rather than rolling your own session management, just use built-in session management of your app server. this will use a session cookie to identify that session. the same security concerns apply here though, in that you only want the cookie sent over SSL (by setting the "secure" attribute on the cookie). the issue here is that you need all services to be on the same domain (e.g. *.mp3car.com). I doubt that's an issue in this case though.

                          ultimately, whenever you access a "secure" service requiring authentication, it should be over SSL to protect the credentials (username/password, session key, cookies, etc.). other service calls that don't require authentication don't need to go over SSL.
                          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

                          Comment


                          • #14
                            Originally posted by SFiorito View Post
                            in this case i'm considering the username/password as well as the session key as credentials since they're both used to identify or authenticate the user. so they should not be sent as part of the URL in a GET request and not in the body of a POST request without using SSL. With SSL the message body will be encrypted so the data being sent/returned will not be susceptible to interception (under normal circumstances).

                            optikalefx makes a good point that rather than rolling your own session management, just use built-in session management of your app server. this will use a session cookie to identify that session. the same security concerns apply here though, in that you only want the cookie sent over SSL (by setting the "secure" attribute on the cookie). the issue here is that you need all services to be on the same domain (e.g. *.mp3car.com). I doubt that's an issue in this case though.
                            Well in this case multiple domains is one of the big goals....this would allow a variety of services from a variety of sources to be able to share a common framework. It would also allow mirrors and a few other nice features should this pick up.
                            Originally posted by SFiorito View Post
                            ultimately, whenever you access a "secure" service requiring authentication, it should be over SSL to protect the credentials (username/password, session key, cookies, etc.). other service calls that don't require authentication don't need to go over SSL.
                            Like i said before though, its not the credentials that i would worry about getting sniffed its the data being transferred which would require the entire session to be over ssl not just the authentication. Thats not exactly difficult, it just wasn't in the first draft.
                            openMobile - An open source C# Front End (why choose openMobile?)
                            - Always Recruiting Developers -
                            Like what you see? Donations are always welcome

                            Comment


                            • #15
                              well, another option is to go the OAuth route... that's probably the best alternative
                              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

                              Comment

                              Working...
                              X