The May 2009 issue of MSDN Magazine includes an article titled "A Conversation About Threat Modeling" that discloses a conversation between Paige, a young security neophyte, and Michael, a somewhat jaded security guy. This month I'll take up the conversation where it left off.

Scene I

A small office kitchen, next to the coffeepot.

Paige: Last time we met, you took a good look at my threat model, but you said you'd cover some cryptographic and secure design issues at a later date. Well, welcome to that later date.

Michael: Can I please get a coffee first?

Not waiting for a response, Michael pours himself a huge coffee.

Paige: Er, sure.

Michael: Remind me again what your app is.

Paige: It's a product that allows users to store data on our servers. There's a small piece of client code that pushes the bits to a server set aside for that user. This code can upload files from the user to our back end via the Web server, and the files are stored in the file system along with file metadata stored in SQL Server for rapid lookup. We might store billions of files eventually. The two major environments are domain-joined computers and Internet-joined computers.

Michael: Oh, that's right, I remember now. So much code, so little time. OK, let's go back to your threat model to see which part we're concerned about. Do you have the DFD -- the data flow diagram?

The two walk over to Paige's desk. She logs on with her smart card and loads the SDL Threat Modeling Tool.

Paige: Here it is.

Michael looks over the diagram.

Michael: This is the Level-1 diagram, right? It is one level more detailed than the context diagram?

Paige: Yup. We also have a Level-2 diagram, but I don't think we need to go that deep just yet.

Michael: You're right, this is perfect. If more precision is needed as we go through this, we can look at the Level-2 diagram.

Paige: By the way, we don't call them DFDs anymore.

Michael: Er, OK! What are they called, then?

Paige: Application diagrams.

Michael: Whatever floats your boat, I s'pose. We'll be using crayons next. OK, back to the diagram. So the user makes a request of the client application to upload or download files to or from the server, and the server persists that data in the file system at the back end, along with some metadata about the files that is held in SQL Server?

Paige: That's one use; in fact, it's probably the main scenario. Of course, the admin needs to set up, configure and monitor the application; that's what the admin tool does.

Michael: Let's focus on that core scenario, then.

Scene II

Michael is staring intently at the application diagram.

Michael: Let's start by looking at each element in the core scenario, and we'll spell out each of the STRIDE threats.

Paige: STRIDE? Remind me again.

Michael: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

Michael starts writing quickly on a piece of paper.

Michael: Take a look at this list:

Paige: Aren't all of these in the Threat Modeling Tool?

Michael: Yes, but I want to show you how the tool arrives at the list. By the way, you don't need to use the threat modeling tool to be SDL-compliant, so long as the threat model is complete and accurate. Basically, each element is subject to a specific set of threats. I think you can work it out from the list.

Paige: Yeah, I get it, but aren't you missing something? All those data flows between the various application elements?

Michael: Yup, but I did that on purpose, because I really don't want to focus on those yet -- we discussed them in detail last time.

Paige: We did?

Michael: Yes. Look at the Threat Model.

Paige looks over the SDL Threat Modeling Tool

Paige: Oh, I see, that's where we discussed using SSL/TLS to fix the tampering and information disclosure threats to the data flow between the client and server processes, right?

Michael: Good! So here's a question for you. The data that moves from the user to the server and then onto the server's file system -- is that data sensitive?

Paige: You asked that last time. Yes, it might be.

Michael: Uh-oh.

Paige: What? The data is encrypted using SSL/TLS, so we're fine, right?

Michael: Not at all. SSL/TLS mitigates the information disclosure threat to the data as it flows between the two processes -- the 2.0 Client process and the 3.0 Server process. But after the data leaves that secured tunnel, the data is in the clear, and you're writing data in the clear to the file system.

Paige: Yeah, but what's the risk?

Michael: You tell me!

Paige: I don't understand.

Michael sighs.

Michael: Let's say a client of your application is an employee of a publicly traded company. Let's be more specific: the employee is the CFO of a publicly traded company and he uses your application to store a spreadsheet that shows fiscal data for the current quarter, data that is not public and will not be public until the end of the quarter, when the company announces its earnings. Let's say a hacker breaks into your system, gets that data, and uses it to sell or buy stock in the company. That might be insider trading.

