News - Sony pictures loses 1,000,000 passwords

[watercooled]

Again I completely agree, which is why it's nice to see client-side encryption on any service holding private data. Unlike Dropbox for example which, although they do store data encrypted (apparently), it's server-side and they keep the keys in their own database. I mean it would be hard to keep the same functionality with client-side crypto (https access for instance) but it would be a nice option. Also, something which makes me suspicious about their encryption is, if you drag a large but likely common file into your Dropbox folder, and Ubuntu iso for instance, it syncs almost instantly which shows they are using some form of deduplication. I really don't see how that could work with good encryption, maybe they're using block-level dedup with ECB mode? In which case it's still not that secure anyway...

[peterb]

Anything remotely sensitive that I wish to store on dropbox I encrypt anyway. Trivially easy to do.

[watercooled]

Yep, but I think it's misleading to claim everything is super-secure and not accessible by anyone but you, when in theory it could be.

[Whiternoise]

Depends what the site is for, and what you've agreed to. It's probably not a good idea if, for instance, it's your bank. It may well be thee case that at the least, it's breach of contract, and puts your account at risk if they catch you doing it.

For that reason, my attitude is that if such data is optional, I don't include it. If it's mandatory, I think very carefully about whether I want whatever that site offers badly enough to give it up. And for things like phone numbers and email addresses, it's why I have "burnable" instances of both - if they get abused, I dump them.

On the other hand, there's sometimes a downside to not filling it some data. If you want help with your PC, on here, then it may ell help to have filled in profile fields. But it's optional.

But for "security" data, personally, I will not EVER provide accurate data to anyone that doesn't have a valid reason to know, like banks or the government. If a forum wants DoB, they'll get nothing or a fictional one if it's mandatory, and I never use things like my mother's maiden name, including for (or rather, especially for) sites where security matters.

It's impossible to keep all personal data personal in today's society, but I'm very selective about who I tell what. You cannot prevent risks to personal data, unless you have a hankering for being a monk in a secluded retreat, but you can minimise them.

I would hope most people are clever enough to give honest data when required (and that it was implied). However, if I need a service that asks me to provide data that I don't think it needs (say, trial software), I normally use fake information - why do they need my address?

Similarly if I need to use an email address for something not 'mission critical', I use 10 minute mail.

And of course there are situations where it would be stupid to provide fake info - if you're getting something delivered, for instance.

For 'mission critical' passwords/details it's far easier just to hide them in an innocuous place at home, such as inside a book, or whatever your poison. The odds of being burgled are relatively low, though it has happened to me, but it would have to be either a police investigation or a determined burglar to find the details. Even then it's incredibly easy to use further obfuscation - say ringing page numbers or transposing the digits, writing the number in reverse (for something like a PIN it works simply because the crook only has 3 guesses normally). An enterprising burglar might check through your library to see if you've hidden cash between the pages, but I can't see any actually reading them all to get to the honey.


http://wuala.com/ has client side encryption built in. Same limits as dropbox (for the vast majority of people 2GB is more than enough). I use Dropbox mostly because it's stupidly useful for collaborating in group projects and most people have it these days. However, for stuff like syncing my 1password file, I use Wuala, still not amazing having to share it over the web, but until I can get hold of a home server it'll do.

[watercooled]

http://wuala.com/ has client side encryption built in. Same limits as dropbox (for the vast majority of people 2GB is more than enough). I use Dropbox mostly because it's stupidly useful for collaborating in group projects and most people have it these days. However, for stuff like syncing my 1password file, I use Wuala, still not amazing having to share it over the web, but until I can get hold of a home server it'll do.

Something else I'll have to try out. I also stumbled upon yet another one called SpiderOak you may wish to try.

[Whiternoise]

Something else I'll have to try out. I also stumbled upon yet another one called SpiderOak you may wish to try.

Ah yeah, SpiderOak was the one I was looking for when I found wuala - I couldn't remember the name!

[badass]

Even hashes have their limitations, especially if you know how the hash is calculated, and have database access.

Years ago (and nor on Hexus) I ran a little check. I ran various standard passwords (like "password" and "letmein", etc) though an MD5 hash generator, and then did a database search on a fairly large forum database. The number of hits was quite shocking.

What you did there was use a very small rainbow table - a proof of concept if you like.

Salting the passwords mitigates the effectiveness of this kind of attack.

A rainbow table is more or less a dictionary of hashes. It's a great way of looking through a large database of passwords for simple ones. Salting the passwords adds security by adding some random characters to the beginning or end. It means if you use the same password in 2 locations, you get idfferent hashes. It also hugely reduces the effectiveness of a rainbow table as it'll need the be the size of the dictionary multiplied by the number of key combinations to the power of the number of characters added.

[watercooled]

Simply running the plaintext password through a hash function and storing the result is also terrible from a security standpoint and there is again no excuse for doing this. Standard practice on, say, a Linux password DB is to first add a fairly big random salt then run it through the hashing algorithm a few thousand times. Not only does the number of rounds of hashing make it harder to construct rainbow tables to a degree (if you set a custom value, since the attacker wouldn't know the number) but it greatly slows down the speed of either an exhaustive key search or rainbow table construction even if the variables are known - 1000 rounds of hashing will, in theory, make an attack take 1000 times as long.

[Petra Ceason]

I'm with you Whiternoise,

I needed to speak to a Motherboard Company to ask them how to stop their helpful (sic) MB Software from wasting my time offering me services that I didn't want at every Boot-Up. {By which most of you will have guessed which company.}

They demanded I fill out a questionnaire of personal details, before allowing me through to ask the question.

Leaving the fields blank, produced error messages, and no progress.

However, giving an address on the Moon, my birth-date somewhere in the middle of the Nineteenth Century and my favourite colour as Yesterday etc. etc. worked fine, I got through and got my question answered.

Sorry this is nearly a year on from the last post, but I've only just found it.

Regards,

Petra.