Bitcoin Forum

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...

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).

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

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

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

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....

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.

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

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!!!

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?

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)

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.

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.

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.

Wow! I'm impressed!  ;D
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.

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.

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. :D

That's an improvement of
http://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher

The indecipherable cipher suffers from patterns, the pathetic attempt done by Gilbert was to create an algorithm where the key matches in size the crypt text. Resulting in a stupidity, as if you can send such key securely, you rather send the plain text the same way and spare you from some worthless work.

Given a long enough key and a short enough text to Vernam's method and you would get that effect already.

PS - This topic isn't about cryptography anyway... my idea just provides a "hiding the wallet" not "encrypt it". -> This means that currently is like if everybody was using their wallets in the back pocket, making life easier to pickpockets. My method would simply make anyone put the wallet wherever he wishes... making pickpockets to have to look for it - still doesn't mean you get rid of pickpockets, just their job gets harder.
 ::)

if the pickpocketsers already has locked your in a prison, and searched you, you are doomed.
by hiding your wallet you gain nothing, if you gets a trojan, you are doomed.

im comparing a trojan with a prison. you are comparing a trojan with a pickpocketser, a trojan haves more control on your computer, then a pickpocketer haves on you, and it is therefor stupid to compare them.

about the cryptography, it is not stupid it is usable:
give 1mb key to a submarine, when they are at port, and keep the key yourself. you can now communicate 1mb of data between the submarine, when its 10000 miles away, 100% securely. not near 100%, but exactly 100%.

Depends on what the trojan does.

Still, you believe it doesn't worth 2 lines of code because some other attacks will get through? Then we rather let go computer security all at once, as eventually some kind of attacks will pass... so what's the use?

You give 1MB key for OTP comm with a sub, and rather you not send them any block longer than 1MB, send him War and Peace and you start to get a pattern.

no, trojans often install backdoors, an attaker can/will return.

100LOC in the client, and 5LOC in a trojan.

sending him the pattern "War and Peace" in 1MB, does not create a pattern, in the encrypted data.
giving him a 10^100 byte key, and sending him 10^100 bytes "War and Peace", also does not.

it seems you simply dont understand it.

Are you talking about OTP's here?  These days getting a good source of entropy is relatively easy.

Uh...no

Key distribution is a different problem from encryption for a very good reason.   You can choose the time for key distribution and make it secure.  This allows for a secure OTP transmission at any time forward.  You don't have to think very hard to come up with an example such as....wartime.


Shakes head...you actually have too much noise and not enough signal there.


Good because you don't appear to understand what you are talking about...


Only if that place isn't stored anywhere and the user is prompted each time the application is run.  Even then it's not very much harder.  A machine that can scan tens of thousands of files per-second would let me narrow down the search tree easily.

So as said before this isn't significantly more secure than the original system.

No, the "Indecipherable cypher" is the "father" of OTP:

Caesar's cypher -> Indecipherable cypher -> OTP

Differences:

Caesar's Key: B
Text: APPLE
Result: BQQMF
(this was used by the Romans, strong enough for what they were facing)

"Indecipherable Cypher" Key: BEAN
Text: APPLE
Result: BTPZF

Early OTP Key -> has to match the size of the text to chyper, so BEANS
Text: APPLE
Result: BTPZX

Yes, but if the key gets compromised - and you didn't figured it out - then you'll be giving away info.
But that's for another field, a field for which encryption is a tool -> information.
Information is also valid in a time frame, imagine a German message intercepted in 1939 that just now got decrypted, it says «Tomorrow we will invade Poland»; what's the use to know it now?!

There's a significant increase in security by moving the file, despite if "some software can scan your computer", as that very same software probably can do whatever it takes no matter what security you imply.
I don't know if you were looking at the code or can reverse engineer software of the latest virus for Bitcoin, this method alone would put them all out of commission... yes in the future a better skilled coder(...); but also in the future machines calculating Petahashes per second(...).