Paige: Uh-oh.

Michael: Uh-oh, indeed. This is serious. The CFO does not have appropriate controls on this sensitive data, which might be a violation of SOX regulations.

Paige: You said "might" a lot.

Michael: You bet I did. Do I look like a lawyer to you? So back to my original question. Is this situation something you care about?

Paige: Well, not really. I think our terms state that you shouldn't use our service for ultra-sensitive data. But I'll play along. Let's assume I say, "Yes, we care about this scenario." Now what?

Michael: My first bit of advice would be to consult your attorneys to make sure you're not putting the company at risk with this scenario. But let's assume they say you can go for it, but you need to be sure you protect the data at the back end.

Paige: What you're trying to say is that the data held in data store 5.0, the file system at the server, is subject to information disclosure and we need to mitigate that threat. Am I right?

Michael: You're spot on. So how do you fix it?

Paige: ACLs.

Michael: Why access control lists?

Paige: We can limit access to only valid users of the data.

Michael: So how does the server application read and write the data?

Paige: Oh, let's assume the process runs as a unique identity. We'll call it FooID. We could apply an ACL to the files that allows FooID as well as to the valid users' access to the files.

Michael: It won't work; it's not secure.

Paige: Why not?

Michael: If I'm an attacker, I can compromise the server process by running as FooID and then run my malicious code on that server. Voila, my code is running as FooID, and I own the data!

Paige looks dejected.

Paige: Humph.

Michael: You have to use encryption.

Paige: Of course! The server will just read and write encrypted blobs, and if an attacker compromises the server, he still can't get at the data unless he can break the encryption.

Paige perks up.

Michael: Now the fun really starts. We touched on some of the crypto issues last time, especially as they relate to keys.

Paige: What do you mean?

Michael: OK, how are you going to encrypt the data?

Paige: The user types in a password in the client-side application, and the client-side application encrypts the data with the password and sends the encrypted blob across the wire to the server. The server writes metadata to SQL Server and then writes the encrypted blob to the server file system.

Michael: What's in the metadata?

Paige: Owner's identity, the file size, the filename, the time it was written to the file system and last read time. That kind of stuff. I know this information is held in the file system, too, but it's way quicker to do a lookup in something designed to store this kind of data: a SQL Server database.

Michael: Good, I'm glad it doesn't store data held within the file!

Paige: Why?

Michael: For a couple of reasons. First, it would mean your server application has access to data in the clear, and to get that data requires your server process to decrypt the data.

Paige: So?

In a loud but not-quite-shouting voice, Michael responds.

Michael: Because it means your server application needs to know a decryption key, which means you get into all sorts of truly horrible key management games. If at all possible, you want to stay out of that business! There are ways you can do this cleanly by having multiple keys, but I don't want to explain that right now. If ever! If you really want to understand this, read up on how Microsoft encrypts files using the Encrypting File System, or EFS.

Paige: Could we use EFS?

Michael: Possibly. It depends on your clients. What platforms do you support at the client?

Paige: We'll ship at the end of the year on Windows and then a couple of months later on Linux.

Michael: No Solaris?

Paige: What's Solaris?

Michael sniggers and ignores Paige's reply.

Michael: You can't use EFS because it requires Windows accounts. So you have to encrypt the data using different technology. It'd be great if you could use EFS, or even Data Protection API, known as DPAPI, because both use the same underlying crypto technology and can seamlessly encrypt and decrypt data by using keys derived from the user's password. Oh well. Let's see what else we can do.

Paige: Can we use an encryption library?

Michael: Of course we can. In fact, that's a much better idea than something I heard the other day.

Paige: What?

Michael: Someone asked me if it would be OK to create his own crypto algorithm.

Paige: You said no, right?

Michael: Of course I said no. What would you expect me to say? I also made it pretty clear that it's a complete violation of SDL policy, and he should not even contemplate the possibility of using any homegrown crypto.

Paige: So what should we do?

Michael: Because your client code is C#, you could use the .NET System.Security.Cryptography namespace. It's available in Mono, which means you could call it from Linux. I haven't tried it, but you could do an experiment. You'd also need to chat with the lawyers to make sure there are no licensing issues.

