The Stack Overflow podcast is back! Listen to an interview with our new CEO.

Hot answers tagged

203

This approach is fundamentally flawed. Anything on the client side can and will be tampered with by players. It is the same problem which makes DRM untenable - the user owns the machine and all the data on it, including your executables, data in memory, etc. Keeping algorithms secret doesn't work (see Kerckhoffs's principle) because it only takes a small ...


138

Of course you can start small and implement your own algorithms. But do not assume they provide any security beyond obfuscation. The difficult thing when it comes to cryptography is finding reasons why something actually is secure. You won't be able to decide that within months and if you feel like you are at that point, you are most probably wrong. It is ...


85

What you do really is hashing: you built a hashing function out of a block cipher. Incidentally, "encryption of a known value with the password as key" is how the traditional DES-based crypt scheme for Unix was designed. On the plus side, your construction includes the user name, which partially provides the effect of a salt: parallel cracking is ...


54

There are two ways you can save authentication information in the browser: Cookies HTML5 Web Storage In each case, you have to trust that browsers are implemented correctly, and that Website A can't somehow access the authentication information for Website B. In that sense, both storage mechanisms are equally secure. Problems can arise in terms of how you ...


49

The .NET Core team specifically recommends against using SecureString for new development. See the SecureString documentation: We don't recommend that you use the SecureString class for new development. For more information, see SecureString shouldn't be used on GitHub. as well as the team's reasoning on GitHub: Motivation The purpose of ...


45

The problem with client sided Obfuscation/Protection is that the attacker will always win. Your code runs on his PC so he can intercept and manipulate everything in the end. In the specific case of .NET it might make sense to apply basic obfuscation to remove function names for example but free tools are perfectly fine for that. To answer your question a ...


40

There are three problems here: What you're trying to do is fundamentally misguided in several ways, as described in Polynomial's answer. If you insist on doing it anyway, then you're not even using the right primitive! Authenticating messages requires a MAC, not a hash. It's possible to build a MAC out of a hash -- this is what HMAC does -- but it's not as ...


38

I propose the following four step program, where you first pick the low hanging fruit to give you some minimum of protection while you work on the bigger problems. 1. Activate client side filtering 1.1 Set the X-XSS-Protection header Setting the following HTTP response header will turn on the browsers built in XSS protection: X-XSS-Protection: 1; mode=...


37

Coursera Here's my 2 cents: Join the Coursera Cryptography online class: Coursera: Stanford University, Professor Dan Boneh, Cryptography I The class takes six weeks. Each week there are several lecture videos, a graded quiz and an optional programming assignment. (And these assignments involve implementing crypto parts.) At the end of the six weeks ...


34

Using SecureString correctly is difficult, and protects against a threat surface that is unlikely for most use cases. As you say, if an attacker can read your memory, you have other problems. I would advise to use normal strings instead of SecureString, unless you are worried by attackers carrying liquid nitrogen with physical access to your server. If you ...


27

Edit: To clarify, I can't speak to the security of your approach, only the hash portion. There are some strong comments here discouraging your approach. (i.e. a good hash can be part of a secure approach or an insecure approach, just like a good lock can be used on either a good door/frame, or a flimsy door/frame) In response to your TL;DR I can say quite ...


24

Rfc2898DeriveBytes implements the standard algorithm known as PBKDF2 and defined in RFC 2898 (hence the name). That algorithm uses a configurable underlying pseudorandom function, which is usually HMAC, and HMAC itself relies on a configurable underlying hash function, usually SHA-1. While all of this is configurable, a given implementation might not be as ...


21

Start by breaking, not building your own. There's a worrisomely large number of stackexchange posts by people who've written their own algorithms. Take a look around and figure out what's wrong with them. (Don't look at the posted answers.) [Good searches include "Is this secure" and "whats wrong with this algorithm".] Only when you've found issues in ...


19

At least one thing you can improve rather easily: You can simply store the IV in the database next to the encrypted data. The IV itself is not supposed to be secret. It usually acts as a salt, to avoid a situation where two identical plaintext records get encrypted into identical ciphertext. Storing the IV in the database for each row will eliminate the ...


18

MD4 and MD5 are not encryption algorithms. They are one-way hash function designed for cryptography. It is important you understand the difference. MD5 is a slightly modified version of MD4 that improves its security somewhat. Another thing that is important to understand is that neither of these function are considered safe for use in cryptography: MD4 ...


