Info about the recent attack

[FalconFour]

I suppose that is true. With admin access, they just had to press one button to get a full database dump. That is much less work than coding a dump program yourself.

Basically, this is a case where you just have to weigh the risks that the hacker would decide to suddenly start cracking the passwords after you release the details, to the damage that anything less than full disclosure would cause to your reputation. Remember when Mt.Gox was hiding things how pissed everyone was?

Well, wasn't around for that, but I do remember hearing all the uproar about it (in fact, I hopped on the Bitcoin wagon just as things were beginning to crash-and-burn around then - I tend to do that with tech trends *facepalm*). But just to contrast: SMF is "open source", remember? "Anyone could figure out how passwords are hashed", or so the parroting went just a few pages ago I still don't think it was necessary at all to rehash (pun) the details of how SMF hashes passwords. It wouldn't've been hiding anything to have not mentioned it - the notification that passwords may have been compromised is really all that needed to be disclosed.

Of course, since it's my reasoning against a person wearing the title "mod", if this is anything like any other forum, cue the community blindly bashing the guy that doesn't 100% agree with the post

Nobody here really thinks that mods are special. We just happen to read more posts than everyone else, so we were given the power to moderate the forum ourselves instead of having to report everything.

Hey, that works for me (and I also noticed in the subsequent [lack of] replies). Certainly a change of pace from the typical forum behavior I'd grown accustomed to after 10+ years of forums

FWIW, I haven't had any spam yet, and I do the unique-email thing as well (so I'd know where it came from). Does everyone getting Liberty Reserve emails have an account there? They could be bouncing the addresses off Liberty Reserve to see if they have an account, before sending the phishing mails...

[minerva]

Fortunately for me, for all forum accounts I use one of four usernames, and one of six passwords. So even factoring in prefering a username and a password over the others, the majority of forum accounts I have will be safe. And then for important accounts, obviously use a safe semi-secure password and change it semi-annually.

Hardly the best security policy, but it's better than most.

[terrytibbs]

Goddammit, theymos.

[ctoon6]

what your saying is stupid on all kinds of levels. any and all information should be shared in any and all forms of communications. you trying to hid information that others could use to increase security elsewhere might not make it to where it needs to be, all because you thought you were helping.

I stopped taking you seriously at that "your" part, but continued to read through your self-perpetuated lack of capitalization* just for entertainment value. And for similar entertainment value, I figure I should tell you that it would've been just as effective, and much less damaging, to have just left out the part about "how the passwords are stored" and just cut to the "if your password is this long" part. There was absolutely no benefit to blurting out exactly how the passwords are stored.

* - that is, "what does it matter to me what some idiot forum noob thinks about my spelling" / "i don't need to be in grammer class whenever i go onlien, fukk you" / "i feel like relaying my low mood and chronic depression through the use of nocaps" / "I Swear i could write Proper Grammar when I need too, I don't need some Stupid forum troll telling me what too do!"

Srsly?

So, in short. You belong to the crowd who believe your own non-vetted coding to be vastly superior to the joint work of others, when it comes to writing secure online software, yet you have no idea what salt is or why it's used?

Salting bascially changes the original value and the comparison value with a known figure so the hashes can't be referenced to a lookup table, and so they can't be broken without knowing the salt value. Oh wait, we know the salt value now. Haha, that was easy™.

Again, with the big exclamation of, "Everyone lock your doors, they might have gotten a copy of the KEY TO THE KINGDOM! *attachment: high-res picture of key to the kingdom.jpg*"

you are unable to refute therefore you go after the way i write, WTG! i congradz you on your proper spelling and capitalization and grammar and all that, while in reality i also am perfectly able to do so, but it simply takes longer to type the additional punctuation, yet you are perfectly able to understand everything i write out.

[FalconFour]

you are unable to refute therefore you go after the way i write, WTG! i congradz you on your proper spelling and capitalization and grammar and all that, while in reality i also am perfectly able to do so, but it simply takes longer to type the additional punctuation, yet you are perfectly able to understand everything i write out.

I shit you not, it actually takes me longer to backspace and un-capitalize words, and to write improperly. You should practice it... most people don't have to sit there and think about how to spell and use proper grammar. Kinda like using blinkers in a lane change (I'm guessing you're too holier-than-thou to do that, either). It just becomes habit if you ever gave 2 shits enough to think about it.