Paige: What licensing issues?

Michael: It's third-party code. Who knows what the license says.Paige: OK, so we encrypt the data with the user's password, send the blob ...

Michael: No. Non. Nyet. Nada. Nope. You do not use the user's password as an encryption key; you derive the encryption key from the password. Passwords are way too easy to guess.

Paige: How does one "derive" a key?

Michael smiles.

Michael: With a key-derivation function.

Paige: Mr. Smarty. Could you be a little more precise?

Michael: Sure. You pass the key into a function such as Rfc2898DeriveBytes in .NET, along with a salt. A salt is just a unique number that makes it harder to perform certain attacks. It's an iteration count, usually in the tens if not hundreds of thousands. The function takes the password and munges it thousands of times with the salt. This is often referred to as "stretching the password." At the end of the operation, which usually takes less than a second, you get some bytes, and you can use those bytes as keys. Key derivation not only makes it hard to guess the key, it also makes it hard to mount high-speed password-guessing attacks because the attacker has to go through the iteration count, too. So if an attacker could normally test 1,000,000 passwords per second, with an iteration count of 100,000, he's reduced to 10 per second! Cool, huh?

Paige: Very cool. So we use that key to encrypt the data, using, say, Advanced Encryption Standard?

Michael: Yes. Of course, all this does is encrypt the data. It doesn't provide any form of integrity check, but that's pretty easy. You can derive another key and use that to create a message authentication code and store that along with the metadata. Don't use the same key for encryption and integrity checking. Derive a second key, and use that.

Adam, another security guy, walks by muttering.

Adam: You security wizards always want to go depth-first into crypto and the like. But the attackers go for the weak link.

Michael: Adam's right, security people tend to dig deep quickly. And I'm guilty as charged, but I want to get this out of the way.

Paige: Er, OK. Anything else?

Michael: Well, there's also the sticky problem of users forgetting their passwords. I would give users the opportunity to back up their password to a USB stick or something, and make them aware that we don't have the password and that if they forget it, there's no way we can bring the data back from the dead!

Paige: Are we done?

Michael: For the moment, yes. It's a big and important section of the threat model, and I hope this gives you an idea of some of the trade-offs you need to make when building secure applications.

Paige: I do now. Thanks.

Michael Howard is a senior security program manager at Microsoft who focuses on secure process improvement and best practices. He is the coauthor of five security books, including "Writing Secure Code for Windows Vista," "The Security Development Lifecycle," "Writing Secure Code" and "19 Deadly Sins of Software Security."

Der Ausgabe des MSDN Magazines von Mai 2009 enthält einen Artikel mit dem Titel "Eine Unterhaltung zu Threat Modeling"Erläutert eine Konversation zwischen Paige ein Neophyte Junge Sicherheit und Michael, einem Angreifer etwas jaded Sicherheit. In diesem Monat werde ich die Unterhaltung einnehmen, wo unterbrochen.

Szene ich

Eine Küche Büro neben der Coffeepot.

Paige: Letzten wir erfüllt Sie gute ansehen meiner Bedrohungsmodell dauerte, aber Sie gesagt haben Sie Probleme kryptografischen und sicheren Entwurf zu einem späteren Zeitpunkt behandeln würden. Willkommen Sie gut, bei der späteren Zeitpunkt.

Michael: Geben Sie erhältlich einen Kaffee zuerst?

Wartet nicht auf eine Antwort, gießt Michael selbst eine riesige Kaffee.

Paige: Er, dass.

Michael: Erinnern Sie erneut was Ihre Anwendung ist.

Paige: Es ist ein Produkt, das Benutzern ermöglicht, Daten auf unseren Servern zu speichern. Es gibt ein kleiner Codeabschnitt Client, die Bits an einen Server für diesen Benutzer beiseite verschiebt, der. Dieser Code kann Dateien vom Benutzer an unsere Back-End über den Webserver uploaden, und die Dateien im Dateisystem mit Dateimetadaten in SQL Server für die schnelle Suche gespeichert gespeichert sind. Schließlich können wir Milliarden von Dateien speichern. Die beiden wichtigsten Umgebungen sind Domäne beigetretenen Computer und Internet verbundenen Computern.

