Transcription

Software SecurityByHunter StevensonKhalid AlharbiCSCI 5828Foundations of Software EngineeringSpring 2012

What is the talk NOT about? Cryptography.Database security.Operating Systems security.Network security.Security software.Encryption, digital signatures, andauthentication protocols.

What is the talk about? Part 1:oo oFundamentals of software security.Software security design principles.Building secure software systems.Part 2:oCommon software vulnerabilities.

Part I:Software Security Fundamentals and Best Practices

What is Software Security? Software security is the idea of engineeringsoftware so that it continues to functioncorrectly under malicious attack.Software Security aims to avoid securityvulnerabilities by addressing security fromthe early stages of software development lifecycle."Security is a risk management."

Why Software Security?SQL Injection!!comic: http://xkcd.com/327/

Why Software Security? Most software systems today containnumerous flaws and bugs that get exploited byattackers.New threats emerge everyday.Convenience trumps security measures.Exponential increase in vulnerabilities insoftware systems.Software security is everybody's job.Programmers have a long history of repeatingthe same security-related mistakes!

Recent Stories (I) 2012 - A security flaw in Google Wallet thatleads into full access to your Google Walletaccount without extra app or rooting.o Your Google Wallet account is tied to the device itselfbut not to the account.2011 - Oracle's MySQL.com hacked via SQLInjection Attack!!2011 - Expedia's TripAdvisor member datastolen in possible SQL Injection Attack.2010 - Hacker gained access to the RoyalNavy website using SQL injection attack.

Recent Stories (II) 2009 - A security flaw in the Spotify service, bywhich private account information wereexposed.2006 - Hacker gained access to 800,000 UCLAstudents, faculty, and staff data.2005 - A buffer overflow was deducted inSymantec pcAnywhere that could lead into adenial of service attack.2005 - University of Southern California'sonline system applications were vulnerable toSQL Injection.

Terminology (I) Defects are implementation vulnerabilities anddesign vulnerabilities.Bugs are implementation-level errors that canbe detected and removed.o Example: Buffer overflow.Flaws are problems at a deeper level. They areinstantiated in the code and present or absent atdesign-level.o Example: Error-handling problems.Failures are the inability of the software toperform its required function.

Terminology (II) Risks capture the probability that a flaw ora bug will impact the purpose of thesoftware.oRisk probability x impactVulnerabilities are errors that an attackercan exploit.o Either flaws in the design or flaws in theimplementation.oDesign-level vulnerabilities are the hardest defects tohandle.

Pillars of Software Security The three pillars of software securitySoftware Security

Pillar I: Risk Management A continuous risk management process is anessential part to software security.It identifies, ranks, tracks, and understandssoftware security risks.Risk management framework (RMF)o An overall approach to risk management.o Allows a consistent and continuous expertise-drivenapproach to risk management.o The goal is to consistently track and handle risks.

RMF Activities (I)Measurement and Reporting1)Understandthe businesscontext.2)Identify thebusiness andtechnical risks.3)Synthesize,prioritize, andrank the risks.Artifact AnalysisBusiness Context5)Carry out fixesand validate.4)Define theriskmitigationstrategy.

RMF Activities (II)1- Understand the business context.A key task of an analyst.Extract and describe business goals.Set priorities.Understanding what risks to consider.Gathering the artifacts.Conducting project research to the scope.

RMF Activities (III)2- Identify the business and technicalrisks, synthesize, prioritize, and rank therisks.Business risks impact business goals.Mapping technical risks to business goals.Developing a set of risk questionnaires.Interviewing the target project team.Analyzing the research interview data.Evaluating software artifacts.

RMF Activities (IV)3- Synthesize, prioritize, and rank the risks.Prioritize the risks based on the businessgoals.Riskmetrics:o Risk likelihood.o Risk impact.o Number of risks emerging over time.What shall we do first given the current risksituation?What is the best allocation of resources?

RMF Activities (V)4- Define the risk mitigation strategy.Create a coherent strategy for mitigatingthe risks that takes into account: oooooCost.Implementation time.Likelihood of success.Competence.Impact.Identify the validation techniques.Metrics are financial in nature.

RMF Activities (VI)5- Carry out fixes and validate that theyare correct.Implement the mitigation strategy.The artifacts should be rectified.Progress is measured in terms ofcompleteness against mitigation strategy.Use validation techniques to validate thatartifacts no longer bear unacceptable risk.Metrics include artifact quality metricsand levels of risk mitigation effectiveness.

