Topic: A public service announcement (Read 3813 times)

Let me quote something for you:


It is your job to provide valid logical arguments since you started this stupid discussion. You have failed to do so.


Actually, i personally think about incorporating bcrypt() into my algo for greater performance, but i will be continuing this discussion just to prove how stupid, impudent and manipulative you are.

Scrypt looks good, and if I were a bit less conservative with these issues, I would use it. The only thing is that it hasn't been around for as long, so maybe not quite as much peer review and bcrypt. I'm not sure if I trust the implementations out there yet. The CYA types love PBKDF2 because it meets all "industry standards," and that is ok, I suppose. After all, everything out of RSA® (The Security Division of EMC Corp.) has been bulletproof, right? 

It's not my job to hand-feed you. I provided some initial references, and now it is up to you to explain why your method is superior. You have not.

The reasons why eksblowfish is several orders of magnitude harder to bruteforce that other algos (like SHA, or N interations of hash-x) have little to do with iterations. It is because hashes were never designed to encrypt passwords, despite what theymos may think. They are, in part, designed to be fast. This is the opposite of what you want when protecting from password cracking (slow).

from http://www.skein-hash.info/about :

The references explain why eksblowfish is so good at being slow. But go ahead... keep "daring" me to explain (the references that I posted in this thread do an ample job, for those who are interested). I will admit that your taunts amuse me, however.

The post of yours that I linked is salient because it demonstrates your level of understanding of security issues. You seem to think that just by nesting questionable mechanisms N times, that you have achieved some sort of a secure cascade effect. This is demonstrably untrue in your "methods," as FalconFour described. It may help others decide wether or not to trust your scheme if they know what other schemes you have proposed on these very fora.

Also, the burden of proof rests on the person who presents new methods. You.

Bcrypt is the best tool to protect password databases against offline attacks.

The "strength" of the hashing is irrelevant (even an 80-bit hash function - used properly - cannot be bruteforced by the current bitcoin network in any reasonable time). The only thing that matters is how long it takes to try one key for an attacker. bcrypt and whatever iterated hashing you're using achieve this in a very different way, and it is hard to compare.

It is true by the way that iterated hashing increases the chances for collisions, but only slightly. As explained in an earlier linked post, NIST recommends PBKDF2 for storing passwords, which is in fact based on salted iterated hashing.

So please stop throwing insults to eachother. Yes, bcrypt() is a very good way for storing passwords, but so it a (well implemented) iterated hashing scheme. Iterated hashing schemes are better researched and used, but bcrypt() is somewhat slower to implement in hardware. If you really want maximal resistance to hardware-assisted attacks, scrypt() may be an even better choice, yet even more recent.

This has nothing to do with the current topic.

I am not listening to you, until you explain what is the difference between bcrypt() and my func. Because i keep stating you have no fuckin idea what you are talking about. You are deliberately making offtopic to mask your total lack of knowledge, but this trick does not work with me.

I dare you. Explain that to me. Still waiting.

Also, about earlier post:

This is just one bad idea, **which I admitted is not the best sollution** in the same topic. But still gives you higher level of security than no virtual machine at all (the attacker has to crack all the layers, which will take time. Also, he has to figure out that there is VM within VM, which he may accidentally not do).

But what is important, this has completely nothing to do with the current discussion.

I've been watching http://en.wikipedia.org/wiki/NIST_hash_function_competition and particularly Skein. Seems interesting.

Oh god, I seriously wanted to reply a big fat "WTF?!" to that post. Biggest crock of bullshit I'd ever read. Why the fuck install an entire virtualized operating system inside a multi-encrypted disk image... that shit doesn't even make any sense; just use the same outer encryption library to create another disk image inside the first layer, which itself is, despite the encryption layer residing on the outside, still encrypting data within a subsequent layer in the same way. Shit just makes me cringe thinking the guy wanted to install multiple OS copies inside multiple layers to produce an illusion of security... it's still protected by a f***ing password. /headdesk
KeePass user here. Works damn fucking well IMO. Here's how the key transformation thing works, to my understanding:
your master composite key (whatever method you use to authenticate - a password, a file, etc) -> key to encrypt data stored in each data row of login data <-><-> buttfuck using some encryption algorithm -> repeat 100,000+ times to generate completely incomprehensible data.
That happens whenever the DB is changed and saved. And when it's opened, it goes through the reverse mechanism: take a row, un-buttfuck it 100,000 times, and see if it's valid data. If not, bad composite key, try again. If so, buzzah, there's your key. Except that there's no way to break down any one of those 99,999 intermediate steps to see if you got it right without going through each one of the 100,000 iterations for every attempt. So let's amplify your brute-force method by 100,000 times and see how long it takes to crack the fuckin' database, shall we?

I'd say it's pretty effective.
(that's also why it takes about 20 seconds for my phone to load the database (a 55KB database from SD) that takes only about 1 second for my computer to load. 600MHz processor sucks ass.)

Wrong. I trust that I can keep my private key secure. You're conflating separate issues.

GnuPG.

yet you trust the very keys that have claim over your coins, and what else would you recommend to store passwords in? lastpass?, don't get me started.

The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post) is that in a forum dedicated to software which depends on hashing the shit out of SHA256 -- where people buy cheap video cards which are capable of generating literally hundreds of millions of SHA256 hashes per second on a single video card -- people still think that sha256 is a great way to slow down offline password cracking.