Michael: ACH Ja, erinnern das rechts ist, ich jetzt kann. So viel Code, so wenig Zeit. GUT, wir gehen Sie zurück zu Ihr Bedrohungsmodell, um festzustellen, welcher Teil wir besorgt sind. Haben Sie die DFD--die Datenflussdiagramm?

Die beiden gehen über Paige des Helpdesk. Er meldet sich mit Ihrer Smartcard und lädt das SDL Threat Modeling-Tool.

Paige: Hier ist es.

Michael sucht über das Diagramm.

Michael: Ist dies im Diagramm auf Ebene 1 Rechte? Ist es eine Ebene ausführlichere als Kontext-Diagramm?

Paige: Yup. Wir haben auch ein 2 Diagramm, aber ich nicht glaube, müssen wir, noch tiefer gehen.

Michael: Sie haben Recht, dies ist optimal. Wenn weitere Genauigkeit erforderlich ist, wie wir dies durchgehen, können wir-2-Diagramm betrachten.

Paige: Durch die Art Aufrufen nicht wir diese DFDs mehr.

Michael: Er OK! Was sind, dann Eingabewerten?

Paige: Anwendungsdiagrammen.

Michael: Was Ihre Bootförmig überlagert ich s'pose. Wir verwenden Buntstifte nächsten. OK wieder auf das Diagramm. Damit der Benutzer sendet eine Anforderung der Clientanwendung zum Uploaden oder Downloaden von Dateien zum oder vom Server und der Server weiterhin besteht, dass Daten in das Dateisystem auf der Rückseite, zusammen mit einige Metadaten über die Dateien beendet, die in SQL Server gespeichert werden?

Paige: Das ist eine Verwendung;in der Tat ist es wahrscheinlich das wichtigste Szenario. Natürlich muss der Administrator einrichten, konfigurieren und Überwachen der Anwendung;Das ist Was bewirkt das Administratortool.

Michael: Konzentrieren wir uns das dieses Szenario Core dann aus.

Szene II

Michael wird intently in das Anwendungsdiagramm starten.

Michael: Durch jedes Element im Kern-Szenario betrachten wir starten, und wir müssen jeweils die STRIDE-Bedrohungen ausgeschrieben.

Paige: STRIDE? Erneut erinnern.

Michael: Spoofing von, Repudiation (Nichtanerkennung), Offenlegung von Informationen, Denial-of-Service, Erhöhung von Berechtigungen.

Michael startet schreiben schnell auf ein Blatt Papier.

Michael: Betrachten Sie diese Liste:

Paige: Werden nicht alle diese im Threat Modeling-Tool?

Michael: Ja, Sie anzeigen, wie das Tool an der Liste ankommen möchten jedoch. Durch die Art müssen nicht Sie die Bedrohungsmodellierung Tool SDL-kompatibel sein verwenden, solange das Bedrohungsmodell vollständige und genaue ist. Im Wesentlichen wird jedes Element einen bestimmten Satz von Bedrohungen. Meiner Meinung nach Sie es aus der Liste arbeiten können.

Paige: Oh, mir es, aber fehlt Sie sind nicht etwas? Alle diese Datenflüsse zwischen den verschiedenen Anwendungselementen der?

Michael: Yup, aber ich habe, dass auf absichtlich ich nicht wirklich diejenigen noch--konzentrieren möchten, dass wir diese letzten erläutert.

Paige: Haben wir?

Michael: Ja. Betrachten Sie das Bedrohungsmodell.

Paige sucht über das SDL Threat Modeling-Tool

Paige: Finden Oh, ich ist wo erörtert Verwendung von SSL-TLS zur Behebung der Manipulation, Bedrohungen durch Informationsenthüllung auf die Daten zwischen den Client- und Prozessen, den richtigen fließen?

Michael: Gute! Hier ist also eine Frage für Sie. Daten, die vom Benutzer zum Server verschoben und dann auf Dateisystem des Servers--ist, dass vertrauliche Daten?

Paige: Sie gebeten, zuletzt. Ja, kann es sein.

Michael: Oh, oh.

Paige: Was? Verschlüsselt SSL/TLS verwenden, damit fein, rechts wir die Daten?