17

Kerckhoffs's principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge A wrong example: LANMAN hashes The LANMAN hashes would be hard to figure out if noone knew the algorithm, however once the algorithm was known it is now very trivial to crack. The algorithm is as follows (from wikipedia) : ...


17

Let's be clear: Obfuscation is not there to be a form of security that is subject to scrutiny. It will fall down as soon as someone actually tries to get around the obfuscation and just makes things harder on the attacker. The purpose of obfuscation is to dissuade potential attackers from getting into the system without a large amount of effort, which may ...


17

You cannot. It is unfortunate, but you cannot. Whatever is running as the client (barring some situations you are almost certainly not in involving TPM) can, if someone is sufficiently motivated, be completely understood. Someone can disassemble it, emulate it, patch it - there's virtually nothing you can do about this. What you need to do is not look at ...


16

The short answer is that PBKDF2 is considered appropriate and secure for password hashing. It is not as good as could be wished for because it can be efficiently implemented with a GPU; see this answer for some discussion (and that one for more on the subject). There are some arguable points, notably that PBKDF2 was designed to be a Key Derivation Function, ...


14

The NIST approves of PBKDF2 when hashing and storing passwords, however that is not its original intended purpose. Notably, StackExchange also uses PBKDF2 for the same purpose. Source code is available here. See this answer for a comparison between BCrypt and PBKDF2. BCrypt is the the more conventional method of storing passwords. I'm considering PBKDF2 ...


13

In a cryptographic protocol: Make every authenticated message recognisable: no two messages should look the same A generalisation/variant of: Be careful when concatenating multiple strings, before hashing. Don't reuse keys. Don't reuse nonces. During a run of cryptographic protocol many messages that cannot be counterfeited without a secret (key or nonce)...


13

Bruce Schneier's Applied Cryptography is a must read if you want to start studying this field. I am surprised that nobody suggested it before. And yes, you need to know a lot about crypto even before trying to roll your own algorithms for fun. Don't even think of using them for real-world problems, though -- there's already a lot of bad crypto around. ...


12

There is plenty of malware out there that is written in .NET, but as a C# dev I can see why many malware authors avoid it: Easy to disassemble and reverse engineer. Easy for AV to detect use of certain classes and functions. Requires .NET on the box (older XP boxes might not have it, or might only have .NET 2.0) Harder to do anti-debug tricks in .NET than ...


11

I know this is really, really late in the game, but yes, there is a specific vulnerability that pertains directly to deserialisation of untrusted data. It works in the same way that so-called "PHP Object Injection" attacks do - by abusing classes that perform actions in their finalisation and disposal stages. Consider the following class: [Serializable] ...


11

"Best" implies some gradation on a scale, which should be defined... The most commonly used asymmetric encryption algorithm is RSA. It is good enough for most purposes. RSA has some limitations, which are rather generic (i.e. which apply to most other asymmetric encryption algorithms as well): It can process only limited-size messages (with a 1024-bit RSA ...


11

The other answers already say No, "roll your own" is rarely a good password storage scheme and yours is no exception. I'd like to add: It isn't a good scheme for storing/communicating the username either. You're basically hashing. Nothing wrong with that except: You're using a function not designed as a secure hash function. Being a cipher it's surely on ...


11

A friend of mine once made a flash game (yes it's that long ago) and used the same scheme: md5(authenticated data + secret key), then validate it on the server. I reverse engineered it with some tool and found the secret value he was using in about 30 minutes. Game over. But yeah, it's the second-best possible option. Regardless of using sha2 instead of ...


11

HashCash You could incorporate proof of work into the system: use something like HashCash to require the user to spend, say, 1 second of CPU-time to message your server. This system could be as simple as requiring the user to send a nonce with the message so that when the nonce and message are hashed together, it ends with 5 0's. There will be a tradeoff: ...


10

No it's not a risk to run an earlier framework (except for 1.x), just make sure it's patched as described below. All frameworks will get free security updates as described in Mainstream and Extended Support phase. Each framework needs to have it's own service pack. (scroll to bottom of that link) To make things easier, .NET 3.5 SP1 is considered a core ...


Only top voted, non community-wiki answers of a minimum length are eligible