Hacking data

For discussions about security.
Message
Author
Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

Hacking data

#1 Post by Edwardo »

Today I encrypt my files. This is good. A good exercise. There's nothing to hide but then again it is impolite if others nosey around one's affairs. And maybe dangerous.

The question is when we enter the password into the box to do the file encryption and it happened that an intruder in the aether saw that data being entered by some means of intrusion, could such a thing happen? I have no idea.

Later when we need to use the password this takes place I believe at BIOS level so no body can observe it and this occurs before connecting to the world wide globus.

Encryption appears to be an action difficult to explain in terms that are easy to comprehend.

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#2 Post by Flash »

Well, an app running under the OS, whether Linux or Windows, is what encrypts the files, even if the files are to be stored in the "cloud." If a keystroke logger has somehow been installed in the OS, it could secretly record your password, along with every other key you hit, and perhaps transmit the whole mess to somewhere in the cloud, for who knows what reason.

Encryption is just another method of access control. A major problem with encryption is that the algorithms are too good. If you lose the password, you can forget about ever recovering the encrypted information. A more practical method of controlling access to archived information would be for instance to put it unencrypted on a DVD or in a flash drive, then put the DVD or flash drive in a place that is safe from prying eyes.

Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

#3 Post by Edwardo »

Normally I remove the memory stick from the computer for safety reasons but yesterday I neglected to do so for several hours while connected. At that point I removed the stick and powered off without saving (force dismount?)

Could files on the stick be changed in some way, adding files for example, by some hacker on my network even when I do not allow Puppy to do the final 'save' routine as it closes down, because the memory stick has been removed? Or do the changes occur only in RAM, or both RAM and the disk? (Later I'll post some explanations from Truecrypt for extra confusion)

Let's say the stick is attached for a few hours and periodically you see the Yellow Box saying it is saving, then you remove the stick and switch off the power, have any changes to the original files taken place on the memory disk?

http://www.truecrypt.org/docs/unencrypted-data-in-ram
http://www.truecrypt.org/docs/paging-file#Y797
Some interesting notes here. I'll go through them and see if we can make some sense out of all this. At this point there are a few unanswered questions in need of clarification.

User avatar
Barkin
Posts: 803
Joined: Fri 12 Aug 2011, 04:55

Re: Hacking data

#4 Post by Barkin »

Edwardo wrote:The question is when we enter the password into the box to do the file encryption and it happened that an intruder in the aether saw that data being entered by some means of intrusion, could such a thing happen? I have no idea.
Encryption with free software like Peazip and truecrypt permit a "keyfile" to be used with/instead-of a password, which will stymie someone relying on a keylogger.
Last edited by Barkin on Mon 08 Jul 2013, 23:46, edited 2 times in total.

Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

Re: Hacking data

#5 Post by Edwardo »

Barkin wrote:
Edwardo wrote:The question is when we enter the password into the box to do the file encryption and it happened that an intruder in the aether saw that data being entered by some means of intrusion, could such a thing happen? I have no idea.
Encryption with free software like Peazip and truecrypt permit a "keyfile" to be used with/instead-of a password, which will stymie someone relying on a keylogger.
Hi Barkin.

I came across this just now.
http://www.ivizsecurity.com/security-ad ... -0803.html via a Wilder's post.

TrueCrypt Security Model bypass exploiting wrong BIOS API usage
Synopsis
The password checking routine of TrueCrypt fails to sanitize the BIOS keyboard buffer before AND after reading passwords.
Affected Software
TrueCrypt 5.0 (possibly older versions also)
Technical Description
Truecrypt's pre-boot authentication routines use the BIOS API to read user input via the keyboard. The BIOS internally copies the keystrokes in a RAM structure called the BIOS Keyboard buffer inside the BIOS Data Area. This buffer is not flushed after use, resulting in potential plain text password leakage once the OS is fully booted, assuming the attacker can read the password at physical memory location 0x40:0x1e. It is also possible for a root user to reboot the computer by incrementing the BIOS keyboard buffer in spite of the full disk encryption.
Impact
1) Plain text password disclosure. Required privileges to perform this operation are OS dependant, from unprivileged users under Windows (any), to root under most Unix.

2) A privileged attacker able to write to the MBR and knowing the password (for instance thanks to 1), is able to reboot the computer in spite of the password prompted at boot time (and in spite of disk encryption) by initializing the BIOS keyboard buffer with the correct password (using an intermediary bootloader that will in turn run TrueCrypt).

This particular BIOS bug has been fixed by TC. I posted this because this is the first time I know about such things as "BIOS Keyboard buffer inside the BIOS Data Area". All very curious. Mysteries within mysteries. Quite fascinating.
I think if I were a bug this is a place I might like to be hiding.

