www.btcbalance.net - View your balance easily online.

[Grouver (BtcBalance)]

Rather than checking blockexplorer for your wallet data, have you considered running your own block data software? There's an open source version in development on this thread: http://forum.bitcoin.org/index.php?topic=22785.0.

Yes of course.
I tried this, but for some reason I could not get it to work.
So for now I decided to go via the easy way.
Right now its okay to parse the information via blockexplorer.
If this thing grows big, I of course need to get this to work without parsing from the blockexplorer API.

Maybe add caching of the blockexplorer data every 30 minutes?
At least until you can setup your own.

Well right now the data amount being parsed isn't that significant.
So I guess I am not gonna plan in that one yet.
But we will see. Thanks for your input though.

[1713934221]

1713934221

[1713934221]

1713934221

[1713934221]

1713934221

[1713934221]

1713934221

[Grouver (BtcBalance)]

Just wanna bump this since it got complety burried.

[Grouver (BtcBalance)]

The exchange rate display stopped working cause the Tradehill API died.
It's now retrieved from the Mtgox API.

Go check out now how many your bitcoins (spread over different addresses) are worth in euros or dollars.

[bitcams]

The exchange rate display stopped working cause the Tradehill API died.
It's now retrieved from the Mtgox API.

Go check out now how many your bitcoins (spread over different addresses) are worth in euros or dollars.

Thanks, I was just spending hours looking for this it was meant to be! (-:

[Seal]

Sounds like a good idea. I'm not sure if this makes sense though:

Encrypted with three random of the most secure algorithms

[Grouver (BtcBalance)]

Sounds like a good idea. I'm not sure if this makes sense though:

Encrypted with three random of the most secure algorithms

1) Thanks.
2) Which part doesn't make sense?

[Vod]

You shouldn't be encrypting the IP addresses at all.

Use a one way hash to stop spam accounts.  Then if the database is compromised they have nothing.

[Grouver (BtcBalance)]

You shouldn't be encrypting the IP addresses at all.

Use a one way hash to stop spam accounts.  Then if the database is compromised they have nothing.

The passwords of each account are being tripple hashed with 3 random algorithmes.
IP adresses are hashed one time with SHA512.
Why shouldn't I hash the IP's if I may ask?

[DeathAndTaxes]

He never said you shouldn't be encrypting hashing IP addresses.

[Grouver (BtcBalance)]

He never said you shouldn't be encrypting IP addresses.

You shouldn't be encrypting the IP addresses at all.

[DeathAndTaxes]

BLERG.  Fail on my part  I intended to write hashing.  You asked why shouldn't they be hashed.

[Grouver (BtcBalance)]

@mlawrence
The word: 'Encrypted' needs to be: 'Hashed'. Your right. Thanks guys.

[DeathAndTaxes]

Hashed with three random of the most secure algorithms

So now that we got the encrypt vs hash confusion behind us I think the point was this sentence doesn't make much sense and isn't very professional.

First there is no reason to triple hash.  If you use a solid algorithm like SHA-256 the results can't be unhashed.  If SHA-256 is compromised in the future you could also require users to change password and re-hash.

Second plain hashing algorithms aren't a good idea for passwords.  The problem isn't that they can be reversed the problem is that they are fast.  Too damn fast. A mining farm can attempt to brute force tens of billions of hashes per second.  An algorithm like bcrypt, scrypt, or PBKDF2 are much better suited for protecting a password list.

Third no idea what you mean by three random secure algorithms?  You can't pick the algorithm randomly or even if you do you must provide it in the password file which doesn't provide any security.

Saying something like the following makes more sense:

Your password is never stored in plain text.   A secure hash of your password is used for authentication.  We can't recover any lost/forgotten passwords.  For technical details click here.

The here could be something like:

For the cryptographically oriented, the stored password hash is the output of bcrypt using workload=20 and the input is the user supplied password and a per account randomly generated 64 bit salt."