And really, I already refuted you 2 pages ago. I just didn't have to (nor want to) reply to you, but rather to the other people that actually took the minuscule amount of mental effort to present their ideas in a meaningful and more linguistically-respectable manner.

tldr: Suck it, you're not worth the time nor mental effort I've already expended in trying to reason with you.

edit: But 'gratz on your 666th post. 

[ctoon6]

you are unable to refute therefore you go after the way i write, WTG! i congradz you on your proper spelling and capitalization and grammar and all that, while in reality i also am perfectly able to do so, but it simply takes longer to type the additional punctuation, yet you are perfectly able to understand everything i write out.

I shit you not, it actually takes me longer to backspace and un-capitalize words, and to write improperly. You should practice it... most people don't have to sit there and think about how to spell and use proper grammar. Kinda like using blinkers in a lane change (I'm guessing you're too holier-than-thou to do that, either). It just becomes habit if you ever gave 2 shits enough to think about it.

And really, I already refuted you 2 pages ago. I just didn't have to (nor want to) reply to you, but rather to the other people that actually took the minuscule amount of mental effort to present their ideas in a meaningful and more linguistically-respectable manner.

tldr: Suck it, you're not worth the time nor mental effort I've already expended in trying to reason with you.

edit: But 'gratz on your 666th post. 

u2

[phillipsjk]

Create 4 random passwords which contains no special characters and are 10 characters long:

Code:

cat /dev/urandom| tr -dc 'a-zA-Z0-9' | fold -w 10| head -n 4

It struck me as strange that /dev/uramdom is being used instead of /dev/random. The latter blocks until the entropy pool is replenished. The reason /dev/urandom is needed is that the above script throws away a lot of information. It is still an interesing little script (using tools installed by default in many distros), but a dedicated tool like pwgen (that another user suggested) is probably better.

I am posting this reply because another user was suggesting using /dev/urandom as a source of entropy based on the above script, possibly not understanding the implications. If you want guaranteed entropy, you use /dev/random. If all you need is "very good psuedorandom," then you would use /dev/urandom.

In the above script, the following happens:

• High quality psuedorandom bytes are generated.
• 75% of those are filtered out because they are not one of the 62 allowed characters.
• The lines are wrapped to the desired width.
• The first 4 lines (passwords) are displayed. I think the whole chain quits when 'head' exits (+- buffering).

Edit: I totally used the 12 digit, special character version for my updated forum password. The use of 'grep' at the end may actually weaken the passwords by omiting any that do not use special characters.

[defxor]

The point is

... that you even after having been told you've completely misunderstood "salt" kept posting your misinformed rants.

"Ignore user" is the best thing that's happened to these forums.

[defxor]

The principle of this browser extension is that at any site where you are asked to enter a password, the extension will enter a password that is sha256(<your password of choice> + domain) (or any other cryptographic hash function). For example, if my chosen password is "masterpassword", the password that would be used to log into gmail.com would be sha256("masterpasswordgmail.com") (=9b2b649d3124c81093f9080a88b9d3723940dfe0707d8524d0403c9641bc99c3).

According to your description you only get entropy matching your password. Unless your password is a complex 12 char password that means an attacker can still bruteforce it. While they do need to know that your passwords are generated this way, they have knowledge of the domain of the site and the above indeed looks like an obvious hash.

Security by obscurity isn't.

[Blackout]

were wallet.dat files uploaded or not?

[terrytibbs]

were wallet.dat files uploaded or not?

My oh my.

EDIT: Did you know the progress bar was brought to you by Mt.Gox?

[FalconFour]

were wallet.dat files uploaded or not?

To answer your question with another question:

Why would they go after your wallet.dat when they could just go after your browser's (unprotected by default) password store?

[Blackout]

Sure this has been answerd. Not trying to be annoying. Just couldn't find it and didn't feel like reading the entire thread and got e-mail from one of the pools (or could be bull spam) saying wallet.dats were attempted being uploaded when you came here during the cosbycoin time.  I did not on a machine that has a bitcoin wallet on it.  This is posted on several pools though including bitcoinpool so I was just checking.

Passwords changed, and I don't store any passwords in the browser of any importance anyway.

[molecular]

were wallet.dat files uploaded or not?

To answer your question with another question:

