Is this secure

[Gef.Mongoose]

I MD5 encrypt passwords in a user table of my database. I have a global
application object (initiated in global.aspx) which contains a few
static members (for counting users online etc). because the MD5 encrypt
algorithm is used on creation of a new user, and on login of a user, I
considered putting it in a shared place. Would there be any security
risk if I put it as a public static method in the global object? Or is
this a bad idea?

Paul

[Kevin Spencer]

I can't see any reason why it would be a security risk.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

<Ge**********@g mail.com> wrote in message
news:11******** **************@ u72g2000cwu.goo glegroups.com.. .

I MD5 encrypt passwords in a user table of my database. I have a global
application object (initiated in global.aspx) which contains a few
static members (for counting users online etc). because the MD5 encrypt
algorithm is used on creation of a new user, and on login of a user, I
considered putting it in a shared place. Would there be any security
risk if I put it as a public static method in the global object? Or is
this a bad idea?

Paul

[MSDN]

what if your memory gets hijacked? You might say what?
Ask this question why did Microsoft create System.Security .SecureString()
Sessions can by hijacked etc...

Keep your objects a moving memory target. just make it more difficult.

SA
<Ge**********@g mail.com> wrote in message
news:11******** **************@ u72g2000cwu.goo glegroups.com.. .

I MD5 encrypt passwords in a user table of my database. I have a global
application object (initiated in global.aspx) which contains a few
static members (for counting users online etc). because the MD5 encrypt
algorithm is used on creation of a new user, and on login of a user, I
considered putting it in a shared place. Would there be any security
risk if I put it as a public static method in the global object? Or is
this a bad idea?

Paul

[Gef.Mongoose]

The encrypt function wouldn't contain anything sensitive as such. It
takes a string, MD5 encrypts it, and returns the encrypted string. Are
you saying persistent objects, such as ones initiated at application
start, are a potential security risk? Also, once I authenticate a user,
I store the fact they are authenticated in an object created at session
start - no sesntive information is there, just their role, username and
isLoggedIn = true etc. Is this wrong to do? If so, what would be a
secure way of maintaining the knowledge a user has successfully logged
in?

paul

[MSDN]

Just reduce the surface of attach, memory/time and make it more difficult
there is no bullet proof way.

Few notes: ( keep an open mind )
What if a super hacker gets into your memory or session and change the role
to Admin role.
I would not store encrypted passwords in the database, I would Hash and Salt
them ( Pepper is optional )
Is Public shared can be easier to access?
After Authentication store the user id then check the role on every page
access. I have seen that on web sites ( no kidding )
that way no one can change the role.
What if they change the Id? if they know it you have a point. You might
issue a GUID with exportation as a token and not an Id.
Expire the Token every few minutes. and renew the GUID with a new
expiration. Then the super hacker need to find the new GUID etc..

To completely not allow hackers to sniff or detect your session then check
out Quantum Optical Photon Encryption.

Thank You,

SA
<Ge**********@g mail.com> wrote in message
news:11******** **************@ i39g2000cwa.goo glegroups.com.. .

The encrypt function wouldn't contain anything sensitive as such. It
takes a string, MD5 encrypts it, and returns the encrypted string. Are
you saying persistent objects, such as ones initiated at application
start, are a potential security risk? Also, once I authenticate a user,
I store the fact they are authenticated in an object created at session
start - no sesntive information is there, just their role, username and
isLoggedIn = true etc. Is this wrong to do? If so, what would be a
secure way of maintaining the knowledge a user has successfully logged
in?

paul

[Dumbell]

You are right it has been broken

"Spam Catcher" <sp**********@r ogers.com> wrote in message
news:Xn******** *************** ***********@127 .0.0.1...

Ge**********@gm ail.com wrote in news:1147297682 .398014.186360
@u72g2000cwu.go oglegroups.com:

I MD5 encrypt passwords in a user table of my database.

Actually MD5 is not an encryption algorithm - it only hashs data.

I wouldn't consider MD5 "secure".

[Gef.Mongoose]

What would be considered a secure way to store passwords?

Paul

[Gef.Mongoose]

Ok, so is the main potential security risk server side? Is it possible
for people to easily change session data client side? If so, would
checking role each page load be considered too time-consuming on the
DB? Or is this the norm?

Thanks,

Paul

[Gef.Mongoose]

Yeah, I've read about it being broken, but currently it takes a lot of
processing power and time?

[Ray Booysen]

Ge**********@gm ail.com wrote:

What would be considered a secure way to store passwords?

Paul

Hi Gef

I use SHA1 to hash my passwords. When a user is created on my site, his
password prefixed with a randomly generated salt and hashed with SHA1.
Both the hashed password and salt are stored in the database.

When the user logs in, his password is sent to the SQL server in plain
text through a stored proc and the stored procedure returns whether it
is correct or not, the salt and hash never leave the database once there.

If the user changes their password a new salt is generated and stored
again in the database.

Hope this helps.

Regards
Ray