Storing the password in traidor.conf is insecure. An alternative is needed. Perhaps the password could be read from the TTY if the user doesn't provide it in traidor.conf.
Also, the program should check the $LINES and $COLUMNS environment variables every time it updates the screen, instead of having to set it manually with the d menu option.
Hmm, I tried reading $LINES from os.environ, it's not in there. while "echo $LINES" in bash works, "env | grep LINES" doesn't show it either. Any hint for me? |
|
|
|
WTF? I just noticed that this program uses the sound card to make strange "ticking" noises.
Yeah, that's the "ClickBot". I should probably make that optional or start it by command. btw, you can also set an alarm using the TriggerBot: mtgox | x BTC | y USD #> tb >= 12.5 ps alarm.wav
|
|
|
|
I hope this script don't betray me!
The source code is right there to check. I'm sure if I inserted malicious code, it'd be reported here quite quickly. |
|
|
|
Storing the password in traidor.conf is insecure. An alternative is needed. Perhaps the password could be read from the TTY if the user doesn't provide it in traidor.conf.
True. I will switch to using api-key, like goxsh does, with encrypted secret. Password authentication will be switched off for the api at some point anyhow. Your suggestion is a good way to deal with it in the meantime. If I get around, I'll implement that. Also, the program should check the $LINES and $COLUMNS environment variables every time it updates the screen, instead of having to set it manually with the d menu option.
That's a good suggestion. Will probably implement that. Thanks for your feedback! |
|
|
|
|
Isn't there a simple way to find out? How about a couple of supecting miners decide to use a slightly modded miner that would inform the user when it finds a block.
It'd be sufficient for this group to be able to present only 1 block that was stolen by the operator.
Of course they would have keep their identities secret, otherwise the pool operator can just always leave their blocks untouched and choose blocks of other miners for stealing.
This would at least create a lot of danger for the pool operator. The pool operator getting caught stealing would certainly destroy the pool, so even a slight danger of that happening should keep him from stealing, right?
Am I overlooking something?
|
|
|
|
MyBitcoin.com USERS HAD BITCOIN STOLEN. They are returning a portion 49% of them to you: Not sure where to send them? CALL ME. 646-580-0022
Yes, I think most of us are convinced they got stolen. What are you trying to say? Why should we call you? For more great advice? I'm really having trouble understanding you. I was expecting something like: Oh God, this lift's some weight from my shoulders, because at least I'm getting back 49% of my 50,000 BTC and all my friends I recommended MBC to, also. Other than that: you're doing a great job promoting bitcoin. Thanks, and keep going! |
|
|
|
Instead you can create yourself your privkey (at least the hex one, 64 characters long, I don't know if all base59 ones are valid they are not because of the checksum) using your own pattern that you know by heart, thus no need to write it
E.g. 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef for 19ffB4HttNCHfY1t3YuErEytCspyHyVMwv
Is 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef really a valid privkey? importprivkey says it's not. #> bitcoin importprivkey 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
error: {"code":-5,"message":"Invalid private key"}
Afaik, importprivkey only accepts base58 privkeys I didn't think you could just use any 256 bit number as private key. Please, someone knowledgable clear this up for me.
You can use any 256bit number as private key, except 0 I see. Thanks for clearing that up. |
|
|
|
Or, in summary, once this unique event ends, the price of bitcoins will go up, go down, or stay about the same.
Joel, I usually enjoy your posts for their depth and insight, this one for it's humor. |
|
|
|
Instead you can create yourself your privkey (at least the hex one, 64 characters long, I don't know if all base59 ones are valid they are not because of the checksum) using your own pattern that you know by heart, thus no need to write it
E.g. 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef for 19ffB4HttNCHfY1t3YuErEytCspyHyVMwv
Is 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef really a valid privkey? importprivkey says it's not. #> bitcoin importprivkey 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
error: {"code":-5,"message":"Invalid private key"}
I didn't think you could just use any 256 bit number as private key. Please, someone knowledgable clear this up for me. |
|
|
|
One can now claim 49% of the funds, it seems: https://mybitcoin.comI claimed and received 49% of my 0.3 BTC  |
|
|
|
during the last weeks I made quite a few improvements to traidor: - use websocket implementation made by Giel (more stable)
- avoid queue-up of websocket messages by using asynchronous display thread
- be able to set market depth display precision (key "p")
- many small bugfixes
- improve connection trouble handling (catch exceptions, retry)
Any suggestions or bug reports always welcome. |
|
|
|
And yes, I am thinking about refining our offers including rates. You will hear from us in the next 7-10 days.
Cool! |
|
|
|
It does seem that if a smaller exchange is above the Mt. Gox rate, and the Mt. Gox rate itself is dropping, it's very likely that exchange's rate will move down as well. Similarly, if a smaller exchange is below the Mt. Gox rate, and the Mt. Gox rate is increasing, it's very likely that exchange's rate will move up.
Especially with arbitrage bots starting to show up. It'll be very fast. Actually when you think about it, this is a mechanism that might actually synchronize rates on all the exchanges (at least the ones that have good enough apis) and finally give smaller exchanges a chance to enter the market more easily. Just a thought... |
|
|
|
Watching those walls you mention get put up and torn down within seconds on mtgoxlive makes me go "hmmmm". You can see the lines jump thousands of BTC or tens of thousands of USD all of a sudden. There is a very large bot or human messing with us. The only thing that is clear is that he has a ton of money to play with. Confirms the speculators that always say "you think the market moves a lot now? wait until your average wallstreet guy comes in and starts throwing a few million around".
Good thing it will be millions of USD, not millions of BTC. Somebody just threw up 10,000BTCs at $10. Methinks we're going down. Why? This could well just be someone wanting to buy. Putting a fake wall like that tends to trigger a lot of orders just below it, which can then be bought up. After that, the wall order is removed. We'll see... EDIT: wall at $10 now 17,000 BTC |
|
|
|
Watching those walls you mention get put up and torn down within seconds on mtgoxlive makes me go "hmmmm". You can see the lines jump thousands of BTC or tens of thousands of USD all of a sudden. There is a very large bot or human messing with us. The only thing that is clear is that he has a ton of money to play with. Confirms the speculators that always say "you think the market moves a lot now? wait until your average wallstreet guy comes in and starts throwing a few million around".
Good thing it will be millions of USD, not millions of BTC. |
|
|
|
I would've thrown $400 USD into BTCs back a few hours ago when it was only $8, but sadly it takes a day to get money into Mtgox from Dwolla's bank account. I rely on Paypal for instantaneous payments.  Well, why not keep some USD on mtgox balance, just in case? |
|
|
|
Some percent of miners always invest, so they need to convert BTC into USD, because AMD, Intel and Foxconn don't accept BTC. (emphasis mine) and there my friend, you have identified the real problem. |
|
|
|
Here's a google cached version of an earlier posting on the site "From the desk of Tom Williams", including PGP sig: http://webcache.googleusercontent.com/search?q=cache:EN0mtcwBftAJ:https://www.mybitcoin.com/downloads/incident-report-2011-06-22.txt+From+the+desk+of+Tom+Williams,+operator+of+MyBitcoin.com&cd=1&hl=en&ct=clnk&gl=de&source=www.google.deYou really have to wonder why the current info is not signed... I somehow doubt it's Tom Williams talking to us... EDIT: decided to post the text here, in case google cache forgets: -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
From the desk of Tom Williams, operator of MyBitcoin.com
For immediate release.
There are a lot of unanswered questions floating around on the Bitcoin
forum and other places about the recent Mtgox password leak, and theft
from the MyBitcoin system.
I will attempt to answer as many of the questions and concerns as best
as I can in order to silence the rumor-mill once and for all.
As many of you already know, Mtgox was hacked and its password file was
leaked. As soon as we heard about the leak we were closely monitoring
the system for abnormal activity, and we didn't see any.
At first glance, we didn't see any hard evidence that a password leak
had even occurred. There was just a lot of speculation to an SQL
injection vulnerability in Mtgox's site. A few clients of ours had
informed us of the forum threads, and we watched them carefully.
The following morning a client of ours sent us the download link to the
leaked Mtgox password file. We prompty downloaded the file, put up a
warning on the main page, and disabled the login.
We attempted to line up usernames from the leak, and we found a lot of
matching ones. We started locking down all of those accounts using a
script that we had to have written at a moment's notice. It was during
this time that we noticed a flurry of spends happening. Yes, even with
the site disabled.
The attacker had active sessions open to the site. We quickly flushed
them and the spends stopped abruptly. We disabled the SCI, all payment
forwarding, and all receipt URL traffic on all of the usernames in the
Mtgox leak.
We proceeded to change the password on every account where the username
matched our system's database. PGP-signed emails went out to all of the
accounts that we changed the password on. If an account didn't have an
email address or had already been compromised we put up a bulletin.
(Email addresses were mandatory when we opened our service initially,
but people complained that it wasn't truly anonymous so we made them
optional. Unfortunately this makes contacting a security-compromised
customer impossible.)
An investigation was conducted at that time, and we determined that the
attacker had opened up a session to each active user/password pair ahead
of time, solved the captcha, and used some sort of bot to maintain a
connection so our system wouldn't timeout on the session. It was likely
his intent to gain access to more accounts than he did, but as soon as
he noticed that we had changed the main page of the site he sprung into
action by sending a flurry of spends.
(Before you ask: no, we don't limit logins per IP address. We can't. We
have a lot of users that come in from Tor and I2P that all appear to
share the same source IP address.)
We've concluded that around 1% of the users on the leaked Mtgox password
file had their Bitcoins stolen on MyBitcoin. It is unfortunate, and a
horrible experience for the Bitcoin community in general.
The IP address that the attacker used was a Tor exit node and the spends
were to an address that is outside of our system.
Now to address the rumors:
No, our database wasn't compromised. We had a 3rd party company audit
our site for SQL injection attacks and we passed. (We did, however, have
one XSS hole in the address book page last month that would allow an
attacker to insert fake entries into a customer's address book. It was
promptly fixed and offending address book entries were purged. Not a
single customer had spent to the fake address book entries.) Every line
of code was audited last month. Literally line by line audited by
professionals, and it was deemed safe.
No, this site isn't being ran by some amateur that just learned how to
program computers. It was created by seasoned programmers that
understand security.
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.
We also use whole-disk level encryption on every single one of our
servers. When you fail a disk in a NOC and a level 1 technician replaces
it does he wipe the disk before the RMA/tossing it in the garbage? Not
usually! We know these mistakes happen, so we take precautions. Any and
all servers with an IP KVM on them are ran in secure console mode. The
root passwords are required even for single user mode. All disk keys are
held off-site and were never generated anywhere near the internet. All
server passwords are unique per server and per user, of course. Only two
technicians have access to the secure servers. This access is over a VPN
and we only use secured workstations running Linux and BSD to access
them.
We use BSD servers with MAC, immutable flags, jails, PAX, SSP,
randomized mmap, secure level, a WAF, a DDoS mitigation and alert system
- -- the works. Like I said earlier. We are not amateurs. In fact,
combined we have over 30 years of experience in the payment
processing (credit card arena) industry.
A large amount of the Bitcoin holding is in cold (offline) storage. We
only have a percentage of the holding available hot. This is done for
obvious reasons.
Going forward we are implementing a 2-factor login system,
user-configurable spend limits, better session token tumbling, and a
bunch of new SCI features.
Wishing the Bitcoin community all the best and a swift recovery, and
sincerely yours,
Tom Williams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MBC v1.0
iQEcBAEBAgAGBQJOAki5AAoJEJ+5g06lAnqF3tcH/0QNKf7aBEg08vML9MCkwTjF
VCoTAPzVaVsdbZOqiRwE2/6420tcFZrsWTXYZYbjXckEiYrl7/DQ2XsLyhk4W567
T1sOCmpH99Z2/VAvTfAd5obRTEGpMQ0SLIrfznyc8MmG4C1GvtVUr4jM79asPmRY
jsIn7v53o9Ra1sN3QcvMskRUU1JmqfqU6MlJrYwXrtc/P9Tjm7D3AtsjfvJRX12Z
9g5y1N+zRGVpp7OK35VFnfmIKtOOtb3IMgG5EhiUllsoXKfz1eE08v4f4d0aQstL
+HGMi3PktL1HBpIRni2n4MAaIXq/EyzxDSzkSHp6v032H70c1kkUibL//QNxQuM=
=VaXC
-----END PGP SIGNATURE-----
|
|
|
|
|
Show Posts