BTW, back in the days while in the army I designed an OTP based chat system, you need a floppy key (no USB at such time) which have files like 1.key, 2.key(...). Each of those files have a very long passphrase inside and uses sync encrypt/decrypt, at random intervals the part which started the chat send a signal to switch the key to another <number>.key... pretty much simple, but effective... unless someone used diskcopy that is...

Phash/s will not do it! still takes longer time then the age of the universe to crack.
a major breakthough in math, will do it. but then we will have other things to worry about(nuclear missiles flying around).

if i was a script kiddie i would code a 5 line trojan, that could scan your computer, for 1btc, and gain 500btc.

Damn! You're a cute troll  ;D ;D ;D
5 line trojan (with 20 Mb batch of attached DLL's?)  ;D

Thread got off-track a bit, but it could have usefulness outside security... at the moment people who have more than one wallet have to rename them to wallet.dat in order to load them.

wallet.dat -> rename to wallet_temp.dat
wallet2.dat -> rename to wallet.dat

I'd love to be able to call it something else, and in addition being able to specify the location of the wallet separately from the block chain would be handy for placing the wallet on tiny places where you don't want write 300+ mb of data. (like a flash drive). It'd be cool to have the bulky block chain on the hard drive, but wallet on a flash drive.

ummm... returning to the thread topic (i.e., Default Vaues), i don't understand something.

we can already control where the client looks for its configuration file (-conf=<file>), and where it looks for its data (-datadir=<dir>).

why can't we have an option like -wallet=<file> ?

it's hardly perfect, or even particularly elegant:  but it seems to me that the ability to run a wallet.dat file that was called foo.bar would eliminate about 90% of the scriptkiddie issues.

no?

heh.  great minds run...

LOL! Missed this post!  ;D ;D ;D
"Send him War and Peace" doesn't mean send him "pattern War and Peace", but broadcast War and Peace, Leo Tolstoy book:

http://en.wikipedia.org/wiki/War_and_Peace

 ;D ;D Sending patterns.. I'm still laughing!!!  ;D ;D

just found my wallet:
it could be easily be automated in a shell script, but i did not have time for now

of course you suggested client, would not have it open all the time, and it would not be a *.dat. but its really not that hard, see?

why the hell would someone send a public available book, over a highly secure communication line?

but anyway sending something with a pattern with a OTP, will not make the pattern known.

The class of attacks you are seemingly trying to thwart is an external application which steals the wallet.dat file off disk.  As opposed to something that compromises the bitcoin client itself which would likely be immune to these attempts.  Time is a factor in defense so if I can steal your wallet in a few hours rather than a few seconds that is not a significant increase in security.  Compared with encrypting the file with OpenSSL and a passphrase the "file stealing attack" no longer works.

So considering the class of attack and considering the countermeasure it doesn't add much.  Think of it as installing a door lock that can withstand three attempts to kick the door in instead of two.  True this makes the attack "harder" but not in a significant way.

Shell scripting... OMG!!!! LOL! Well, we were talking about script kiddies weren't we? That might a bit weird trojan for distribution btw, you would need to put something like: do a chmod a+x mytrojan then ./mytrojan to run it.  ;D
Despite all the virus for Bitcoin I came across lately were for Windows... probably your should think about a trojan.bat  ;D

The "War and Peace" means "Send a damn long text out"... that's what War and Peace is; a damn big book.

Weaknesses of Encryption - Lesson 1 - PATTERNS

In the 3 named encryption methods, patterns will occur when the key is too small for the content given. Should occur on OTP for a simple reason, to encrypt War and Peace you need a key of the size of... War and Peace.  ;D
Let's say the key is APPLE for the "undecipherable cypher", if the text is bigger than 5 letters the key turns to be:
APPLEAPPLEAPPLEAPPLE...
A decrypter would start to look at spaces patterns, then the most used letters on your language to start to get a pattern and get they key out.

Also another rather important reminder.

If there were to be a browser vulnerability that facilitated the stealing of a file (without relying on something like Java), what would be an incredibly easy target? Exactly, a Bitcoin wallet in a default location.

The chance of a browser exploit that allows scanning the disk for a certain file is infinitely smaller than the chance of a browser exploit that allows stealing a file in a predefined location.

Default locations are bad policies, is like a sitting duck vs a moving target (period).
And if you add an extra layer, like store the wallets in a pen you just connect when you need them, good luck for those guys with "file scanners" for look for something that isn't even in the computer.

I'm giving up on you 2... useless! You speak out like wannabes! Yes, encrypt your wallet for safety and storage... but the bitcoin client will need to access it unencrypted. Unless, instead of all that nonconstructive trolling you would say something like: "Add an encryption layer in the bitcoin wallet to request a password to open the file." - still a weak password and say goodbye to it, but it would be another good security measure to take to account.
Now trolling about locks is just ridiculous!

likewise a file I can use the OS search facility to find.


But when you've got something capable of tracking the target and shooting a thousand rounds per second.  You're probably not better off. (period).  ::)

