Category Archives: Security

The older, the more security concerned

Posted on by
Reply

This is the conclusion of a study performed by Dimensional Research for ZoneAlarm (a division of Check Point).   For memory, ZoneAlarm offers a free Antivirus and Firewall, as well as two paid security suites.

The result is not surprising.  One of the questions requested to rate relative importance of computer related activities between Community, Entertainment, Information, Productivity, and Security.  Following picture summarizes the rating.

Without surprise, for younger generations, the computer is mainly used for entertainment and community (40% compared to the 8% of the baby boomers).    Security and privacy will be sacrificed if they interfere with the access to community.   This is normal in view of the addictive behavior related to social networking.   I would guess that this trend will grow the pyramid of ages as more and more people will be enrolled in social networking (Facebook has more than 1 billion accounts, whereas Twitter has more than 500 millions).

Interestingly, Gen Y (18-25 years) believes to be more knowledgeable about security than baby boomers (63% versus 59%) but suffered of more security incidents in the last two years.   This most probably comes from different activities and larger exposition to risk by  more risky sites.

And without a surprise, the cost of security is one excuse for not implementing security solutions.   Which highlights that some vendors such as ZoneAlarm, or Avast do not a good work on communication as they all offer free versions of their tools.  Trans generational, half of the respondent estimated that security should be free.

Lessons:

  • Ideal security should be transparent for users (price, and ease of use).  It must not impair the user experience.
  • Expect many more attacks on social networks in the future.  Many people will not sacrifice their community for a more secure environment.   This is usual for addiction.

 

Yahoo private key in the field

Posted on by
1

End of May, Yahoo issued new browser AXIS and its extensions for Chrome and Firefox.  As usual, the extensions were signed.  Unfortunately, Yahoo made a mistake.  On 23rd May, security researcher Nik Cubrilovic disclosed that the private key used to sign the applet was present in the applet!

Private keys should never be published.  They are the secret part and the root of trust.  You sign the applet with your private key to prove that you’re the originator.  Any principal who has your public key can check whether the signature is valid.  Thus, you should never disclose your private key.  If an attacker has your private key, she can impersonate you.  This means that, with the Yahoo private key, you can sign any piece of software and pretend it to be issued by Yahoo.  A perfect tool for malicious applets!

Yahoo quickly released a new version using a different signing key and published the corresponding certificate.  Yahoo will revoke the leaked key.

It is difficult to understand how such a mistake could happen.  There are at least two errors:

  • The developer(s) who wrote the applet was not understanding what a signature is.  There is no rationale why a private key should be in the code.
  • The signing private key was available in the clear to developer.  Good practice is to have the private key in a hardware secure module (HSM), such as a smart card. The module performs the signature thus the private key does never leave the module.

Law 6:  You are the weakest link.  Once more, a human error.

LinkedIn password leak

Posted on by
1

OK, now everybody should be aware that about 6.5 millions hashed passwords did leak out from LinkedIn.   On 6th June, the information was starting to buzz around.   The same day, LinkedIn confirmed that some of the alleged leaked passwords were real.  Soon the leak was confirmed and LinkedIn requested the compromised users to change their password.  I was among the happy compromised users.

What is the problem.   You never store passwords in the clear on the computer.  In fact, the good practice is to store the hashed password rather than the password itself.

 hashedPassword=Hash(password)

To test the validity of the password you check whether the hash of the proposed password fits the stored, hashed password.  The hash is the result of a one way function (SHA1 and MD5) are examples of such one way function).  It is extremely difficult (not anymore impossible in the case of SHA1) to create a valid entry of a one way function that matches a given hash value.  In other words, having a hashed password, it is extremely difficult to guess a valid password matching this hashed password.

Then, we are safe.  No.  Where is the problem?   It comes from rainbow tables.  Rainbow tables are huge precomputed values for a given known hash function.  Ophcrack is such an example of rainbow tables.  If the password is part of this dictionary, then it is extremely fast to find it.

Indeed, the good security practice for storing password is to use salted hash.  A salted hash is a one way function that uses an additional “secret” value called the salt.  In that case, usual rainbow tables do not anymore work.

hashedPassword=Hash(password + salt)

Unfortunately, it seems that LinkedIn did not use salted password.

Lesson: Use always the best practice in security.  If we are using so many tricks, it is often because there are good reasons.  Often the result of a lesson coming from a hack.

Secure Data Management 2012

Posted on by
Reply

The ninth workshop on secure data management (SDM’12) has extended its submission deadline to June 1, 2012.