Michael: Absolut nicht. SSL-TLS verringert die die Daten Bedrohung Offenlegung von Informationen, wie es zwischen zwei Prozessen--der 2.0 Client-Prozess und 3.0 Server-Prozess fließt. Aber nachdem die Daten, die gesichert Tunnel verlässt, Daten in Klartext, und Sie Daten in Klartext in das Dateisystem schreiben.

Paige: Oh, aber was ist das Risiko?

Michael: Sie Infos!

Paige: Ich bin mir bewusst nicht.

Michael sighs.

Michael: Angenommen, ein Client der Anwendung ein Mitarbeiter von börsennotierten Unternehmen ist. Wir werden spezifischere: der Mitarbeiter ist CFO börsennotierten Unternehmen, und er die Anwendung verwendet, um eine Kalkulationstabelle zu speichern, die Geschäftsjahr Daten für das aktuelle Quartal Daten, das ist nicht öffentlich und werden nicht öffentliche bis zum Ende des Quartals anzeigt, wenn das Unternehmen seinen Gewinn kündigt. Angenommen, ein Hacker teilt in Ihrem System, ruft die Daten und zum verkaufen oder Kaufen von Aktien im Unternehmen verwendet. Die möglicherweise Insider handeln.

Paige: Oh, oh.

Michael: Oh-oh, tatsächlich. Dies ist schwerer. Die FINANZDIREKTOR muss nicht geeignete Steuerelemente auf diese vertraulichen Daten, die möglicherweise eine Verletzung des SOX-Bestimmungen.

Paige: Eingabe "möglicherweise"eine Menge.

Michael: Ich habe mit Sicherheit. Führen Sie ich ein Jurist, aussehen? So an meine ursprüngliche Frage. Ist dies etwas Sie interessieren?

Paige: Nun, eigentlich nicht. Ich glaube, unser Begriffe Zustand, unseren Dienst für ultra-sensitive Daten zu verwenden, sollten nicht. Aber ich werde zusammen spielen. Angenommen, ich sage, "Ja, wir dieses Szenario kümmern." Was nun?

Michael: Meine erste Bit Ratschläge wäre finden Sie in Ihrem Anwälte sicherstellen, dass Sie nicht das Unternehmen gefährdet bei diesem Szenario einlagern sind. Aber angenommen, Sie sagen können Sie dafür jedoch müssen Sie unbedingt, dass Sie die Daten im Back-end schützen.

Paige: Was Sie sagen möchten ist, dass die Daten im Datenspeicher, gehalten 5.0, das Dateisystem auf dem Server ist, unterliegt die Offenlegung von Informationen und wir müssen die Bedrohung minimieren. Bin ich rechts?

Michael: Sie können auf Spotfarben. So wie behoben Sie es?

Paige: ACLs.

Michael: Warum access Control Lists?

Paige: Wir können den Zugriff auf nur gültige Benutzer die Daten beschränken.

Michael: Wie der Server-Anwendung lesen und schreiben die Daten?

Paige: Oh, angenommen der Prozess als eine eindeutige Identität ausgeführt wird. Wir müssen Sie FooID aufrufen. Wir konnten Dateien, die FooID sowie als gültige Benutzer können eine ACL zuweisenZugriff auf die Dateien.

Michael: Es funktioniert; nichtEs ist nicht sicher.

Paige: Warum nicht?

Michael: Wenn ich ein Angreifer kann ich den Serverprozess gefährden, indem als FooID ausgeführt und führen Meine bösartigen Code auf dem Server. Voila, mein Code als FooID ausgeführt wird und ich besitze die Daten!

Paige sucht dejected.

Paige: Humph.

Michael: Müssen Sie die Verschlüsselung verwenden.

Paige: Natürlich! Der Server wird nur lesen und Schreiben verschlüsselte Blobs, und wenn ein Angreifer den Server gefährdet, er noch nicht mehr auf die Daten, sofern er die Verschlüsselung aufheben kann.

Paige perks einrichten.

Michael: Jetzt startet wirklich den Spaß. Wir berührt einiger Crypto Probleme im letzten besonders als Schlüssel Zusammenhang.

Paige: Was bedeuten Sie?

