I've personally found out how annoying it is to have a strong AES method. I used Axcrypt on some secure data a while ago (it was data that was given to me and had to be secure) I still have it, but can't remember the bloody password!
'Hashed data is incredibly hard to crack, but since it destroys the original data there is no real "conversion method" back.'
A hash is designed to be unreversable, cracking it is, in most cases, impossible. The best you can do (with the latest MD5/SHA1 attacks) is subsitute a block of data in the file with a random block.
'This concept is what makes UNIX password hashes so secure in comparison to Windows, which simply encrypts its user data in a basic, readily known method.'
NTLM used to do this (circa NT4), but that disapeared a long time ago.
For domain machines, Kerberos is used instead, which is more secure as the machine you're connecting to never knows your password, or even a hash of it (hashes can be used to perform replay attacks when a recorded response is used). So in actual fact most UNIX boxes are more succeptable to direct password stealing attacks then Windows machines, especially if you're using NIS anywhere.
'you get your devices logged onto it, hide your SSID'
This does nothing to protect you against hackers. Hiding your SSID doesn't slow down most of the hacking tools available. Also, XP SP2 machines assume that the SSID is available and this hiding tends to make your connection unreliable, so people give up and go back to WEP assuming that as they're hidden they can't be attacked. Not the best situation to be in.
'The beauty of SSH is its asymmetrical encryption...'
SSH is not asymmetric, it's too slow. SSH uses Diffie-Hellman key exchange at the beginning of a session to generate a unique random key that is used to symetrically encrypt the traffic for that session.
Nice little article. I knew most of the back story but the applied crypto stuff could be useful.
Also, I liked the fact that you tackled the weakest part of any encryption - the human part.
Thanks for the input, but I have a couple contentions with your corrections.
Quote:
Originally Posted by Hashes A hash is designed to be unreversable, cracking it is, in most cases, impossible. The best you can do (with the latest MD5/SHA1 attacks) is subsitute a block of data in the file with a random block.
The best you can hope for is to put something in and have it be properly accepted, not deconstruct the entire list. That would be why I said "there is no conversion method back." I also stated that it is destructive. Therefore, this isn't a correction, it's simply a clarification of my point.
Quote:
Originally Posted by UNIX vs Windows password security
NTLM used to do this (circa NT4), but that disapeared a long time ago.
For domain machines, Kerberos is used instead, which is more secure as the machine you're connecting to never knows your password, or even a hash of it (hashes can be used to perform replay attacks when a recorded response is used). So in actual fact most UNIX boxes are more succeptable to direct password stealing attacks then Windows machines, especially if you're using NIS anywhere.
Particularly for your remote connections, you make a very valid point. However, in the article I spoke of direct, physical access to the box. I bring this up because users may have a roommate in college or in a flat that has access to the physical machine - in that case, Windows becomes far less secure.
Hand me a Windows box (server or client), a knoppix CD and a couple tools of my choosing and I'll have an entire list of all viable login accounts and their passwords. Try doing that with a UNIX box and you'll get nowhere (see your own argument on hashes above). I DO agree with the point you're making about remote login, but please keep in mind that it wasn't what I was intending to say.
Quote:
Originally Posted by SSID point This does nothing to protect you against hackers. Hiding your SSID doesn't slow down most of the hacking tools available. Also, XP SP2 machines assume that the SSID is available and this hiding tends to make your connection unreliable, so people give up and go back to WEP assuming that as they're hidden they can't be attacked. Not the best situation to be in.
I have several XP machines running on hidden SSIDs, so I'm not sure what your point is. My basic concept for hiding it is to add one more layer of difficulty for a hacker, not to make it foolproof. Sadly, no wireless security is truly "safe" - there needs to be a balance between safety and speed in a streaming method. That's one reason why I put it in as an after-point, though maybe I should have clarified better.
The point of hiding the SSID isn't total hacker protection, it's simply to add one more layer of difficulty. If you are sniffing packets, you now have to determine one more factor before you can use the network in the first place. Most run of the mill, drive-by hacking types will never bother to do something like this. Your SSID should always be hidden when you are not actively inviting people to join your networks - it's a good security precaution to just get in the habit of.
Quote:
Originally Posted by SSH SSH is not asymmetric, it's too slow. SSH uses Diffie-Hellman key exchange at the beginning of a session to generate a unique random key that is used to symetrically encrypt the traffic for that session.
For this one, I'm just gonna have to say you're wrong. I can handle arguments about where I didn't go into detail enough, but I'd appreciate that you at least give me credit for doing my research first.
The entire creation is done at random and is transparent to the user, but it is indeed assymetric encryption. I can give you a long list of sources explaining the asymmetric-key methods used in SSH, but this should give you a good beginner read:
I agree with your hash points, just me reading your description in a funny way.
As for the password storing I believe this depends on the settings of Windows. I'm pretty sure the swap to kerberos can be done on a client machine, but not 100% sure on that.
That said, there are attacks using rainbow tables against unix password tables. They aren't pretty, but they do work. And as you pointed out yourself, once someone has physical access to a machine you're pretty much screwed unless the whole disk is encrypted.
I only mentioned the SSID thing as it's a well know bug with the XP wireless stack. That said, I think it mainly causes problems when the connection isn't very strong.
On SSH we're both wrong, and right :).
During setup, key-exchange and other things are done using public key encryption. However, if you look at RFC 4253 (as reference from the Wikipedia article) on page 9 you'll see the list of encryption types used for the transport layer. All of these are symmetric. Page 17 defines the encryption type field used to describe the client-server and server-client channel as: 'A name-list of acceptable symmetric encryption algorithms (also known as ciphers) in order of preference.'
So while the setup is asymmetric the data after that is encrypted using a symmetric cipher, which was the point I was (badly) trying to get at :).
Sorry if some of my 'corrections' seemed a bit blunt. It's been a long day at work and I should know better to post replies without having a break to re-read them first. :)
I see your point on the SSID, I hope my clarification makes more sense then. And as for SSH, yes, I guess we can say we're both correct. The initial handshakes are done using public-key methods, allowing for authentication. After that, the cypher changes to a symmetric standard. Since the connection method is asymmetric, it guarantees a safe channel with authentication (which is the basic point of public-key to begin with). Once authenticated, it can switch safely to a symmetric method using a randomly-generated key between client and host. That goes quite a bit above and beyond the "field guide" approach of basics and applications, but I agree it's a valid amendment. My point in pointing out the public-key method is to show that there is indeed an authentication mechanism in place for SSH, something that can't be done with solely symmetrical means.
Don't worry about the discussion, that's what a forum is for. :) It's nice to know where I missed the boat on my explanations and to have some deeper insight provided by our readers. I appreciate the contribution!
next we need an introduction to hiding data. As that's where the money is at, there's 2 techniques I'm familiar with the first which I can't find anymore is storing text files in mp3's by changing the encoding algorythm slightly If you had 3-5gigs of mp3's it would be a tough time just trying to find the mp3 that stored the text file. The next issue which as far as i know hasn't been cracked yet is to grab a stack of digital pics, open them up in photoshop and then just burn in a message one or 2 shades lighter or darker in an image if it's a large photo it will be invisible to the naked eye and it will be invisible unless you know which photo and where to look and then you raise the contrast in that area. I suppose there's million's of ways of hiding data which is what I'm more interested in as it's much harder to crack a file you can't find.
anyways nice article I was always a little clueless to file encryption mainly as I never had a reason to encrypt anything, but it's was an interesting read
Hand me a Windows box (server or client), a knoppix CD and a couple tools of my choosing and I'll have an entire list of all viable login accounts and their passwords.
I am not sure how you would do that. All the tools I am aware of let you change the password or bruit force (or dictionary) crack them, but I have not seen anything that will tell you what the password is in a timely fashion unless the passwords are not very strong. It took me around 5 hours to crack my local passsword when I tried it. My more secure password hadn't been cracked after 2 days non stop.
Recently I have tried cracking into a couple of windows machines (a customer had locked them selves out) by replacing the password hash and it doesn't seem to work properly with XP SP2.
Excellent article. It was a fascinating read. :D (Da Dego)++
Now, one question. Let's say I'm paranoid (I am in fact paranoid, but let's pretend I'm actually not and we're just pretending I am :p). I've got my USB key which is completely secured using TrueCrypt, except for a small portion which carries DSL (leaving aside how that would work, for now). So I go to a random computer and use QEMU to boot up DSL and get my own secure environment. There's just one concern I have: I'm not sure how QEMU's emulation works, but could a keylogger running in the host operating system (presumably Windows) still log all my keystrokes even within QEMU?
Originally Posted by cebla I am not sure how you would do that. All the tools I am aware of let you change the password or bruit force (or dictionary) crack them, but I have not seen anything that will tell you what the password is in a timely fashion unless the passwords are not very strong. It took me around 5 hours to crack my local passsword when I tried it. My more secure password hadn't been cracked after 2 days non stop.
Recently I have tried cracking into a couple of windows machines (a customer had locked them selves out) by replacing the password hash and it doesn't seem to work properly with XP SP2.
It really is that easy... Boot the knoppix cd, copy over the SYSTEM and SAM files, use 2 tools (bkhive and samdump2) to extract the password and done... (goolge it, it'll pop up quite easily)...
But to be fair, Linux isn't more secure when one has physical acces to the system. If you boot into single user (or recovery) mode, you have all the rights you want. Remote access on the contrary is a fair bit more secure :)
BIOS password rules ! (only if you can't clear CMOS, otherwise it's pretty useless too, I was thinking about laptops.)
As soon as you get physical access and BIOS control (boot sequence...) it gets a tad easier.
I've got a CD you can boot with and reset the windows passwords of any user accounts on WinXP or 2k.
the TOR browser could also be mentioned, as it anonymizes the user. (not very sure)
Excellent article Brett, a very interesting introduction to something I knew a little about. Thanks :)
Personally I'd played around with Truecrypt once before. I considered using it for my entire RAID. I realised though that while running Truecrypt prevents other people from getting access to my data, if I screw up, it prevents me gaining access to my data. Weighing up the possibility of others getting my data against the possibility of me screwing up and losing my key or somehow messing up my access to a huge ammount of data, I chose not to. That said, I wasn't aware that you could use a file on a USB key as a password type thing, which does sound like it woud work extremely well.
Originally Posted by specofdust That said, I wasn't aware that you could use a file on a USB key as a password type thing, which does sound like it woud work extremely well.
It works great, untill you mistakenly format your USB drive like a friend of mine did...
Originally Posted by Glider It really is that easy... Boot the knoppix cd, copy over the SYSTEM and SAM files, use 2 tools (bkhive and samdump2) to extract the password and done... (goolge it, it'll pop up quite easily)...
But to be fair, Linux isn't more secure when one has physical acces to the system. If you boot into single user (or recovery) mode, you have all the rights you want. Remote access on the contrary is a fair bit more secure :)
Ok I just looked up both bkhive and samdump2 and they only seem to extract the password hashes. This means you still have to use a dictionary or brute force attack to crack the passwords. If you have week passwords then the dictionary crack will give you the password very quickly, but if you have a strong password it could still be quite some time before you get the password.
One problem is that we still call these passwords. A change to pass phrase implies longer. If I tell a user to pick a password they come back with Fido or Fido1. If I ask for a pass phrase they'll come back with "My dog is Fido." This usually is easier to remember and much longer than a password. Factor in a couple of numbers and you've got a good start to getting you (or your users) using strong passwords(phrases). "My 1st dog is Fido." #, punctionation, cap and small.
Originally Posted by article Unfortunately, much like Truecrypt, it looks like most of the versions require a full install rather than just being able to be run straight from the USB key. However, I've not checked out all of the versions out there - so if someone spots one, please let us know!
Hand me a Windows box (server or client), a knoppix CD and a couple tools of my choosing and I'll have an entire list of all viable login accounts and their passwords.
I am not sure how you would do that. All the tools I am aware of let you change the password or bruit force (or dictionary) crack them, but I have not seen anything that will tell you what the password is in a timely fashion unless the passwords are not very strong. It took me around 5 hours to crack my local password when I tried it. My more secure password hadn't been cracked after 2 days non stop.
Comments 1 to 22 of 22
'Hashed data is incredibly hard to crack, but since it destroys the original data there is no real "conversion method" back.'
A hash is designed to be unreversable, cracking it is, in most cases, impossible. The best you can do (with the latest MD5/SHA1 attacks) is subsitute a block of data in the file with a random block.
'This concept is what makes UNIX password hashes so secure in comparison to Windows, which simply encrypts its user data in a basic, readily known method.'
NTLM used to do this (circa NT4), but that disapeared a long time ago.
For domain machines, Kerberos is used instead, which is more secure as the machine you're connecting to never knows your password, or even a hash of it (hashes can be used to perform replay attacks when a recorded response is used). So in actual fact most UNIX boxes are more succeptable to direct password stealing attacks then Windows machines, especially if you're using NIS anywhere.
'you get your devices logged onto it, hide your SSID'
This does nothing to protect you against hackers. Hiding your SSID doesn't slow down most of the hacking tools available. Also, XP SP2 machines assume that the SSID is available and this hiding tends to make your connection unreliable, so people give up and go back to WEP assuming that as they're hidden they can't be attacked. Not the best situation to be in.
'The beauty of SSH is its asymmetrical encryption...'
SSH is not asymmetric, it's too slow. SSH uses Diffie-Hellman key exchange at the beginning of a session to generate a unique random key that is used to symetrically encrypt the traffic for that session.
Also, I liked the fact that you tackled the weakest part of any encryption - the human part.
Thanks for the input, but I have a couple contentions with your corrections.
Hand me a Windows box (server or client), a knoppix CD and a couple tools of my choosing and I'll have an entire list of all viable login accounts and their passwords. Try doing that with a UNIX box and you'll get nowhere (see your own argument on hashes above). I DO agree with the point you're making about remote login, but please keep in mind that it wasn't what I was intending to say.
The point of hiding the SSID isn't total hacker protection, it's simply to add one more layer of difficulty. If you are sniffing packets, you now have to determine one more factor before you can use the network in the first place. Most run of the mill, drive-by hacking types will never bother to do something like this. Your SSID should always be hidden when you are not actively inviting people to join your networks - it's a good security precaution to just get in the habit of.
The entire creation is done at random and is transparent to the user, but it is indeed assymetric encryption. I can give you a long list of sources explaining the asymmetric-key methods used in SSH, but this should give you a good beginner read:
http://en.wikipedia.org/wiki/Secure_Shell
Make sure to read down to the bottom where it talks about the encryption standards.
Anyhow, thanks for the challenges to some of my points, apparently I didn't clarify them well enough for more discerning eyes :)
:)
I agree with your hash points, just me reading your description in a funny way.
As for the password storing I believe this depends on the settings of Windows. I'm pretty sure the swap to kerberos can be done on a client machine, but not 100% sure on that.
That said, there are attacks using rainbow tables against unix password tables. They aren't pretty, but they do work. And as you pointed out yourself, once someone has physical access to a machine you're pretty much screwed unless the whole disk is encrypted.
I only mentioned the SSID thing as it's a well know bug with the XP wireless stack. That said, I think it mainly causes problems when the connection isn't very strong.
On SSH we're both wrong, and right :).
During setup, key-exchange and other things are done using public key encryption. However, if you look at RFC 4253 (as reference from the Wikipedia article) on page 9 you'll see the list of encryption types used for the transport layer. All of these are symmetric. Page 17 defines the encryption type field used to describe the client-server and server-client channel as: 'A name-list of acceptable symmetric encryption algorithms (also known as ciphers) in order of preference.'
So while the setup is asymmetric the data after that is encrypted using a symmetric cipher, which was the point I was (badly) trying to get at :).
Sorry if some of my 'corrections' seemed a bit blunt. It's been a long day at work and I should know better to post replies without having a break to re-read them first. :)
I see your point on the SSID, I hope my clarification makes more sense then. And as for SSH, yes, I guess we can say we're both correct. The initial handshakes are done using public-key methods, allowing for authentication. After that, the cypher changes to a symmetric standard. Since the connection method is asymmetric, it guarantees a safe channel with authentication (which is the basic point of public-key to begin with). Once authenticated, it can switch safely to a symmetric method using a randomly-generated key between client and host. That goes quite a bit above and beyond the "field guide" approach of basics and applications, but I agree it's a valid amendment. My point in pointing out the public-key method is to show that there is indeed an authentication mechanism in place for SSH, something that can't be done with solely symmetrical means.
Don't worry about the discussion, that's what a forum is for. :) It's nice to know where I missed the boat on my explanations and to have some deeper insight provided by our readers. I appreciate the contribution!
anyways nice article I was always a little clueless to file encryption mainly as I never had a reason to encrypt anything, but it's was an interesting read
I am not sure how you would do that. All the tools I am aware of let you change the password or bruit force (or dictionary) crack them, but I have not seen anything that will tell you what the password is in a timely fashion unless the passwords are not very strong. It took me around 5 hours to crack my local passsword when I tried it. My more secure password hadn't been cracked after 2 days non stop.
Recently I have tried cracking into a couple of windows machines (a customer had locked them selves out) by replacing the password hash and it doesn't seem to work properly with XP SP2.
Now, one question. Let's say I'm paranoid (I am in fact paranoid, but let's pretend I'm actually not and we're just pretending I am :p). I've got my USB key which is completely secured using TrueCrypt, except for a small portion which carries DSL (leaving aside how that would work, for now). So I go to a random computer and use QEMU to boot up DSL and get my own secure environment. There's just one concern I have: I'm not sure how QEMU's emulation works, but could a keylogger running in the host operating system (presumably Windows) still log all my keystrokes even within QEMU?
But to be fair, Linux isn't more secure when one has physical acces to the system. If you boot into single user (or recovery) mode, you have all the rights you want. Remote access on the contrary is a fair bit more secure :)
As soon as you get physical access and BIOS control (boot sequence...) it gets a tad easier.
I've got a CD you can boot with and reset the windows passwords of any user accounts on WinXP or 2k.
the TOR browser could also be mentioned, as it anonymizes the user. (not very sure)
Personally I'd played around with Truecrypt once before. I considered using it for my entire RAID. I realised though that while running Truecrypt prevents other people from getting access to my data, if I screw up, it prevents me gaining access to my data. Weighing up the possibility of others getting my data against the possibility of me screwing up and losing my key or somehow messing up my access to a huge ammount of data, I chose not to. That said, I wasn't aware that you could use a file on a USB key as a password type thing, which does sound like it woud work extremely well.
Ok I just looked up both bkhive and samdump2 and they only seem to extract the password hashes. This means you still have to use a dictionary or brute force attack to crack the passwords. If you have week passwords then the dictionary crack will give you the password very quickly, but if you have a strong password it could still be quite some time before you get the password.
Truecrypt has a "traveler" mode that lets it run without installation (still requires you use and administrator account, though): http://www.truecrypt.org/docs/?s=traveller-mode.
Good article. As crypto-geek, I think it gives the reader a solid overview of crypto. :)
And this: http://www.petri.co.il/forgot_administrator_password.htm
In my early days of striving to become "1337" I lived off www.petri.co.il
Wish they hadn't added the "Digg" function. :(
H.B.