Then someone will simply use two or three or four accounts.
If you're running an exchange, you need to be fair. If someone wants to buy all their shares available, then let them. Do not create artificial limitations.
A better IPO would have been launched in batches anyways.
|
|
|
And it users that's decided to put it to force. No, it's not. Ultimately the miners decided.
|
|
|
That doesn't prove you don't have a backdoor or is vulnerable to side channel attacks.
If this is not open source, not interested.
|
|
|
Dude all you do is screw over your users and abuse your powers Yes, I screwed over a hacker / phisher / script kiddie / DoSer. Was he your friend? Also, you're. Try digesting messages before rushing to post! I'm happy to post a SQL dump of users.password, which are hashed and salted with a user unique salt. That proves nothing through, if it was not indistinguishable from randomness then it was done wrong. No, you're not getting SSH / mysql / whatever access.
|
|
|
LOL so gweedo still wants the database of coinlenders. Dream on buddy.
|
|
|
OK, so CoinChat doesn't salt passwords. It means that if an attacker gets access to the CoinChat user database, he will be able to lookup hashes in rainbow tables and find cleartext of obvious, dictionary and otherwise weak passwords. That certainly isn't "best practice compliant", but since CoinLenders is not affected, isn't it a bit off topic here?
I think we have all taken good note that TF and gweedo aren't best friends, but this is getting ridiculous IMHO
Especially with him wanting the database for CoinLenders. Like lol. CoinLenders now hashes passwords with a user unique salt. The entropy for the randomly generated salt is from /dev/urandom, which is good for most cryptographic purposes but still not as good as /dev/random. CL didn't use /dev/random at the start because it is blocking and that's not practical for a site with thousands of users. Soon, when you sign into CoinLenders your password will be resalted with random bits from /dev/random.
|
|
|
Inputs used bcrypt since the start, we've been looking into & implementing alternative security like GPG or password derivatives for signing transactions too. Just because bitcoin-qt does something doesn't make it correct. Most, if not a figure very close to 100% of software in the world does not use absolute best practices. People should be demanding absolute best practices for sites handling money like storing Bitcoins for example, and that's a valid point - but like I said before, Inputs.io uses bcrypt and that is the ONLY site that stores bitcoins. Demanding that for a web chatroom not recommended to be used for sensitive communications isn't what you should be wasting your time with. If you compromise someone's coinchat or coinlenders account - cool. Now withdraw to Inputs.io and try to compromise that! When did inputs.io become Bitcoins? So you claiming that inputs.io is now bitcoin? No, just that it actually handles Bitcoins.
|
|
|
I'm not talking about bitcoins. I'm talking about web security basics / best practices, which you violated many times for BitcoinLister. Including things like your architecture and code layouts. Every developer does that for hacky / pet projects really.
Aren't you arguing over a CHATROOM? Instead of Bitcoins (ie Inputs.io)?
Also, soon, the next time users sign into CoinLenders, they will be hashed and salted with data from /dev/random (so it's guaranteed to be all from environmental noise instead of some from PRNGs). I'm not doing this right now because it's impractical to get long salts for thousands of users from a blocking source.
|
|
|
gweedo: you have multiple security vulnerabilities on your sites like BitcoinLister.
I've already admitted that some of my sites weren't best practices, but that does not matter in the slightest when talking about Bitcoins because Inputs.io. And CoinLenders now uses a user specific salt generated from /dev/urandom.
No, I am not posting my entire source code or database.
Now the only thing remaining is coinchat. I'd love for you to bitch more about how a pet project chatroom doesn't use best practices, especially when it uses Inputs.io and has an effect of about nil!
(Keep in mind that this forum does not use a user specific salt.)
|
|
|
It was more a "why", why make it more insecure than necessary? Proper password security also protects your users if the site is compromised and users (being users) ended up using the same password on multiple sites, possibly even your other sites.
Took a while but CoinLenders now hashes passwords 3 times (for legacy reasons), including once with a user specific randomly generated salt collected from environmental noise (/dev/urandom, I'm using the non blocking version for now because /dev/random is impractical as a quick update for thousands of users). Still a mostly pointless change as (i) we tell users to not reuse passwords in large font, but yes some users don't listen and (ii) Inputs.io is required. Difference this will make in practice due to CoinLender's Inputs.io requirement: close to zero Difference this makes to forum posters: ??
|
|
|
If you're still using salts in 2013 you're an idiot, no exceptions.
My Little Pony Forums needs to implement GPG auth! (We're implementing GPG signing for logging in for inputs too) bitcoin-qt uses a random salt that scales according to host computational power for wallet encryption, FYI.
|
|
|
So one site has no salt, one site uses a weak static salt and one site does it "right"?
That makes sense.
I could remove login checks for CoinLenders and nobody will be able to steal a single coin (because you're only able to transfer them to your Inputs account)
|
|
|
Wait what? Salt should be random and per record/account. Anything less doesn't prevent a parallel execution attack. Yeah, that's the best practice. I use a user unique salt for Inputs. For CoinLenders it is one salt. This doesn't matter because you need to get into a Inputs account to get coins from CL anyway.
|
|
|
Also, if you want your negative trust rating removed you just need to stop making false statements. Like the topic of this post.
|
|
|
1) He only takes full source code and database as proof apparenty
Only way in my book to prove it. CoinLenders and CoinChat hashes passwords. CoinLenders also salt passwords. CoinLenders also hashes your password in your browser with Javascript. I cannot access your password (unlike what gweedo is claiming) on CoinLenders. I can only access the hash which is useless if it has been salted with a strong hash. Gweedo is spreading FUD that I don't do this. He is posting a misleading screenshot out of context. I DO hash passwords. I don't salt them for CoinChat, but they are hashed.
|
|
|
Screenshots shouldn't be trusted, they can be faked.
|
|
|
More lies from you. I do hash and salt my passwords (sha256 + salt, or bcrypt + user unique salt).
CoinLenders and CoinChat hashes passwords.
CoinLenders also salt passwords.
CoinLenders also hashes your password in your browser with Javascript.
I cannot access your password (unlike what gweedo is claiming) on CoinLenders. I can only access the hash which is useless if it has been salted with a strong hash.
Gweedo is spreading FUD that I don't do this. He is posting a misleading screenshot out of context. I DO hash passwords. I don't salt them for CoinChat, but they are hashed.
As I am tired of saying the same thing again and again, this is now my stock response.
|
|
|
@Trade if you want i can make a test account on both of your sites with a random password, you can then post hash with salt here and a screenshot of username /hash from database to prove him wrong.
You can also put a bounty to crack it.
A few things: 1) He only takes full source code and database as proof apparenty 2) I am not disclosing my salt 3) If I wasn't hashing / salting them, I could just hash later.
|
|
|
You're the one who has been attacking me and who started all this
|
|
|
|