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 ...


137

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 ...


84

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 ...


66

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 ...


47

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=block ...


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 there ...


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 ...


25

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 ...


18

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, ...


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 ...


16

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 ...


15

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 ...


13

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] ...


13

"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 ...


13

Finding out that a user is using a VPN service provider isn't that difficult. Most of them have static IP addresses for their exit gateways, so it could just be using a list of known IP addresses to identify VPNs. And even when they don't have a list, a simple reverse DNS lookup might tell them that the IP has a hostname which is obviously a VPN provider and ...


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

There area a number of places that Request validation may be bypassed, depending on the architecture and function of the application under review, which is likely why Microsoft don't recommend relying on it. Data which enters the application via another channel (e.g. an API) will not be affected by request validation and so could cause XSS issues if that ...


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

The best way to protect your access token is to not store it client-side at all. How does that work? Well at the point of generating the access token, generate some other cryptographically secure PRNG (which you map to the access token on the server), map this to the users session ID and return this to the client instead. This will reduce the attack area ...


10

A good start would be to implement existing algorithms and learn how they work in depth. For example, the one-time pad algorithm is easy to learn and implement, and studying its strengths and weaknesses will get you started. It will also get you comfortable with the kind of bit-twiddling that's important in cryptography. Doing a search for "one-time pad" ...


10

Is obfuscation worth it? Yes, of course it is worth it. Any extra layer which does not interfere with another layer is always worth it. It will deter the average person and keep the majority of people, or would be script kiddies, at bay.... But Commercial tools I would say are not, as anything to advanced could actually hinder your development, using some ...


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