A Senior Developer working mostly with PHP and JavaScript, with a bit of Python thrown in for good measure, all on Linux. My tooling is simple, it's GitLab and JetBrains where possible.
What should be limited to 60 characters? Passwords? That severely limits passphrase usage - they are better than traditional passwords as they are inherently longer and harder to break. If you mean emails, the RFC standard for an email address is 254 characters. Whilst there's very little demand or actual use for a length of that size, a limit to 60 might limit some people (unlikely, but still should be aware of it.
As for MD5 for passwords. Don't. MD5 is broken. It's stupidly fast to evaluate so silly numbers of hashes can be computed in seconds, even on arbitrary hardware.
The important lesson to take from any form of SQL injection discussion is never trust user input
A Senior Developer working mostly with PHP and JavaScript, with a bit of Python thrown in for good measure, all on Linux. My tooling is simple, it's GitLab and JetBrains where possible.
It's the use of EF you should be focusing on. That way you'll be spreading accepted and trusted methods. By giving people "simpler" options, it encourages people to use bad practices, and lower the overall security of web applications. Always focus and aim for the right way to do things, not the quickest ways. Security should always be done right and to best practice.
I'd love to see a follow up explaining how to protect against SQL injection using EF, and encouraging standard, secure practices.
I mean you should limit it to for example 60 because anyway, the standard is it. but yes, you can encrypt it to md5.
What should be limited to 60 characters? Passwords? That severely limits passphrase usage - they are better than traditional passwords as they are inherently longer and harder to break. If you mean emails, the RFC standard for an email address is 254 characters. Whilst there's very little demand or actual use for a length of that size, a limit to 60 might limit some people (unlikely, but still should be aware of it.
As for MD5 for passwords. Don't. MD5 is broken. It's stupidly fast to evaluate so silly numbers of hashes can be computed in seconds, even on arbitrary hardware.
The important lesson to take from any form of SQL injection discussion is never trust user input
Yes, but there are several methods to make it more protective. if you use EF like me, nobody can inject queries. but in other methods, it's possible.
It's the use of EF you should be focusing on. That way you'll be spreading accepted and trusted methods. By giving people "simpler" options, it encourages people to use bad practices, and lower the overall security of web applications. Always focus and aim for the right way to do things, not the quickest ways. Security should always be done right and to best practice.
I'd love to see a follow up explaining how to protect against SQL injection using EF, and encouraging standard, secure practices.
OK, I will post it