• Fur Affinity Forums are governed by Fur Affinity's Rules and Policies. Links and additional information can be accessed in the Site Information Forum.

5/17 Site Attack

Status
Not open for further replies.
xTwilightStarx

xTwilightStarx

A polished turd.
I'd assume there was some kind of hole in the exploited server that allowed the hacker to access further data.
I mean, that data is linked to the users themselves, so I could see it being possible.
But hey, I don't actually know anything about this stuff, so I could be very wrong.
 
Samandriel Morningstar

Samandriel Morningstar

The Morningstar
Snow Sailor said:
Didn't they say that there were a week's worth of new users and content removed? That implies that there was user data stored on the exploited server. Maybe I misread something; if I did please correct me.
Click to expand...

As said by Dragoneer:

This attack targeted the site’s database by deleting user information, submissions, and watches. It was stopped before any further damage could be done. Other information such as journals, notes, passwords, and personal information was not affected. We're currently in the process of doing a security audit on the existing code and closing any loopholes which may be accessible from the source code.

We are also working to restore the deleted data. Our most recent full backup is from May 11, so approximately 6 days worth of new user registrations, account watches, and new submissions have been lost due to the attack. We are still trying to evaluate the scope of the attack.
 
Snow Sailor

Snow Sailor

New Member
Samandriel Morningstar said:
As said by Dragoneer:

This attack targeted the site’s database by deleting user information, submissions, and watches. It was stopped before any further damage could be done. Other information such as journals, notes, passwords, and personal information was not affected. We're currently in the process of doing a security audit on the existing code and closing any loopholes which may be accessible from the source code.

We are also working to restore the deleted data. Our most recent full backup is from May 11, so approximately 6 days worth of new user registrations, account watches, and new submissions have been lost due to the attack. We are still trying to evaluate the scope of the attack.
Click to expand...

Ah I see. So they are just restoring a backup from 6 days prior even though the data was not deleted. Thanks for the clarification. It is still strange how he says that user information was attacked, yet nothing important was deleted. Sounds like a strange setup they have =P
 
Samandriel Morningstar

Samandriel Morningstar

The Morningstar
Snow Sailor said:
Ah I see. So they are just restoring a backup from 6 days prior even though the data was not deleted. Thanks for the clarification. It is still strange how he says that user information was attacked, yet nothing important was deleted. Sounds like a strange setup they have =P
Click to expand...

No problem,I guess we'll all see what the real turn out is once the page is back up.
 
A

Anakhet

New Member
supersonicbros23 said:
Like a little pat-down at the door? That'd be difficult, those things are so easy to disguise, there are soooooooo many novelty ones...
2012119112424635.jpg
this is actually a 2GB jump drive
Click to expand...

Something else to point out. Many vendors use flash drives at events! I attended one that everyone who bought a ticket got one with like 20 short stories uploaded onto it as swag. I've picked up a few walking around from vendors with their website printed on it. I bring one when I'm working that has my inventory on it in case my tablet has a malfunction and the file is lost on there. My husband carries one every day with records on it. My mom has one on her keys with medical info as a modern Vile of Life. So not allowing drives into cons because of something like this is just nuts.
 
C

CreideikiStormbringer

