If developers, project managers, and business owners aren\u2019t paying attention to some of the basics of software development, then they certainly aren\u2019t spending any time making sure that their software is secure.\u00a0 Following that logic, if a piece of software shows signs of inattentive design in one area, then it is reasonable to assume that there was inattentive design in other areas. \u00a0Since security is typically addressed after functionality (although it shouldn\u2019t be!) it stands to reason that software that demonstrates sloppy architecture, design, or user interface, is probably not secure.Here are the top 5 signs that software is poorly written and is probably not very secure:1. Format compliance warnings (Phone numbers, SSN, etc.)One of my first clues that the development team didn\u2019t spend any time on processing input and just did the minimum to make the software functional is when I get a warning that an input is not formatted properly.\u00a0 We have all seen these.\u00a0 You enter your phone number as \u201c1234567890\u201d and the software responds \u201cyou must enter your phone number in the format (123) 456-7890.\u201d\u00a0Why?\u00a0If the software can determine that the number isn\u2019t in the right format, then it should be able to format it. \u00a0Formatting warnings like this tell me that the programmer is just looking for one particular instance and has not accounted for, and is not handling, data as data, but is rather trying to constrain input into a predetermined format.\u00a0 This might sound like it is a good thing, but in reality it means that the programmer did not take the time to write a true data handling method and instead just wrote for minimum functionality.2. Case sensitivity on email addressesThis is one of my biggest pet peeves.\u00a0 It shows that the developers were either very lazy, or that they didn\u2019t understand how the internet works.\u00a0 Either tells me that they are not writing secure code.\u00a0 Email addressing is not case sensitive.\u00a0 That means that email@example.com and BiLl@MYsItE.COm are exactly equal. \u00a0When software asks me to input my email twice to confirm that it is the same and then tells me they don\u2019t match because of capitalization, it tells me that the programmer just did a byte by byte compare and didn\u2019t actually analyze the input.\u00a0 If that is true here, then that means that they probably didn\u2019t fully analyze input from other inputs and a hacker could use that fact to inject input that the programmer wasn\u2019t expecting.\u00a0 This is the foundation of SQL injection vulnerabilities.3. Limiting the length of a passwordSeriously?\u00a0 We are trying to make the software secure, but we are limiting the length of passwords?\u00a0 This tells me that the programmer was probably very junior and didn\u2019t know how to program variable length strings or that they didn\u2019t understand how to convert a variable length string into the fixed length key that an encryption algorithm needs.\u00a0 Either demonstrates a rudimentary understanding of programming that is not on an industrial level, and someone who doesn\u2019t understand security at all.4. \u201cComplex\u201d passwordsI know that NIST just changed their stance on \u201ccomplex\u201d passwords and that they have been advocating password complexity and aging for decades, but security practitioners have known for a long time that aging passwords and enforcing \u201ccomplexity\u201d standards just causes people to create passwords that they can\u2019t remember, which means they write them down somewhere.\u00a0 Security practitioners have also known that the human element is the easiest to breach.\u00a0 Complex passwords that are only 8 characters long are easier to break than easy to remember passphrases comprised of multiple every day words that are 16-20 characters long.\u00a0 Personally, I feel that disallowing any dictionary words in a passphrase is as bad as enforcing password complexity.\u00a0 Of course, if we are going to allow dictionary words, then the passphrase needs to be of a minimum length. (But not constrained to a maximum length!)5. Emailing lost passwordThis is the absolute worst.\u00a0 No one should do business with a company that does this. \u00a0 I thought this was a thing of the past but I experienced it just last week.\u00a0 This is how it happens:You forget your password to a site and hit the \u201cForgot Password\u201d button.\u00a0 You receive a message or popup that says \u201cyour password has been sent to your email.\u201d\u00a0 When you open your email, there in plain, unencrypted text is your username and your password.There are two things horrifically wrong with this.\u00a0 First, the company is actually storing your clear-text password instead of storing a hash of your password.\u00a0 That means that when (not if) they are compromised, hackers will instantly have your password.\u00a0 Second, they are sending your username and password via email in clear-text.\u00a0 They might as well print it on the outside of an envelope and send it through the mail.\u00a0 Everyone along the way will be able to see both the username and the password.\u00a0Writing secure code isn\u2019t easy, but it isn\u2019t difficult either.\u00a0 What it takes is a knowledge of what is safe and what is not, and a desire to place security at least tantamount to functionality.\u00a0 If you see any of these signs in software that you use, it is an indicator that the functionality was more important to that company than security and the software is probably not very secure.\u00a0 If your company has software that demonstrates these signs, it is time for a rewrite!