RMF Activities (VII) Risk management is a central software security practice.Successful use of RMF relies on continuous andconsistent identification of risks.Use project management tools to track risk information.o Example: Open Workbench.RMF is a multilevel loop.o Identifying risks only once during the project isincorrect.o The five fundamental activities need to be appliedrepeatedly throughout the project.

Pillar II: Touchpoints Security touchpoints are set of security bestpractices.

Seven Touchpoints (I)1. Code Reviews.ooArtifact: Code.Example of risks found: Buffer overflow on line 30.2. Architectural Risk Analysis.ooArtifact: Design and specifications.Example of risks found: Failure of a Web Service toauthenticate calling code.3. Penetration Testing.o Artifact: System in its environment.o Example of risks found: Poor handling of programstate in Web interface.

Seven Touchpoints (II)4. Risk-Based Security Testing.ooArtifact: Units and system.Example of risks found: Extent of data leakagepossible by leveraging data protection risk.5. Abuse cases.ooArtifact: Requirements and use cases.Example of risks found: Susceptibility to well-knowntampering attack.

Seven Touchpoints (III)6. Security Requirements.o Artifact: Requirements.o Example of risks found: Explicit description of dataprotection needs is missing.7. Security Operations.o Artifact: Fielded system.o Example of risks found: Insufficient logging toprosecute a known attacker.

Fixing defects: Early is better!

1- Code Review (I) Source code analysis.Focus is on finding and fixing bugs.Use static analysis tools to find security bugs.o Static analysis tools suffer from false negatives andfalse positives.o Examples: Coverity, Fortify, Ounce Labs, and SecureSoftware.

1- Code Review (II) Useful source code analysis tools must:1- Be designed for security.2- Support multiple tires.3- Be extensible.4- Be useful for security analysts anddevelopers alike.5- Support existing development processes.6- Make sense to multiple stakeholders.

2- Architectural Risk Analysis (I) Design flaws:o Account for 50% of security problems.o Can't be detected by staring at code.o A higher-level understanding is required.Architectural Risk Analysis:o Tracks risk over time.o Links system-level concerns to probability andimpact measures.o Fits with RMF.

2- Architectural Risk Analysis (II) Critical Aspects of Architectural RiskAnalysis:oooAttack Resistance Analysis.Ambiguity Analysis.Weakness Analysis.

2- Architectural Risk Analysis (III) Attack Resistance Analysis:o It captures the check-list like approach to the riskanalysis taken in Microsoft STRIDE approach.o Steps: Identify general flaws using secure designliterature and checklists. Map attack patterns using either the results ofabuse case development or a list of historicalrisks. Identify risks in the architecture based on the useof checklists. Understand and demonstrate the viability ofthese known attacks.

2- Architectural Risk Analysis (IV) Ambiguity Analysis:o oIt captures the creative activity required to discovernew risks.It requires at least two analysts and experience.Weakness Analysis:o Is aimed at understanding the impact of softwaredependencies.o Software is built on top of complex middlewareframeworks.o Understand what kind of assumptions we makeabout outside software.o What happens when assumptions fail?

3- Software Penetration Testing A method of evaluating software security bysimulating an attack in an outside-inmanner.Testing the system in its final.Most commonly applied of all seventouchpoints.Use static and dynamic penetration testingtools.oExamples: fault injection tools, Cenzic, Holodeck,SPI Dynamics, Immunity CANVAS, and IEInspectorHTTP Analyzer.

4- Risk-Based Security Testing (I) Testers must follow:o Different from Penetration Testing:o Risk-based approach:o Grounded in both system's architectural realityand the attacker's mindset.o Focused on areas of code where an attack is likelyto succeed.oLevel of approach: Inside-out approach.Timing of testing: Before the software is complete.Should start prior to system integration.Risk analysts should identify and rank risks.

4- Risk-Based Security Testing (II) Security Testing must involve twoapproaches:ooFunctional security testing: Testing mechanisms that ensure thatfunctionality is well implemented.Adversarial security testing: Risk-based security testing motivated byunderstanding the attacker's approach.

5- Abuse Cases (I) Determining what the software can't andwon't do (No positive features).oExample: users can't enter more than 50 characters.Must anticipate abnormal behaviors.Don't accept the idea that says "No onewould do these things".What happens when functional securitymechanisms are compromised?