New Member
Snow Sailor said:
I do development and things like this interest me, so I was just hoping one of the developers or staff members would be able to fill us in. Feels like if the exploiters had access to the database, they also had access to user passwords. Even if they were hashed, there is still the potential that they were hashed with an algorithm like sha1 or md5, which are meant to be very fast and mainly used for verification of file contents. It's not hard to put a bunch of hashes into some brute forcing software and get a few weak ones within a minute or two. So I think it would be a good idea to change your password.
Click to expand...
Straight hashes by themselves are a stupendously bad idea. Only thing worse than storing the passwords as a simple hash is storing them in the clear. (Also bad idea: Encrypting the passwords. Because that's like storing them in the clear, but you get a false sense of security out of it.)

The correct way of storing user passwords is with a specific password algorithm like scrypt or bcrypt which of course also mean that user passwords are stored with a salt. Which are specifically designed to be hard to parallelize, and to require longer compute times. Your next best choice is to use good ol' PBKDF2 introduced back in PKCS #5 v2.0; which is an iterative process involving an HMAC (the standard being HMAC-SHA1) iterated a huge number of times, which are increased as time goes on (Apple iOS 4 runs 10000 iterations, while server-side hashing for LastPass is 100000 iterations). A "salt" is a random number stored alongside the password in the clear, which is concatenated with the password before the password is hashed. That way you can't use a rainbow table to find hashes of common passwords (you'd need to recalculate the rainbow table for each salt).

Of course there's much better methods of login and authentication than passwords, but the average user has no idea what a public/private keypair is, or how they work.


I'm a crypto nerd, ask me anything.
 
AsheSkyler

AsheSkyler

Feathered Jester
There might have been a week's worth of submissions and watches lost, but imagine the opportunity of gaining all new watches and faves when you re-upload your past week's stuff! Amidst the restoration stampede of the other folks repairing their galleries when not recording their notes. XD
 
supersonicbros23

supersonicbros23

Appearance: unoriginal; Personality: out to lunch
Its not hollywood quality but I managed to kill an hour making it. Here's going to be my first submission (probably to scraps) once all this blows over. (don't worry its thread-relevant)
 

Attachments

  • FAWNE1.png
    FAWNE1.png
    645.9 KB · Views: 211
ZX6R

ZX6R

Member
Snow Sailor said:
Didn't they say that there were a week's worth of new users and content removed? That implies that there was user data stored on the exploited server. Maybe I misread something; if I did please correct me.
Click to expand...
I don't know where I was going with that to be honest.
 
F

Fordoxia

Member
CreideikiStormbringer said:
Straight hashes by themselves are a stupendously bad idea. Only thing worse than storing the passwords as a simple hash is storing them in the clear. (Also bad idea: Encrypting the passwords. Because that's like storing them in the clear, but you get a false sense of security out of it.)

The correct way of storing user passwords is with a specific password algorithm like scrypt or bcrypt which of course also mean that user passwords are stored with a salt. Which are specifically designed to be hard to parallelize, and to require longer compute times. Your next best choice is to use good ol' PBKDF2 introduced back in PKCS #5 v2.0; which is an iterative process involving an HMAC (the standard being HMAC-SHA1) iterated a huge number of times, which are increased as time goes on (Apple iOS 4 runs 10000 iterations, while server-side hashing for LastPass is 100000 iterations). A "salt" is a random number stored alongside the password in the clear, which is concatenated with the password before the password is hashed. That way you can't use a rainbow table to find hashes of common passwords (you'd need to recalculate the rainbow table for each salt).

Of course there's much better methods of login and authentication than passwords, but the average user has no idea what a public/private keypair is, or how they work.


I'm a crypto nerd, ask me anything.
Click to expand...
Yay! I love cryptography.

Also, P/P key pair is a yes.
 
F

Fordoxia

Member
Also, to the people talking about doing their own backups:

Don't just put it on your HDD or an external drive. Have at least 3 different storage mediums as backups (with at least one being offsite). This basically guarantees that you will never loose your stuff.

HDD + Cloud Storage + Ex Drive + Archive = F**kn SORTED!

(Keeping in mind that some cloud storage services take their own backups of your stuff according to this principle)
 
Snow Sailor

Snow Sailor

New Member
CreideikiStormbringer said:
Straight hashes by themselves are a stupendously bad idea. Only thing worse than storing the passwords as a simple hash is storing them in the clear. (Also bad idea: Encrypting the passwords. Because that's like storing them in the clear, but you get a false sense of security out of it.)

The correct way of storing user passwords is with a specific password algorithm like scrypt or bcrypt which of course also mean that user passwords are stored with a salt. Which are specifically designed to be hard to parallelize, and to require longer compute times. Your next best choice is to use good ol' PBKDF2 introduced back in PKCS #5 v2.0; which is an iterative process involving an HMAC (the standard being HMAC-SHA1) iterated a huge number of times, which are increased as time goes on (Apple iOS 4 runs 10000 iterations, while server-side hashing for LastPass is 100000 iterations). A "salt" is a random number stored alongside the password in the clear, which is concatenated with the password before the password is hashed. That way you can't use a rainbow table to find hashes of common passwords (you'd need to recalculate the rainbow table for each salt).

Of course there's much better methods of login and authentication than passwords, but the average user has no idea what a public/private keypair is, or how they work.


I'm a crypto nerd, ask me anything.
Click to expand...
Yeah I understand that just a plain old hash isn't the best way to store passwords. I was just giving an example of one without any sort of hashes. Storing passwords with just hash(salt + password) is pretty common on sites, as I've seen it used over and over again. If we're talking encryption, (which is, yes, a terrible way to store user data) then PasswordStore is really neat. You use your own public GPG key to encrypt the passwords or data and then it allows you to create a git repository to store the encrypted files (not the private key though): passwordstore.org: Pass: The Standard Unix Password Manager

Not so much for site use as your own use so that you can have nice 100 character long passwords.
 
Status
Not open for further replies.
Top