This is closer to a sane thought but all my scanner has to do is to either detect DBT_DEVICEARRIVAL or poll for new drives and scan them.   I'm willing to bet I can scan your drive faster than you can insert it and run bitcoin.

You insist to talk (troll) about hypothetical attacks whereas this measure prevents existing and ongoing attacks.
Yes... and if your scan can read it telepathically can get the wallet even if you store in the brain...   ::)

BTW, in an average used system the OS built-in "find" takes ages to actually "find" something...

Hey is this maud_dib again?  You are the poser here.  Just like maubby you can almost trace your knowledge of cryptography through your googling of each issue as it's mentioned.


We are talking about modifying the client.  You might as well criticize your own idea by saying: "Move the wallet? but the bitcoin client will need to access it in the standard location."



Which requires a different attack.  You are essentially saying that I'm right here.


It's an analogy just like the dozens you've been making.

No. I'm just saying that it would be trivial to modify an existing app to make your modification worthless.  If you don't understand the value in that, then you don't really understand security.  Easy enough to demonstrate though.   Make your change to the app, hand me the code for an existing filestealing exploit and your new source tree.  See if we can make it find your file.


Strawman fallacy.  I'm talking about something that anyone who develops software can see is trivial to implement...unlike telepathy.

time find / -name wallet.dat
real    0m8.198s

QED

Not for very long - for example under unix I could just query the process table and find out the command line arguments.  You could change the binary itself...

diff -Naur bitcoin/src/init.cpp bitcoin2/src/init.cpp
--- bitcoin/src/init.cpp        2011-07-06 16:26:16.920000001 -0400
+++ bitcoin2/src/init.cpp       2011-07-06 16:28:27.890000001 -0400
@@ -386,7 +386,7 @@
     printf("Loading wallet...\n");
     nStart = GetTimeMillis();
     bool fFirstRun;
-    pwalletMain = new CWallet("wallet.dat");
+    pwalletMain = new CWallet("boogie.dat");
     if (!pwalletMain->LoadWallet(fFirstRun))
         strErrors += _("Error loading wallet.dat      \n");
     printf(" wallet      %15"PRI64d"ms\n", GetTimeMillis() - nStart);

but then you can look at the files the app is using (kokjo did) or scan the binary...blah blah...

yes.

but how many of the scriptkiddies have your level of knowledge?  the heavies run darkcomet by rote...

a -wallet=<file> command line option isn't a panacea - but there's very little that is in the realm of security.  we chip away at attack vectors like the attackers chip away at us.

eh.  i wouldn't mind having the option to run wallet off a thumbdrive, without the rest of the data directory on it.

You seem to have conveniently left out the second part of my post.

DELETE THAT S*** ASAP

