Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: ASP authentication |
|---|---|
| Date: | Mon, 30 Aug 2004 03:41:21 -0500 |
Hi there. :) I hope my code is of some use to you. (Remember, I'm a student...that means I'm POOR. *hint hint* :) Anyhow, here's my spiel on this: While sessions alone are secure enough for most sites to allow access to content after authentication (i.e.: upon successful authentication a session variable called "authenticated" is set to "yes" and this session variable is checked whenever a members-only portion of the site is viewed), the added protection of encrypting any session data stored on file (i.e.: in a database server, not just in memory), is a step in the direction of thwarting users who gain access to the database, or perhaps less than ethical DBAs, from abusing that access. It's not foolproof, but it lets you say "Absolutely none of your data is stored unencrypted on disk," and mean it. (Assuming you don't store anything sensitive outside of the session, in which case you'd want to encrypt that too.) A more lofty encryption scheme (and more CPU- and disk- intensive one) that blinds pretty much everyone but the user from seeing data (including blinding you!) would make use of RSA or other asymmetric encryption algorithm(s), using the user's password or session key as the private key, and storing the public key (generated from the passwd/session id/private key in the database entry/record/row with the encrypted data. I didn't implement such a scheme because I thought it might be overkill and would definitely not be very resource-friendly. Best wishes, Ido Rosen On Sun, Aug 29, 2004 at 04:28:09PM +0000, focus@karsites.net wrote:
May be of some use: Encrypted session date code example - HTH http://www.cs.uchicago.edu/~ido/session_include_php.txt Regards - Keith Roberts On Sat, 28 Aug 2004, pfeito wrote:To: 'B?noni MARTIN' <Benoni.MARTIN@libertis.ga>, webappsec@lists.securityfocus.com From: pfeito <pfeito@netcabo.pt> Subject: RE: ASP authentication You could hash or encrypt the UserID and store it in a session variable. This adds an extra layer of security. Its not bullet proof but its more safe and it adds little cpu overhead. Hash would be better than symmetrical encryption, but then you'll need the passwords hashed in the database also. -pfeito
-- +-------------------------------------------------+ | Email : ido@ieee.org / ido@cs.uchicago.edu | | Jabber : phaedo@jabber.org | | PGP : http://www.cs.columbia.edu/~ido/pgp | +-------------------------------------------------+
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: key storage, Brown, James F. |
|---|---|
| Next by Date: | Re: ASP authentication, Saphyr |
| Previous by Thread: | RE: ASP authentication, focus |
| Next by Thread: | RE: ASP authentication, Sarbjit Singh Gill |
| Indexes: | [Date] [Thread] [Top] [All Lists] |