Michael: OK, wie Sie beabsichtigen, die Daten verschlüsselt?

Paige: Der Benutzereingabe in einem Kennwort in die clientseitige Anwendung und die clientseitige Anwendung verschlüsselt die Daten mit dem Kennwort, und sendet das verschlüsselte Blob über das Kabel an den Server. Der Server schreibt Metadaten in SQL Server und schreibt dann in das Dateisystem Server das verschlüsselte Blob.

Michael: Was ist in den Metadaten?

Paige: Des Besitzers Identität, die Dateigröße, den Dateinamen, die Zeit in das Dateisystem geschrieben und letzten Mal gelesen wurde. Diese Art von Dingen. Diese Informationen auch im Dateisystem, gehalten wird weiß aber Weise schneller, dazu einen Lookup in etwas entwickelt, um diese Art von Daten zu speichern: eine SQL Server-Datenbank.

Michael: Gut, bin ich froh, dass es innerhalb der Datei gehalten Datenspeicher nicht!

Paige: Warum?

Michael: Für eine Reihe von Gründen. Es würde zunächst bedeuten die Serveranwendung hat Zugriff auf Daten in Klartext und zum Abrufen der Daten erfordert des Serverprozess zum Entschlüsseln der Daten.

Paige: So?

In einer Stimme laut jedoch nicht ganz Shouting reagiert Michael.

Michael: Denn es bedeutet, die Serveranwendung dass muss einen Entschlüsselungsschlüssel wissen, was bedeutet, Sie erhalten in allen möglichen wirklich horrible Schlüsselverwaltung Spiele. Wenn möglich, möchten Sie dieses Unternehmen zu bleiben! Es gibt Möglichkeiten Sie dies problemlos tun können, indem Sie mehrere Schlüssel, aber ich möchte, jetzt erläutern. Wenn überhaupt! Wenn Sie dies zu verstehen möchten, bis zum Lesen Sie auf wie Microsoft Dateien mithilfe von Encrypting File System oder EFS verschlüsselt.

Paige: Können wir die EFS verwenden?

Michael: Möglicherweise. Das hängt von Ihren Clients. Welche Plattformen unterstützen Sie auf dem Client?

Paige: Wir werden am Ende des Jahres auf Windows und wenige Monate später auf Linux liefern.

Michael: Keine Solaris?

Paige: Was ist Solaris?

Michael sniggers und Paige des Antwort ignoriert.

Michael: Sie können EFS nicht verwenden, da Windows-Konten erforderlich sind. So haben Sie Verschlüsseln der Daten mit anderen Technologie. Es würden hervorragende sein, wenn könnten Sie EFS oder sogar Datenschutz-API, DPAPI, genannt, da beide verwenden die gleiche zugrunde liegenden Crypto-Technologie und kann nahtlos verschlüsseln und Entschlüsseln von Daten mithilfe von Tasten das Kennwort des Benutzers abgeleitet. Oh gut. Sehen Sie, was wir tun können.

Paige: Verwenden wir können eine Verschlüsselung Bibliothek?

Michael: Selbstverständlich. In der Tat ist eine viel bessere Vorstellung als etwas ich anderen Tag gehört.

Paige: Was?

Michael: Jemand gefragt mich Wenn Sie OK, um seinen eigenen kryptografischen Algorithmus zu erstellen würde.

Paige: Haben Sie gesagt keine Rechte?

Michael: Ich sagte natürlich keine. Was würden Sie mir sagen erwarten? Ich war es auch ziemlich löschen, es eine vollständige Verletzung der SDL-Richtlinie ist, und er sollte die Möglichkeit, alle eigenen Crypto selbst nicht contemplate.

Paige: So sollten was wir tun?

Michael: Da Ihr Clientcode c# ist, können Sie .NET System.Security.Cryptography-Namespace verwenden. Es ist verfügbar in Mono, d. h., Sie ihn von Linux aufrufen konnte. Noch nicht haben Sie versucht, jedoch Sie könnten dazu eine experimentieren. Sie müssten mit Rechtsanwälte sicherstellen, dass es sind keine Lizenzierungsprobleme chatten.

Paige: Welche Lizenzierung Probleme?

