And totally compatible with most modern PCs, thanks to a clever interface cable. |
|
|
|
Here is a list of the first few thousand passwords. http://pastebin.com/r3hYJYLaThe first 3000 are apparently using straight md5 with no salt, so they are fairly easy to crack If you appear on that list, please take appropriate precaution. Odd. That appears to be 361 passwords, out of the roughly 1700 that were unsalted. That is an order of magnitude away from your claim of 3000, but let us put that aside for the moment. The more interesting thing is that roughly 80% of the weakly hashed passwords have not yet been cracked, even in today's world of giant rainbow tables and precomputed MD5 databases. |
|
|
|
|
32 bits are supplied by the final miner. 2^32 =~ 4 billion.
Besides, no one but us cares that their hashes start with a bunch of zeros.
|
|
|
|
|
Your captcha is useless and annoying. There are better ways to prevent oracle attacks.
If anyone is interested in breaking this style of captcha, the basic technique is: intensity histogram, contrast, despeckle, horizontal histogram, cut letters/find hulls, unrotate and rescale, build grid, lookup in database. Building the database in advance is the hardest part, and it is really only hard if the site under protection isn't worth getting into.
Captchas were great 10 years ago, when not everyone knew how to break them. By now, they have to be nearly unreadable to be effective. Within a few years, I suspect that getting a correct answer for a difficult captcha will be taken as evidence against the humanness of the interpreter.
|
|
|
|
Is it feasible for the hash power of the bitcoin network to be hijacked for code cracking?
If the code cracking problem solution was a mapping to the block solution space it could be as simple as inserting a 'magic' transaction into the block that maps the two solutions together.
Probably easier performed by a large pool operator that distributes work and controls the included transactions in the sought after block solution, for example ... or if all diff. 1 solutions are collected then other auxiliary problems that lie in the same mapping space can be solved simultaneously also.
No. Even if an attacker really did want to find a bunch of double hashes of specific 680 bit blocks, each result he got back would have a 1 in 4 billion chance of being the one he wanted. |
|
|
|
|
In my experience, flash drives tend to fail all at once, rather than losing a sector at a time.
I would make about 3 copies.
Put one away, and never, ever use it again.
Put the second away, and check it once a year or so.
Put the third away, and check it every week or month.
Or, take the second and third copies, and check both of them every week or month, and if either one goes bad, or does anything even slightly unusual, replace it with a new copy of the one that isn't broken.
|
|
|
|
|
The exchange part is easy. There are several. I think the first was implemented as a bot on IRC.
The hard part is being a clearing house (or an exchange plus a clearing house). This is also the most useful part.
|
|
|
|
This hack was inevitable. Mt Gox deals with millions of dollars per month and was ripe for the picking. I bet there's a million dollars stored in accounts on the site right now, and millions more in BTC. The withdrawl limit saved Mt Gox, this time, but next time they won't be so lucky.
I am unlikely to use Mt Gox ever again after this. It's the equivalent of the NYSE or FTSE being hacked and all shares sold. If we're to treat BTC seriously we need serious security and service. This hacking shows just how flaky bitcoin can be and despite the claims of P2P, security, etc, it's almost totally reliant on a few nodes for trading and bitcoin creation.
We know very little as of yet. I think you may be overreacting. At worst someone stole tons of coins, at best they got 1000 USD from a site that makes tons and tons each day. One is a huge deal, the other is a minor annoyance. There is no overeacting here. Mt Gox had no automatic safeguards and logic checks to ensure the market could not be compromised. Gox is no longer a Magic The Gathering trading site. They are dealing with serious amounts of money with no auditing or regulation. How was taking a BTC's value down 99.95% within minutes not stopped by the exchange? I know the rabid libetarians will say it was the will of the market, and if it needs to fall to zero and back again then so be it. Witness the sheer unbridled greed of some posters on this forum who managed to snag BTCs at 99% off, and now whining that the trades will be rolled back. We truly don't know the extent of this attack yet. If it was done properly, the script should have transferred out as many BTCs as possible before the market was shut. Those cannot be retrieved. Unless you are completely wrong, and the attack was largely contained by the safeguards built into their system. You know, the safeguards that you for some strange reason assume don't exist. |
|
|
|
|
Is the first partition marked active? What did you use to write the ISO to it?
|
|
|
|
The weaknesses in MD5 are largely overhyped. It is still just fine when used in a salted + iterated password hash system. Even shitty old DES would be fine in this system, if not for the tiny keyspace.
Don't want to start a fight about password encryption types... but MD5 was not created to encrypt passwords... it was created to check data integrity. Don't forget the beautiful bruteforce rainbowtables you can download. Personally I always use SHA256, which is barely decent. True, but unimportant. And rainbow tables are of absolutely no help for an iterated salted password system. There are a lot of things that MD5 is no longer secure enough for. This is not one of them. The security is in the details, the iteration and salting scheme, not the hashing algorithm. |
|
|
|
|
It has been mentioned before in this thread, but if you are using unetbootin to write the ISO to the flash drive, you need to edit the syslinux.cfg file in the root directory and add "persistent" to the first append line. Unetbootin overrules the boot configuration in the ISO and uses its own.
The step by step sequence that I've been using is:
1) plug new flash drive into a linux box (an existing one, or write the linuxcoin ISO to a CD and boot that for this step)
2) find the device name, and unmount it if it automounted.
3) use fdisk to create 2 partitions. Partition 1 is 1GB, type "b" or "c", active. Partition 2 is all remaining space, type 83, not active.
4) use mkfs.ext4 to create a filesystem on partition 2 (probably /dev/sda2 or /dev/sdb2) (use -L live-rw)
5) plug the drive into a windows box
6) go to disk management, format partition 1.
7) use unetbootin to write the ISO
8 ) edit syslinux.cfg
9) remove the flash drive from windows, boot the new box with the drive.
Optional steps if you are doing a lot of boxes:
10) accept the AMD license
11) install ntp
12) copy over my startup and restart scripts (generic versions with CHANGEME as the worker name)
13) shut down, boot from the CD again, and use dd to clone this prepared drive onto other drives
|
|
|
|
Nifty progress today. [Desktop Entry]
Encoding=UTF-8
Name=coin
Exec=lxterminal --command "/home/user/start.sh"
Terminal=true
#!/bin/bash
xhost +
echo $DISPLAY > /home/user/.display
lxterminal --title miner1_start --command "/home/user/miner1.sh"
lxterminal --title miner2_start --command "/home/user/miner2.sh"
#!/bin/bash
cd /opt/miners/phoenix
./phoenix.py -u http://__USER__:__PASSWORD__@__PROXY/POOL__:__PORT__/ -k phatk BFI_INT VECTORS FASTLOOP=false AGGRESSION=11 DEVICE=0
#!/bin/bash
cd /opt/miners/phoenix
./phoenix.py -u http://__USER__:__PASSWORD__@__PROXY/POOL__:__PORT__/ -k phatk BFI_INT VECTORS FASTLOOP=false AGGRESSION=11 DEVICE=1
#!/bin/bash
export DISPLAY=`cat /home/user/.display`
pc=`ps waxuf | grep miner1.sh -c`
ld=`aticonfig --odgc --adapter=0 | grep "GPU load" | cut -c 30-35 | cut -d % -f 1`
if [[ $pc -lt 2 || $ld -lt 50 ]] ; then
killall -KILL miner1.sh
nohup lxterminal --title miner1 --command /home/user/miner1.sh &
fi
pc=`ps waxuf | grep miner2.sh -c`
ld=`aticonfig --odgc --adapter=1 | grep "GPU load" | cut -c 30-35 | cut -d % -f 1`
if [[ $pc -lt 2 || $ld -lt 50 ]] ; then
killall -KILL miner2.sh
nohup lxterminal --title miner2 --command /home/user/miner2.sh &
fi
1,11,21,31,41,51 * * * * /home/user/restart.sh
miner1.sh and miner2.sh are owned by root.root, and are setuid/setgid (mode 6755) while the others are owned by user.user and are mode 0755. Very simple to extend this to multiple miners, and it will restart any that are crashed or hung. |
|
|
|
|
This is why I don't do humorous error messages any more.
|
|
|
|
There are a bunch of sites that show the current block count. Right now it is 131,977. Play with the block explorer a bit. Search for your address and you'll be able to tell if there was a payment sent to it or not. |
|
|
|
The excuse given was to blame the auditor. And for privacy reasons, they won't name the auditor.
This doesn't make any sense at all. What use is an audit performed by unnamed entities? It's the credentials of the auditor which give credence to the audit they perform, is it not?
What use is it for an auditor to have password hashes? No use whatsoever. However, they are easy to overlook if someone asks you to make a quick dump of the database to give to the auditors. Bet they'll have a formal policy and procedure in place before the next audit... |
|
|
|
|
Does your node (the client software on your computer) have the entire block chain downloaded and processed? It won't show your balance correctly if it isn't done.
You can also go to bitcoin block explorer (google it) and search for your payment address.
And yeah, the payments are only down to the hundredth of a bitcoin, which is a bit silly. I don't know why he hasn't changed that yet.
|
|
|
|
With all the layers it is almost irrelevant, but is the hash MD5 or something considered secure? MD5 has been deemed inferior for quite awhile now. It sounds like you use some unique way to make the salt and key very difficult to determine, and that implies encryption and not a one way hash like MD5 or SHA1. So, I am afraid that I did not quite follow what was hashed and stored in the database. Clearly running a lot of crypto and getting a hash of the result for every login would be expensive, do that is why I ask.
The weaknesses in MD5 are largely overhyped. It is still just fine when used in a salted + iterated password hash system. Even shitty old DES would be fine in this system, if not for the tiny keyspace. |
|
|
|
For some reason, your application is not working anymore for me. All i get is this (i got this error days before MTGox was down): == 2011-06-19 06:54:16 ================================
*** curllib: Operation timed out after 30001 milliseconds with 0 bytes received
PHP Notice: Trying to get property of non-object in /home/peter/toyotasupra-ToyTrader-7825748/mtgox.php on line 35
PHP Notice: Trying to get property of non-object in /home/peter/toyotasupra-ToyTrader-7825748/mtgox.php on line 36
USD: BTC: Mtgox is currently down. For more information, head on over to the discussion forum and read any of the last 300 threads or so. |
|
|
|
I see a portable dedicated device with very limited communications ability. Just a serial port will do, which probably means serial over USB or serial over bluetooth. It will also have a SD card socket for wallet backups.
I think this could help with the retail problem too; no reason why you couldn't plug it into a potentially hostile terminal.
How will you ensure, that the 2.00 BTC which the hostile terminal shows you are about to pay isn't 450.00 BTC. Ie: How do you plan to deal with the hostile display issue? Will your device have its own screen? Yes, it will have a display. I guess I didn't mention that, but it is absolutely essential. It can either show the address, and ask for an amount. Or it can show the address and amount, and ask for a Yes/No. |
|
|
|
MD5 I suppose? That hasn't been considered secure for a long time now. SHA1 is what I think has become the defacto standard.
It is all in the way it gets used. MD5 is perfectly fine for passwords, when used properly. eleuthria, please make sure you aren't doing anything strange when storing passwords. Your best bet is to use the crypt() function built into PHP, and make sure you are generating a proper (random) salt string to force MD5, Blowfish or SHA. |
|
|
|
|
Show Posts