Why would they go after your wallet.dat when they could just go after your browser's (unprotected by default) password store?

What are you talking about? How would they gain access to the browser password store?

[FalconFour]

were wallet.dat files uploaded or not?

To answer your question with another question:

Why would they go after your wallet.dat when they could just go after your browser's (unprotected by default) password store?

What are you talking about? How would they gain access to the browser password store?

EXACTLY MY POINT. They didn't steal wallet.dats because they couldn't. And even if they could, they'd probably rather go after something more useful than the Bitcoins they hate so much. That's my point: if they COULD steal wallet.dat, they probably wouldn't've bothered with something so trivial. Browsers have paranoid amounts of security regarding file-upload abilities (remember when the "file path" field disappeared from HTML file controls?), so it's just not possible for a stupid little Javascript playtime script to go stealing wallet.dats. That's the point I was making.

[molecular]

were wallet.dat files uploaded or not?

To answer your question with another question:

Why would they go after your wallet.dat when they could just go after your browser's (unprotected by default) password store?

What are you talking about? How would they gain access to the browser password store?

EXACTLY MY POINT. They didn't steal wallet.dats because they couldn't. And even if they could, they'd probably rather go after something more useful than the Bitcoins they hate so much. That's my point: if they COULD steal wallet.dat, they probably wouldn't've bothered with something so trivial. Browsers have paranoid amounts of security regarding file-upload abilities (remember when the "file path" field disappeared from HTML file controls?), so it's just not possible for a stupid little Javascript playtime script to go stealing wallet.dats. That's the point I was making.

Allright, thanks for clearing that up, man. Cause you had my hard stop for a second there.

[FalconFour]

Allright, thanks for clearing that up, man. Cause you had my hard stop for a second there.

lmao. Sorry 'baut that. No, for that very reason - that browsers store passwords in a common file - is exactly why browsers are so paranoid about preventing web scripts from interacting with the local file system. They're run in little sandboxes, and it while it's not entirely impossible to hack around those safeguards, it would take an *entirely* different set of hacks to do so, not just a "display random funny Cosbycoin/uplaoding walletdat" image randomizer to do so

[smurfix]

Salting bascially changes the original value and the comparison value with a known figure so the hashes can't be referenced to a lookup table, and so they can't be broken without knowing the salt value. Oh wait, we know the salt value now. Haha, that was easy™.

Again, with the big exclamation of, "Everyone lock your doors, they might have gotten a copy of the KEY TO THE KINGDOM! *attachment: high-res picture of key to the kingdom.jpg*"

You forget that everybody and their dog can just go and check out the forum PHP code themselves, and examine the password hashing algorithm in detail.

This mess. ultimately, is the PHP language authors' fault. They seem to argue that securing your scripts (and not just from SQL injections) is the programmer's problem.
A properly designed SQL interface (with prepared statements and placeholders) makes writing code that's prone to injections more difficult to write than code which isn't.
In PHP, it's the other way round, and the language authors don't think that's a problem.

Well, I happen to disagree, rather vehemently in fact, which is why I try to encourage people to program their web sites in some other language (Python for instance), and why every single PHP-using website on my server runs in a FastCGI sandbox and has (almost) no access to the rest of the system.

[molecular]

Allright, thanks for clearing that up, man. Cause you had my hard stop for a second there.

lmao. Sorry 'baut that. No, for that very reason - that browsers store passwords in a common file - is exactly why browsers are so paranoid about preventing web scripts from interacting with the local file system. They're run in little sandboxes, and it while it's not entirely impossible to hack around those safeguards, it would take an *entirely* different set of hacks to do so, not just a "display random funny Cosbycoin/uplaoding walletdat" image randomizer to do so

No problem. It's this damn paranoia lately. Who knows? Some browser exploit, whatever...

I happy I made you laugh, though. Much needed in these forums nowaday

[error]

This mess. ultimately, is the PHP language authors' fault. They seem to argue that securing your scripts (and not just from SQL injections) is the programmer's problem.
A properly designed SQL interface (with prepared statements and placeholders) makes writing code that's prone to injections more difficult to write than code which isn't.
In PHP, it's the other way round, and the language authors don't think that's a problem.

PHP has this...now. The old insecure way is "deprecated" which means because so many billions of lines of deployed code depend on it, it'll be forever before it gets removed.