With and option to disable this behavior from the HTML websites could chose to disable it on forms which might contain sensitive data. Browsers could even disable it by default and let the websites enable using an attribute.
I think anothermachine meant it should be default behavior in browsers. I agree, with the attribute to disable or enable this from the html it would be a nice feature for browsers to implement.
Not unless you manage to forge a certificate at the same time. It has been done before, as SSL is based on more or less the same level of trust as BGP.
Maybe you can't read the data in the packets, but HTTPS doesn't do a thing about SIGINT (signals intelligence) which, on such a large scale, could give you a lot of valuable information.
Whatsapp, ebuddy pro, ebuddy XMS, Angry Birds, Angry Birds Space, FML, XKCD, Facebook, Spotify, BBC News, Dropbox, Steam and PokerStars are the more popular ones official I have installed. I also have Cydia, a few tweaks and finally Installous (didn't want to admit that - I don't use it often - but thought it may spread some light here)
I run Cydia, and have determined only 16.7% of the UDIDs in that file are from jailbroken devices: I thereby do not believe that whatever managed to get this data is anywhere in our ecosystem.
The question "how many users do you have" is impossible to answer, as all I can ever demonstrate is "X users used Cydia in the last Y period". As for your second question, the information I have for your average Cydia user (one that is not actively paying me money, in which case I obviously have tons of information) is purposely highly limited: I certainly do not have, for example, the "names" of devices that was included in these dumps from AntiSec (which often discloses the name of the user), or any of the other personal details that are claimed to be in the original file.
One would not expect it to be at the average, because this information is going to have come from some popular app, and there will be high correlation between "people who have never used even a single app: they just wanted a phone" and "people who have never considered jailbreaking: they just wanted a phone"; this is even more the case once you consider that it might not be an app that "virtually everyone has": it might be an app that is either correlated with skill (you are slightly more likely to have the app, even controlling for people who have apps at all, if you are the kind of person who really cares) or negatively correlated with age (you are more likely to have the app if you are younger, which correlates better with the demographic of people who jailbreak).
Very interesting analysis. The question now is : which app/network exhibits such properties? Considering the data is recent, I suppose it eliminates big guys like Facebook/Apple. Thanks for sharing your numbers with the community.
I have Installous, so that could make this possible. However you need to jailbreak (which often involves Cydia) in order to even get access to Installous, so how about the other 84%?
(PS: I only use Installous if I need to trial an expensive app - I will buy the app if it does what I need :))
Honestly, I'm pretty sure it's Facebook. They are the ones tracking everyone, including non-FB users, via a tracking cookie the moment you visit their site after all... And you know the feds just love that data that FB can acquire.
Does it really matter that the hacker doesn't know which hash belongs to the user? He will still be able to do a dictionary attack using the same method you use to login.
Wouldn't this just make dictionary attacks easier? Now the hacker doesn't have to find one exact password but has the option to match any of his dictionary passwords to any of the password hashes.
I know that there are hardly any collisions and that in practise this wouldn't really change a thing. But in theory the dictionary attack would be faster this way.
1. The point of hashing passwords is to protect the password itself (the plaintext), so that users who use the same password over and over again (which is most of them) don't see all their accounts opened if one of the services they use has a security breach.
2. Collisions are not actually very likely (understatemeeeent)
3. > He will still be able to do a dictionary attack using the same method you use to login.
Sure, but that's not the point. The point is that validating a hash now requires a lookup into terabytes of data, meaning it's much harder to use ASICs or GPUs to brute-force the site, and the validation may even require hitting disk which is extremely expensive compared to even expensive hashings.
4. It also makes retrieving the data that much harder: a users table is not usually big and noticeable (especially just 3 columns thereof), a terabyte+ of data going out might show up on the network stats.
Note that I'm no cryptographer and do not recommend TFA's scheme as I can't judge one way or the other, but your objections don't hold as far as I can see.
Side-note (and weakness) for 4: on the other hand the retrieval is trivially shardable and parallelizable, so at the end of the day you probably don't gain much: the data from the GPU/ASIC hash-computer is fed into a sharded db server for matching against the hash data, it will have a cost impact but depending on the cost of the hashing function itself it may not even increase the overall operation time.
