Topic: The biggest security hole -> Default values - page 3. (Read 4142 times)

no nobel price to me, already invented http://en.wikipedia.org/wiki/One-time_pad

by you saying that, can conclude that you have no knowledge at all on the subject. and therefor you are a troll.

You are engaging in "ignoratio elenchi".  

Obscurity in the sense you're using it is simply something that a few people know.  Here kokjo and myself are saying that what is being proposed only moderately increases the difficulty in finding the file with - no useful lower bound - by putting it in a location that is not expected.  This is not even obscurity in your sense since the application itself has to know where the file is.

If the application does not know where the file is then you have to specify it each time (kokjo makes a good point about replacing the app but I'm assuming that we are trying to deal with a very narrow class of attacks).

However the facility for finding it exists in the OS (and in RAM but again that's another class of attack) and any user program has unrestricted access to this facility.  Ergo this hurdle does not defeat a class of attacks and makes it marginally slower with no useful lower bound (I could scan your drive over the course of a day or two without putting very much load on your system).

Edit: Even if we go further and encrypt the file with a OTP that the user enters from memory (good luck!).  I can still make short work of finding the file by search for files with some meta-characteristic.  Like a small file with a write-lock.


Cryptography is subtle.  It is just as likely that your algorithm misses something because you have not shown it to nobody else.  History is replete with people cracking algorithms which were not known.  e.g. DVD's : 40 bit CSS had us ROTFL the day it was released.

Teams of people have poured over MD5, SHA1 and we still are finding collisions and shortcuts. Please formally justify (using actually math) how the probability has a lower bound of absolutely no less than 2x of a key being found through an obscured algorithm than an unobscured one.  Please show your work.


Which is done because we know the attack surface of these algorithms whereas your algorithm we do not.


...and here it looks like you are begging the question.

Wow! I'm impressed! 
Not even PGP or SSL can be considered "unbreakable" - rather really hard to break -, guess you would get a Nobel Prize out of that one.

im not confused, you are.

yes, im not talking about including 'my code' in the client, im talking about replacing it with a fake, by a trojan.


security!=obscurity , cryptography, ensures that by a certian chance that something is unbreakable.

we did not say that some security is not breakable.
i can make a 100% unbreakeable cipher, i can publish how it works, but you still can't break it, without my key.

Troll, no. Many folks failed to understand the purpose of encryption and confuse it by "security" when all it does it "hide things" - therefore: provides obscurity.

Everyone with coding skills can make a fake client... what's your point with that one?!
I'm talking about implement this in the open source one...

@jgraham

Obscurity is meant to be something just you know, or a specific recipient; cryptography is just one way to do it. But to very end, security is obscurity and the more obscurity you add to it the more security you get; may it be in method or final product.
The worse part in security is to believe it's unbreakable... but that's "a wrong assumption" no matter the methods you used.

Actually, going a bit side line here, security and cryptography works this way:

If you're a good cryptographer and can create your own algorithms you get twice of the protection: Your own algorithm nobody else's knows and the final product.
If you can't or don't want to create new algorithms you get standard protection: just the final product is protected, but the algorithm is widely known.
If you are a lousy crypto and still go for it, you get half or less of protection; your easy to break/figure out algorithm and poorly encrypted data.

You changed the verb.  Kokjo said "security through obscurity".   What he (and most IT professionals mean) that obscurity is your methodology not your end product.

LOL! troll!

i did not say it was a magical bullet.

R U MAD? i could make a fake client, in about an hour. (no i will not, but i can)

Wrong! Cryptography IS NOT security. Cryptography is a WAY to provide you OBSCURITY.
If you believe on security in open air, then just post your password. Better on, why use passwords? Just come, pick an username and wear it up.

A script kiddie normally go by AutoIt scripts and easy to implement code he can pick from the web; hooking into a running process isn't part of it.
This is also NOT the magical bullet that will kill all malicious software, is a way to make it harder to do so less people CAN do it, therefore less people DO IT.

Why make it easy to attack when all it takes is a file open dialog in the client or an argument passed to the bitcoind to make it way harder?

real security, cryptography is (for now) secure in the next few million years.

The value of BTC justifies for the user to search for it when he opens the client, so the wallet place isn't stored anywhere outside its owner brain. the client could well also allow hot-swap of wallets.


eazy pick by script kiddie:
1. replace client,
2. wait until user open teh wallet.dat
3. send wallet.dat to script kiddie.
4. PROFIT!!!

At least you probably wouldn't be able to write a done-in-10-seconds wallet stealer in AutoIt anymore.

Security IS obscurity. That dogma you stated makes no sense at all. Anything that's open isn't by nature secure; it's just open.

The value of BTC justifies for the user to search for it when he opens the client, so the wallet place isn't stored anywhere outside its owner brain. the client could well also allow hot-swap of wallets.


Yes, a trojan may scan your computer... making it dead slow and probably making you try to figure what's going on. But the current way the trojan have all the way open %APPDATA%\Bitcoin\wallet.dat; easy pick virus for any script kiddie.

You stole my thunder man.  I was leading up to that. 

Point is that even if you called the file a random name...the client needs to know what that is.   Which means you store it somewhere....

Only exception I see is if you are willing to select the file each time you start the client up.   In which case the file might have some distinguishing characteristics so you could just san the whole machine for it (or anything resembling it).   Which means you could encrypt it with a sufficiently padded OTP...which you store somewhere....

useless! trojans cloud scan the whole computer for the wallet.

this is just security through obscurity, and will NOT WORK.

Question...how does the client find the new wallet.dat (or whatever it gets called).

That's a brilliant idea - if this is implemented, much of the current Bitcoin malware will be obsolete for those who upgrade to the newest version (although new malware will adapt to any changes, I'm sure).  I assume you're suggesting that the user could specify a wallet name and location in the "Options" dialog box?  Perhaps you could go to the developers' IRC channel and inform them of this proposal, if they haven't heard about it yet...

EDIT:
Please don't misunderstand, I'm not saying that this will "fix" the client or "protect" against all malware (remember, security experts/black-hat hackers always find ways around security eventually).

Having default values set is the biggest security hole on most software, this behavior allows malicious software to know exactly what and where to find what it wants. Some examples are:

C:\Windows
%AppData%\Mozilla Firefox
%AppData%\Mozilla Thunderbird
%AppData%\Filezilla
%AppData%\Bitcoin

For some sort of data this ok, like the blockchain, for personal data ain't. Bitcoin client needs to be patched to allow the users to choose where to store wallet.dat and, more over, to choose what name to give to that file.
Think about it...