Michael: Es ist Code von Drittanbietern. Welche der Lizenz says.Paige kennt: OK, damit wir die Daten mit dem Benutzerkennwort verschlüsselt das Blob senden...

Michael: Nein. Nicht. Nyet. Nada. Nope. Das Kennwort des Benutzers verwenden als einen Verschlüsselungsschlüssel; Sie nichtSie ableiten der Schlüssel vom Kennwort. Kennwörter sind leicht zu erraten.

Paige: Wie wird eine "abgeleitet „ein Schlüssel?

Michael Smiles.

Michael: Mit einer Schlüssel-Ableitung-Funktion.

Paige: MR. Smarty. Konnten Sie ein wenig genauer sein?

Michael: Bestimmt. Sie übergeben den Schlüssel in einer Funktion wie Rfc2898DeriveBytes in .NET zusammen mit einer Salt. Eine Salt ist nur eine eindeutige Zahl, die es schwieriger zu bestimmter Angriffe durchführen. Es ist eine Iterationsanzahl normalerweise in der Dutzende, wenn nicht Hunderte oder Tausende. Die Funktion übernimmt das Kennwort und Munges es Tausende von Zeitangaben mit der Salt-Wert. Dies ist häufig bezeichnet als "Strecken das Kennwort." Am Ende der Operation in der Regel weniger als eine Sekunde dauert Sie erhalten einige Bytes und Sie können diese Bytes als Schlüssel verwenden. Schlüsselableitung nicht nur macht es schwer zu erraten des Schlüssels, dies auch macht es schwierig, schnelle Erraten von Kennwörtern Angriffe bereitstellen, da der Angreifer hat die Iterationsanzahl zu durchlaufen. Also Wenn Angreifer normalerweise pro Sekunde mit eine Iterationsanzahl 100.000, 1.000.000 Kennwörter testen konnte ist er auf 10 pro Sekunde reduziert! Cool, nicht wahr?

Paige: Sehr gut. So verwenden wir den Schlüssel, um die Verschlüsselung der Daten verwenden, z. B. Advanced Encryption Standard?

Michael: Ja. Natürlich, verschlüsseln all diese unterstützt werden die Daten. Es nicht einer beliebigen Form der Integritätsprüfung bereit, jedoch das ist ziemlich einfach. Sie können einen anderen Schlüssel ableiten und, einen Nachrichtenauthentifizierungscode erstellen und speichern, die zusammen mit den Metadaten verwenden. Verwenden Sie nicht den gleichen Schlüssel für Verschlüsselung und Integrität zu überprüfen. Leiten Sie eine zweite Taste, und verwenden.

ADAM anderen Sicherheit Angreifer führt von muttering.

ADAM: Sicherheit Assistenten soll immer Tiefe-zuerst in Crypto und ähnliches gehen. Doch die Angreifer für die schwache Verknüpfung.

Michael: ADAM ist richtig, Sicherheit Personen in der Regel sehr schnell untersuchen. Und ich bin guilty wie belastet, aber dies aus die Möglichkeit erhalten soll.

Paige: Er OK. Alles?

Michael: Gut, ist auch das Kurznotiz Problem der Benutzer ihre Kennwörter vergessen. Ich würde Benutzern die Möglichkeit, Sichern Sie Ihr Kennwort auf ein USB-Stick oder etwas und machen beachten, dass wir das Kennwort besitzen und, wenn Sie es vergessen haben, es gibt keine Möglichkeit wir die Daten übertragen von der Dead zurück!

Paige: Ist unsere Arbeit abgeschlossen?

Michael: Für den Moment Ja. Es ist ein Groß und wichtige Teil des Bedrohungsmodells, und ich hoffe, Sie eine Vorstellung davon einige Kompromisse dadurch Sie beim Erstellen von sicherer Anwendungen müssen.

Paige: Ich tun jetzt. Danke.

Michael Howard ist senior Security Programmmanager bei Microsoft, auf die Prozesssicherheit sowie auf Empfehlungen konzentriert. Er ist Mitautor von fünf Sicherheit Bücher, einschließlich "Writing Secure Code for Windows Vista""Des Sicherheitsentwicklungszyklus""Writing Secure Code"und "19 Deadly Sins of Software Security."