From where I stand, despite you look a good coder, you're RETARDED!
You just posted MASM32 code for a virus, do you at least have a clue on what you're doing?! Or trolling is more important to you?!

So what? It's already out there, anybody who wants to can find it easily. It's not like your browser's going to execute it or something.  :D

I hope nobody's listening to you for security obscurity advice.

Uh...You look a good agitated?

So it would be bad if something on the internet was posted some where else on the internet?

Anyway don't get your panties in a bunch there grandma.

This isn't a virus.   Just the payload.  This is, essentially no different than the script that was posted kokjo yesterday.

Or didn't your l33t security sk1lz tell you that.

Yeah... I already come across 5 variants (normally just with user/pass replaced) of that ftp stealer. Why not make it easier and publish it everywhere?
Coders normally wage enough to not need to steal, script kiddies however doesn't and will thank you a lot for your effort.

This isn't even about "security through obscurity or clarity" this is just making their life easier.

I see most of those to pretend to be security experts to be nothing but dumb brats; security isn't about making an attack impossible, because that's also impossible to achieve. Security is about make the attackers' life as hard as we can and keep vigilante.

In other words I *thought* you wrote this yourself but now that I googled it I see you didn't...and I forgot to admit that it isn't a Virus.


Ok, in case you haven't heard of it I'd like you to introduce to you Google.   It's this idea that the Internet should have some relatively centralized way of finding things.  Essentially it means that if it's in one place...it's everywhere.


Yes, I have now enabled those hackers who have access to the Bitcoin forum but not access to Google.   Do you really see that as a large group?


Not sure to whom you are referring but I've actually explicitly stated that I'm not an expert.  I'm a professional.   IT Security is simply part of my job.


Equivocation.   "an attack" is not the same as "any attack".   Obviously it is possible to remove some attack vectors.

I didn't run your code or even googled it, just read the claims and it seams you were improving it to scan the hard-drive for any position where the wallet may be. Sorry if you didn't, anyway there's always a good reason to not re-publish it.

Removing attack vectors == make the attacker's life harder.

Moving the wallet already removes one attack vector; its sitting duck place.

Encrypt it, as you suggest earlier, removes another; be able to easily open it.

You clearly did not read the post very well and do not understand the attack posted and did not understand what I said about modifying it and apparently how it's almost irrelevant if something is published once on the internet or a hundred times.   Ever hear the adage: "You don't know enough to know what you don't know?"


You are using the term in an obscure way.   Clearly you can remove a vector  that is not a threat.

So rather than deal with your oddness I'll talk about my approach to security:

It is rare to know the probability of specific exploit being employed because it is rare to know enough about the environment to determine the probability of attack.  If it is rare to know the probability of an attack you are unlikely to know the utility of a defense.   i.e. how likely it was worth the cost of deployment.  So rather than talk about fixing potential attacks I tend to talk about reducing the attack surface.   That is removing or increasing the difficulty by a useful median case of a group of methods situated around obtaining an asset.
 
The wallet.dat file contains an asset you want to protect.   Moving it does not alter the attack surface.  It may have utility but as established....you can't know that!
However encrypting the wallet.dat file can reduce the attack surface.  It can remove the potential for an attacker to obtain the asset by a useful median case.

You miss some utility on my proposal, the improved security of make you have to scan the computer to find it is just a surplus of the overall functionality.

And scan the computer gives out an alert to the user, by over usage of hd access and slowness of the system - this alone already worth it; more important than prevent an attack is to know when you're attacked so you can try to do something about, actually your idea of encrypt it voids mostly by refusing my idea, if the wallet is still a sitting duck under ~/.bitcoin/wallet.dat or %APPDATA%\Bitcoin\wallet.dat a trojan targeting it can get it without ringing any bells, leaving the robber time enough to try to break the user's password while the user is still using that wallet totally unaware of any danger. This means sooner or later the attacker manages to break the key and the user is pretty much done and caught by surprise.

