Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14

    User Authentication


    I have a site hosted on a Linux / Apache platform and will be password-protecting an area of the site. I have been contemplating doing this with HTTP Basic Authentication. I read some information on the web that stated that when using HTTP Authentication, username and password are transmitted unencrypted across the web, which seems to defeat the whole purpose of the password-protection, except when dealing with users that are non-malicious, or malicious, but inept. Is there a way to implement HTTP Basic Authentication in conjunction with SSI so that username and password are encrypted for transmission?
  2. #2
  3. No Profile Picture
    Apprentice Deity
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Jul 1999
    Location
    Niagara Falls (On the wrong side of the gorge)
    Posts
    3,237
    Rep Power
    18
    Do you mean SSL? If so, yes. If SSL is implemented, EVERYTHING (including HTTP Basic Auth usernames and passwords) will be encrypted.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2000
    Posts
    23
    Rep Power
    0

    basic authentication


    yes, a user's credentials entered after a 401 browser challenge (which brings up the standard browser dialog box asking for username and password) will be passed in the header request as essentially clear-text. Like this:

    Authorization: Basic hu748dlAG837842BZzU==

    Don't be fooled that the usernameassword string (which is what the junk text represents) is encrypted... it's not. It's in base64 format, so that anyone can easily decrypt it.


    ===========================================
    http://badblue.com/helpphp.htm
    Free small footprint web server for Windows
    PHP, P2P file-sharing, transcoding and more
    ===========================================
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14

    User Authentication


    Rod K,

    Yes, you're right of course, I did mean SSL. The thing is, I don't want to put everything behind SSL due to the performance penalty and other issues, I would like to just authenticate the user in that fashion and then have them go back to a regular HHTP connection to continue browsing the site.

    ame12,

    That kind of defeats the purpose then, doesn't it?
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    4
    Rep Power
    0
    >> I don't want to put everything behind SSL due to the performance penalty and other issues

    What performance penalty? What other issues? In 5 years or so, http will be gone, just https that is left.
  10. #6
  11. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2001
    Posts
    4
    Rep Power
    0
    Look into the method used by PHPLib for handling this very issue without SSL. They use MD5 and a randomly generated key value to create a hash value to be returned from the client to the server. The Password is never sent as clear text.
  12. #7
  13. No Profile Picture
    Apprentice Deity
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Jul 1999
    Location
    Niagara Falls (On the wrong side of the gorge)
    Posts
    3,237
    Rep Power
    18
    That's nothing be a horrible hack.

    Since no decryption is done server side, all a sniffer would have to do is send what they sniff. I.E. the md5 hash
  14. #8
  15. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2001
    Posts
    4
    Rep Power
    0
    True a sniffer could get the hash, but the key which is randomly generated, passed to the login page to be used in the MD5 hash generation, is only valid for the current session. Even if a sniffer had all that information, it is only valid for the session that was in progress, unless I'm missing something here.
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2001
    Location
    Tauranga, NZ
    Posts
    349
    Rep Power
    13
    If i was to the pass the session via a url
    example
    https://secutesite.com/mysite/index.php$session_id$

    Will it be encrypted using SSL
    or am I better off the to post the session id via a form ?
  18. #10
  19. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2000
    Posts
    23
    Rep Power
    0

    penalty


    Just an FYI.. yes there is a huge performance penalty for implementing SSL (20X on some systems). That's why there's a great business in selling hardware crypto accelerators.

    Regarding MD5... depends upon the implementation, but usually MD5 is susceptible to sniffing because it is a flat hash that is compared with the server's version of the same credentials.

    Not entirely secure in most cases...


    ===========================================
    http://badblue.com/helpphp.htm
    Free small footprint web server for Windows
    PHP, P2P file-sharing, transcoding and more
    ===========================================
  20. #11
  21. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    4
    Rep Power
    0
    >> yes there is a huge performance penalty for implementing SSL (20X on some systems)

    Wrong. The performance difference is minimal. There is no reason not to implement SSL for such situation.

    >> That's why there's a great business in selling hardware crypto accelerators

    This statement doesn't support the performance penalty of SSL.
  22. #12
  23. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2000
    Posts
    23
    Rep Power
    0

    SSL performance penalty


    >>> The performance difference is minimal. There is no reason not to implement SSL for such situation.

    Y'know I did a search and... you appear to be absolutely correct in this statement. I've got to back to my IT department and figure out why they are buying these SSL hardware accelerators. The reason they were buying these is - they told me - 10x or 20x delays in SSL... but having done a search I found that typically delays are 22%... not 20x.

    Research paper here:
    http://www.cs.nyu.edu/artg/research/...omparison.html

    Thanks for the heads up


    ===========================================
    http://badblue.com/helpphp.htm
    Free small footprint web server for Windows
    PHP, P2P file-sharing, transcoding and more
    ===========================================
  24. #13
  25. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    4
    Rep Power
    0
    Not to mention 20%, even 30% is reasonable. 20x is just way too non-sense. Getting better hardware would also make the difference less significant, maybe just 5%.
  26. #14
  27. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14

    security


    Everyone's input is greatly appreciated, but is there any consensus on this subject: how to implement a secure form of user authentication? I didn't realize this was going to be uncharted territory. I mentioned a performance penalty with SSL becuase that is what I had heard. My site is already taking aperformance hit because I am using a single PHP template as the basis for the entire site and using includes to incorporate the content for individual pages, so if there is a performance penalty with SSL I think the combination would cripple the site. At this point, the option that seems to be most viable is to create a database of usernames and passwords, then have the user enter their username and password on a form that is submitted through a https connection. If the username and password checks out, place a cookie (that will expire after, say, a day) on their machine that will be checked for by all pages in the protected area of the site. A couple of questions about that approach...how safe would my database be on the server? I actually don't even know where the database is located, I have a virtual hosting account and just connect to the database with a datasource name. Also, I apparently get just one database, so I would be putting various tables in the same database that are not related to each other , such as a table storing usernames / passwords, a table containing a membership directory for the organization, etc. Is that a good idea in general / in this context? Any advice appreciated.
  28. #15
  29. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2001
    Location
    Manchester, UK
    Posts
    80
    Rep Power
    13
    i have a question. is the security issue more on the server or client side? if the issue is with server side snooping then my suggestion below will not be valid, if the issue is more on the client side then...

    why not authenticate on an alternative port? would you guess to snoop on port 1603? (this is an example port number ) a redirect could then take you to the approriate page back on the http port.

    i would be interested to hear what others think to this approach.

    cheers - robert.
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo