Return to Answer

You are only as strong as your weakest exploitable link. Also just because you aren't rolling your own scheme, doesn't mean your scheme will be secure, it's possible that the person who created what you rolled out was not an expert, or created an otherwise weak scheme.

You are only as strong as your weakest exploitable link. Also just because you aren't rolling your own scheme, doesn't mean your scheme will be secure, it's quite likely that the person who created what you rolled out was not an expert, or created an otherwise weak scheme.

• Timing Attacks. E.g., to the nanoseconds do completely-bad keys and partially-bad keys take the same amount of time in the aggregate to fail? Otherwise, this timing information can be exploited to find the correct key/password.

• Trivial Brute Force Attacks; e.g., that can be done in within seconds to years (when you worry about it being broken within a few years). Maybe your idea of security may be a 1 in a billion (1 000 000 000) chance of breaking in (what if someone with a bot net tries a few billion times?). My idea is to aim for something like 1 in ~2¹²⁸ ( 34 000 000 000 000 000 000 000 000 000 000 000), which is roughly ten million billion billion times more secure and completely outside the realm of guessing your way in.

• Attacks on user accounts in parallel; e.g., you may hash passwords with the same (or worse no) 'salt' on all password hashes in the database like what happened with the leaked LinkedIn hashes.

• Attack any specific account trivially simply. Maybe there was a unique random salt with each simply hashed (e.g., MD5/SHA1/SHA2) password, but as you can try billions of possible passwords on any hash each second, so using common password lists, dictionary attacks, etc. it may only take an attacker seconds to crack most accounts. Use strong cryptographic hashes like bcrypt or PBKDF2 to avoid or key-strengthen regular hashes by a suitable factor (typically 10^(3-8)).

• Attacks on guessable/weak "random" numbers. Maybe you use microtime/MT-rand or too little information to seed the pseudo-random number like Debian OpenSSL did a few years back.

• Attacks that bypass protections. Maybe you did hashing/input validation client side in web application and this was bypassed by the user altering the scripts. Or you have local application that the client tries running in a virtual machine or disassembles to reverse engineer it/alter the memory/ or otherwise cheat somehow.

• Other attacks, including (but not attempting to be a complete list) CSRF, XSS, SQL injection, network eavesdropping, replay attacks, Man in the Middle attacks, buffer overflows, etc. Best protections very quickly summarized.

  • CSRF: require randomly generated CSRF tokens on POST actions; XSS: always validate/escape untrusted user-input before inputting into the database and displaying to user/browser
  • SQLi: always use bound parameters and limit how many results get returned; eavesdropping: encrypt sensitive network traffic; replay: put unique one-time nonces in each transaction
  • MitM: Web of Trust/Same as site last visited/Certificate issued by trusted CA
  • Buffer Overflows: safe programming language/libraries/executable space protection/etc).

You are only as strong as your weakest exploitable link. Also just because you aren't rolling your own scheme, doesn't mean your scheme will be secure. Its quite likely that the person who created what you rolled out was not an expert, or created an otherwise weak scheme.

• Timing Attacks. E.g., to the nanoseconds do completely-bad keys and partially-bad keys take the same amount of time in the aggregate to fail? Otherwise, this timing information can be exploited to find the correct key/password.

• Trivial Brute Force Attacks; e.g., that can be done in within seconds to years (when you worry about it being broken within a few years). Maybe your idea of security may be a 1 in a billion (1 000 000 000) chance of breaking in (what if someone with a bot net tries a few billion times?). My idea is to aim for something like 1 in ~2¹²⁸ ( 34 000 000 000 000 000 000 000 000 000 000 000), which is roughly ten million billion billion times more secure and completely outside the realm of guessing your way in.

• Attacks on user accounts in parallel; e.g., you may hash passwords with the same (or worse no) 'salt' on all password hashes in the database like what happened with the leaked LinkedIn hashes.

• Attack any specific account trivially simply. Maybe there was a unique random salt with each simply hashed (e.g., MD5/SHA1/SHA2) password, but as you can try billions of possible passwords on any hash each second, so using common password lists, dictionary attacks, etc. it may only take an attacker seconds to crack most accounts. Use strong cryptographic hashes like bcrypt or PBKDF2 to avoid or key-strengthen regular hashes by a suitable factor (typically 10^(3-8)).

• Attacks on guessable/weak "random" numbers. Maybe you use microtime/MT-rand or too little information to seed the pseudo-random number like Debian OpenSSL did a few years back.

• Attacks that bypass protections. Maybe you did hashing/input validation client side in web application and this was bypassed by the user altering the scripts. Or you have local application that the client tries running in a virtual machine or disassembles to reverse engineer it/alter the memory/ or otherwise cheat somehow.

• Other attacks, including (but not attempting to be a complete list) CSRF, XSS, SQL injection, network eavesdropping, replay attacks, Man in the Middle attacks, buffer overflows, etc. Best protections very quickly summarized.

  • CSRF: require randomly generated CSRF tokens on POST actions; XSS: always validate/escape untrusted user-input before inputting into the database and displaying to user/browser.
  • SQLi: always use bound parameters and limit how many results get returned.
  • Eavesdropping: encrypt sensitive network traffic.
  • Replay: put unique one-time nonces in each transaction.
  • MitM: Web of Trust/Same as site last visited/Certificate issued by trusted CA.
  • Buffer overflows: safe programming language/libraries/executable space protection/etc).

