The privacy issue that recently showed up in Google Buzz and now makes a lot of noise, aka, the public auto-follow feature, could have been red-flagged by any guy with some focus on privacy after reading the functional specification (if there was any).

Not even one single line of code would have been required before flagging this as risky. You don't even need to be an expert, just buy and read Threat modeling on Amazon and you're done:

• Phase 1: identify assets (aka: follow lists)
• Phase 2: identify possible threats. The 'I' in the "STRIDE" threat effects tool stands for "Information Disclosure" (aka, confidentiality or privacy breach).
• Phase 3: Correlating both (assets and threats) leads to a question. "Are there possible privacy issues that may result from automatically building and publishing someone's following/followed list?"

That's it. Just asking raises the issue. This is low-cost threat modeling, this is even part of product security & privacy management. Effectively applying this process reduces reputation risks and business interruptions, protects consumers and users, anticipates legal issues and even avoids undesired PR costs.

There are dozens of well-known threats that aren't currently being addressed on social networks and ready to be exploited by some disgruntled guy. What are these companies playing at? What are they waiting for? Is there no-one in charge or just one but useless guy? Please don't tell me this all comes to simple economics such as while AdSense generates revenue, there is no need to protect users...

I came upon a very interesting reading about how passwords should be stored and hashed in a database, to which I kept disagreeing even after having read it five times.

I guess there is something I didn't understand there so I thought the best way to get an answer would be to blog my understanding of the problem, and then to invite my readers to correct me when I am wrong.

As usual, I tried asking it the fictional-story way.
read more »

Some time ago, I picked up a notebook in a bus. It was filled with personal notes, written in chronological order. Like some sort of journal. Its owner seems to be working for a big firm. He is into software testing I guess. He is also building a social networking website, like Facebook but smaller, as a personal project during his spare time. The notebook also contains notes from that project. The guy seemed to be interested in application security: he wanted his web application to be safe against most common attacks. I couldn't find why exactly, I guess there must be a reason. There is always one.

I could not find the author's name, either. So, I decided I would call him Dave. (Dave, if you read this, please contact me!)

Some parts of the journal describe Dave's thoughts about protecting user passwords in his web application. The lines below show excerpts of the notes he wrote. I added comments, where I could.
read more »

Many answers exist to that question. On a purely methodological standpoint, your choice should result from:

• the security requirements you gathered, including those extracted from internal practices (security policy) and regulatory documents;
• the current state of the art regarding cryptography (which algorithms and implementations are broken or not;
• the adversary you are up against (are you protecting data from your spouse or from the National Security Agency?);

Now, in most web development projects, developers don't have that information available. A threat analysis or security requirement document is still considered top-notch Hollywood fiction and most customers have no clue whether or not they are exposed to particular regulations regarding cryptography. In most situations, the developer choses.

Hence the modified question: "Which cryptographic algorithms can I use in web applications with high degree of assurance?"


Microsoft included a very clear list of cryptographic algorithms requirements in its the design chapter of its Security Development Lifecycle process guidance. It says as follows:

• For symmetric encryption and decryption, use AES. Use it with 128-bit or better keys.
• For asymmetric encryption, use RSA. Use it with 2048-bit or better keys.
• For digital signature, also use RSA. Use it with 2048-bit or better keys.
• For hashing operations, including message-authentication codes, use SHA-256 or better.

Conclusion? Forget TripleDES, forget MD5, forget SHA-1 and forget any encryption algorithm you've come up to by your own brain.

The Web Application Security Consortium (WASC) just released a new version of its threat classification.

The first section of the document references 34 attacks that describe how hackers may try breaking into your web application. The second section references a list of 15 weaknesses. These weaknesses describe 15 mistakes most web developers do when designing or building web applications.

While the attacks listing may consist of pure "theoretical" stuff for many web developers, I would definitely recommended reading the weakness section as it describes what should or should not be done in the code.

Definitely worth reading.

The WASC Threat Classification v2.0

Microsoft a publié mardi dernier une nouvelle version de sa méthodologie de conception et développement de logiciels sécurisés, Secure Development Lifecycle (SDL). En dehors des habituelles petites améliorations que l'éditeur appose entre chaque version du document, cette date marque une étape-clé dans la maturité de cette méthodologie en apportant enfin des réponses ciblées pour les éditeurs logiciels de petite à moyenne taille...
read more »

Je suis tombé récemment sur une liste de pièges à mettre en place dans une application web, pouvant faciliter la détection de tentatives d'intrusion.

La liste a été publiée par Johannes Ullrich, dont je recommande la lecture des publications, souvent très intéressantes dans un cadre de développement sécurisé.

Ces pièges visent, comme leur nom l'indique, à piéger les pirates (ou les internautes en devenir) souhaitant s'introduire dans votre application. L'avantage particulier de cette démarche est qu'elle offre en premier lieu des possibilités d'analyse sur la couche métier, couche devant laquelle les pare-feux applicatifs sont fréquemment impuissants. D'autres avantages seront abordés dans la conclusion.
read more »

Two interesting resources that were referenced to me yesterday.

How do I...in C#? (Security)
A list of the most frequent design and implementation scenarios met by C# developers when dealing with security.
http://msdn.microsoft.com/en-us/library/ms186212.aspx


Patterns & Practices security checklists for Dotnet development
A large list of useful specialized and security-focused checklists, organized by framework version (mostly 1.1 and 2.0, but still applies to 3.x) and activities (architecture & design, implementation, code analysis and review).

I've found the .Net Framework 2.0 security checklist and the ASP.Net 2.0 security checklist particularly interesting.

Although these lists where built some time ago, they still constitute a good start if you are involved in application security assessment activities and don't know where to begin with.

http://msdn.microsoft.com/en-us/library/ms998392.aspx

I am preparing a course on secure development and I would like the first slide to describe the idea in one sentence, that software developers can understand without knowledge of typical security words.

Well...it's damn hard!

Here is my current result:

Secure software development:
"Designing and implementing software that both satisfies legitimate privacy expectations, that were not explicitly expressed by the people described in the data or by the customer, and resists unacceptable hostile behavior such as attacks and fraudulent use."

This definition includes several aspects such as:

• the existence of a separated and structured design and implementation process;
• the existence of legitimate privacy expectations from people that do not interact with us when we are gathering requirements but whose data will be stored, transmitted or processed.
• the resistance to threats resulting from hostile behavior, such as attacking the software directly, using it as an attack vector or simply using it for fraudulent activity;
• the concept of "acceptable" hostility, which represents the idea of an accepted risk and defines which attacks and fraudulent use should the software be protected from;

It's still "under construction" so, if you spot something better, I may be interested.



PS: If you're into secure development, I recommend you the reading of David Rook's Epicenter2009 slides.
PS2: I am back to work. If you never tried surfing (not the web, actually), well, I recommend it ;)

Greg Laden at the airport. Well...just read it. :)