rinkel
asked on
Internet Security
What are the strengths and weaknesses of the user-authentication technologies that are employed (such as cookies, digital certificates, secure socket layer, Internet Protocol address recognition)?
They can be spoofed.
Cookies are client side data, and as such cannot be trusted for security related purposes, unless you have some kind of matching test on the server side.
SSL is a better way of securing a network transaction, but again, do you want to authenticate the client or the server, or both? You can trust a certificate only so much (fake certificates can be obtained, root ertificates can be compromised....).
It is more difficult to spoof ip addresses over sessions, but this is still possible.
For rather detailed discussions on this topic, I suggest looking at the OWASP mailing list at http://www.securityfocus.com archives and their site http://www.owasp.org
SSL is a better way of securing a network transaction, but again, do you want to authenticate the client or the server, or both? You can trust a certificate only so much (fake certificates can be obtained, root ertificates can be compromised....).
It is more difficult to spoof ip addresses over sessions, but this is still possible.
For rather detailed discussions on this topic, I suggest looking at the OWASP mailing list at http://www.securityfocus.com archives and their site http://www.owasp.org
They *all* can be spoofed, somehow.
So we don't need to think about any kind of "strength".
:-o
So we don't need to think about any kind of "strength".
:-o
But relative strenghs are important too. We do need to consider strength. If you rely only on cookies, you have bigger problems than if you rely on certificaes, and you will have still less if you rely on cookies+certificates+sessi
Defense in depth is what counts.
Defense in depth is what counts.
I agree, what is best is a combination of the above for security not necessarily just one. I would throw cookies right out the window if information security is of concern however. At any rate none of these are 100% secure in any manner and to believe that your system can even achieve 100% while connected to the Internet is at best naive. All you can do is make it hard as possible for people to intrude. Using SSL+Digital Certificates is a good start. If you’re in a position to be able to restrict by IP or even network ID this is an added bonus. If your site is going to be open and available to the Internet public then IP restriction isn't going to be an option. Using certificate services from MS will cause further restrictions as well.
TooKoolKris
MCSE+I, CCNA, A+
TooKoolKris
MCSE+I, CCNA, A+
On Strength:
All those techniques, and more, will help secure any system you have. More is better, inhibiting casual abuse, limiting vulnerability to simple mistakes even.
On Weakness:
Determined intruders can always find a way to break a 'system'. Whichever you so choose. Internet is open and insecure, by definition.
Relative:
The goal here, is to manage the system intelligently, using resources efficiently and effectively.
* One must understand the tools used and applied. For example, take text like this and apply authentication. Let us say it is for encrypting eMail.
Person_A takes the text and applies programs to encrypt it (text file) on local disk. Then sends text pasted into eMail through clipboard, 'assuming' there is some protection this affords on internet.
Not true, it is still plain text on the web.
Person_B creates in NotePad. Has a checkbox in one $$$ eMail client to encrypt it (text file). Sends file to one friend, 'assuming' no one else could ever see it or read it.
Not true. It is still plain text on both his machine AND now the friend's machine. (ever hear of Outlook Virus? They retrieve these files now)
A beware: both such users may switch to alternative machines and/or eMail platforms, thinking the prior protection (encryption) is inherited.
Not true. It is indeed possible that the very thought of having increased security may cause them to let down their guard when it comes to protecting what is important, thinking, assuming they have done more in securing systems than they had done. So --- their use of encryption may have left them less secure.
Recently, a guest speaker to USofA from Russia presented some slides and information in NV on exactly how, many companies marketed products with terms of using technology such as you mention, while a detailed examination of the products themselves indicated the presumed protection level was unavailable. Hence, to his company, translators were less difficult to generate, and user education on protection levels that exist are based more on innuendo than on fact. Some of the $$$ encryption found needed no more than a kids' decoder ring (free in cereal box).
In Brief:
Systems are made more secure by understanding the techniques and technologies used, than by any differences between the technologies per se.
All those techniques, and more, will help secure any system you have. More is better, inhibiting casual abuse, limiting vulnerability to simple mistakes even.
On Weakness:
Determined intruders can always find a way to break a 'system'. Whichever you so choose. Internet is open and insecure, by definition.
Relative:
The goal here, is to manage the system intelligently, using resources efficiently and effectively.
* One must understand the tools used and applied. For example, take text like this and apply authentication. Let us say it is for encrypting eMail.
Person_A takes the text and applies programs to encrypt it (text file) on local disk. Then sends text pasted into eMail through clipboard, 'assuming' there is some protection this affords on internet.
Not true, it is still plain text on the web.
Person_B creates in NotePad. Has a checkbox in one $$$ eMail client to encrypt it (text file). Sends file to one friend, 'assuming' no one else could ever see it or read it.
Not true. It is still plain text on both his machine AND now the friend's machine. (ever hear of Outlook Virus? They retrieve these files now)
A beware: both such users may switch to alternative machines and/or eMail platforms, thinking the prior protection (encryption) is inherited.
Not true. It is indeed possible that the very thought of having increased security may cause them to let down their guard when it comes to protecting what is important, thinking, assuming they have done more in securing systems than they had done. So --- their use of encryption may have left them less secure.
Recently, a guest speaker to USofA from Russia presented some slides and information in NV on exactly how, many companies marketed products with terms of using technology such as you mention, while a detailed examination of the products themselves indicated the presumed protection level was unavailable. Hence, to his company, translators were less difficult to generate, and user education on protection levels that exist are based more on innuendo than on fact. Some of the $$$ encryption found needed no more than a kids' decoder ring (free in cereal box).
In Brief:
Systems are made more secure by understanding the techniques and technologies used, than by any differences between the technologies per se.
The strengths and weaknesses of such technology boil down to whether or not you can use them to dictate whether or not you know who the user is at the other end....
eg -
Cookies
Just a file on a hard disk. Perhaps secure if protected by NTFS and part of a user-login system, but not if one something like Win 98.
Digital certificates
Users can only get these if they are verified by someone who knows them. These are then password protected. If certificate is comprimised/lost/stolen, users can get them revoked.
SSL
Only verifies the server side is whom they say they are, and encrypts communication. Doesn't authenticate users, only servers.
IP address recognition
Only verifies the IP address. Not the user, or the MAC address for that matter.
Two factor authentication - eg SecurID
Very popular and very secure. User needs to posess both the token, and their password, in order to log in.
eg - the token has a unique number that regenerates every 60 seconds, and users use this plus their password to login. If user loses token, it can't be used on its own to log in. If user writes down password and it is copied, again it can't be used on its own to log in.
Now... what are you looking to implement / do ? :)
eg -
Cookies
Just a file on a hard disk. Perhaps secure if protected by NTFS and part of a user-login system, but not if one something like Win 98.
Digital certificates
Users can only get these if they are verified by someone who knows them. These are then password protected. If certificate is comprimised/lost/stolen, users can get them revoked.
SSL
Only verifies the server side is whom they say they are, and encrypts communication. Doesn't authenticate users, only servers.
IP address recognition
Only verifies the IP address. Not the user, or the MAC address for that matter.
Two factor authentication - eg SecurID
Very popular and very secure. User needs to posess both the token, and their password, in order to log in.
eg - the token has a unique number that regenerates every 60 seconds, and users use this plus their password to login. If user loses token, it can't be used on its own to log in. If user writes down password and it is copied, again it can't be used on its own to log in.
Now... what are you looking to implement / do ? :)
OK, I'll chime in too on this one....
Cookies -
o Cookie contents have to be very carefully chosen to avoid brute-force/guessing attacks.
o Cookie can be stolen in transit and replayed (protect with SSL).
o Rogue user with physical access to computer can use cookie for authentication (protect by also requiring password)
o Hacker can steal cookie over net if they can break into computer (protect by also requiring a password or binding cookie to specific IP address [but many machines have dynamic IP's these days])
o Chicken-and-egg problem of authentication needed to set cookie.
Digital Certs -
o Rogue user with physical access can steal private part of cert (protect by requiring additional password, password-protecting cert itself, or storing cert on smart-card/crypto-card)
o Hacker can steal cert over net if can break into computer (protect by binding to IP address, password-protecting cert, or storing on smart-card/crypto-card)
SSL -
This is not an authentication mechanism. However, it can be used to protect other authentication mechanisms (cookies, passwords) from replay attacks. It can also protect sensitive data from confidentiality attacks.
IP address recognition
o Trivial to spoof
o Many computers have dynamic IP's
Cookies -
o Cookie contents have to be very carefully chosen to avoid brute-force/guessing attacks.
o Cookie can be stolen in transit and replayed (protect with SSL).
o Rogue user with physical access to computer can use cookie for authentication (protect by also requiring password)
o Hacker can steal cookie over net if they can break into computer (protect by also requiring a password or binding cookie to specific IP address [but many machines have dynamic IP's these days])
o Chicken-and-egg problem of authentication needed to set cookie.
Digital Certs -
o Rogue user with physical access can steal private part of cert (protect by requiring additional password, password-protecting cert itself, or storing cert on smart-card/crypto-card)
o Hacker can steal cert over net if can break into computer (protect by binding to IP address, password-protecting cert, or storing on smart-card/crypto-card)
SSL -
This is not an authentication mechanism. However, it can be used to protect other authentication mechanisms (cookies, passwords) from replay attacks. It can also protect sensitive data from confidentiality attacks.
IP address recognition
o Trivial to spoof
o Many computers have dynamic IP's
> Internet Security
= Oxymoron
= Oxymoron
Hmm, there seems a lot of comment above, so best guess is question has been answered, so movin' on until rinkel's feedback on comments to date.
> smart-card/crypto-card
.. and IBM posted a paper (somewhere) how to crack cards within minutes (well, the described algorithm worked with their cards only, but ...)
relative strength - strength - oxymoroon
anyway, nice chat for a homework :-))
.. and IBM posted a paper (somewhere) how to crack cards within minutes (well, the described algorithm worked with their cards only, but ...)
relative strength - strength - oxymoroon
anyway, nice chat for a homework :-))
Ability to proof an editorial on subject summarizing above would be welcome
http://www.research.ibm.com/intsec/emf-paper.ps
or serach for "side channel attack", "partitioning attack"
or serach for "side channel attack", "partitioning attack"
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Blow the cookies away--they are useless--for the most part:)
Your best buy is going Norton Systems 2002. It will orrect the bullshit and make your computer viable for future operations
Your best buy is going Norton Systems 2002. It will orrect the bullshit and make your computer viable for future operations
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q260971&GSSNB=1
Description of Digital Certificates (Q195724)
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q195724
HOWTO: Set Up Test Certificates for SSL/TLS Application Development (Q288897)
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q288897
HOW TO: Perform Security Planning for Internet Information Services 5.0 (Q311184)
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q311184
These should get you started
TooKoolKris
MCSE+I, CCNA, A+