WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!
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)?
Asked:
3-
2
-
2
- +7
1 Solution
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
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
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 :-))
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"
All those methods are not separate, they should be used
in combination. I'll add to the comments that:
cookies: is used for user tracking.
- more reliable for tracking than IP addres recognition.
- more secure if no expiration field is sent in the http header.
because then the browser will keep it in memory (ram),
rather than a file.
Digital certificates:
Is certainly the best way to encrypt data on the web.
it's not completely fool proof, but 128-bit encryption
is the safest the web can do without asking the user
to download anything.
secure socket layer: (SSL) SSLv3 is nothing but how most browser implement digital certificates above.
Internet Protocol address recognition:
ip address is unreliable on the internet at large, since
anybody can spoof an ip... however, most ips are not spoofed
and they can be used to tag a user on his first login or
similar methods.
This cannot be used for security, but can is certainly very usefull as a tool to record user access, stats, multiple-connects. an easy way in apache is to use
the mod_usertrack module.
if you want real security for your users, the best is to
give them ssh access. but then you'd need to develop
an application on top of secsh protocol. a program like WinSCP does fully secure file transfer between users.
well that's in short...
We use all these methods and many others at rootroute.com were I work, including 128-bits SSL certificates.
Regards,
Boris
in combination. I'll add to the comments that:
cookies: is used for user tracking.
- more reliable for tracking than IP addres recognition.
- more secure if no expiration field is sent in the http header.
because then the browser will keep it in memory (ram),
rather than a file.
Digital certificates:
Is certainly the best way to encrypt data on the web.
it's not completely fool proof, but 128-bit encryption
is the safest the web can do without asking the user
to download anything.
secure socket layer: (SSL) SSLv3 is nothing but how most browser implement digital certificates above.
Internet Protocol address recognition:
ip address is unreliable on the internet at large, since
anybody can spoof an ip... however, most ips are not spoofed
and they can be used to tag a user on his first login or
similar methods.
This cannot be used for security, but can is certainly very usefull as a tool to record user access, stats, multiple-connects. an easy way in apache is to use
the mod_usertrack module.
if you want real security for your users, the best is to
give them ssh access. but then you'd need to develop
an application on top of secsh protocol. a program like WinSCP does fully secure file transfer between users.
well that's in short...
We use all these methods and many others at rootroute.com were I work, including 128-bits SSL certificates.
Regards,
Boris
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
Featured Post
WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network. Check out this quarters report on the threats that shook the industry in Q4 2017.
Tackle projects and never again get stuck behind a technical roadblock.
Join Now
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+