5- Abuse Cases (II) Generating abuse cases:o Creating Anti-Requirements: Provide insights into how attackers will approachsystem's assumptions. Applied throughout the lifecycle. Generated by security analysts.o Creating an attack model: Explicit consideration of well-known attacks. Select attack patterns relevant to the system. Build abuse cases around attack patterns. Include anyone who can gain access to thesystem.

6- Security Requirements Cover both functional security and emergentcharacteristics.Satisfy three criteria:o Definition: Must be explicitly defined what securityrequirements are.o Assumption: Must take into account theassumptions that the system will behave as expected.o Satisfaction: Security requirements must satisfythe security goals, and the system must satisfy thesecurity requirements.

7- Security Operations Software security operations can beintegrated with network security operations.Defensive technique:o Understanding software behaviour that leads intosuccessful attack.Knowledge gained by understanding attacksshould be cycled back into softwaredevelopment.

Pillar III: Knowledge (I) Involves gathering, encapsulating, andsharing security knowledge.Software Security Knowledge Catalogs:Principles.o Guidelines.o Rules.o Vulnerabilities.o Exploits.o Attack Patterns.o Historical Risks.o

Pillar III: Knowledge (II)Mapping of software security knowledge catalogs to various software artifacts and softwaresecurity best practices.

Part 2:19 Deadly Sins (defects)

19 Deadly Sins (defects)1.Buffer Overruns11.2.Format String problems12. Failing to Store and Protect Data Securely3.Integer Overflows13. Information Leakage4.SQL Injection14. Improper File Access5.Command Injection15. Trusting Network Name Resolution6.Failing to Handle Errors16. Race Conditions7.Cross-Site Scripting17. Unauthenticated Key Exchange8.Failing to Protect Network Traffic18. Cryptographically Strong Random Numbers9.Use of "magic" URLs and Hidden Forms19. Poor Usability10. Improper use of SSL and TLSUse of Weak Password-Based Systems

19 Deadly SinsSin 1: Buffer Overruns “smashing the stack” The core problem is that user data and program flow control informationare intermingled for the sake of performance, and low-level languages allowdirect access to application memory.o Mostly prevalent in C and C .Occurs when a program allows input to write beyond the end of theallocated buffer.The effect of a buffer overrun is anything from a crash to the attackergaining complete control of the application.

19 Deadly SinsSin 1: Buffer Overruns examplesvoid DontDoThis(char *input){Morris finger worm:char buf[16];char buf[20];gets(buf);strcpy(buf, input);printf(“%s\n”, buf);}int main(int argc, char *argv[])#define MAX BUF 256void BadCode(char* input){short len;char buf[MAX BUF];{If a short is 2 bytes andinput 32767, then len becomesa negative numberlen strlen(input);If input is not null-terminated///of course we can use strcpy safelyif(len MAX BUF)strcpy(buf, input);DontDoThis(argv[1]);return 0;}bool CopyStructs(InputFile *pInFile, unsigned long count){unsigned long i;m pStructs new Structs[count];for (i 0; i count; i ){if (!ReadFromFile(pInFile, &(m pStructs[i])))break;}}}Slightly better: Use size tto define size for MAX BUF and len

19 Deadly SinsSin 1: Buffer Overruns: Spotting the sin patternHere are the components to look for: Input, whether read from the network, a file, or from the command lineTransfer of data from said input to internal structuresUse of unsafe string handling callsUse of arithmetic to calculate an allocation size or remaining buffer sizeRedemption Steps: Replace Dangerous String Handling FunctionsAudit AllocationsCheck Loops and Array AccessesReplace C String Buffers with C StringsReplace Static Arrays with STL ContainersUse Analysis Tools

19 Deadly SinsSin 2: Format String Problems The root cause of format string bugs is trusting user-supplied input withoutvalidation.o Mostly prevalent in C and C .Can also occur when the format strings are read from an untrusted locationthe attacker controls.Even if you’re not dealing with C/C oUsers can be misledoAn attacker might also launch cross-site scripting or SQL injection attacks

19 Deadly Sins Sin 2: Format String Problems examples#include stdio.h int main(int argc, char* argv[]){if(argc 1)printf(argv[1]);bug.exe%x %x12ffc0 4011e5The %x specifierreads the stack4 bytes at a timeand outputs themLeaks importantinfo to the attackerreturn 0;}unsigned int bytes;printf(“%s%n\n”, argv[1], &bytes);printf(“Input is %d characters long.\n”, bytes);Usage:bug.exe “Hello“HelloInput is 5 characters longThe %n specifier writes4 bytes at a time based on the lengthof the previous argumentCarefully crafted, allows an attackerto place own data into the stack