That would tell people how you are hashing (and doesn't help the attacker at all).

[Grouver (BtcBalance)]

SHA-256 is compromised in the future you could also require users to change password and re-hash.

Or you just hash them three times with 3 random methods out of a big algorithm pool to begin with so you don't have to re-hash and notify everybody.
Therefore, I don't register any email addreses, so I can never notify every user about a database comprimise.

Second plain hashing algorithms aren't a good idea for passwords.  The problem is they are too fast.

That's why each user has a unique code bind to there account to decrypt (when logging in) what hash methods have been used.
This would make the cracking of 3 different hash methods very hard since for each new account the password is hashed with different methods in a random order.
It's not hashed with just only md5 or something.

A mining farm can attempt to brute force tens of billions of hashes per second.

Not sure what you think, but I still think nobody would want to crack this and invest tons and tons of time, energy and money in hacking a small database containing passwords that are connected to a bitcoin address and some hashed ip's that are not even connected to the accounts.

Saying triple hashed w/ three "random" (is that even possible) algorithms doesn't make any sense.
Saying something like.  "Your password is never stored in plain text.   A secure hash of your password is used for authentication.  We can't recover any lost/forgotten passwords.  For technical details click here" makes a lot more sense.

I agree with you on this. I will change this at short notice.

[DeathAndTaxes]

I agree it is unlikely anyone would want to crack this but you you got a nice first project and maybe your next one involves coins or other sensitive details.  Like most developers you will work with what you know and trying dubious "roll your own security methods" may lead to you using them on other sites too.

Encrypting the hashing method provides no security.   If someone gets the password list they can decrypt it.   That is the entire reason for hashing.  Keeping the hashing method a secret isn't security.   Bitcoin puts its algorithms out in the open and it hasn't been broken.

Generally speaking "rolling your own encryption (or hashing)" is a bad idea.  I don't want to derail this anymore than I already have so I will leave it at that.   Still given the scope of the site there isn't any real risk (even if pwd were stored in plaintext).  For the record I made an account to check it out.

[Grouver (BtcBalance)]

Encrypting the hashing method provides no security.   If someone gets the password list they can decrypt it.   That is the entire reason for hashing.  Keeping the hashing method a secret isn't security.   Bitcoin puts its algorithms out in the open and it hasn't been broken.

How do you mean: "If someone gets the password list they can decrypt it. "
I mean sure, theoretically it's possible to crack one user his password hashed by sha512, whirlpool and ripemd320.
But practically it will take dozen of years to do so. And then you have what? A password connected to a bitcoin adress.
Maybe keeping the hashing methods a secret isn't providing security, but making sure each account it's password has a different way of being hashed makes it damn more difficult for the hacker to crack it.

For the record I made an account to check it out.

Thanks, feedback is appreciated.

EDIT:
You may also pm me if you don't want to answer in this thread.

[DeathAndTaxes]

How do you mean: "If someone gets the password list they can decrypt it. "

I mean encrypting the method is dubious because anyone who can obtain the list can also obtain the encryption key and decrypt the method.  The reason we hash passwords instead of encrypting them is because one must assume if the attacker was able to gain access to your password list he will be able to gain any encryption keys.

Encrypting the hash method is simply "feel good security".  Either attacker never gets password list (in which case the encryption protects something that wasn't stolen) OR the attacker gets the password list AND likely the encryption key and the first thing he does is decrypt the hashing method.

This is the same reason that salt is stored in plaintext.  The algorithm, salt, # of rounds (for some algorithms), IV, etc are non-secure pieces of information.   Good security assumes the attacker already knows them.  Hiding, obfuscating, or encrypting them doesn't make the system any stronger.

I mean sure, theoretically it's possible to crack one user his password hashed by sha512, whirlpool and ripemd320.
But practically it will take dozen of years to do so. And then you have what? A password connected to a bitcoin adress.
Maybe keeping the hashing methods a secret isn't providing security, but making sure each account it's password has a different way of being hashed makes it damn more difficult for the hacker to crack it.

The number of methods doesn't make it any harder.  Brute force cracking is solved by brute force.  It isn't any harder to brute force 3 algorithms which combined take 3x clocks cycles as it is to brute force a single algorithm which takes 3x clock cycles.  All that matters is the amount of computing power required to check a single key, and the weakness of the password.    As an alternative using something like bcrypt (instead of 3 random encrypted algorithms) would be simpler, peer reviewed, and would require the attacker to take 10,000x  (where x= 1 SHA-512 hash) clock cycles to perform one password check.  Multiple secret methods just add complexity without adding security.

For weak passwords it wouldn't take years, or even weeks it is more like days or hours. SHA, whirlpool, and ripemd320 are very fast algorithms (with throughput in billions of hashes per second.  A cracker with a quad GPU machine could brute force ~ 500 trillion possible passwords per day.  Half a quadrillion is every common/weak/known/leaked password plus exhaustive brute force search of all passwords 7 char or less (upper/lower/number/symbol) for site containing 50,000 accounts.

For the record it is mostly academic because there is little value in attacking the site however it is a good idea to separate strong security from "feel good security".  Adding extra complexity which doesn't make the attacker's job materially harder is "feel good security".  Someday you may write the next Bitcoinica. 

[Seal]

Encrypted with three random of the most secure algorithms

Saying triple hashed w/ three "random" (is that even possible) algorithms doesn't make any sense.
Saying something like.  "Your password is never stored in plain text.   A secure hash of your password is used for authentication.  We can't recover any lost/forgotten passwords.  For technical details click here" makes a lot more sense.

I agree with you on this. I will change this at short notice.

Yeah, I was getting at the wording as opposed to the technical details behind it. It didn't really make sense. My English is pretty terrible but I'm sure its grammatically incorrect too.

[Grouver (BtcBalance)]

A cracker with a quad GPU machine could brute force ~ 500 trillion possible passwords per day

And why would bycrypt have any more resistance to a mining farm?
I mean if we start using mining farms to brute force (On what actually? You need to check if the outcome is correct right?) no hashing method is safe.

It isn't any harder to brute force 3 algorithms which combined take 3x clocks cycles as it is to brute force a single algorithm which takes 3x clock cycles.

Doesn't it take 3 times as long to decrypt a password that has being hashed 3 times?
Above you say it will take as long to decrypt a single hashed md5 password as a password that has being hashed with sha512, md5 and whirlpool.

[DeathAndTaxes]

And why would bycrypt have any more resistance to a mining farm?
I mean if we start using mining farms to brute force (On what actually? You need to check if the outcome is correct right?) no hashing method is safe.

Of course bcrypt is safe against hashing farms. That is the whole point.  

As to why/how?  It isn't a single hash but instead a looping construct which performs multiple hashes using the prior hash's output as input for the next round.  The default workload is 10 which is 2^10= 1024 hashes.  Today the recommended minimum is 16 = 65,536 recursive hashes.   That significantly cuts the throughput of a hashing farm.  Instead of being able to check billions of potential passwords every second the same hardware can only check thousands.  

Another way to look at it is for a given password complexity and cracking hardware a sha-512 hash could be brute forced in 1 hour it would take multiple years using bcrypt(16).

It isn't any harder to brute force 3 algorithms which combined take 3x clocks cycles as it is to brute force a single algorithm which takes 3x clock cycles.

Doesn't it take 3 times as long to decrypt a password that has being hashed 3 times?
Above you say it will take as long to decrypt a single hashed md5 password as a password that has being hashed with sha512, md5 and whirlpool.

I think you are missing the point.  If you use n algorithms to acheive a total hashing time of 3x you haven't gained anything (other than needless complexit) over using a SINGLE good algorithm and iterating it enough times to take 3x time.

this:
Stored hash = RandomAlgo#1(RandomAlgo#2(RandomAlgo#3(password+sat)+salt)+salt)

isn't any more secure than this:
Stored hash = SHA512(SHA512(SHA512(password+sat)+salt)+salt)

All of the picking randomly algorithms from a pool of algorithms and then encrypting them is what is known as "feel good security".  It does nothing that simply using a single good algorithm multiple times doesn't do.  However the second issue is when dealing with massive cracking engines a multiplier of 3x (or 5x or 18x) doesn't provide any meaningful increase in resistance.  Since you seem hell bent on catching the "I must reinvent the wheel" train, your next though likely is to increase the number of iterations. So lets take this to the logic conclusion.

If you took the above idea, used a core hashing algorithm which was harder to brute force, ensured sufficient entropy in the salt (64 bit minimum), built in protection for intra-round key collision (which optimizes attacks using rainbow tables), designed it to store the version, hash, salt, and # of rounds in the output (which adds upgrade/compatibility), built in a whole bunch of error checking to reduce/prevent usage bugs which weaken the output, and allowed for changing the # of rounds as computers get faster .... well you would have just re-invented bcrypt.  In a decade or two when it was as exhaustively tested and analyzed as bcrypt you have a high confidence it was as secure as bcrypt.  

Alternatively you could just use what has already been written a decade ago.

BTW bcrypt isn't the only option.  scrypt is a variant which is memory-hard throughput on GPU/FPGA restricted.  PBKDF2 (Password-Based Key Derivation Function) is a third common option which can use a variety of base hashing algorithms.