Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Proposed Web Service: Login

  1. #11
    Antenna Engineer
    Auto Apps:loading...
    optikalefx's Avatar
    Join Date
    Apr 2009
    Location
    Baltimore, Maryland, United States
    Posts
    829
    Blog Entries
    86
    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

  2. #12
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote 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?

  3. #13
    FLAC SFiorito's Avatar
    Join Date
    May 2004
    Posts
    1,365
    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

  4. #14
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote 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.
    Quote 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.

  5. #15
    FLAC SFiorito's Avatar
    Join Date
    May 2004
    Posts
    1,365
    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

  6. #16
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote Originally Posted by SFiorito View Post
    well, another option is to go the OAuth route... that's probably the best alternative
    Great call! I forgot all about that...

  7. #17
    fka - Nextabyte_Matt ioi8's Avatar
    Join Date
    Apr 2006
    Location
    Cleveland
    Posts
    126
    We need this implemented soon. Here is my idea for this.

    Webservice Function string ActivateSession(hash userpasshash)

    userpasshash = a 32/64 bit hash of the username and password. This can also be made more secure such as adding in the date as well into this hash.
    return string is a 32/64 bit hash of the session key generated by the server

    The server will then compare this userpasshash recieved against a real-time generated userpasshash retrieved from username/password stored in the forum DB.

    Proposed function for generating userpashhash = Hash64(username + GMTime(date) + Hash32(password))



    We also need a function to test for active session key and authenicate

    Webservice Function uint Authenicate(hash sessionkey)

    Same sessionkey as recieved. Every authenticate will also check the time of the sessionkey and will either disable the sessionkey at 8/24/48 hour intervals based on the settings we give it. No need for CRON jobs.


    It will take me a couple of hours to write this service. If you guys trust me, I will need some time with access to the raw DB so I can get column names, DB names, and user/pass to read the DB. We can then add an extra table to existing DB or add a whole new DB with write abilities so that I can add these sessionkeys to the DB.

    I can have this completed in one night. Your call if you want me to do this or your own internal staff.

  8. #18
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Instead of inventing some arbitrary hash function you should probably start by looking at how the forum stores its credentials. Its a HUGE security risk to store raw credentials so most likely its either stored as a plain-text username and a password hash (I'm fairly sure this is the method vBulletin uses) or the username and password hashed together. Once you figure that out, along with the hash algorithm (I suspect md5) then the rest is easy although a random salt should be used not something like a date which can vary by timezone.

Page 2 of 2 FirstFirst 12

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, 02:35 AM
  2. Proposed Webservice - Proximity Web Control
    By ioi8 in forum OSDash - Web Services
    Replies: 7
    Last Post: 12-29-2009, 04:54 PM
  3. Proposed Web Service: Notifications
    By justchat_1 in forum OSDash - Web Services
    Replies: 13
    Last Post: 12-29-2009, 03:12 AM
  4. Proposed Web Service: Online Playlist Management
    By justchat_1 in forum OSDash - Web Services
    Replies: 11
    Last Post: 12-26-2009, 06:05 PM
  5. Proposed Web Service: Simple Online/Offline Status
    By tripzero in forum OSDash - Web Services
    Replies: 5
    Last Post: 12-22-2009, 02: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
  •