You are only as strong as your weakest exploitable link. Also just because you aren't rolling your own scheme, doesn't mean your scheme will be secure, it's possible that the person who created what you rolled out was not an expert, or created an otherwise weak scheme.

• Timing Attacks. E.g., to the nanoseconds do completely-bad keys and partially-bad keys take the same amount of time in the aggregate to fail? Otherwise, this timing information can be exploited to find the correct key/password.

• Trivial Brute Force Attacks; e.g., that can be done in within seconds to years (when you worry about it being broken within a few years). Maybe your idea of security may be a 1 in a billion (1 000 000 000) chance of breaking in (what if someone with a bot net tries a few billion times?). My idea is to aim for something like 1 in ~2^128 ( 34 000 000 000 000 000 000 000 000 000 000 000), which is roughly ten million billion billion times more secure and completely outside the realm of guessing your way in.

• Attacks on user accounts in parallel; e.g., you may hash passwords with the same (or worse no) 'salt' on all password hashes in the database like what happened with the leaked linkedin hashes.

• Attack any specific account trivially simply. Maybe there was a unique random salt with each simply hashed (e.g., MD5/SHA1/SHA2) password, but as you can try billions of possible passwords on any hash each second, so using common password lists, dictionary attacks, etc. it may only take an attacker seconds to crack most accounts. Use strong cryptographic hashes like bcrypt/PBKDF2 to avoid or key-strengthen regular hashes by a suitable factor (typically 10^(3-8).

• Attacks on guessable/weak "random" numbers. Maybe you use microtime/MT-rand or too little information to seed the pseudo-random number like Debian OpenSSL did a few years back.

• Attacks that bypass protections. Maybe you did hashing/input validation client side in web application and this was bypassed by the user altering the scripts. Or you have local application that the client tries running in a virtual machine or disassembles to reverse engineer it/alter the memory/ or otherwise cheat somehow.

• Other attacks, including (but not attempting to be a complete list) CSRF, XSS, SQL injection, network eavesdropping, replay attacks, Man in the Middle attacks, buffer overflows, etc. Best protections very quickly summarized. CSRF: require randomly generated CSRF tokens on POST actions; XSS: always validate/escape untrusted user-input before inputting into db and displaying to user/browser; SQLi: always use bound parameters and limit how many results get returned; eavesdropping: encrypt sensitive network traffic; replay: put unique one-time nonces in each transaction; MitM: Web of Trust/Same as site last visited/Certificate issued by trusted CA; buffer overflows: safe programming language/libraries/executable space protection/etc).

• Timing Attacks. E.g., to the nanoseconds do completely-bad keys and partially-bad keys take the same amount of time in the aggregate to fail? Otherwise, this timing information can be exploited to find the correct key/password.

• Trivial Brute Force Attacks; e.g., that can be done in within seconds to years (when you worry about it being broken within a few years). Maybe your idea of security may be a 1 in a billion (1 000 000 000) chance of breaking in (what if someone with a bot net tries a few billion times?). My idea is to aim for something like 1 in ~2¹²⁸ ( 34 000 000 000 000 000 000 000 000 000 000 000), which is roughly ten million billion billion times more secure and completely outside the realm of guessing your way in.

• Attacks on user accounts in parallel; e.g., you may hash passwords with the same (or worse no) 'salt' on all password hashes in the database like what happened with the leaked LinkedIn hashes.

• Attack any specific account trivially simply. Maybe there was a unique random salt with each simply hashed (e.g., MD5/SHA1/SHA2) password, but as you can try billions of possible passwords on any hash each second, so using common password lists, dictionary attacks, etc. it may only take an attacker seconds to crack most accounts. Use strong cryptographic hashes like bcrypt or PBKDF2 to avoid or key-strengthen regular hashes by a suitable factor (typically 10^(3-8)).

• Attacks on guessable/weak "random" numbers. Maybe you use microtime/MT-rand or too little information to seed the pseudo-random number like Debian OpenSSL did a few years back.

• Attacks that bypass protections. Maybe you did hashing/input validation client side in web application and this was bypassed by the user altering the scripts. Or you have local application that the client tries running in a virtual machine or disassembles to reverse engineer it/alter the memory/ or otherwise cheat somehow.

• Other attacks, including (but not attempting to be a complete list) CSRF, XSS, SQL injection, network eavesdropping, replay attacks, Man in the Middle attacks, buffer overflows, etc. Best protections very quickly summarized.

  • CSRF: require randomly generated CSRF tokens on POST actions; XSS: always validate/escape untrusted user-input before inputting into the database and displaying to user/browser
  • SQLi: always use bound parameters and limit how many results get returned; eavesdropping: encrypt sensitive network traffic; replay: put unique one-time nonces in each transaction
  • MitM: Web of Trust/Same as site last visited/Certificate issued by trusted CA
  • Buffer Overflows: safe programming language/libraries/executable space protection/etc).