The topics of interest are:

  • Secure Data Management
  • Database Security
  • Data Anonymization/Pseudonymization
  • Data Hiding
  • Metadata and Security
  • XML Security
  • Authorization and Access Control
  • Data Integrity
  • Privacy Preserving Data Mining
  • Statistical Database Security
  • Control of Data Disclosure
  • Private Information Retrieval
  • Secure Stream Processing
  • Secure Auditing
  • Data Retention
  • Search on Encrypted Data
  • Digital and Enterprise Rights Management
  • Multimedia Security and Privacy
  • Private Authentication
  • Identity Management
  • Privacy Enhancing Technologies
  • Security and Semantic Web
  • Security and Privacy in Ubiquitous Computing
  • Security and Privacy of Health Data
  • Web Service Security
  • Trust Management
  • Policy Management
  • Applied Cryptography

PST 2012

Posted on by
Reply

Usually, I do not make advertisement for conference and call for papers.  But for Privacy Security & Trust 2012 (PST 2012), I will make an exception.  If you go on the site, you will understand easily why  :Wink:

The preferred topics are:

  • Privacy Preserving / Enhancing Technologies
  • Critical Infrastructure Protection
    Network and Wireless Security
    Operating Systems Security
    Intrusion Detection Technologies
    Secure Software Development and Architecture
    PST Challenges in e-Services, e.g. e-Health, e-Government, e-Commerce
    Network Enabled Operations
    Digital forensics
    Information Filtering, Data Mining and Knowledge from Data
    National Security and Public Safety
    Security Metrics
    Recommendation, Reputation and Delivery Technologies
    Continuous Authentication
    Trust Technologies, Technologies for Building Trust in e-Business Strategy
    Observations of PST in Practice, Society, Policy and Legislation
    Digital Rights Management
    Identity and Trust management
    PST and Cloud Computing
    Human Computer Interaction and PST
    Implications of, and Technologies for, Lawful Surveillance
    Biometrics, National ID Cards, Identity Theft
    PST and Web Services / SOA
    Privacy, Traceability, and Anonymity
    Trust and Reputation in Self-Organizing Environments
    Anonymity and Privacy vs. Accountability
    Access Control and Capability Delegation
    Representations and Formalizations of Trust in Electronic and Physical Social Systems

The submission deadline is 18 March 2012.

Sony once more under fire, but proper reaction

Posted on by
Reply

Philip Reitinger, CISO of Sony, has announced that about 93,000 accounts on Sony’s systems have been compromised.  They monitored a suspect massive set of trials of login/passwords.  Most of them were unsuccessful, but about 93,000 succeeded.  Most probably, the attackers get access to a database of plugin/passwords of another web site (such information is available on the Darknet).

Some people use the same login/password for different sites.  These persons may be the victims of this attack.

We must congratulate Sony for its reaction:

  • Transparency;  they were clear on what happened, and provided the data.  The reaction of customers was extremely positive
  • Monitoring:  this proves that Sony is carefully monitoring activities to detect strange behaviour or patterns.  This is key in security.

Lessons:

  • Customers are ready to hear the truth in case of attack.  I would even guess that they would rather be aware than listen about it once it is far too late.
  • Do not use the same password for all sites, at least not for the critical ones.

TELEX: a new path to anti-censorship

Posted on by
Reply

Usually when you want to avoid censorship on Internet, you used tools such as TOR and other anonymizing proxies.  Eric Wustrow, Scott Wolchok, Ian Goldberg, and J. Alex Halderman propose another solution: TELEX.  The idea is elegant:

  • The client software hides, using steganography, the query to a censored site in a query for a high-traffic innocent site.  As the request is hidden, the censorship should not detect it.
  • Stations outside of the frontier of the censoring state, within collaborating routers, will extract the hidden query and route it to the censored site.  For that purpose, they will use Deep Packet Inspection (DPI).
  • The censored site and the client enter into a secure channel, thus avoiding the censor to analyze the exchanged data.
  • The collaborating router “impersonates” the innocent site in traffic to avoid detection.

The paper presents a nice threat analysis explaining all the trade-offs to remain stealthy, the strategy that optimally locates the collaborating stations, and how to ideally select the “innocent” site.   It is an excellent work that was presented at Usenix 2011.

The main issue is of course to find collaborating routers.  This would require either collaborating NSPs or state-funded infrastructure.  This is most probably the trickiest part to solve.  An utopia?

Alex Halderman, the last author, is well known by the medias.   He is the one (at that time he used John A) who in 2002 demonstrated the weakness of Sony anti-rip solution (shift key), or more recently how to retrieve keys after a cold boot.