 Show Posts
|
|
Pages: [1] 2 3 »
|
From the code above, I have questions about the base58 used. I have search one base58.py in the google code (and elsewhere) which use the encoding:
"123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ"
but the C and java implementation of bitcoin use the the following encoding:
"123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
So I want to know whether there is consensus about the use of base58?
If I recall correctly Flickr also uses/used a base58 encoding - with a different character set(!) - that's the one you probably found on Google code. I forgot to link to the base58 module I used - I borrowed base58.py from Abe: https://github.com/jtobey/bitcoin-abe/blob/master/base58.py |
|
|
|
- If you maintain proper password policies, you shouldn't have to worry about disclosing a password which you're not using anymore (you weren't reusing it anywhere, were you?) - If it was actually 'random' and 'long' enough you should be able to determine the average time required to crack it - ie. the feasibility of a brute force attack (dictionary should be useless) given am average set of cracking hardware (GPUs). All that, without having to resort to calling me retarded.  |
|
|
|
Your password was probably brute forced from the user dump like mine was. Mine wasn't super simple either.
I call this BS. My hash is up there - go and try to brute force it. I guess I'll see you in several years/decades. Then please disclose your password - if it was anything but totally random & a-z/A-Z/0-9/special & >9 chars you were definately at risk. |
|
|
|
mewantsbitcoins:
Your password was probably brute forced from the user dump like mine was. Mine wasn't super simple either.
> If someone gained admin level user account why would they go to the lengths of SQLi to get the database?
My account still had admin access. They were able to get my account password because of the SQLi
I'm sure Mark is very busy with mtgox so has been neglecting Kalyhost.
Mistakes were obviously made but I don't think Mark is being greedy or incompetent here. He needs to hire more people and he knows this. But which if you have ever tried to do you know takes time which he doesn't have much of these days.
Why did you still have an account with administrator privileges? Auditing? Why did it still grant additional privileges with respect to being able to modify account balances? Some degree of withholding information to be expected when you are compromised. Gox may have been concerned that immediately releasing all they knew could aid the people who did this.
Absolute nonesense. If you discover a vulnerability it's your duty to inform your users, doesn't matter whether you are actually compromised or not - there's a risk and you should inform people about it. |
|
|
|
We've evaluated the situation and decided to implement logout due to inactivity. Security trumps laziness Grin
We're coding it in as I write this and it should be live today after extensive testing.
Solution: make it configurable up to a certain extent, with a tight default session length. |
|
|
|
PCI scanning and putting a seal on your website from Trust Guard, Verisign or McAffe doesn't make you immune to all attacks but it is one step towards a safer exchange and something we should have done a long time ago. At least you acknowledge the uselessness of a seal. Really, it shouldn't be a selling point - every idiot can run nmap/nessus/acunetix <whatnot>.. Luckily (from Camp BX): We were tested for >1,000 known vulnerabilities specific to our platform and services by McAfee Secure Means you're obviously 43x as secure as they are. In all seriousness, publishing a report of a manually performed pentest or source code audit (perhaps with selected individuals) would be useful - this is 99% marketing talk like TrustGuard/McAfee sells it to their customers. But it's good to see you're at least informing your clients... |
|
|
|
|
Aha, the long-awaited clarification. Turns out the majority of speculations were correct after all.
Still, existence of the SQL injection vulnerability should've been disclosed two weeks ago(!), instead of dodging all speculations.
|
|
|
|
A single typo is trivial to correct, as the private key includes a checksum as well. Warning: hackjob ahead#!/usr/bin/python
import base58, hashlib
def sha_checksum(data):
return hashlib.sha256(hashlib.sha256(data).digest()).digest()[:4]
sec = '5JjNVWPaRTPg1i4etqfPHFnsDZ1Js5qBYXFH9G4jC2Drb6kERsm'
data = base58.b58decode(sec, 37)
checksum = data[-4:]
key = data[:-4]
for i in xrange(len(sec)):
for c in base58.__b58chars:
modkey = sec[:i] + c + sec[i+1:]
decoded = base58.b58decode(modkey, 37)
if decoded:
if sha_checksum(decoded[:-4]) == checksum:
print 'Found:', modkey
print (6+base58.__b58chars.index(c))*' '+'^'
Output:Found: 5JjNVWPaRTPg1i4etqfPHPnsDZ1Js5qBYXFH9G4jC2Drb6kERsm
^
|
|
|
|
You seem to be right. I have submitted a pull request for Jeff: https://github.com/jgarzik/pushpool/pull/39(I passed unc_len instead of unc_len + 1, as the last byte is used for null termination and not part of the compressed data) |
|
|
|
We were tested for >1,000 known vulnerabilities specific to our platform and services by McAfee Secure (formerly McAfee Hacker-Safe), who are ranked #1 in security industry for threat detection. This is the same auditing service used by well-known brands like Costco, Petco, and Roush Racing for their e-commerce websites.
Congratulations, you fell for the same ploy as Costco, Petco & friends - you're paying for a useless logo. Correct me if I'm wrong, but iirc. McAfee only performs an automated remote scan - nothing you couldn't do yourself with Nessus or some other equivalent. Get a proper audit done - a white/grey box pentest and a source audit. They didn't do that, did they? |
|
|
|
Test reports, suggestions, and donations are all welcome.
Great job. However (as mentioned before), I believe the proper way of solving the issue is by implementing keepalive on top of the asio [1] pull request (that's what Jeff suggested). I've looked into the issue reported there - turns out to be a trivial fix (send buffer goes out of scope, hence large tx'es fail). Implementing keepalive on top of that should only take a few lines (header handling and timeout), and is probably a better merge candidate. Seems to work for me after fixing the asio patch and adding a quick hack to accept additional requests. [1]: https://github.com/bitcoin/bitcoin/pull/214 |
|
|
|
They're calling it a way to get "free bitcoins". Good job OP. I don't suppose you'd "fully disclose" that the "exploit" as you call it, is not, in fact, a way to get "free bitcoins". I don't suppose you'd bother to correct the misinformation you've fostered.
You can't blame him for 'journalists' writing about matter they have little to no knowledge about. |
|
|
|
Yes, even with the site disabled.
Either it was disabled, or it wasn't. Yes, we use password encryption. We are currently using SHA-256, but
since the recent Mtgox hack we will be upgrading that to something
stronger. It's surprising how many sites still use MD5, even though it
was broken years ago. It is my personal opinion that MD5 be deprecated
from modern operating systems.
Every time someone calls a (one-way) hash function 'encryption' the FSM kills a kitten. Yes, MD5 should be deprecated due to known weaknesses (collision attacks), but using one of the SHA variants isn't going to magically make things unbreakable. MtGox's crypt(md5) is alot more resitant to attacks than plain SHA-256. The keywords are salting and stretching (or: bcrypt/scrypt) - all general purpose cryptographic hash functions were designed to be fast. |
|
|
|
In truth, none of these are the right solution. I have some ideas for the 'right' solution (bitcoind should push changes to the mining controller so it doesn't have to poll), and I'll try to get them thought out and proposed as modifications to the official source. (Think of it as extending long polling back one more link in the chain.)
Even so it would make much more sense to do it properly (so we end up having a useful pull request against bitcoin); the asio route appears to be the way to go (patch is there, yet bugged) instead of spawning multiple threads. |
|
|
|
|
Yes, providing signatures on the front page would be a good thing.
|
|
|
|
While I realize Adam has clarified this to a certain degree, this whole response has just been clownshoes and this is just yet another example of it. Clearly they're not in the right frame of mind if one of their top of mind concerns is the effect of the cost of sms messaging for authetication on their bottom line.
Last time I checked the problem was on their end, not on their users'. Although adding a second factor is undiably a good thing, it's not going to do much for security on their end. In addition to that, I suspect a large number of bitcoin/mtgox users own a smartphone. There's a HOTP implementation for pretty much all platforms - completely free.. |
|
|
|
As for the Yubikey, you will pay for a key and the service itself would of course be offered free of charge, making it effectively a one time fee.
HOTP clients are available for most smartphones. No SMS needed then, and free for the end-user. An alternative would be HOTP hardware tokens (Yubikey supports HOTP too, in one of it's two configuration slots). Still doesn't improve your database security though |
|
|
|
And you're absolutely sure it isn't due to the multitude of peers trying to connect to you? |
|
|
|
|
The Guardian? I thought that was a reputable British paper..
So much cruft combined into one article, amazing.
|
|
|
|
|