My idea could be improved by hot-swap, allowing you to load another wallet without need to restart the client. It can be good to split wallets, allowing yet another security layer; by having his wallets spawned for 3 or 4 thumbdrives or SD cards will allow that even if one is attacked he doesn't go back to 0 coins. - Damage control.

Therefore, encrypt the wallet can be seen as complementary to this idea. If you think your idea alone is the panacea of everything and will reduce any attack surface then you're wrong and are selling false sense of security.

No, no I don't.

Not significantly as evidenced by actual tests.  Kokjo demonstrated using the /proc pseudo-filesystem to find the file without any exhaustive scanning. 


To the idea of the on system relocating or renaming of the file.  Encryption reduces the attack surface moving does not.  I have explained this already.


Again either you simply don't read, don't understand or don't want to.  It's all up there.  Moving a wallet off-system is fine it's better than just relocating the file on your hard drive but the scanning technique doesn't need to be changed very much to compensate.  The value is in how frequently you keep your wallet offline.  The difference between encrypting and moving is that the reduction in attack surface is predictable in the case of encryption and is not in the case of moving.   So the value of encrypting is known, the value of moving is not.

IMHO: You should not be giving security advice.

This is just valid for LINUX, there's no such "/proc" vfs under Windows. For Linux his shell script was actually a goof attempt of show something, not only there're no known virus targeting bitcoin under Linux at the moment, as the script itself would need to be chmoded to get the executable bit.

The value of encrypt without move is zero. Either you use a password you can remember and potentially weak as so, or you use a great password you need to store in your computer. If that "ultimate stealer" can find the renamed and moved wallet.dat, can also get that other file where you stored the password to the wallet.

If you've nothing else to do than troll, then just leave. IMO you're just trolling.

So it's valid.  Good. 


Process explorer finds files opened by processes just fine...and you missed the part about me scanning my system in 8 seconds.


You really don't get how these things work do you.  Nobody claimed that the script was a completely functional trojan.

So you have to use a password cracker not a file stealer.   You have just admitted that the attack surface has been reduced.  Congratulations, on your enlightenment.

False dichotomy.  Some of us, every day use passwords that would take a hundred years to crack.  That doesn't even take into consideration things like passphrases or sequential memory-hard algorithms.  As stated before using encryption creates a known median case.  How much time moving buys you is an unknown.  So it's value is unknown.

QED.

Enough with your fallacies! Either do something productive or zip it!

Your stating resumes to:

You're doing a life vest and the attackers will come with a canon... so for your "solution" I can say you are creating an armor that to stand a canon attack and they will come with a nuke.

And you miss the central point:
In nowhere I stated my "solution" was the panacea of all wallet.dat issues It's an interesting and easy to implement feature, not the "ultimate anti-hack bullshit" as you're trying to sell out yours.

And yeah, some might use AReallyF*#@ngLongPassw00rdWhichTakesAgesToCrack, whereas others don't like to be bothered and will simply input 123...

I fully confess to having no idea how to parse that sentence.

Strawman.  I never said you did.  I just said it has no quantifiable value.  However you did say: "Having default values set is the biggest security hole on most software".  So if moving solves this issue then simple substitution reveals that you believe that moving default files "Solves the biggest security hole on most software".  While that isn't saying that it makes security perfect it does say a heck of a lot more than: "an interesting and easy to implement feature".

Strawman again.  I just said that encryption has a quantifiable value.

Which is irrelevant to the discussion.  In one case the attack surface is reduced in the other it is not.

I'm glad we had this talk.

http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

Since you think passwords are so easy to break, here is a SINGLE-ROUND md5 hash of a password I use daily. It even has dictionary based words in it so that it's easier to remember. Let me know when you've cracked it: 3dcd7dd499205f7f36544e71d3e8ed49

Here's another single-round md5 which would be considered very weak by most security professionals: 827a9861340aa529ad351cd80fcd1283
Let me know when you've cracked that one, too!