Pathetic. And the hits will keep on coming. More stolen password databases from poorly secured websites. More stolen emails and more stolen passwords. An endless comedy of errors and bad PR.

Also, nice ponzi scheme signature, theymos... inspires a lot of confidence in those who are first learning about bitcoin to see that a "Administrator/Hero Member" peddles a fucking ponzi scheme. I'm sure that won't reinforce the suspicions that people already have... What happened to your previous ponzi scheme website? Wasn't there some security problem there too?

BTW. Keypass uses SHA256 to truncate or expand a user's password to 256 bits. It has nothing to do with adding computational cost to cracking.


Who knows? The authors apparently don't go out of their way to make it clear, but then again, I don't use keepass... smells a bit too much like snakeoil.

what is this number for exactly? it makes saving the DB slower so i assumed it did a similar thing.

KeePass uses SHA-256.

is this by chance what keepass uses to make breaking your password DB more difficult?

@gene

When you are done trolling and making a fool of yourself and you actually **understand** what bcrypt() does, then we can talk.
For now, I find discussion with you a complete waste of time.

I'm not the one claiming to have written a superior technique here. The burden of proof rests with the person making claims about his superior his method is compared to established methods. Also, the functions are already written in basically every language that matters.


Look at how easy this is:
Done. That particular problem is now solved, and you can go on to other issues.

No need for algorithms of dubious efficacy written by anonymous authors.

Also, don't take my word for it:
https://bitcointalksearch.org/topic/m.228724

Bcrypt effectively eliminates offline attacks. Iterative hashing does not. Again, I'm not the one who proved that. This has been well understood for many years. Time to use the right tools.

Also worth noting explicitly, as this has come up: the question of obtaining the database is of course important, but it is a separate issue.

Bcrypt means two things: a hashing algorithm and a file encryption utility, both of which are based on the blowfish algorithm.

To encrypt passwords and want to prevent a stolen database from being hacked easily, you need a slowdown. If checking one password for correctness takes N times longer, it takes N times longer to crack as well. The intent is to make a single check as slow as you can bear.

Schemes like iterated sha512 or pbkdf2 achieve this slowdown by hashing multiple times, bcrypt achieves it through a slow key scheduling step.

Given that no preimage attack against the used hash function (sha1 on this forum and in pbkdf2, sha512 on mtgox) exist, I'd say they are equally safe if their verification step takes the same time. There exist attacks against sha1, but only collision attacks (which won't help you here) and theoretical preimage attacks (which don't really help much)

The main advantage of bcrypt is that is slower to implement on hardware, but not so much anymore on modern hardware. A more recent password hashing system called scrypt was designed to overcome this, but is not very much used. Given that the bitcoin community has massive amounts of computation hardware, that may be the best choice.

Sources:

• http://stackoverflow.com/questions/2772014/is-sha-1-secure-for-password-storage
• http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415

This.

Children, can we stop fighting?

I just did a quick search for bcrypt and saw how pointlessly irrelevant it is:
http://duckduckgo.com/?q=bcrypt
It's a file hashing algorithm FFS. First demonstrated on a Pentium-II, I'm sure, to much fanfare after it took a full second to crunch out. In 1999.

(and to think, prior to scrolling up and reading Shadow's full-blown WTFPL-licensed smack-code, followed by gene's totally worthless off-topic reply, I was almost siding with gene here - then I searched it.)

Here's what we need: an algorithm that's designed for passwords, not files. Run an MD5 through a SHA-1 and a Blowfish and a fuck-why-not-throw-the-rest-in-there-too set of hashes, then store THAT fucking hash in the database. Someone types in a password, run it through the same gauntlet of hashes, compare the result. Match? Good, sexy, let 'em in. Mash two together in a run or something. Obscurity? You bet your fucking ass, but without reading the source code, you'd have no idea how to break the values apart to reverse them, it'd be impossible.

Or just find an API to KeePass or some shit, store everything in there. I dunno, it's probably been done.
(and I can guarantee nobody will have a gripey bitch about how secure KeePass is.)

Or here's a better idea: don't let your fucking forum SQL database get compromised in the first place.

OK.... so here you go.
You have no arguments whatsoever and you are simply saying "hey, I am right because the guy in the article said so". You also have completely no idea how the bcrypt() itself works, as you cannot explain the differences between it and my algorithm in detail.

I am sorry, but you are no cryptography specialist or even an experienced programmer. I find it a waste of time to continue discussing with trolls.

EOT.

[SYSTEM MESSAGE]: Arrogance indicator overflowing!

Try harder. Maybe read primary references.


Cool. Now go write a paper and submit it, because you have just discovered something that dozens of security specialists over several decades couldn't. Or... maybe you missed something rather important and are letting your ego get the better of you. Sorry, but you're no Niels Provos.


Try reading and understanding what bcrypt actually does instead of assuming that you have trivially solved one of the most well-studied problems in computer security.