Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

While talking with one of my coworkers, he was talking about the issues the language we used had with encryption/decryption and said that a developer should always salt their own hashes. Another example I can think of is the mysql_real_escape_string in PHP that programmers use to sanitize input data. I've heard many times that a developer should sanitize the data themselves.

My question is what things should a developer always do on their own, for whatever reason, and not rely on the standard libraries packaged with a language for it?

share|improve this question
4  
Depends on the language, task and programmer. –  superM Jun 29 '12 at 18:25
2  
Developers should never attempt to sanitize values to be interpolated into SQL statements. It just annoys the users without improving security. Use prepared statements. –  kevin cline Jun 29 '12 at 19:11
    
@kevincline +1. Use well-tested methods, especially when security is a concern. No need to reinvent (and possibly screw up) the wheel; security is easy to make mistakes with. –  Tom Marthenal Jun 29 '12 at 19:26
    
Are you asking about when to roll your own function, or are you asking about known side-effects of functions that require additional steps by the programmer? If I understood your coworkers example, he meant to add an additional value to the value being hashed (aka salting) but he did not mean to write your own hashing algorithm. –  GlenH7 Jun 29 '12 at 19:27
    
Kinda. Like if relying on PHP sanitizing functions is a pitfall, what other common actions should I do myself to ensure they're done correctly or more appropriately for my situation. –  David Peterman Jun 29 '12 at 19:34
add comment

3 Answers

up vote 3 down vote accepted

I think you may be confusing core language functionality with features provided by extensions and / or toolkits.

I don't know of any cryptographic algorithm that pre-salts a hash for you, which is why your coworker made his comment. But that cryptography function is not a core aspect of the language, it's part of an extension.

In general, you need to understand the tools you are using regardless of their belonging to the core language or being provided through a toolkit.

If the language says it will do X, Y, and Z upon invocation then you can trust the language to do X, Y, and Z when you correctly invoke it. Any other result would be a bug in the implementation of that language. That doesn't obviate the need to understand what the function is providing.

As a related example, memory allocation in C does not initialize the memory segment to a preset / predetermined value. You generally need to then set the memory to a predefined value (such as 0x00) prior to using it. I can trust that when I call for the alloc then the memory was allocated (assuming my returned pointer is non-null). But the alloc doesn't guarantee it will provide initialized memory, so I need to do that myself.

share|improve this answer
2  
I think you may be right with the extensions comment. It looks like php has a cryptography extension. I'm assuming that's what he was talking about. –  David Peterman Jun 29 '12 at 18:51
    
I'm reasonably certain that for C, C++, Java, and C# that the cryptography functions are toolkits or extensions to the core language. In the case of C#, there are system libraries but they aren't part of the "core." I don't know for the scripting languages, but it would make sense that they are extensions. Cryptography has its own set of gotchas that have to be known in advance, primarily because of the multitude of ways the routines can be invoked. –  GlenH7 Jun 29 '12 at 18:56
    
I guess I meant functions that come with the core library, not the "language" itself. Would it make more sense if I edited my question to say core libraries rather than language? –  David Peterman Jun 29 '12 at 19:10
    
@DavidPeterman - it would certainly help the scope of the question, but it would invalidate your example, I believe. OTOH, I'm happy to hear of a language that has crypto as a core component. –  GlenH7 Jun 29 '12 at 19:24
add comment

Like superM said, it really does depend on the language, task, and programmer. If the language (or library) is not used very often or the task is very specific, then it's less likely for bugs to be found and fixed quickly than for something that is commonly used.

Typically you'll want to rely on the language or library much more than anything hand-rolled simply because they have been tested for correctness, robustness, security, scalability, etc. etc. This is especially true these days for open-source libraries since the nature of things like Github make it very easy for random users to submit patches to fix a particular bug.

However there are rare cases where there is an issue with a language/library (less rare for languages that aren't commonly used) and in that case if you know you can do a better job, then it might be a good idea to roll your own stuff. When you start doing this though, make sure that you can actually do a better job than the existing software and that you're not just falling for the "Not Invented Here" syndrome.

share|improve this answer
add comment

Almost never. There are some language features that are known to be unreliable. Typically they are amateur attempts at providing some kind of security. mysql_real_escape_string is such an attempt. Do not use this. Do not ever interpolate user-supplied values, "sanitized" or not, into SQL statements. Use prepared statements.

Similarly, some library random number functions and hash implementations are known to be poor, or no longer secure (e.g. DES-56). In those cases, use better third-party implementations. Do not attempt to write your own code in an attempt to provide cryptographic security. Do not try to write a password hashing algorithm. Do not try to write an encryption algorithm. If the standard library functions have been discredited, then use respected third-party code.

share|improve this answer
    
Just to clarify: there is nothing "wrong" with using mysql_real_escape_string if you understand it and don't abuse it. It protects you against straight SQL injection in strings. It doesn't claim to protect from other types of SQL injection. Prepared statements are better because they help protect against the developer's mistakes. –  Tom Marthenal Jun 29 '12 at 19:32
    
@TomMarthenal: is mysql_real_escape_string even needed if prepared statements are always used, as they should be? –  kevin cline Jun 29 '12 at 19:36
    
No. I'm just clarifying that there is nothing wrong with the mysql_real_escape_string function itself, but instead with the people who use it without understanding its limitations. –  Tom Marthenal Jun 29 '12 at 21:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.