19 Deadly SinsSin 2: Format string patterns : Spotting the sin patternIn C/C , look for functions from the printf family. Problems to look for are: printf(user input);fprintf(STDOUT, user input);Redemption Steps: The first step is never pass user input directly to a formatting function, andalso be sure to do this at every level of handling formatted outputC/C Redemption: printf("%s", user input);

19 Deadly SinsSin 3: Integer Overflows The core of the problem is that for nearly every binary format we can chooseto represent numbers, there are operations where the result isn’t what you’dget with pencil and paper.There are exceptions—some languages implement variable-size integertypes, but these are not common and do come with some overhead.C and C have true integer types; and modern incarnations of Visual Basicpack all the numbers into a floating point type known as a “Variant,” so youcan declare an int, divide 5 by 4, and expect to get 1. Instead, you get 1.25.

19 Deadly SinsSin 3: Integer Overflows examplesconst long MAX LEN 0x7FFF;short len strlen(input);if (len MAX LEN){// Do stuff}If a short is 2 bytes andinput 32767, then len becomesa negative numberProblem here to detect whether twounsigned 16-bit numbers wouldoverflowwhen added?Overflow Problem in C#byte a, b;a 255;b 1;byte c (a b);ERROR: Cannot implicitly convert type ‘int’to ‘byte’bool IsValidAddition(unsigned short x, unsigned short y){if (x y x)return false;return true;}

19 Deadly SinsSin 3: Integer Overflows: Spotting the sin pattern Anything doing arithmeticEspecially if input provided by the userFocus especially on array index calculationsRedemption Steps: Use size t type in C/C Use unsigned integers if appropriate, easier to verifyAvoid “clever” code in favor of straightforward code

19 Deadly SinsSin 4: SQL Injection Perhaps the greatest risk is a SQL injection attack where the attacker gainsprivate PII or sensitive data.oBreak into server using exploit like buffer overrunoGo through open port with sysadmin passwordoSocial engineeringoSQL injection attacksThe damage is not limited to the data in the database; a SQL injection attackcould lead to server, and potentially network, compromise also. For anattacker, a compromised back-end database is simply a stepping stone tobigger and better things.

19 Deadly SinsSin 4: SQL Injection examplesusing System.Data;using System.Data.SqlClient;.string ccnum "None";try {SqlConnection sql new SqlConnection(@"data source localhost;" "user id sa;password pAs w0rd;");sql.Open();string sqlstring "SELECT ccnum" " FROM cust WHERE id " Id;SqlCommand cmd new SqlCommand(sqlstring,sql);ccnum (string)cmd.ExecuteScalar();} catch (SqlException se) {Status sqlstring " failed\n\r";foreach (SqlError e in se.Errors) {Status e.Message "\n\r";}} catch (SqlException e) {// OOops!}import java.*;import java.sql.*;.public static boolean doQuery(String Id) {Connection con er.SQLServerDriver");con ver: “ "//localhost:1433", "sa", " 3cre ");Statement st con.createStatement();ResultSet rs st.executeQuery(" SELECT ccnum FROM cust WHERE id " Id);while (rs.next()) {// Party on the query results}rs.close();st.close();}catch (SQLException e){// OOPS!return false;}catch (ClassNotFoundException e2){// Class not foundreturn false;}finally{try{con.close();} catch(SQLException e) {}} return true;}

19 Deadly SinsSin 4: SQL Injection: Spotting the sin pattern Takes user inputDoes not check user input for validityUses user-input data to query a databaseUses string concatenation or string replacement to build the SQL query oruses the SQL exec command.Redemption Steps: The simplest and safest redemption steps are to never trust input to SQLstatements, and to use prepared or parameterized SQL statements, alsoknown as prepared statements.Filter any unallowable characters like ‘ or “”Never use string concatenation to build SQL statements

19 Deadly SinsSin 5: Command Injection User input that was meant to be data actually can be partially interpreted asa command of some sort.Often, that command can give the person with control over the data accessto far more access than was ever intended.Problems that occur when untrusted data is placed into data that is passedto some sort of compiler or interpreter, where the data might, if it’sformatted in a particular way, be treated as something other than data.

19 Deadly SinsSin 5: Command Injection exampleschar buf[1024];snprintf(buf, "system lpr -P %s", user input, sizeof(buf)-1);system(buf);def call func(user input, system data): exec'special function %s("%s")' % (system data, user input)special function sample("fred")fred"); print ("foospecial function sample("fred"); print ("foo")

19 Deadly SinsSin 5: Command Injection: Spotting the sin pattern Commands (or control information) and data are placed inline next to eachother.There is some possibility that the data might get treated as a command,often due to characters with special meanings, such as quotes andsemicolons.Control over commands would give users more privileges than they alreadyhave.Redemption Steps: Check the data to make sure it is okay.Take an appropriate action when the data is invalid.

19 Deadly SinsSin 6: Failing to Handle Errors Sometimes a program can end up in an insecure state, but more often theresult is a denial of service issue as the application simply dies.The unfortunate reality is that any reliability problem in a program thatleads to the program crashing, aborting, or restarting is a denial of serviceissue, and therefore can be a security problem, especially for server code.A common source of errors is sample code that has been copied and pasted.Often sample code leaves out error return checking to make the code morereadable.

19 Deadly SinsSin 6: Failing to Handle Errors Variants Yielding too much information Ignoring errors Misinterpreting errors Using useless error values Handling the wrong exceptions Handling all exceptions

19 Deadly SinsSin 6: Failing to Handle Errors: Spotting the sin pattern A code review is by far the most efficient way to spot these.Redemption Steps: Handle the appropriate exceptions in your code.Don’t “gobble” exceptions.Make sure you check return values when appropriate.

19 Deadly SinsSin 7: Cross-Site Scripting A form of security defect unique to web-based applications that allow userdata tied to the vulnerable web server’s domain, usually held in cookies, tobe disclosed to a malicious third party.o The cookie is transferred from a client computer accessing a valid, but vulnerable, web-server site to a site ofthe attacker’s bidding.Malicious user can inject script code that is then executed when anotheruser views that page.

19 Deadly SinsSin 7: Cross-Site Scripting working1.The attacker identifies a web site that has one or more XSS bugs—forexample, a web site that echoes the contents of a querystring.The attacker crafts a special URL that includes a malformed andmalicious querystring containing HTML and script, such as JavaScript.The attacker finds a victim, and gets the victim to click a link thatincludes the malformed querystring. This could be simply a link onanother web page, or a link in an HTML e-mail.The victim clicks the links and the victim’s browser makes a GETrequest to the vulnerable server, passing the malicious querystring.The vulnerable server echoes the malicious querystring back to thevictim’s browser, and the browser executes the JavaScript embedded inthe response.2.3.4.5.

19 Deadly SinsSin 7: Cross-Site Scripting: Spotting the sin patternAny application that has the following pattern is at risk of cross-site scripting: The web application takes input from an HTTP entity such as a querystring,header, or form.The application does not check the input for validity.The application echoes the data back into a browser.Redemption Steps: Restrict the input to valid input only. Most likely you will use regularexpressions for this.HTML encode the output.

19 Deadly SinsSin 8: Failing to Protect Network Traffic These kinds of attacks are possible because so many network protocols failto protect network traffic adequately.Many important protocols, such as Simple Mail Transfer Protocol (SMTP)for mail relay, Internet Message Access Protocol (IMAP) and Post OfficeProtocol (POP) for mail delivery, and HyperText Transfer Protocol (HTTP)for web browsing provide no security at all, or at most, provide basicauthentication mechanisms that are easily attacked.

19 Deadly SinsSin 8: Failing to Protect Network Traffic formsNetwork attacks can take a wide variety of forms: Eavesdropping The attacker listens in to the conversation and recordsany valuable information, such as login names and passwords. Replay Theattacker takes existing data from a data stream and replays it. This can bean entire data stream, or just part of one. For example, one might replayauthentication information in order to log in as someone else, and thenbegin a new conversation.Spoofing The attacker mimics data as if it came from one of the twoparties.Tampering The attacker modifies data on the wire, perhaps doingsomething as innocuous as changing a 1 bit to a 0 bit.Hijacking The attacker waits for an established connection, and then cutsout one of the parties, spoofing the party’s data for the rest of theconversation.

19 Deadly SinsSin 8: Failing to Protect Network Traffic: Spotting the sin pattern An application uses a networkDesigners overlook or underestimate network-level risksRedemption Steps: Use SSL/TLS for any network connections, if at all possible, or else someother abstraction, such as Kerberos.Basic security services on the wire:oconfidentiality, initial authentication, and ongoing authentication.

19 Deadly SinsSin 9: Use of Magic URLs and Hidden Form Fields There’s nothing stopping a user from looking at the source content, andthen sending an “updated” form with a changed data(using Perl, forexample) back to the server. Hidden fields are not really hidden at all.“Magic URLs”: many web-based applications carry authenticationinformation or other important data in URLs.oIn some cases, this data should not be made public, because it can be used to hijack or manipulate a session.oIn other cases, Magic URLs are used as an ad hoc form of access control, as opposed to using credentialbased systems.

19 Deadly Sins Sin 9: Use of Magic URLs and Hidden Form Fields examplesHidden Form Fields to pass variables form action “ /” input type text name “product” input type hidden name “price” value “300” /form Magic URLwww.xyzzy.com?id TXkkZWNyZStwQSQkdzByRA “base64 decoder yields “My ecre pA w0rD.”

19 Deadly SinsSin 9: Use of Magic URLs and Hidden Form Fields: Spotting the sin pattern Sensitive information is read by the web app from a form or URL.The data is used to make security, trust, or authorization decisions.The data is provided over an insecure or untrusted channel.Redemption Steps:Consider the following threats: oAn attacker views the dataoAn attacker replays the dataoAn attacker predicts the dataoAn attacker changes the dataUse SSL or store data on server sideSession variables, encrypted

19 Deadly SinsSin 10: Improper Use of SSL and TLS Proper server authentication doesn’t usually happen automatically. In fact,it often requires writing a lot of code.When server authentication isn’t done properly, an attacker can eavesdrop,or modify or take over conversations, generally without being detected.Examples: Most mailers lack support for CRLs or OCSP.Proper validation when using a web browser requires a user to click on thelock and look at the certificate, to make sure the hostname in the certificatematches the hostname the user intended.By default, Stunnel does no validation. If you do request validation, you caneither validate optionally, validate against an allow list, or validate the dateand chain of trust, without actually checking the proper certificate fields.

19 Deadly SinsSin 10: Improper Use of SSL and TLS: Spotting the sin pattern SSL or TLS is used, andHTTPS is not used, andThe library or client application code fails to check whether the server certificate is endorsed by a knownCA, orThe library or client application code fails to validate the specific data within the server certificate.Redemption Steps:When it’s reasonable to use SSL or TLS, do so, making sure that the following is true: You’re using the most recent version of the protocol (as of this writing, it’s TLS 1.1).You use a strong cipher suite (particularly not one with RC4 or DES).You validate that the certificate is within its validity period.You ensure that the certificate is endorsed by a trusted source (root CA), either directly or indirectly.You validate that the hostname in the certificate matches the one you expect to see.Also, you should try to implement one or more revocation mechanisms, particularly basic CRL checking orOCSP.

19 Deadly SinsSin 11: Use of Weak Password-Based Systems Security experts hate passwords because people will use their kids’ names aspasswords, or else write them down and stick them under the keyboard ifthey’re forced to use stronger passwords.In some respect, any software system using passwords is a security risk.Guidelines for Password Resets Locking users out of accounts for too many badpassword attempts may result in DoS

19 Deadly SinsSin 11: Use of Weak Password-Based Systems examplesTENEX Operating System pseudocode to validate:For i 0 to len(typed password)if i len(actual password) fail;if typed password[i] ! actual password[i] fail;if i len(actual password) fail;Success;Flaw: Attacker could put candidate password in memory overlappingpage boundaries. First letter on one page, second letter on the next, ifthe first letter was correct there was a pause while the page for thesecond letter loaded

19 Deadly SinsSin 11: Use of Weak Password-Based Systems: Spotting the sin pattern Is a program using traditional or handmade password systems withoutusing some other authentication technique to provide defense in depth?Even if there is multifactor authentication, there can still be some risksanytime you’re using a password system, such as account lock-out due tofailed login attempts.Redemption Steps: Multifactor AuthenticationStoring and Checking PasswordsGuidelines for Choosing ProtocolsGuidelines for Password ResetsGuidelines for Password ChoiceOther Guidelines

19 Deadly SinsSin 12: Failing to Store and Protect Data Securely There are a number of aspects you need to consider when storing datasecurely:o permissions required to access the data, data encryption issues, and threats to stored secrets.Many developers hardcode secret data into software, such as cryptographickeys and passwords, that they do not expect users to recover, believing thatreverse engineering is too difficult to do.

19 Deadly SinsSi

What is Software Security? Software security is the idea of engineering software so that it continues to function correctly under malicious attack. Software Security aims to avoid security vulnerabilities by addressing security from the early stages of software d