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 20 1441
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**********@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.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
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**********@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.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
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
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**********@gmail.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.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
You are right it has been broken
"Spam Catcher" <sp**********@rogers.com> wrote in message
news:Xn**********************************@127.0.0. 1... Ge**********@gmail.com wrote in news:1147297682.398014.186360 @u72g2000cwu.googlegroups.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".
What would be considered a secure way to store passwords?
Paul
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
Yeah, I've read about it being broken, but currently it takes a lot of
processing power and time? Ge**********@gmail.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
Ray Booysen wrote: Ge**********@gmail.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
Hi Ray,
Thats a big help. I've just rewritten the password section to use sha1
+ salt. As stated in a previous post, I currently store a users role
and ID in a session var. But another poster stated this is a security
risk as the role might be changed within the session. A solution is to
just store the user ID and use it to check the role in the db each page
load. Does this sound like a safe way of doing this? I'm just concerned
about the DB getting hit each page load first for role check and then
to pull out the needed data.
Paul
Ray Booysen wrote: Ge**********@gmail.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
Hi Ray,
I've created a class to create a random salt, use it with a password
to created a salted hash and then put it and the salt into the db.
I'm curious as to what stored proc you use to validate a login
password. When the user wishes to log in, they will supply their
password, but then i'd need the salt to create a saltedhash to compare
against the one in the database. Wouldn't this mean pulling the salt
for the uer out to create the saltedhash?
Paul Ge**********@gmail.com wrote: Ray Booysen wrote: Ge**********@gmail.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
Hi Ray,
Thats a big help. I've just rewritten the password section to use sha1 + salt. As stated in a previous post, I currently store a users role and ID in a session var. But another poster stated this is a security risk as the role might be changed within the session. A solution is to just store the user ID and use it to check the role in the db each page load. Does this sound like a safe way of doing this? I'm just concerned about the DB getting hit each page load first for role check and then to pull out the needed data.
Paul
I wouldn't worry too much on the role being only in the database. If
your site does become very busy, the role DB hit will be one of many
"expenses" that you could look at to fix.
For the moment, pulling from the DB shouldn't be too much of a problem. Ge**********@gmail.com wrote: Ray Booysen wrote: Ge**********@gmail.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
Hi Ray,
I've created a class to create a random salt, use it with a password to created a salted hash and then put it and the salt into the db. I'm curious as to what stored proc you use to validate a login password. When the user wishes to log in, they will supply their password, but then i'd need the salt to create a saltedhash to compare against the one in the database. Wouldn't this mean pulling the salt for the uer out to create the saltedhash?
Paul
For the case of authenticating, the user name and password is passed to
the database. In the stored proc, the password is salted with the
stored salt and hashed. Then this hash is compared to the stored hashed
password. If they are the same, you can pass back true or 1 or whatever
you want.
Let me know if you need any other info! :)
Regards
Ray
Ray Booysen wrote: Ge**********@gmail.com wrote: Ray Booysen wrote: Ge**********@gmail.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
Hi Ray,
I've created a class to create a random salt, use it with a password to created a salted hash and then put it and the salt into the db. I'm curious as to what stored proc you use to validate a login password. When the user wishes to log in, they will supply their password, but then i'd need the salt to create a saltedhash to compare against the one in the database. Wouldn't this mean pulling the salt for the uer out to create the saltedhash?
Paul For the case of authenticating, the user name and password is passed to the database. In the stored proc, the password is salted with the stored salt and hashed. Then this hash is compared to the stored hashed password. If they are the same, you can pass back true or 1 or whatever you want.
Let me know if you need any other info! :)
Regards Ray
Hi Ray,
Thanks for the answers :). I'm currently using MySQL server with this
project, and it doesn't contain any functionality for hashing etc (as
far as I am aware anyway). So this means I would have to create the
hash outside the DB. Would pulling the salt out to create the salted
hash when a user tries to log in create any huge security risk? (I
can't see another way of doing this with MySQL server - but i'm still
learning so i might have missed something).
Paul Ge**********@gmail.com wrote: Ray Booysen wrote: Ge**********@gmail.com wrote: Ray Booysen wrote: Ge**********@gmail.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 Hi Ray,
I've created a class to create a random salt, use it with a password to created a salted hash and then put it and the salt into the db. I'm curious as to what stored proc you use to validate a login password. When the user wishes to log in, they will supply their password, but then i'd need the salt to create a saltedhash to compare against the one in the database. Wouldn't this mean pulling the salt for the uer out to create the saltedhash?
Paul For the case of authenticating, the user name and password is passed to the database. In the stored proc, the password is salted with the stored salt and hashed. Then this hash is compared to the stored hashed password. If they are the same, you can pass back true or 1 or whatever you want.
Let me know if you need any other info! :)
Regards Ray
Hi Ray,
Thanks for the answers :). I'm currently using MySQL server with this project, and it doesn't contain any functionality for hashing etc (as far as I am aware anyway). So this means I would have to create the hash outside the DB. Would pulling the salt out to create the salted hash when a user tries to log in create any huge security risk? (I can't see another way of doing this with MySQL server - but i'm still learning so i might have missed something).
Paul
MySQL can create the hashes for you, the functions are built in. E.g.
SELECT MD5(FullName) FROM Customer will create a hash for you. The SHA
hash functions also exist.
I suppose unless you're using the latest version, you won't have access
to stored procedures.
Its not really a security risk as the highest risk there would be the
transfer of the salted hash and the salt from the database. All the
processing will happen server side and shouldn't be too much of a
problem. (I'm sure the more paranoid of the forum will quickly say
differently. ;) )
Hope this helps.
Regards
Ray
Ray Booysen wrote: Ge**********@gmail.com wrote: Ray Booysen wrote: Ge**********@gmail.com wrote: Ray Booysen wrote: > Ge**********@gmail.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 Hi Ray,
I've created a class to create a random salt, use it with a password to created a salted hash and then put it and the salt into the db. I'm curious as to what stored proc you use to validate a login password. When the user wishes to log in, they will supply their password, but then i'd need the salt to create a saltedhash to compare against the one in the database. Wouldn't this mean pulling the salt for the uer out to create the saltedhash?
Paul
For the case of authenticating, the user name and password is passed to the database. In the stored proc, the password is salted with the stored salt and hashed. Then this hash is compared to the stored hashed password. If they are the same, you can pass back true or 1 or whatever you want.
Let me know if you need any other info! :)
Regards Ray
Hi Ray,
Thanks for the answers :). I'm currently using MySQL server with this project, and it doesn't contain any functionality for hashing etc (as far as I am aware anyway). So this means I would have to create the hash outside the DB. Would pulling the salt out to create the salted hash when a user tries to log in create any huge security risk? (I can't see another way of doing this with MySQL server - but i'm still learning so i might have missed something).
Paul
MySQL can create the hashes for you, the functions are built in. E.g. SELECT MD5(FullName) FROM Customer will create a hash for you. The SHA hash functions also exist.
I suppose unless you're using the latest version, you won't have access to stored procedures.
Its not really a security risk as the highest risk there would be the transfer of the salted hash and the salt from the database. All the processing will happen server side and shouldn't be too much of a problem. (I'm sure the more paranoid of the forum will quickly say differently. ;) )
Hope this helps.
Regards Ray
Thanks again Ray :).
I am using MYSQL5, and tried looking through the online manual for
hash functions but couldn't seem to find any. I'll take another look.
Thanks again, you've been a huge help :)
Paul Ge**********@gmail.com wrote: Ray Booysen wrote: Ge**********@gmail.com wrote: Ray Booysen wrote: Ge**********@gmail.com wrote: > Ray Booysen wrote: >> Ge**********@gmail.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 > Hi Ray, > > I've created a class to create a random salt, use it with a password > to created a salted hash and then put it and the salt into the db. > I'm curious as to what stored proc you use to validate a login > password. When the user wishes to log in, they will supply their > password, but then i'd need the salt to create a saltedhash to compare > against the one in the database. Wouldn't this mean pulling the salt > for the uer out to create the saltedhash? > > Paul > For the case of authenticating, the user name and password is passed to the database. In the stored proc, the password is salted with the stored salt and hashed. Then this hash is compared to the stored hashed password. If they are the same, you can pass back true or 1 or whatever you want.
Let me know if you need any other info! :)
Regards Ray Hi Ray,
Thanks for the answers :). I'm currently using MySQL server with this project, and it doesn't contain any functionality for hashing etc (as far as I am aware anyway). So this means I would have to create the hash outside the DB. Would pulling the salt out to create the salted hash when a user tries to log in create any huge security risk? (I can't see another way of doing this with MySQL server - but i'm still learning so i might have missed something).
Paul MySQL can create the hashes for you, the functions are built in. E.g. SELECT MD5(FullName) FROM Customer will create a hash for you. The SHA hash functions also exist.
I suppose unless you're using the latest version, you won't have access to stored procedures.
Its not really a security risk as the highest risk there would be the transfer of the salted hash and the salt from the database. All the processing will happen server side and shouldn't be too much of a problem. (I'm sure the more paranoid of the forum will quickly say differently. ;) )
Hope this helps.
Regards Ray
Thanks again Ray :). I am using MYSQL5, and tried looking through the online manual for hash functions but couldn't seem to find any. I'll take another look.
Thanks again, you've been a huge help :)
Paul
Sure thing! :)
Paul,
time-consuming? it really depend on your application and number of users
hitting your website.
You might not want to go that route but again it depends.
There is no session data on the client side. But you can get attacked from
the outside.
You have to be a very good hacker with resources to hack or hijack a
session.
Just reduce the surface of attack as much as you can, taking into
consideration performance and how secure you want your website to be.
It is a balancing act. No one can give you the perfect and exact solution.
Keep in mind the possibilities and work with it.
You can have hackers coming at your server from the outside or someone from
the inside.
You need to protect all your servers, Web, Apps, Sql. Need to protect
Physical Hardware also and social engineering attacks.
SA
<Ge**********@gmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com... 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
Paul,
What I do in my business layer I get the salt, then I use my custom classes
to hash the passed in password then send the Hash to a Stored Proc to
compare etc..
You can always do all of that on the database side also. ( we did not )
SA
<Ge**********@gmail.com> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com... Ray Booysen wrote: Ge**********@gmail.com wrote: > Ray Booysen wrote: >> Ge**********@gmail.com wrote: >>> Ray Booysen wrote: >>>> Ge**********@gmail.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 >>> Hi Ray, >>> >>> I've created a class to create a random salt, use it with a password >>> to created a salted hash and then put it and the salt into the db. >>> I'm curious as to what stored proc you use to validate a login >>> password. When the user wishes to log in, they will supply their >>> password, but then i'd need the salt to create a saltedhash to >>> compare >>> against the one in the database. Wouldn't this mean pulling the salt >>> for the uer out to create the saltedhash? >>> >>> Paul >>> >> For the case of authenticating, the user name and password is passed >> to >> the database. In the stored proc, the password is salted with the >> stored salt and hashed. Then this hash is compared to the stored >> hashed >> password. If they are the same, you can pass back true or 1 or >> whatever >> you want. >> >> Let me know if you need any other info! :) >> >> Regards >> Ray > > Hi Ray, > > Thanks for the answers :). I'm currently using MySQL server with this > project, and it doesn't contain any functionality for hashing etc (as > far as I am aware anyway). So this means I would have to create the > hash outside the DB. Would pulling the salt out to create the salted > hash when a user tries to log in create any huge security risk? (I > can't see another way of doing this with MySQL server - but i'm still > learning so i might have missed something). > > Paul >
MySQL can create the hashes for you, the functions are built in. E.g. SELECT MD5(FullName) FROM Customer will create a hash for you. The SHA hash functions also exist.
I suppose unless you're using the latest version, you won't have access to stored procedures.
Its not really a security risk as the highest risk there would be the transfer of the salted hash and the salt from the database. All the processing will happen server side and shouldn't be too much of a problem. (I'm sure the more paranoid of the forum will quickly say differently. ;) )
Hope this helps.
Regards Ray
Thanks again Ray :). I am using MYSQL5, and tried looking through the online manual for hash functions but couldn't seem to find any. I'll take another look.
Thanks again, you've been a huge help :)
Paul
I thank you both for this, very informative, thread.
Juan T. Llibre, asp.net MVP
aspnetfaq.com : http://www.aspnetfaq.com/
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
<Ge**********@gmail.com> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com... Ray Booysen wrote: Ge**********@gmail.com wrote: > Ray Booysen wrote: >> Ge**********@gmail.com wrote: >>> Ray Booysen wrote: >>>> Ge**********@gmail.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 >>> Hi Ray, >>> >>> I've created a class to create a random salt, use it with a password >>> to created a salted hash and then put it and the salt into the db. >>> I'm curious as to what stored proc you use to validate a login >>> password. When the user wishes to log in, they will supply their >>> password, but then i'd need the salt to create a saltedhash to compare >>> against the one in the database. Wouldn't this mean pulling the salt >>> for the uer out to create the saltedhash? >>> >>> Paul >>> >> For the case of authenticating, the user name and password is passed to >> the database. In the stored proc, the password is salted with the >> stored salt and hashed. Then this hash is compared to the stored hashed >> password. If they are the same, you can pass back true or 1 or whatever >> you want. >> >> Let me know if you need any other info! :) >> >> Regards >> Ray > > Hi Ray, > > Thanks for the answers :). I'm currently using MySQL server with this > project, and it doesn't contain any functionality for hashing etc (as > far as I am aware anyway). So this means I would have to create the > hash outside the DB. Would pulling the salt out to create the salted > hash when a user tries to log in create any huge security risk? (I > can't see another way of doing this with MySQL server - but i'm still > learning so i might have missed something). > > Paul >
MySQL can create the hashes for you, the functions are built in. E.g. SELECT MD5(FullName) FROM Customer will create a hash for you. The SHA hash functions also exist.
I suppose unless you're using the latest version, you won't have access to stored procedures.
Its not really a security risk as the highest risk there would be the transfer of the salted hash and the salt from the database. All the processing will happen server side and shouldn't be too much of a problem. (I'm sure the more paranoid of the forum will quickly say differently. ;) )
Hope this helps.
Regards Ray
Thanks again Ray :). I am using MYSQL5, and tried looking through the online manual for hash functions but couldn't seem to find any. I'll take another look.
Thanks again, you've been a huge help :)
Paul This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: Billy Jacobs |
last post by:
I have a website which has both secure and non-secure
pages. I want to uses forms authentication. How do I
accomplish this?
Originally I had my web.config file in the root with Forms...
|
by: debedb |
last post by:
Hi all,
I have a link, <A onClick="javascript:foo()">. The
foo() function does
w = window.open('', fieldid+'mywindow', prop);
w.document.open();
d = w.document;
And proceeds to write...
|
by: Mike |
last post by:
I have noticed that the id of my session object changes
when I switch from a non-secure to a secure connection.
What I'm trying to do:
I have a cookie that is built on the non-secure side of...
|
by: Seth |
last post by:
I have noticed that the id of my session object changes
when I switch from a non-secure to a secure connection.
What I'm trying to do:
I have a cookie that is built on the non-secure side of...
|
by: Iulian Ionescu |
last post by:
I have a page (http://www.something.com/) and a secure page (https://secure.something.com) and the secure.something.com points to http://www.something.com/secure/
All works ok, but, when I...
| |
by: Joe |
last post by:
I have an application which runs in a non-secure environment. I also have an
application that runs in a secure environment (both on the same machine). Is
there any way to share the session data for...
|
by: Robert Seacord |
last post by:
The CERT/CC has released a beta version of a secure integer library for
the C Programming Language. The library is available for download from
the CERT/CC Secure Coding Initiative web page at:...
|
by: Robert Seacord |
last post by:
The CERT/CC has just deployed a new web site dedicated to developing
secure coding standards for the C programming language, C++, and
eventually other programming language.
We have already...
|
by: amitvps |
last post by:
Secure Socket Layer is very important and useful for any web application but it brings some problems too with itself. Handling navigation between secure and non-secure pages is one of the cumbersome...
|
by: zr |
last post by:
Hi,
Does usage of checked iterators and checked containers make code more
secure?
If so, can that code considered to be reasonably secure?
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |