Notes on Security and Privacy

See also Architecture Security.

Random Thoughts Logged Here

Here are some quick thoughts on issues and ideas. Ideas are shown with >>

• people having too simple a PW so it gives away data
  • >> physical token plus remembered 
• people can't remember
  • >> physical token plus bio
  • >> physical token is something person always has with
    • ring or necklace or embedded
• bad guys tracking the log-in of a person
  • >> physical token creates rolling log in token
• person wants single log in -- with preferences too
  • >> tie a pref code to log-in --- but make pref code different than one used for non-log-in preference use (to keep anonymity for non-log in sessions)
• if single password is used -- two people could have the same password
  • have two passwords - it's very difficult to have two users with two passwords equal. But of course, the user has to remember two passwords....
    • Comment: discussion about 1 or 2 normally implicates only different length: there is no difference between a user name and a password in general. One part is only the publicly known part of the authentication token. By ensuring the uniqueness of a user name, the password is unique by definition. User chosen token always can become non-unique as long passwords tend to degrade to "realpass12345678"
  • Or you can generate a PUK based on the password (the PIN) entered by the user.
• Someone can just send in random pairs of words etc. by robot to get random hits and then peoples information
  • this called a brute force attack
  • include something to slow down a robot
    • this is only valid if the server is never hacked [1],[2]
  • include something to foil a robot (is this possible anymore)
  • include a real phone number that is called or an SMS is sent to -- that has to be entered back as part of the process
  • (and a password)
  • Phone number not associated with account but just recorded as a number that at one time asked for a password reset so that it can't be used for mass fishing expeditions.   ALSO can track number of times it was used with an invalid password or password pair to further identify robots. 
• Revocation and changing of tokens and passwords needs to be considered: This e.g. rules out basically any biometric scheme.

Some References

In chronological order:

• Rohit Ranchal et al: "An Approach for Preserving Privacy and Protecting Personally Identifiable Information in Cloud Computing" (no date).
• Marten van Dijk and Ari Juels: "On the Impossibility of Cryptography Alone for Privacy-Preserving Cloud Computing", May 2010. See also abstract in Cryptology ePrint Archive.
• Kehuan Zhang, Xiaoyong Zhou, Yangyi Chen, Xiaofeng Wang, Yaoping Ruan: "Sedic: Privacy-Aware Data Intensive Computing on Hybrid Clouds", ACM CCS 2011. Discusses techniques for privacy-aware data-intensive computing; MapReduce.
• Susan Kuchinskas: "8 Steps to a Secure Cloud Initiative", eSecurityPlanet, April 26, 2012.
• Rachel Metz: "More Passwords, More Problems", MIT Technology Review, September 21, 2012.
• Tom Simonite: "How to Steal Data from Your Neighbor in the Cloud", MIT Technology Review, November 8, 2012: about a study that used a side-channel attack to snoop on data used by another virtual machine that is running in the same cloud environment.
• WikiPedia Article on NFC - Security Section http://en.wikipedia.org/wiki/Near_field_communication#Security_aspects
• Microsoft joins group seeking to replace passwords, 13 December 2013.
• A prominent password failure because of lacking accessibility
• J.Bonneau's research on real passwords in the wild [3], [4]
• Why preference sets and plug-ins are a threat to anonymity/pseudonymity already today: https://panopticlick.eff.org/
• SMS is not secure
• Privacy enabled User Profile Portability: [5]

See Also

• ICT Ethics.
• W3C Private User Agent Community Group.

• FOAF+SSL
• WebId
• Security tokens
• Password Hasher
  • can potentially make many password input accessible and password does not become known to server
• Android token