User avatar
Barkin
Posts: 803
Joined: Fri 12 Aug 2011, 04:55

Re: Hacking data

#6 Post by Barkin »

Edwardo wrote:Hi Barkin.

I came across this just now.
http://www.ivizsecurity.com/security-ad ... -0803.html
If you used a keyfile with a password this vulnerability would be avoided : BIOS does not "know" about a keyfile.

BTW "A privileged attacker" usually means someone who can lay their hands on your computer.
Last edited by Barkin on Tue 09 Jul 2013, 00:30, edited 1 time in total.

Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

Re: Hacking data

#7 Post by Edwardo »

Barkin wrote:If you used a keyfile with a password this vulnerability would be avoided : BIOS does not "know" about a keyfile.
Is this the method Bcrypt uses?

User avatar
Barkin
Posts: 803
Joined: Fri 12 Aug 2011, 04:55

Re: Hacking data

#8 Post by Barkin »

Edwardo wrote:
Barkin wrote:If you used a keyfile with a password this vulnerability would be avoided : BIOS does not "know" about a keyfile.
Is this the method Bcrypt uses?
IIRC some implementations of Bcrypt permit a keyfile , [ the no-frills version of Bcrypt I have on Windows doesn't ].

Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

Re: Hacking data

#9 Post by Edwardo »

Barkin wrote:
Edwardo wrote:
Barkin wrote:If you used a keyfile with a password this vulnerability would be avoided : BIOS does not "know" about a keyfile.
Is this the method Bcrypt uses?
IIRC some implementations of Bcrypt permit a keyfile , [ the no-frills version of Bcrypt I have on Windows doesn't ].
OK. What about Bcrypt on Puppy 5.5, Does it use a keyfile?

User avatar
Barkin
Posts: 803
Joined: Fri 12 Aug 2011, 04:55

Re: Hacking data

#10 Post by Barkin »

Edwardo wrote:OK. What about Bcrypt on Puppy 5.5, Does it use a keyfile?
The Implementation of Bcrypt which comes with Puppy 525 does not use keyfiles.

I use PeaZip and select 7z format , which does permit the use of keyfiles . NB: If you loose (or modify) the keyfile you are locked-out. Any file can be used as a keyfile : a document, an image, an audio-file, or specifically made keyfile filled with random stuff, (see below).
Attachments
Bcrypt on lupu-525 , no keyfile, only password.gif
(13.87 KiB) Downloaded 466 times
The contents of a KeyFile generated by PeaZip shown in a Hex editior.png
A KeyFile made by PeaZip
(16.2 KiB) Downloaded 368 times

Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

#11 Post by Edwardo »

Flash wrote:Well, an app running under the OS, whether Linux or Windows, is what encrypts the files, even if the files are to be stored in the "cloud." If a keystroke logger has somehow been installed in the OS, it could secretly record your password, along with every other key you hit, and perhaps transmit the whole mess to somewhere in the cloud, for who knows what reason.

Encryption is just another method of access control. A major problem with encryption is that the algorithms are too good. If you lose the password, you can forget about ever recovering the encrypted information. A more practical method of controlling access to archived information would be for instance to put it unencrypted on a DVD or in a flash drive, then put the DVD or flash drive in a place that is safe from prying eyes.
You might for example use the serial number for a part on the boiler, something permanently installed in the house. Or the chassis number of your auto, with a salt, or a book's ISBN number. On the bottom of my desklamp the number 1812IPO27-G is stamped. I find I can train myself to memorize 15 digits just as an exercise with repetitive use. I just ordered a few wrist-band USBs. All of this is overkill of course but a recent disaster has made me think more carefully about these kind of things. Why not. Making strong security an embedded way of life without it being too onerous.

What about Chinese and Japanese symbols?

User avatar
Barkin
Posts: 803
Joined: Fri 12 Aug 2011, 04:55

#12 Post by Barkin »

Edwardo wrote:... with a salt
see ... http://www.murga-linux.com/puppy/viewtopic.php?p=623478#623478
Edwardo wrote:... a book's ISBN number
If your house catches fire that won't be much use to access your encrypted data in the "cloud".

When it comes to passwords, size matters ... https://www.grc.com/haystack.htm

MD5sum calculators always generate a 32 character hexadecimal number whatever file or text you put into them. A 32 character hexadecimal number allows about 10^39 permutations , which would take trillions of years to crack by brute force.

Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

#13 Post by Edwardo »

Thank you for the link to Steve Gibson, Barkin, this is excellent information. Again, fascinating.

If I may I would like to put a series of simple questions to the forum re general security matters such as wifi, passwords, intrusion detection, intrusion prevention and so on, one by one so things don't get mixed up. Please forgive if we go over topics already discussed, if so a forum link would suffice.

The first is this. My house wifi antenna connected to my home router box is several kilometers distant from the AP. Should I assume my wifi signals can be intercepted by attackers at all points along this route from the house to the AP, or can they be intercepted only when the attacker is in close proximity to my home antenna/router?

User avatar
Barkin
Posts: 803
Joined: Fri 12 Aug 2011, 04:55

#14 Post by Barkin »

Edwardo wrote: My house wifi antenna connected to my home router box is several kilometers distant from the AP. Should I assume my wifi signals can be intercepted by attackers at all points along this route from the house to the AP, or can they be intercepted only when the attacker is in close proximity to my home antenna/router?
You should select the most recent method to encrypt your wi-fi link to prevent neighbours (within WiFi range ~100meters) from eavesdropping, which is WPA2, (not WEP). If you choose a random key (password) of 16 characters , your wi-fi is secure, (use upper and lower case letters).

https://www.google.com/search?q=router+wpa2+encryption+setup+how

If you view a website use https if available rather than http, again to prevent eavesdropping by anyone anywhere en-route , you can get a browser plugin for that ... https://www.eff.org/https-everywhere

Financial transactions are always via https links.

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#15 Post by Flash »

Actually if you're really paranoid it isn't a bad idea to use a book's ISBN number for an encryption key. If the book is lost or stolen, you can find the exact same book and it will have the same ISBN number. It's easier to remember the title of a book than its ISBN number. Just be sure to choose a book that was popular, so there will be a lot of them in used book stores, but not too popular. Don't use a bible for instance, that would be too easy to guess.

User avatar
Barkin
Posts: 803
Joined: Fri 12 Aug 2011, 04:55

#16 Post by Barkin »

ISBN's are different for each edition of a book, (and different in different countries). So if you're going to use one as part of an encryption-key that make sure there are several sources where you can access that ISBN.

If the book is lost you would need Internet access, (or another copy of the same edition of the book), to obtain that number, so if you are working off-line, without internet access, on encrypted data you'd be stuck.

Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

#17 Post by Edwardo »

Flash wrote:Actually if you're really paranoid it isn't a bad idea to use a book's ISBN number for an encryption key. If the book is lost or stolen, you can find the exact same book and it will have the same ISBN number. It's easier to remember the title of a book than its ISBN number. Just be sure to choose a book that was popular, so there will be a lot of them in used book stores, but not too popular. Don't use a bible for instance, that would be too easy to guess.
Can we say 'caution' or 'common sense' in preference to paranoia. In the house in which I grew up the telephone for example was stationed in the hall, some distance from people in rooms whose doors were usually closed despite the fact the technology of the day did not permit the telephone to listen to conversations in its vicinity with its receiver in its cradle.

Recently I gave my smartphone away as I came to realize it was not the innocent toy it seemed to be. Then I ask my lady friend if she would much mind keeping her telephone in another part of the house when not in use. At first she was horrified, almost rebellious. It took a little time explaining things and now she has an excellent grasp of concepts like 'network', 'public telephone system', 'privacy', 'eavesdropping' etc. I could continue but I think there is little need for for it when addressing this sophisticated audience.
Last edited by Edwardo on Wed 10 Jul 2013, 15:11, edited 1 time in total.

Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

#18 Post by Edwardo »

Barkin wrote:ISBN's are different for each edition of a book, (and different in different countries). So if you're going to use one as part of an encryption-key that make sure there are several sources where you can access that ISBN.

If the book is lost you would need Internet access, (or another copy of the same edition of the book), to obtain that number, so if you are working off-line, without internet access, on encrypted data you'd be stuck.
Yes, indeed. The ISBN idea was an idle thought. But I do believe the best place for the password to be kept is in one's head. Of course if someone knew it was in my head and he wanted it very badly, I would hand it to him as a gift. He would then have a most interesting reading list which hopefully would improve his mind :lol:

Edwardo
Posts: 42
Joined: Wed 26 Jun 2013, 07:17

#19 Post by Edwardo »

Re passwords, the OTP token method, one time password, gives one a deeper sense of security so long as one has faith in its manufacturer. This I have used for financial transactions with success so far. RSA is one such provider to financial institutions of these tokens whose 6 digit number changes every 60 seconds, and I believe they were hacked a couple of years ago. Probably now their security measures regarding security token internals have improved. Hopefully. On the other hand one is placing a lot of trust in a 'cloud', an indeterminate thing, in an indeterminate place, operated by unknown people.

Getting back to a Linux BIOS level password entry, can we use a dedicated USB to store and enter something really absurd, like this

nKlN2.Sl^mD={PxYBax,gxSWS$zYQeCO20/ik%23",aZa09fDUFW?w=TZubLe=lGQJ61#p@8Y*!W(O'uXjAt!lh'SxCgc*Cj')(%F^hr0B9oE}s36'x&t&41?JQP+MXsXmJ2E,nV[yLf{6fGZ}BZM1#w:U$UqeJK5J:gsWR*:^WMc2Dg:n"D6|f-/oX'tH![)L.wrrEDt86DNef&Mj[h(/MN1me17@YT=CVan)ML:tCZj|iy{W(TE9#Dvj)0S.Akniw(>GhviZq1~5tI6nU?o3*/TNmXtr/PI!BC)c=Uh2n\ER^hBT-;mG|va'LwCB4@7XAjse19VA%nVv2YuV~lfI<%}[SUL|yR)8+Eb1%kisBuQl3%CLNv|@%bAE(p8QH2fRCorGH/=#''FRR?k"s?kN=Z{!<!Q-.b&RYM$Ra@;"Q/9#BOp,j3'u!0Uo^%'sJR&6{b|nqY2oI'wV/.YgfP8rj3LmM7|PV@M3#{m1TwB^ZVE\Vcf#9m%WX#9S7u7J.jXGKs2T7k@N?@,RlCJ{lO+"Nsq9.y{5=%|5MffQedYLt;[lC~RmAgrj.@)cDE8E#&&yEd2>6HmM0FSE=dl#f/LD2{"|P;(<Yt^Mz9obF(kn@KA'#?"("|h''1()9=jeYl"D>a&f|lJ<JtJ-tI6Z~Qro=sF$~Rze3PXzr)BxMzM.mqT@T|LQiz-r7|r@2BkQh^)oD6zjS|<|CO5)"C>8(<I<U6\(|KKbu+QbVvv,/B-%{sbVOt\zjp9$-(&$d9A7!kJ|cKiR-luQ(e//"!U4hqP9s8t"f|^Y7r-

I guess for this one we'd see you in the next universe.

User avatar
Barkin
Posts: 803
Joined: Fri 12 Aug 2011, 04:55

#20 Post by Barkin »

Edwardo wrote: ... Getting back to a Linux BIOS level password entry, can we use a dedicated USB to store and enter something really absurd, like this

nKlN2.Sl^mD={PxYBax,gxSWS$zYQeCO20/ik%23",aZa09fDUFW?w=TZubLe=lGQJ61#p@8Y*!W(O'uXjAt!lh'SxCgc*Cj')(%F^hr0B9oE}s36'x&t&41?JQP+MXsXmJ2E,nV[yLf{6fGZ}BZM1#w:U$UqeJK5J:gsWR*:^WMc2Dg:n"D6|f-/oX'tH![)L.wrrEDt86DNef&Mj[h(/MN1me17@YT=CVan)ML:tCZj|iy{W(TE9#Dvj)0S.Akniw(>GhviZq1~5tI6nU?o3*/TNmXtr/PI!BC)c=Uh2n\ER^hBT-;mG|va'LwCB4@7XAjse19VA%nVv2YuV~lfI<%}[SUL|yR)8+Eb1%kisBuQl3%CLNv|@%bAE(p8QH2fRCorGH/=#''FRR?k"s?kN=Z{!<!Q-.b&RYM$Ra@;"Q/9#BOp,j3'u!0Uo^%'sJR&6{b|nqY2oI'wV/.YgfP8rj3LmM7|PV@M3#{m1TwB^ZVE\Vcf#9m%WX#9S7u7J.jXGKs2T7k@N?@,RlCJ{lO+"Nsq9.y{5=%|5MffQedYLt;[lC~RmAgrj.@)cDE8E#&&yEd2>6HmM0FSE=dl#f/LD2{"|P;(<Yt^Mz9obF(kn@KA'#?"("|h''1()9=jeYl"D>a&f|lJ<JtJ-tI6Z~Qro=sF$~Rze3PXzr)BxMzM.mqT@T|LQiz-r7|r@2BkQh^)oD6zjS|<|CO5)"C>8(<I<U6\(|KKbu+QbVvv,/B-%{sbVOt\zjp9$-(&$d9A7!kJ|cKiR-luQ(e//"!U4hqP9s8t"f|^Y7r-

I guess for this one we'd see you in the next universe.
The maximum length of the encryption key determines the maximum length of password ...

http://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_measure_of_password_strength

Creating a password longer than that does not increase security : a brute-force-crack will have to cover the entire search-space possible, e.g. in 256-bit encryption, in binary from

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

to

1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

Making the password longer than the key length permits just causes the mileometer to go around the clock, so to speak : all permutations will have been covered and the password already cracked.

https://www.grc.com/passwords.htm

Post Reply