How do unzip programs check if the password is correct?

Thinking of it as "password protection" slightly misrepresents the actual situation.

What happens when you password-protect a zip file is that the archive is encrypted using a symmetric algorithm (same key to encrypt and decrypt) using the password as the key.

The unzipper program "checks" whether the key is correct the same way I check whether the key to my front door is correct: If it opens the lock, it was the correct key.

So in this case the unzipper attempts to decrypt the data using the password you provide, and if the output is a properly structured archive, it was the correct password.

(I'm skipping the whole cryptography debate WRT collisions and possible duplicate keys for now; this is about how the concept works in theory rather than a specific implementation that may or may not have flaws)

EDIT: As user MobyDisk points out in comments, in the case of Zip specifically, the structure and the file tree are not encrypted, just the files themselves, as well as checksums for each file. If the password you use decrypts the file, and the decrypted checksum matches, you had the right password.


Security behind "Windows Security" Feature

If you have Windows Authentication on IIS you are effectively allowing the following protocols:

NTLM
Kerberos
Negotiate - which automatically chooses one of the above to use.

If it is your internet users that are getting the prompt, it is most likely that they will not authenticate with Kerberos unless you have internet facing authentication and ticket granting servers. Therefore the response derived from the NTLM hash will be sent over the wire as cleartext. This does not expose the password itself though, but the challenge/response can be sniffed. It would also be possible to intercept and/or modify the session whilst in transit.

To secure this you should implement SSL/TLS so that your server encrypts the connection - it will have a HTTPS URL. This will prevent any eavesdroppers or Man-In-The-Middle intercepts of the connection and authentication data.


These days it's simple to create a phake email claiming to be from zixcorp with buried links to third party websites that have malware payloads waiting to be accessed and deployed.  It's stunning to me that there are companies still using a supposedly secure message system that can be so easily compromised.

But I'm sad to report that it is.  My own bank is apparently sending out secure communications via ZixCorp in the form of a crude form letter with links that the user apparently has to click in order to receive the "secure message" from their bank.  Amazingly these emails don't even have a digital signature!

So, anyone who wants to get access to a huge treasure trove of usernames and passwords just has to craft a form letter email that claims to have secure messages for the reader with a bit fat button that ostensibly claims to be a link to zixcorp and spam it out to the world.  There ya go, job done.  Tsk tsk tsk and shame on any financial institution relying on such a flimsy service.


PCI Complient Storing Credit Card Data On Offline Tablet

As you can read in the PCI_DSS bullets 3.1 and 3.2 you can store this information if it is needed by your business.

You will find in the point 3.2.1 the information you need to store, and as you can read in 3.1.1 as long as you have politics and procedures to treat the information securely and delete it in a secure way, your system will be PCI_DSS compliant.

In the section 3.5 you will find also the rules you must to follow to ensure the password/key you use to cypher/decypher are used in a safe way.

Long story short, as long as you manipulate the credit card information in a secure (and normative) way and store it only the time needed to use them, there is no problem in doing so.


Why is blog spam always written so badly?

The spammers are automatically generating new comments by taking existing comments and running them through a thesaurus program that replaces words with synonyms or related parts of speech. The result is a sentence which makes sense, but has word choices that no native speaker would ever make:

  Where else may I am getting ...

is clearly not something a native speaker would write, but

  Where else could she be getting...

is, and can be transformed by a simple substitution of pronouns and synonyms into the spam text.

This way, even if anti-spam forces have a huge database of known-spam comments, the spammers can generate infinitely many new ones that are plausibly English.

I long suspected this was the case but I recently got proof. I now occasionally get comment spam containing the entire substitution script; it'll be something like:

  I can't [believe/understand/comprehend] the [great/superior/amazing] [content/information/data]...

Since the spammers were likely non-English speakers to begin with, they didn't notice they were sending the script rather than the output.

If you examine a large enough corpus of spam, you can pretty easily figure out what algorithms they're using. It would be an interesting challenge in reverse engineering to write a program that deduces the algorithms used from the corpus.

  I ask because when I first saw it, I thought perhaps they were being genuine but inarticulate.

They fooled you once. It probably won't happen again!

Commenter TildalWave points out:

  none of the sample spam messages OP posted actually endorse any products, or are otherwise promoting any other cause.

Well let me give you an example: here's a comment that arrived a few minutes ago on my blog:

user name:  cuisinart compact toaster review
user url:   toasterovenpicks.com
user email: jeffryshuler@2-mail.com
user IP:    37.59.34.218
Comment contents:
One in particular clue for that bride and groom essential their
own absolutely new everything, actually a surname burned which has a mode,
which render nearly girl thankful recognizing their refreshing surname
therefore distinctively printed.

The product is promoted in the user's metadata, not in the content of the comment. The content is just an attempt to get past the spam filter.  (I suspect that in this case the text is not a mutation of an existing text but rather generated by a Markov process over a corpus of documents about wedding planning.)

Obviously anti-spam forces are on to this one too, which is why this was in my spam filter. My spam filter (akismet) on average lets through one spam for every 705 submitted. Again, that's what spammers are going for; they know that 99.9% of their work will never be seen by anyone. They're trying to randomly explore the space of false negatives in spam filters, a space which is getting quite small indeed.


Web browsing on Windows 2008 R2 terminal server (RDS): IE9 or Firefox? Flash or not?

RDS is just an "exported display". You should allow exactly what you would allow the users to do if they could sit in front of the machine itself. The most important thing is to keep the browser (and the OS) always up to date. For that, I tend to prefer Chrome, which updates itself transparently and can often do so without requiring any browser restart.

I recommend avoiding Flash for a usability reason: Flash is used to animate things, and, as such, implies considerable data traffic between the computer and the display mechanism -- in your case, over the network which connects the thin clients with the base system. Playing a Flash-based video over RDP can be a frustrating experience (of course, if you use gigabit ethernet, this is not necessarily an issue).


Safely decrypting an unsolicited/untrusted PGP message

##Dangers of printing untrusted text

The encrypted message could contain any sort of untrusted/malformed data that could try to exploit my bash environment, my terminal emulator, etc.

When outputting arbitrary text to a terminal, as GnuPG does by default, you are risking the exploitation of your terminal emulator. New vulnerabilities regarding handling of untrusted text being printed are found all the time, and while the most severe vulnerabilities have been weeded out, they are still an issue. One solution would be to pipe the untrusted output through a command that strips non-printing characters.  You can use cat -v for this purpose. From section 3.1 of the coreutils GNU Info page:
-v
--show-nonprinting
    Display control characters except for LFD and TAB using ^ notation
    and precede characters that have the high bit set with M-.

Printing untrusted text while stripping non-printing characters should prevent exploitation of your terminal emulator through mishandled control codes or any other typical avenue of attack.
$ gpg -d untrusted.gpg | cat -v

##Dangerous of decrypting untrusted messages

Any potential vulnerabilities in GnuPG or whatever PGP client I am using could also be exploited by the untrusted data.

This is also a risk. GnuPG is incredibly complex, and any parsing of complex data can lead to exploitation. The only solution would be to run GnuPG airgapped, or in a tight sandbox or properly isolated virtual machine. GnuPG v2 has improved its architecture, allowing the decryption to occur in a process which has no access to your private key, but this is far from a complete sandbox. In general, you should always assume that a sufficiently competent attacker will be able to exploit GnuPG through way of providing you with a maliciously malformed encrypted message.
A quick search turned up several bad vulnerabilities in GnuPG in the past 10 years:

CVE-2008-1530 - Memory corruption via duplicate keys from keyservers allowing code execution.
CVE-2010-2547 - Use-after-free vulnerability in certificate parsing allowing code execution.
CVE-2013-4242 - Side-channel attack revealing private key information to local processes.
CVE-2013-4576 - Side-channel attack allowing acoustic cryptanalysis during RSA decryption.
CVE-2016-6313 - Broken RNG leaking 160 bits of random material, weakening certain key types.

##But what is the actual risk?

Am I going too far with this risk or should I use an air-gapped single-use offline machine to decrypt each individual message, and securely erase it afterwards? What other security controls or practises can I put in place to help?

An airgapped machine would do nicely, but may not always be an option. There is no need to securely erase the messages afterwards, as an unlinked (deleted) message poses no risk. The only reason to try to securely delete something is if you do not want it to be available through forensic analysis.
Overall, the actual risk should be fairly low. Exploiting a popular program requires a certain level of expertise which is unlikely to be used to compromise you through your website unless you are high profile, or very unlucky. There are easier ways to be compromised through an exploit that via GnuPG messages (for example, hyperlinks to compromise your browser, images to compromise image parsers, etc). Even so, there are a few things you can do to reduce this risk with regards to GnuPG:

Decrypt messages using an unprivileged, or better yet dedicated, user.
Strip control codes from decrypted output. Never view raw output with vim, less, etc.
Keep GnuPG up to date at all times so known vulnerabilities will be patched on your system.
Use the virtual terminal and not a terminal emulator. Never use xterm or related forks.
Use AppArmor or similar on GnuPG. Do not run it under a user with X11 access.


Reliability of windows OS security for "program files" safe guard

If you're assuming that the malware is running as a UAC limited user, then you should assume that it has the capability to escalate itself to administrator. Privesc on Windows is trivial, since you can just trick the user into thinking a legit software update operation is occurring and they'll almost always accept the escalation prompt. There are many other avenues for escalation too.

That being said, if you're doing IPC, do it properly - use a named pipe. They're not tied to the filesystem permissions model, and you can set your own ACL on it. Even better, once you've created it and accepted the other endpoint, you can stop accepting new client connections, increasing security.


What's the advantage of passing credit cards via javascript vs. over the server (without saving it)?

The risks are more on the client end of things than your server side. What I mean by that is as a consumer I do not want my data going to your server for "processing" which then gets sent over to stripe/wepay. I dont know how you're transmitting the data or whether or not you're not storing it the way you say you are. Also from the consumer side of things if you're not PCI compliant I wouldnt go near your systems.

If you did however want to do the processing you'd have to find a server side library (of which ive not looked into) and make sure the data being passed is sent securely from the client to you and from you to the transaction handler.

The risks are the same on both sides, MITM. If I know my connection to the service is safe why would I risk using your system as a MITM?


Did I miss anything when checking for passwords?

Forensics is a very interesting field to get into because it really all comes down to detective work. First finding the breadcrumbs, then following them to their conclusion. You're definitely off to a good start. As was mentioned by a commenter, the program strings is very handy. It processes a binary file looking for sequences of printable ASCII characters. Using it you can often find text segments of databases or executables and sometimes very handy data.

I would also try taking the next step and move on to trying out an actual forensics examination tool. The Linux tool Sleuthkit, and the web interface Autopsy, are fantastic free tools for doing this kind of work. You'll also want to look more in-depth at the technique called File Carving, with some of the available tools listed on this wiki page. Since good file carving doesn't always depend on certain file system data structures being intact, you will be able to find a lot more files than a simple undelete will.

Since most of the good free tools are Linux based, you'll need to have an acceptable working environment. If you don't, then try your hand at using the BackTrack LiveCD. It is a Linux distro specially designed for use by penetration testers, and to a less extent forensics examiners. It ships with both Sleuthkit and Autopsy, as well as a large number of file carving and other forensics utilities.


Is there such a thing as a modern cable modem without an onboard operating system?

I think you have some X/Y conflicts in your reasoning behind the question.

Modems do not need an operating system. What you are calling a modem (with a web interface) is far more than a modem, which requires an "operating system".
The operating system you are supposing is not a "whole operating system" but an embedded form of an operating system (likely with a custom kernel) to supply the necessary functions.
The operating system is not "hacked" in your threat scenario, but rather the externally-facing services are.

So, with these reframing points in mind: There have been many different cable modems without the extra features like the ones you listed. The problem is that they only allow a single device to connect to it, so they have not been a popular product since adding a hub, WiFi, and NAT functionality have become the norm.

That last point is the practical one. If you were able to find a dumb cable modem, you would need to attach a multi-function WiFi access point, router, hub, and a means to manage these features. So, what do you do? You chain the modem (basically a layer 1/2 device) to the router (layers 2+). Now you have exactly the same threats as you did before, but you now need to buy an extra device for the privilege.

Want to limit your risk with your existing modem? Turn off all services to the Internet, put in a very long admin password, and turn on the highest security for the Wifi.


HTTPS connection issue on Chrome/Chromium/Opera

Thanks for StackzOfZtuff's help, I found the problem finally.

While connecting to a server with a self-signed certificate, the Chrome would show "Your connection is private", and we can keep going by clicking "Advanced" and "Proceed to XXX". However, even the website is loaded, but the chrome would create many SSL connections and disconnect some of them after handshake finish.

By analyzing the Chrome event by "chrome://net-export" and "chrome://net-internal", it shows the socket is closed after SSL handshake and an error "ERR_CERT_AUTHORITY_INVALID" shows.

I tried to disable the SAN(Subject Alternative Name) check of Chrome first (because my mbedTLS doesn't support creating a certificate with SAN now) and import the certificate manually to Chrome, then the Chrome can connect to my httpd without certificate warning message and the Chrome would no more drop the connection.


How does Google not care about "spaces" in Application-specific passwords?

Passwords are sent plain text, that's why you use SSL to set up a secure connection so no-one can sniff your communication. Suggest you would send a hashed password, it would still be able to just sniff the hash and forge a request, since the server would be expecting a hash instead of the password. (which is basically just a string again)
Storing hashes is primarily done to make sure when the database is
hacked/looked into they can not see your password and try to re-use
it on other accounts/services.
They possible strip off spaces before hashing the password. As you say yourself, keeping a password's hash for every possibility where a white space could be, would storing multiple hashes. Or the password is always constructed of four groups of four letters. Then it would be easy to first remove all spaces and then just split it up again in 4 groups of 4 letters.


But that means that XSS is not for cookie stealing anymore?

In short, no, XSS isn't used to steal cookies when this flag is set.

The longer answer is that modern browsers support the HttpOnly flag on cookies. This flag can be set when the server sends a Set-Cookie header to the browser to keep document.cookie from getting the contents of cookies. It is a mitigation technique to the larger problem of XSS. As far as I am aware, with up-to-date browsers and current versions Flash, Java, and other plugins, there's no way to bypass this flag.

However, because you have XSS, there are other ways to get access to credentials without getting access to the cookies.


How to code for "Establish and maintain control over all of your outputs"

It simply means you should not only check your Inputs (encoding, sql injection, xss, etc) but also you should validate and check your outputs (again for example XSS) so that if your input security mechanisms fail and/or your server sends "garbage" (PHP Error codes presented to the end user for example) you´re still on the safe side.

For example if you got a Web-Application like Twitter, you should not only enforce security checks on inputs by Users (their tweets) but also on the output of your server to users (the tweets of others they see) so that if your input control failed, the output control still recognizes that something went wrong/is a possible threat

IMHO your own link explains everything very well:

https://cwe.mitre.org/top25/archive/2011/2011_mitigations.html#Mit-M2


Should I let users pick their own secret questions for password reset?

Basically, people are rubbish at coming up with questions. They come up with things like "Type 'secret'" or "My name" - they're worthless at best, and actively harmful at worst ("Usual password" - the answer to the question will tend to be stored in plain text...). Even pre-determined questions are fairly bad - they tend to either be easily guessed, or easily forgotten (for example, if you ask "What was your first car?", and your site caters for 18 year olds, it's a matter of looking on Facebook and there is almost certainly a photo of them with it...).

Best practice is to email a password reset link to the stored email address (avoiding exposing whether the entered address exists or not), which is time-limited and one-use. You can then ask a question if you want, but since you have already verified that they have access to the email address associated with the account, it's probably best to assume they know anything that might commonly be emailed (address, date of birth, partner's name, etc.), so it may not add much, if anything, in terms of security.


Is UUID v4 cryptographically safe for passwords?

UUID4 does not rely on the machine's MAC address, from the documentation:

  If all you want is a unique ID, you should probably call uuid1() or
  uuid4(). Note that uuid1() may compromise privacy since it creates a UUID > containing the computer’s network address. uuid4() creates a random UUID.

However, UUIDs of any kind do not promise to be cryptographically secure as it is not guaranteed in the RFC. Certain implementations may use a cryptographically secure random number generator, but I wouldn't rely on it. I would choose to use another library if that is what is needed. If you are using Python3 you can use the secrets library which has functions for doing just this.


Most applications that issue DNS queries do so through common OS-specific libraries. There was a recent vulnerability that impacted multiple linux distributions:

https://access.redhat.com/articles/2161461

There is a body of work on fingerprinting OSes by the DNS traffic they initiate, e.g.

http://intrusion-detection.org/papers/Matsunaka13DNSFingerprint.pdf


I'm unfamiliar with the details of the systems you specify but understand email encryption in general. Once a message is encrypted, the system cannot re-encrypt it with a stronger algorithm without user intervention as the system can't decrypt the email to re-encrypt it. So you're email is frozen in time in terms of the encryption that was used.

Even if the system did re-encrypt the emails with user help, that doesn't guarantee security as the encrypted email can have had many copies made of it that can't be retroactively re-encrypted.

In fact, your concern about emails becoming insecure as stronger processing power becomes available is true for all encryption. Consider an SSL connection between a browser and a website. If I could record all of the traffic and was really patient, I could come back with my wizzy-fast quantum-plus whatever processor and decrypt it quickly. Given enough time, my password safe will become hackable and SHA-512 will be easy to crack.

The solution is that cryptographers have crystal balls (or at least they pretend to) that allow them to predict how fast computing power is likely to be N-years from now. When determining what crypto algorithm to use, one is selected that will be secure for at least as many years as the data is expected to continue to be sensitive.

Some assumptions are made here that may or may not be true:

Cryptographers can predict processing power. This is made easier by the fact that they don't need to be accurate. They only need to figure out the worst case for increase in processing power.
Data becomes less sensitive over time. If the data is always going to be sensitive then you are going to need to do more than just encryption to secure it. For example, encrypt it and never put it on a public network and burn the computers that handled it when you're done.
The strength of a crypto algorithm is accurate. Unfortunately, sometimes crypto algorithms are less secure than we think and cracks can be found that require less computing resources than a brute-force attack.

As an example of this timeout, this statement is made about 3DES:

  This is not currently practical and NIST considers keying option 1 to be appropriate through 2030

This is why 3DES is considered weak encryption. 2030 is just too soon to be interesting.

So no crypto lasts forever. Secure email is just one example of this.


Brute Force RDP Attacks Despite Having RDP Restricted to 1 IP - HOW?

This can happen often with Domain Controllers.

Do you have a Domain Controller? If so, on the DC, enable the netlogon.log debugging file (via elevated cmd prompt):

nltest /DBFlag:2080FFFF

Now, go to %WINDIR%\debug\netlogon.log and open it up. You'll be able to see the user(s) attempting to log in, and which machines they're attempting to log in to. It may turn out that you have other systems on the network which are trying to RDP into those systems using Active Directory credentials.

You should be able to track down the offending server with the above data. My guess is something connected to the DC is exposed to 0.0.0.0/0:3389, like an AWS server that remotes into your network using a VPN. May want to check your AWS security groups.

It could really be anything, though. You'll want to find this server before it becomes a pivot point.

Having said that, none of the Wireshark tips in this thread will detect this behavior unless you're on the system being RDP'd into - which is likely not the DC. You'll need to go straight to the DC logs and find out for yourself where it is.

To disable netlogon.log debugging later (via elevated command prompt):

nltest /DBFlag:0x0


First of, let's look at your input:

'   <-- this closes the quoted string
;   <-- this closes the SELECT statement
--  <-- this comments out the rest

This doesn't actually make that much sense. Even if your run_query_find_all function supports multi-queries - which is unlikely - why would you want to create a new query just to comment it out? [It actually shouldn't cause a problem, but it's also not needed, and it's always good to keep your payload as simple as possible; complexity makes it difficult to see where the actual errors are]

This means we can simplify your payload to '--.

Now we have this:

'   <-- this closes the quoted string
--  <-- this comments out the remaining characters, so that we have a valid query

We still get an error though. The MySQL comment documentation explains why:

  From a --  sequence to the end of the line. In MySQL, the --  (double-dash) comment style requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on).

You need a whitespace character after the double-dash comment. So either add it, or use a different comment character:

'-- -   <-- will work
'#       <-- will also work (URL encode as %23 if needed)

Note that I added another character after the whitespace to avoid the whitespace being trimmed.


What are the realistic, and most secure crypto for Symmetric, Asymmetric, Hash, Message Authentication Code ciphers?

The recommendations you cite are kind of overkill. One point to take into account is that beyond a certain level (e.g. on key size or hash function output size), all functions are "unbreakable with foreseeable technology" and it is a bit delicate to compare them. Stating that SHA-512 is "more robust" than SHA-256 means that you are imagining that SHA-256 could be broken, which, as far as we can tell for now and the next 40 years, is not true (beyond 40 years, trying to envision what technology we could have is risky; 40 years ago, nobody was imagining the Internet as it is today, but most people assumed that by 2010 we would all drive flying cars).

AES-128 is already secure enough, and less expensive (AES-256 uses 14 rounds, while AES-128 uses 10 rounds).

The currently largest broken RSA key is a 768-bit modulus, and it took some huge effort (four years, and really big brains). 1024-bit keys are considered usable for short term security, although larger keys are encouraged. 2048-bit keys are appropriate. Using a key twice larger means 8 times more work for signing or decryption, so you do not want to overdo it. See this site for a survey of how RSA key length can be related to security.

ECDSA over a 256-bit curve already achieves an "unbreakable" level of security (i.e. roughly the same level than AES with a 128-bit key, or SHA-256 against collisions). Note that there are elliptic curves on prime fields, and curves on binary fields; which kind is most efficient depends on the involved hardware (for curves of similar size, a PC will prefer the curves on a prime field, but dedicated hardware will be easier to build with binary fields; the CLMUL instructions on the newer Intel and AMD processors may change that).

SHA-512 uses 64-bit operations. This is fast on a PC, not so fast on a smartcard. SHA-256 is often a better deal on small hardware (including 32-bit architectures such as home routers or smartphones).

Right now, cheap RFID systems are too low-powered to use any of the above (in other words, RFID systems which can are not as cheap as they could be). RFID systems still use custom algorithms of often questionable security. Cellphones, on the other hand, have ample enough CPU power to do proper cryptography with AES or RSA (yes, even cheap non-smart phones).


Asymmetric Encryption Digital Signatures

The message digest is a hash of the original message.  You can't reconstruct the message from the digest.

Bob computes the digest and compares it to the one Alice sent him.  If it matches, Bob knows that the message hasn't been changed, since any change in the message will cause a change in the digest.  He also knows that the message came from Alice, because he can decrypt the digest with Alice's public key.

The message itself is not encrypted because Alice wants it to be readable by multiple people.  The digest lets everyone know that it really was Alice who sent the message.


Where are the anonymous/private domain validation SSL certs?

While there doesn't appear to be any existing privacy-friendly CA at this moment, all evidence suggests that the recently-announced Let's Encrypt CA (launching summer 2015) will not require users to provide personal information.  This could change, but I doubt it will given EFF's involvement.

If Let's Encrypt will not collect any personal information when it launches, then that suggests that existing CAs do not fundamentally require your personal information, and that they ask for it simply because they can.


Is it possible to determinate which functions a kernel module calls?

Trusting kernel drivers is bad.

Oh? Why? Almost everybody does this. Whether it is a Windows kernel driver or a Linux driver doesn't matter. Furthermore: they are an extension of the kernel, and if you don't trust device drivers, why trust the rest of the kernel?
In general, we trust the OS we get. We take some precautions to make sure it is correct (for example: we download from a trusted source, buy it from Microsoft/RedHat/Apple/... etcetera). The kernel drivers are part of this. Of course, if you need specific hardware (e.g. graphics cards), you may need to use a driver from the hardware manufacturer. If you do not trust him (f.e. you fear that there may be NSA/Chinese/Russian/... backdoors in it), don't  use that hardware.
The example you gave is, as you said, for system calls. On Linux, some additional info can  be found in man 2 syscall.
In general, it is far easier to look at the source code, if it is available, than to look at the binary. Disassembly or decompiling may seem a viable option, but (for example if you're on Windows) check your license.
The kernel drivers in general run in privileged mode. That means that almost everything is possible.


HMAC is a Message Authentication Code, which is meant for verifying integrity. This is a totally different kind of beast.

However, it so happens that HMAC is built over hash functions, and can be considered as a "keyed hash" -- a hash function with a key. A key is not a salt (keys are secret, salts are not). But the unique characteristics of HMAC make it a reasonable building block for other functions, which is what happens in PBKDF2: that's a key derivation function, commonly subverted into password hashing (a role for which it appears to be adequate). PBKDF2 includes a salt, and internally invokes HMAC (several times).

Good password hashing must be slow (in a configurable way) and include a salt. These characteristics are not easily obtained, and you will not get them out of a lone HMAC (which is fast and does not use a salt).


Does it increase connection security if I regenerate the dhparam files
  used with NGINX on our servers periodically e.g. every week?

No, not significantly.
DH parameters are really just a large prime that takes a lot of time to be generated (because it needs to be a safe prime). Additionally there's a so-called "generator", but this one is cheap to generate.
Right now it is impossible to break a DH connection negotiated with a 2048-bit or longer safe prime. Thus if you regenerate your safe prime every week you gain no extra security beyong "unbreakable". However this should not be confused with generating your own proper (strong) parameters once. This is to make an internet-scale Logjam attack much more difficult, but as I already said is optional as the parameters can't be broken anyways.

  What issues may arise from this?

More computational load. Generating the parameters is probably one of the most intense cryptographic computations you will encounter.

  Is there any benefit in doing this?

You gain something like "super-forward-secrecy". With ephemeral Diffie-Hellman, the attacker needs to break each connection individually to recover plaintexts. The per-connection load can be reduced when applying the Logjam trick of doing one giant pre-computation for the parameters and only doing the last step for each connection. If you change your parameters regularly you limit the impact a Logjam-style attack could have. However, running the algorithm required for Logjam is infeasible for DH parameters that use long primes (e.g. 2048-bit or more) .


Corporate Domain-Joined PC Used in China

It's hard to find any reason why it would be advantageous to sending someone with a non-domain joined PC as opposed to a domain joined PC.

Domain joining a PC has several distinct advantages

Administrator can control update policies to software and anti-virus
Administrators can control firewall settings and VPN tunnels / routing
Policies of all sorts can be forced upon the machine easily and centrally administered (admittedly this can be done with some MDM's)
Full Disk Encryption can be enforced on the PC

I'm not sure why you would think there is any security disadvantage to this machine being domain joined.

SIDE NOTE : Simply working on the Internet in China poses no additional threat to your system than anywhere else in the world. I'm not sure why people have the misconception that as soon as your laptop hits the Internet in China it will be infected with MalWare. Keep your PC locked, don't hand it over to anyone without witnessing what they're doing to it and pay attention to certificate errors and you (or your employee) should be fine.


Why is 3DES not used to store passwords?

Site owners should not have the ability to instantly see every single user's password (and possible every password they've ever used on your site) - many users share passwords, and you don't need to get into their bank account.

Nor do you need to be accused of getting into their bank account based on having their password.

Should an attacker get your database password list somehow, the only thing they need them is your encryption key to get 100% of all passwords, nearly instantly, regardless of password strength - "12345" and "abDPZJg2$f3e4^po6aB]s67Kbfd;:vIr4}52Fqa\~Rep`,>ioNuJ" will be found in the same time (and at the same time, for practical purposes).  With properly hashed passwords, "12345" remains worthless.  However, with even the weakest cryptographic hashing algorithm, that long, random password will be an incredible challenge.

Even if an attacker does get your database password list but not your encryption key, you'll be on major security sites who tell you that your methodology is a giant disaster, just like Adobe when they leaked over a hundred million 3DES encrypted passwords.

Don't encrypt passwords.  Hash them, using a password hashing function like PBKDF2, BCrypt, or SCrypt with a random 8-16 byte salt and as high an interation count or cost/work factor as you can afford during expected peak times.  Wee How to securely hash passwords? for more detail.


What kind of attack vectors are made possible as a result of Java being hopelessly intertwined with Android?

Android is essentially a huge Java virtual machine. There is the core operating system, the kernel running a virtualization system called Dalvik, and Dalvik runs a bunch of applications. Java is easy to exploit, many bugs have been discovered since Androids inception that allow breaking out of dalvik sandbox, you can google "Android dalvik CVEs" or "Android JVM CVEs" to see some examples. All the underlying security of linux is made less effective because of this. In 2010 security researchers were able to upload a malicious Angry birds game app to Android Marketpkace that invisibly downloads other apps without users permissions. Yes Android CAN be hardened for security, but not without compromising the user experieince.


Is "Please update/confirm your email address" actually helpful?

Besides the obvious UX values, this practice (if done correctly, like Steam) actually helps to mitigate stolen accounts.

This is what Steam does with all e-mails (both on update and periodically)

Ask user for email / Ask user is email is still valid for him/her.
Validate email selected with a one time token that is transmitted to given email address.
User uses 'link' / 'token' to validate email retrieval (this does NOT require authentication, nor does it AUTHENTICATE the user)
Steam notifies user that said email is now considered valid for the user and will be used for security announcements regarding its account (login tokens for 2FA, suspicious activity etc.)

Now, since a lot of people use their provider's e-mail account, there are many cases where this changes over time. These steps help to notify the user of what email is being used, validates that its mail server is still up to par and working for said user (this is done through strict mail delivery settings on the MTA of Steam). And that the user can actually receive notices when something security related happens to the user (a breach or loss of password or something).


Problem finding a vulnerability in memcpy

There are several problems in the code:
The first one is that the target username is shorter than the source msg and that thus a long msg can cause a overflow of username. But given the code this results only in flowing into msg, i.e. no crash.

More interesting is the following part:

    int i;
    ...
    i = read(STDIN_FILENO, msg, sizeof(msg)-1);
    memcpy( username, msg+2, i-2);

If int i is 0 or 1 this will cause i-2 as the last argument of memcpy to be negative (i.e. -2 or -1). Since the type of the last argument is size_t which is usually unsigned this negative signed value will be treated as a huge unsigned value. Thus in effect the code gets on platforms with 64 bit size_t when i is 1:

    memcpy(username, msg+2, 0xffffffffffffffff)

This way the copy will quickly reach memory areas which don't belong to the process so that a segmentation fault occurs.

The needed values for i can be reached by either just closing the input (i=0) or giving exactly one byte of input (i=1, i.e. no additional new lines or similar) with for example

    echo -n "u" | ./crashme


openssl: does -keyform engine enables accessing TPM persistent handles with any key arguments ? Even with third party plugin like CMP?

I am not sure to fully understand the question, but I recently encountered a similar situation.

I did not found evidence that it is possible to use TPM persistent handle in OpenSSL command in place of file path for keys. OpenSSL is not made to fully interact with the TPM, it can only use the tpm2 cryptographic calculations through the engine.

To know if an engine can work with some OpenSSL extensions like CMP, you can run openssl engine -t -c tpm2tss, it will return something similar if the engine is able to communicate with the TPM:

(tpm2tss) TPM2-TSS engine for OpenSSL
    [RSA, RAND]
        [ available ]

RSA and RAND are for example the OpenSSL commands supported by my OpenSSL TPM2 engine.

And for the purpose of -keyform engine, it indicates OpenSSL to use the key format proposed by the engine. In the case of the TPM2 engine, the keyform is a custom TSS format, a PEM-like format with the TSS key encoded inside, and when I looked up in the code, the struct of for example the TSS private key appeared to be:

typedef struct {
    ASN1_OBJECT *type;
    ASN1_BOOLEAN emptyAuth;
    ASN1_INTEGER *parent;
    ASN1_OCTET_STRING *pubkey;
    ASN1_OCTET_STRING *privkey;
} TSSPRIVKEY;

Source (Github)

It stores additional TPM related information in this custom format.

To finish with, I did not find lot of information about the use of the TPM2TSS engine to share, this is mainly what I ended up with through my experimentations.


Bypassing x-frame options possibility discussion

As I understand it this guy reads all content of a website and then displays it in his iframe.

He literally downloads the site's content and prints it out on his own page. This means that the content he downloaded afterwards belongs to his own domain.

But whole the idea of a clickjacking attack is that you embed a site from a different origin in a frame. For example, a  simple clickjacking attack could be that I embed https://facebook.com/ in a hidden frame on my site and I position the frame in a way that as you click anywhere on my site, you actually click inside the frame and, say, involuntarily like one of my Facebook posts. Obviously, Facebook prevents this scenario by supplying an X-Frame-Options: DENY header.

However, if I proceed as in the blog post and download the Facebook page to my own domain to then embed it in my own frame, that would be pointless because clicking around in my downloaded copy of the page would not trigger any action on the real Facebook site.

  An attacker then tricks a user to click on his link to a site that has an url similar to mine (e.g. mys1te.com).
  The user thinks it is my site and logs in

What you describe sounds more like a phishing attack. Copying the content of a different page and making it look similar to the original will always be possible.


Suricata Ripple20 rule for IP-in-IP resulting in 100M alerts

At first, I thought that ip_proto:4 was going to match on IPv4, but that's not correct.
IP protocol number 4 is IP-in-IP, which is what the rule is supposed to report on.
So, for both rules, it is inspecting all IP traffic, regardless of direction or destination for IP-in-IP traffic.
Suricata's documentation on ip_proto.
Why are you getting 100M alerts? Because, according to your comments, you are using IP-in-IP. So, this is not surprising in the least.
This one rule is only going useful in networks that do not use IP-in-IP. All the rest of the rules for Ripple20 can still be useful for you.


Password manager vs remembering passwords

I wrote this last year on the pro's and cons of password managers:

Pros:

Great balance of convenience and security - people tend to choose simple passwords and the reuse the same password (or base) because there are so many of them and you have to enter them so often. With 1Password or Lastpass you can generate a truly strong password (at least for your critical accounts) but still have the convenience of having it auto-filled or at least available written down on your phone. A real benefit is also in things like secret questions, this is commonly a weak point where a really strong password has a 5 letter dictionary word as a secret question answer. You can now generate strong secret question answers also
Portability - the problem with using your browsers save password function is that unless you combine it with something like Google or Firefox sync it is not portable. Even then it is currently not available on your phone (at least not the iPhone, not sure whether the Android browser has Google sync)
Secure storage - your sensitive information is encrypted in storage and protected by a master password. This is a lot better than just writing it somewhere or storing in a note or unencrypted spreadsheet
Not just for passwords - you can store bank details, insurance numbers, credit cards, passport numbers, etc which can save you time entering in these details and provide you secure access to the details on move. You can also store files like scans of your documents or your private keys
Improve your memory - on sites I hardly ever use, and government sites with those complicated usernames I can never remember these details. Launch up the iPhone, 1Password and everything to hand with easy search
People also add anti-phishing / anti-malware to this list but that one I don't agree with. You still have to enter your master password which malware can capture, if you have it on your phone and enter the password again it can be captured. If you launch websites from the tool I guess it could be anti-phishing but that's the same as typing it in directly or using your bookmarks

Cons:

Single point of failure, keys to the kingdom - if you sync your keychain to your phone or have it on your desktop or laptop some could get access to that. If your master password is weak then you lose everything in one go. As far as I'm aware 1Password does not offer a hardware based two factor authentication option for the master password which would reduce the risk of this significantly. Lastpass does offer a using a yubikey as a two factor mechanism but because Lastpass has a web application it can suffer from web application vulnerabilities (e.g. XSS) which could leave your account details and at worst case passwords exposed.
Terms and conditions - it is still technically 'writing a password down'. This maybe against the terms and conditions on things like your Internet Banking site. This may reduce or remove any protection you get in case of a fraud. You can always check this and not store the password for these sites
Trust in the cloud - it is supposed to be encrypted in storage but if you do synchronize the data some people will never trust that 1Password or Lastpass does not have a backdoor, potentially allowing a malicious or disgruntled employee access. All software has vulnerabilities, again a serious one could allow an attacker access to your data

Another option is to use a password vault stored in a hardware encrypted device like an Ironkey. Versions come with a password manager loaded in. It is a little bit less convenient as you have to attach it to a USB drive and have read access to this but it is definitely more secure. It mitigates some of the risks highlighted above, it is hardware encrypted and only stored on your device. Also if your Ironkey is on your physical key chain you are far less likely to lose it than your phone or laptop. You can also remotely destroy it if you do manage to lose it.

For the online remote destruction you need the enterprise version of the key. The remote destruction is a feature in the management console. When the key is plugged in it, it phones home. If the destruction has been activated, at that stage it becomes unusable and all data is effectively lost (believe by trashing the decryption keys). There is also an offline mode (similar to an iPhone), where you can set it to auto self destruct after 10 failed master password attempts.

Conclusion

Overall I believe the pro's outweigh the cons. If you have no option for two factor authentication then having a strong password is your only defense. Using a password vault just makes this a lot more practical and convenient.

There is no reason why you could not keep half the password in a password manager and remember the rest, it would make it more difficult for a key logger to capture your password, however the trade-off for usability may not be worth it. A better option maybe to use two factor for your really sensitive information and a password manager for the rest


What is the difference between active reconnaissance and scanning/enumeration

Active Recon -- doesn't matter if touching or not touching any
infrastructure -- the important part is the recon comes first in
order to determine the target(s) which normally consist of company
and partner names, employee names, identification of technology
vendors in use, identification of public IP ranges, primary
top-level domain names, email address structure, et al (think mindmaps or scratch pads)
Enumeration -- this is the second stage that produces a
narrowed-down list of specific IP addresses, port numbers, hostnames, bulk
lists of email addresses, etc to be used in later stages (think structured ASCII lists or relational databases)
Scanning -- the last stage automates against the enumerations to get
further information. It is typically a client-server
request-response paradigm using tools such as nmap, curl, SET,
msfconsole, et al where the responses include the desired
information (think robots that do your dirty work for you)


How to tell if a SSL certificate is deployed correctly and check if it is working?

Use SSL Labs
For a first test, run the URL through SSL Labs:

https://www.ssllabs.com/ssltest/ (Be sure to check the Do not show the results on the boards checkbox.)
Or try HTBridge: https://www.htbridge.com/ssl/ (Be sure to check the Do not display test results in statistics checkbox.)

This will tell you if the certificate is correctly installed when looking at it from the outside.
Keystore alias probably won't matter
Now concerning the "keystore alias": That is only visible from inside the server. So you will have to ask the developers of your specific software if their software cares about the alias. (I don't think it should care about it.)


How long (in letters) are encryption keys for AES?

An AES 128-bit key can be expressed as a hexadecimal string with 32 characters.  It will require 24 characters in base64.

An AES 256-bit key can be expressed as a hexadecimal string with 64 characters.  It will require 44 characters in base64.


mod_spamhaus whitelist example to allow a range of ips

I spent a good half an hour searching the web and found absolutely no documentation regarding your question, neither in English nor in Italian (mod_spamhause author Luca Ercoli is Italian). We're not entirely out of luck, though. The mod_spamhause code was published on-line and we can have a look at how filters are handled in this unit. The part of the code relevant to your question is (in C++):

if ( (strchr(lista[count],'/') == NULL )){
  if ( strcmp(lista[count],r->connection->remote_ip) == 0  ) return 1;
}
else {
  sscanf(lista[count], "%[^/]/%u", ippi, &bitmask);
  sscanf(ippi, "%lu.%lu.%lu.%lu", &a, &b, &c, &d);
  first = (a << 24) + (b << 16) + (c << 8) + d;
  mask = (0xFFFFFFFF << (32 - bitmask));
  last = first + (~mask);
  first = htonl(first);
  last = htonl(last);
  in.s_addr = first;
  sscanf(inet_ntoa(in), "%d.%d.%d.%d", &a_min, &b_min, &c_min, &d_min);
  in.s_addr = last;
  sscanf(inet_ntoa(in), "%d.%d.%d.%d", &a_max, &b_max, &c_max, &d_max);
  sscanf(r->connection->remote_ip, "%d.%d.%d.%d", &a_daverificare, &b_daverificare, &c_daverificare, &d_daverificare);
  if (
     ((d_daverificare <=  d_max) && (d_daverificare >=  d_min)) &&
     ((c_daverificare <=  c_max) && (c_daverificare >=  c_min)) &&
     ((b_daverificare <=  b_max) && (b_daverificare >=  b_min)) &&
     ((a_daverificare <=  a_max) && (a_daverificare >=  a_min))
  ) return 1;
}

It's quite straight-forward, but if you don't read C++ then let's just sum it up that it will accept both individual IPs as well as CIDR ranges, formatted same as Apache does.

To answer your question then, according to this code, you can add a CIDR range 123.123.0.0/16 (that covers IPs 123.123.0.0 - 123.123.255.255) as a single line in your /etc/spamhaus.wl like so:

123.123.0.0/16

The published code would handle CIDR notation, however we have no way of knowing this code is actually in use with your mod_spamhaus build. If it doesn't work for you then I'd suggest you search for other builds, or compile your own version using SourceArchive.com published code.

Cheers!


AES encryption between Java and Ruby: what is the default mode and padding for AES in Java?

The default mode of operation and padding isn't defined by the JCA Standard. Each provider is free to provide different default values. As you can imagine, relying on the default values is completely unreliable so you should always explicitly set the mode of operation and padding.

For Oracle JDK 7, the default for AES is AES/ECB/PKCS5Padding.


Recommended options for LUKS (cryptsetup)

You might want to use PBKDF2 with SHA-512. This step is for converting your password into an encryption key (more or less directly). This is inherently open to offline dictionary attacks, and relates to the password hashing problematic. For that, you want to maximize the effort of the attacker by choosing an algorithm and iteration count which will make the task hardest for the attacker while keeping it tolerable for you; "tolerable" here depends on your patience, when you type the password at boot time.

Attackers will want to use some GPU and/or FPGA to speed up their attack, while you use a normal PC. Nowadays, normal PC are at ease with 64-bit arithmetic operations, and run SHA-512 about as fast as SHA-256; however, GPU much prefer 32-bit operations, and mapping them on FPGA is also easier than 64-bit operations. Therefore, by using SHA-512 instead of SHA-256, you give less an advantage to the attacker. Hence my recommendation: on modern hardware, for password hashing, prefer SHA-512 over SHA-256.

Remember to adjust the "iteration count" so that the time taken to process your password is at the threshold of the bearable: higher iteration counts mean longer processing time, but are proportionally better for security.

For actual encryption, you will want XTS, which has been designed to support disk encryption efficiently. This indeed shows in the benchmarks; this is for a SSD and you do not want the encryption to be much slower than the underlying hardware. Note that XTS splits the key into two halves, only one of which being used for the actual encryption. In other words, "aes-xts" with a 256-bit key actually uses 128 bits for the AES part. And that's good enough. There is no rational need for going to 256-bit keys -- i.e. 512-bit in the context of "aes-xts". 256-bit keys for AES imply some CPU overhead, which the benchmarks duly observe (300 MB/s vs 375 MB/s). With a SSD under the hood, you really want a fast encryption system, so do that.


how to check what process connects to my squid

Finally found the problem - of course it was firewall.

I use droplist from this tutorial and put rules iptables -I FORWARD -j droplist somewhere in the middle of rules. But this rule has to be first rule

#!/bin/bash
_input="/root/blocked.ip.db"
IPT=/sbin/iptables

$IPT -F
$IPT -F nat
$IPT -A INPUT -P DROP
$IPT -A OUTPUT -P DROP
$IPT -A FORWARD -P DROP

$IPT -X droplist
$IPT -N droplist
egrep -v "^#|^$" $_input | while IFS= read -r ip
do
    $IPT -A droplist -i eth1 -s $ip -j LOG --log-prefix "IP BlockList "
    $IPT -A droplist -i eth1 -s $ip -j DROP
done

# Drop it
$IPT -I INPUT -j droplist
$IPT -I OUTPUT -j droplist
$IPT -I FORWARD -j droplist

and the rest of the rules


(a) a desktop CPU can do roughly 1000 passwords/second.
(b) a desktop GPU (graphics processor) can do roughly 80000 passwords/second, or 80 times the speed of a CPU, or 30 days to crack your hypothetical password
(c) a cluster of 8 GPUs is 8 times the previous number, or 8*80000 or 640k passwords/second, or 4 days to crack your hypothetical password
(d) Amazon EC2 uses older/slower GPUs

You say "not dictionary word", but it's more complicated than that.

The "dictionaries" used by password crackers aren't the "English dictionary", but dictionaries of known passwords. The most common dictionary is the list of 20 million RockYou passwords. These were passwords chosen by users of a website that was hacked. Once hackers broke in, they published all the passwords, so they form the basis of cracking dictionaries. This is many times larger than an English dictionary, and contains such things as "ncc1701" (Star Trek ship designation).

Furthermore, cracking looks at "mutations" of dictionary words. Thus, while your password may not be in the RockYou list, it might be a near match that will eventually be found.


Not unless you know the correct password. VeraCrypt works by trying each hash and cipher combination with your supplied password one-at-a-time until one of them works, and tells you that your password is incorrect if none work. Without the correct password, you can't even tell if it's a VeraCrypt volume or not.


Does MAC address filtering provide security?

MAC filtering doesn't provide an high security. An attacker can simply see which devices (and their relative MACs) are connected to your network, and spoof one of theese MACs. When he changes it to his machine, he can connects to your network without any problem. In conclusion, MAC address filtering doesn't increase your security.


Well my first thing to check would be are you sure you didn't give anyone else even temporary access to your machine? I seems very odd to me for someone to remotely log you in to their google account.

Second solution. It's possible that Google Chrome was originally installed on your machine by somebody else who logged into google chrome, and then when it was uninstalled it failed to clear the saved login data from the last user, meaning that when the program was reinstalled the browser automatically picked up on the saved login data.

Your best bet is to speak to your IT team. It's possible you aren't the first owner of that company laptop and it's extremely possible that it wasn't cleared correctly. It's probably nothing malicious.

With regards to the software that you said was installed on the machine, it looks to me after a brief glance to be a remote monitoring program without the functionality of remote administration, so therefore unlikely it was used in this case.


Security purpose of asking admin password to mount partition on Linux

When I wanted to access the NTFS partition fedora asked me for my admin password to mount that partition. Why does it do that? What security purpose does it have?

As everybody else has said, you must be the root user to mount partitions, barring some special exceptions such as defining the partition and setting the user flag on the entry in /etc/fstab.

Why this is important to restrict is because mount can layer any mount point on top of any other directory, or even just one directory tree on top of another. With permission to run mount, I could put /home/jeff/bin on top of /bin using mount /home/jeff/bin /bin -o bind. Suddenly everybody is using the version of su, ls, or anything else I wish from my directory.

As doing the above would demonstrate, mount points don't need to be empty. Everything in a directory that is mounted on top of simply becomes unaccessible. Mount is capable of turning just about anything into a directory structure too, not just partitions. Loopback filesystems and remote network drives are also possible mount sources.

So, in multiuser system, one isn't able to walk all over the filesystem structure using mount because it would completely break security restrictions and any assumption that files are coming from the location you expect them to be because somebody could simply mount one directory to mask another.


Can you exploit an application that imports a vulnerable library, but does not actually use the classes from the library?

Yes, this can be done under the right circumstances via deserialization.

Your jar file must have a serializable class which can be used in a gadget chain
Your jar file must be on the classpath
An attacker must be able to provide data that your application deserializes

The attacker provides that data, referencing the class in your jar file in the serialized stream of data.

There are lots of articles and videos available on deserialization and why it's an issue.  You might find https://github.com/trendmicro/SecureCodingDojo/ useful as well.


What are the dangers of storing webserver temp files in the /tmp/ folder?

The greatest concern is that an attacker can use a temporary directory to store executable code,  which is a useful foothold when exploiting your system.   Almost always the /tmp has very open privileges,  such that any process can write to them (chmod 777).  As an example, I took advantage of this property of /tmp when bypassing AppArmor to obtain remote codex execution in PHP-Nuke using a Local File Include vulnerability chained with a MySQL's into outfile.    File uploads are also commonly stored in /tmp which in PHP can also turn a LFI vulnerability in to remote code execution.

Regardless of platform there are two permission strategies you must adopt.  The rational is that an attacker is going to use your application against you and there for is limited by what the application can do.

The web application must never have write access to any file
    or folder within the web root or any of the application's executable
    files.  An attacker will use this to introduce a backdoor or to
    perform drive-by-download attacks on clients.
A web application must never be able to execute code that is not
in a file within the application's directory.  never use
eval(), it is often a dirty shortcut and leads to remote code
execution.  In PHP you can set the open_basedir configuration
option such that it can only include files within your application
directory.  You can also disallow access to eval() and other
exploitable php functions using hardened-php.


Why Windows allows Administrator login via RDP by default?

Starting at least with NT4, Windows uses the notion of domain of administration, and the administration of a machine is normally done through the network. This is a general design decision: if you know an administrator account of a machine (or of the domains it belongs to) and if the system has not be tweaked to remove default services, you can have access to any disk through the administrative shares (\\HOST\C$), you can connect to its registry, and you can generally manage its users and shares.

The RDP follows same principle: if you are allowed to administer a machine, you should have all priviledges on it. Simply you can also allow other users to use it in addition to the administrators.

Be it or not a best design is another question, but it is Windows general design.


Procedure of tranmission of original virus

If it's a flash video that's malicious, and your flash player is vulnerable to that particular attack, than it does not matter where it comes from and where you watch it. It's enough to play it to give access to your PC to the attacker.


understanding where tor interferes (screenshot)

Tor works by routing the traffic through many nodes between you and the host. Here is a good diagram


Public Key Encryption vs HSM for storing encryption keys

There are two different, but related problems here.  One is the security of the key; the other is the security of the data decrypted by the key.

An HSM and "a separate server" are essentially the same thing from the point of view of your app server.  It's sending the encrypted data "elsewhere" for decryption, but the cleartext data will end up back in your app server.  The app server will always need enough protection to protect against an attacker inside it, siphoning off your secrets.  So you can ignore the security of the cleartext data in making this choice, because the cleartext problem is the same regardless of which option you choose.

Let's consider HSMs first.  It's usually true that protecting the key is more important than protecting any one single piece of data (unless leaking a single piece of data could result in a catastrophic loss); and that's where an HSM is a very good tool for the job.  The drawbacks of an HSM approach are that they're quite expensive to purchase, maintain, and operate.  They're usually priced on transaction throughput, so the more data you need to decrypt at a time, the more expensive the HSM.  Any accounting for the expense also needs to include the complexity needed to interact with it - you'll probably spend a lot of time learning how to use it, how to perform key ceremonies, integrating it into your existing systems, etc.  But you'll have the best protected keys money can offer.

On the other hand, if you build your own server to perform the decryption of the data, you'll have to spend time hardening it against attack, issuing certificates to authorized app servers, performing audits, etc.  And be aware that an admin on the machine will always have enough access to get to the key.  (This is not true of an HSM that requires a number of shares of a master key in order to access the keys, meaning a number of trusted people would have to collude to violate the security.)  So building your own server will cost less than buying an HSM, but it isn't cheap; and the key is at more risk than an HSM.  It's especially problematic if you don't know how to properly secure it.

Given all that, it becomes a matter of money vs risk. (Welcome to Security!)  How critical is it to your organization's continued existence that you secure those keys?  What security classification have you given to the data stored in those emails?  Will it store data in scope for PCI, HIPAA, SOX, GLBA, or some other regulated industry?  Does your data contain industrial secrets so valuable that a foreign government might bring all their resources to hack into it?  Does it protect so much money that you would go bankrupt if a hacker siphoned it off?  Will stealing from the database put your organization out of business?  Next, price out buying an HSM vs building and securing your own decryption server.

If the answers to the above add up to "it's not really worth all this", then you have to consider more affordable means of securing it.


Utility of Output Chains in IPTABLES when there is no Network Firewall-- Is it ok to permit all outgoing connections from a server?

It is a good idea to have secure egress rules for your server. This can protect against an attacker gaining a reverse shell.

  Remote shellcode is used when an attacker wants to target a vulnerable process running on another machine on a local network or intranet. If successfully executed, the shellcode can provide the attacker access to the target machine across the network. Remote shellcodes normally use standard TCP/IP socket connections to allow the attacker access to the shell on the target machine. Such shellcode can be categorised based on how this connection is set up: if the shellcode can establish this connection, it is called a "reverse shell" or a connect-back shellcode because the shellcode connects back to the attacker's machine

If there are any vulnerabilities on your server and you have secured the ingress rules to prevent the attacker running another service and then connecting to it, it is a good idea to prevent the attacker from connecting to other hosts from any sort of access gained from your machine. This will reduce the risk if you are running things with the rule of least privilege. That is, they may not have root but they could then do other things such as downloading tools and/or exploits from their own machine over the network or internet with a view to privilege escalation. Locking down outgoing connections can significantly reduce this risk.


Unless the VPN provider guarantees it, and possibly not even then, you shouldn't assume that the data just moves from Bob's VPN to Alice's VPN without passing over the wire unencrypted within the VPN provider's facility.  It may even pass over the open internet if the VPN provider has multiple, distributed endpoints.

If Alice and Bob want a guaranteed, encrypted connection they should use a VPN directly between them leaving the provider out of it.  The downside of this is if they set things up directly there won't be a nice prepackaged installer from the VPN provider so the scope for making mistakes is increased.

If the networks in country B are being monitored the people monitoring will be able to see that Alice is using a VPN, roughly how much data she is sending an receiving.  They may be able to infer more through traffic analysis.  They won't be able to see what is being sent and received though.  If it is the government doing the monitoring Alice may get a knock on her door.


Can anyone bypass preg_replace for SQLi in my app?

There is no reason to implement your own sanitization logic in 2016. As Aria points out, you can just use mysqli_real_escape_string if you want to sanitize.
The key here is that this is NOT a 100% effective means of preventing SQLi.

The proper way would be to use the mysqli library to parameterize queries, because this renders first order injection impossible! You might see a lot of recommendations to use PDO to make prepared statements. It's important to note that prepared statements are not the same as parameterized queries. Prepared statements are just statements passed to a module that does the sanitization for you.

That's not to say sanitization isn't useful, it just isn't useful for preventing SQLi. You should still do it, though, to prevent stored cross site scripting. Strip out anything that a browser might recognize as HTML or JS or CSS if you're storing any untrusted input that might be displayed in a page.

TL;DR Parameterize your queries to protect from SQLi; prepare them to protect from stored XSS.

EDIT: I just noticed that your regexp doesn't seem to account for semicolons or dashes, so I could achieve injection against it quite easily.


Cloud-specific standards and regulations

There are no Cloud-specific ones I am aware of, however you should definitely think about SoD:

Most Financial Audit regulations require Segregation of Duties (SoD), and generally these are relatively easy to manage in a traditional environment. In a virtualised environment (I'm looking at the wider scope of 'cloud' here) front and back office IT may end up being managed by the same individual or team, and may actually be on the same server, so when viewed from an audit perspective there is an increased risk of insider fraud. Regulations like Sarbanes-Oxley do require strict controls around segregation of duties, despite not being explicitly worded for IT in virtual environments.

Data Protection regulations are also likely to present an issue. Despite not being cloud specific, these regs tend to require that personal information remains within specific jurisdictions (eg Europe, US, UK) and if you have a standard 'cloud' there may not be any controls to restrict where data is actually stored. For example, if I wanted to store UK personal customer data on a cloud that is partially in the US I could fall foul of the UK's Data Protection Act 1998.

In terms of client expectations, cloud is often touted as being very resilient, due to its distributed nature, however outages do occur, and when they do, you are entirely reliant on the cloud provider sorting it out "in the cloud". See Amazon's April 2011 outage for an example.


Do I need Gateway Firewall for IoT network?

Yes, you still need a firewall on your end. In the case of a DoS/DDoS, your connection would potentially be flooded to the point where your devices would not be able to establish the IPSEC tunnel and would therefore not function [properly].  If the firewall only exists on the cloud side, that does nothing for your service at your house/office.

A DoS/DDoS attack will probably not be stoppable no matter what equipment you have since it's happening at the connection level.  Typically with a DoS/DDoS you deal with it further and further up the path as close to the source as can be.  For example, you call your ISP so they can block it from getting to you, then they call their provider to have them block it before it gets to them, and so on.  It can only be blocked so much before someone is left to take the hit but that's usually at the backbone level where they have more than enough bandwidth to deal with it until it is dealt with by other means (like finding the people causing it and stopping the attack).


What threats and mitigations are there for a CA when processing a CSR?

CA's usually don't use the originally provided CSR and just sign it. Instead they extract and verify only the information they want to include in the certificate from the CSR (i.e. public key, subject..), add some additional information like expiration, CRL distribution point, OCSP URL etc and then they sign this newly created CSR. This way the CA does not need to deal with OID or similar it does not understand since these information are not included in the generated certificate anyway. It only needs to understand and verify the parts it will include from the original CSR, i.e. only  few parts. And these parts usually have a well known syntax which can be enforced, for example a domain name.


Basic question about why it's useful to have VPN encrypt traffic

The internet is a mesh of telecommunications lines run by different companies which are leased by ISPs which use them to sent traffic from customer to customer. Any one of the ISPs or telecommunications companies can sniff the traffic that goes over their lines or network devices in ways you cannot detect. Some governments have forced (or paid) ISPs to install traffic sniffing devices to collect traffic going through their networks, and others could have been breached by state sponsored or organized crime funded hacking groups.

There's really no assurance that anything going over the web is in any way secure, which is why companies use VPNs to encrypt traffic between offices and SSL is used for websites to protect browsing traffic.


GPG encryption subkey on multiple smart cards issue

I guess you will have bad luck, and this is not supported by GnuPG. When using OpenPGP smart cards, a secret key dummy is stored in your keyring, holding a reference to the smart card it is stored on. The secret key subpacket looks like this when displayed through gpg --list-packets:

:secret sub key packet:
        version 4, algo 1, created 1358985314, expires 0
        pkey[0]: [2048 bits]
        pkey[1]: [17 bits]
        gnu-divert-to-card S2K, algo: 0, simple checksum, hash: 0
        serial-number:  01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
        keyid: 9FF7E53ACB4BD3EE

Peeking at the code, it does not seem to me more than one serial number would be supported.


SGC is server gated cryptography which allows older browsers (e.g., 40-bit security) to connect to 128-bit; see for example: http://www.sslshopper.com/article-say-no-to-sgc-ssl-certificates.html

But anyways the certificate for www.google.com was issued by:

CN = Thawte SGC CA
O = Thawte Consulting (Pty) Ltd.
C = ZA

and Thawte SGC CA was issued by

OU = Class 3 Public Primary Certification Authority
O = VeriSign, Inc.
C = US

which your browser probably has as a trusted certificate authority.


How to reverse engineer str_shuffle (PHP) to get its mt_rand outputs

According to PHP 7.2.7 sources, the str_shuffle function uses php_string_shuffle which does

while (--n_left) {
    rnd_idx = php_rand();
    RAND_RANGE(rnd_idx, 0, n_left, PHP_RAND_MAX);
    if (rnd_idx != n_left) {
        temp = str[n_left];
        str[n_left] = str[rnd_idx];
        str[rnd_idx] = temp;
    }
}

So I guess you would like to know the intermediate values of rnd_idx (since php_rand() is an alias of php_mt_rand()).

But RAND_RANGE is a macro defined as #define RAND_RANGE(__n, __min, __max, __tmax) (__n) = php_mt_rand_range((__min), (__max)) so the 1st value of the php_rand() is already instantly lost.

Hence, you won't get the list of all intermediate mt_range() values.

Still, knowing that the algorithm there seems to be at each round, swap the current letter with a random letter before in the input string; the 1st round takes the last letter as the current one; the next round takes the letter previous current letter as the new current letter then you can get the mt_rand value by reasoning backward.

If ABCD is the input value and BADC is the result, then it means the values were 2;2;0 (ABCD => ABDC => ABDC => BADC) but you still don't know the value of the "lost" calls to php_mt_rand. So the sequence of mt_rand was actually ?;2;?;2;?;0 which matches the seed 4 and 25: if you do mt_srand(4); echo str_shuffle('ABCD'); then you'll get BADC and same if your seed is set to 25. You would need a pretty long chain of unique characters to get a sequence long enough to match only one seed.


Shouldn't netstat show connections from many different IP addresses during a DDoS, unlike this example?

Great question. The answer is, maybe.

There are multiple reasons why an internal host might see 1 IP in place of many, a big one being load balancers. Load balancers have been a problem for internal monitoring for quite some time. They act as a full proxy (typically) and basically it's impossible to tell where any connection started from because all you see is the LB IP.

To answer a separate question in here, UDP would be most common also for connections in DDOS. TCP doesn't "reflect" in the sense of if you want to pretend to be a different server and try to TCP connect, the 3rd part of the handshake won't go to you, it will go to the spoofed IP and be dropped breaking the connection.


As the article describes it, VM introspection looks like inspecting the contents of the VM in real-time, to see that everything appears to be "in order". Virtual machines allow for such inspection without consent or knowledge of the guest system. This contrasts with classic antimalware software on physical systems: the antimalware runs on the system itself, so it is reachable by successful malware; indeed, when some virus or malware succeeds in taking control of a given machine, its first task is to deactivate any antimalware software on the machine, and prevent installation of such software, so that the malware can keep on controlling the machine.

Thus, classic antimalware software must reliably block malware upon entry; if they miss one, they have lost. On the other hand, with a VM, the antimalware could run on the host, outside of the guest, thus impossible to deactivate by malware who subverted the guest system. That's the VM introspection concept. It may possibly "clean up" an infected machine.

It is like surgery. Self-surgery is, let's say, difficult. In particular, invalidating illnesses may make you unconscious, thus unable to heal yourself. An external doctor, being healthy at that time, is still able to help you.


Am I using RfcDeriveBytes correctly, when the salt I'm providing it contains the password?

Why is using the password as part of the salt a problem?

Because you need to store the salt separately from the hash of the password. You can either do this by encoding them in a specific way, such as storing them as $Rfc2898$iterations$mysalt$myhash or by using dedicated database tables.

If you would go with the scheme you proposed (crating a random salt, appending the password and hashing it with SHA-512), then an attacker would not need to crack the 100000 rounds of PBKDF2 at all. Why? Because you provided them with what is essentially SHA-512(password, salt). The fact that you later use this data as input for a more computationally expensive form of hash doesn't matter, because you need to save this data for further verification?

But what if I just save the random part of the salt and then mix the user input in on-the-fly?

Yes, you just proved that mixing in the password gives you no security gain whatsoever. All you need is the random part!


This is an ill-worded attempt at explaining RSA signatures. The basic operation - modular exponentiation - is the same for all RSA operations. So in that sense you can think of RSA signature verification as "decrypting" with the public key.

However, both the type of key as the message padding are an integral part of RSA operations. They are required to secure RSA operations. RSA padding is different for encryption and signature generation, even if both are informally called PKCS#1 v1.5 padding. The input parameters are generally also different; the signature generation requires the padding to be applied on a specific formatted hash value internally.

Public and private key operations differ in several ways. Both use modular exponentiation. However, private keys require additional protection to make sure that the secret components that make up the private key aren't leaked through side channel attacks. Private key also used a large exponent or multiple values that allow calculations using the Chinese Remainder Theorem (CRT). Saying that signature generation is encryption with the private key is therefore a very dangerous statement; internally they should be quite different operations.

I would urge you to simply read the RSA PKCS#1 v2.1 specifications in RFC 3447. They are quite readable, and they make a clear distinction between the various primitives in section 5.2:

  The main mathematical operation in each primitive is
     exponentiation, as in the encryption and decryption primitives of
     Section 5.1.  RSASP1 and RSAVP1 [EDIT: for signature generation / verification] are the same as RSADP and RSAEP [EDIT: for decryption / encryption, in that order]
     except for the names of their input and output arguments; they are
     distinguished as they are intended for different purposes.

This was different for PKCS#1 v1.5 and earlier versions of the PKCS#1 standard. The change in wording in PKCS#1 was very deliberate. Unfortunately the confusion remains when it comes to the OID that specifies an RSA public key, even one that is used for signature verification:

{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsaEncryption(1)}

This is a legacy of the older PKCS#1 version 1 standards, I'm afraid.

For more information, also see https://crypto.stackexchange.com/q/15997/1172.


False Positives- Server side protection against XSS

First, what htmlspecialchars() and similar functions do isn't removing dangerous code, it's encoding data as HTML.

So, what htmlspecialchars does not do is the following:

Receive data
Find dangerous HTML code and replace this by harmless code
Return the sanitized data

But it does the following:

Receive data
Convert this data to HTML, so that when this code is displayed it will look the same as when the original data would be viewed without being parsed by an HTML parser.
Return the HTML code

➥ You can see the difference here

Additionally, since you're asking this, you may be misunderstanding where XSS prevention should be applied. Encoding data as HTML shouldn't be done when it is received, but when it is outputted by the web server.

So, you should not be doing it like this:

Server receives data from a client
Server escapes the data as HTML
Server processes the data
Server outputs the data to the client

But like this:

Server receives data from a client
Server processes the data
Server escapes the data as HTML
Server outputs the data to the client


The work factor only applies to some hashing algorithms, so you still need to find a reliable way of identifying the hash - and most hashes are pretty much indistinguishable in terms of output, beyond having set lengths:

539080ba278cf4cf4db2e4a32642ff30
8d777f385d3dfec8815d20f7496026dc
042636dba1586150f13670473360ca06
2eb9b7b30492034d392888f72ace81a1

are all 32 character hashes of the same input. The only way to tell which is which is to try hashing them all with functions which produce 32 character output (128-bit, in Base-64 representation).

Since the work factor needs to be known in order for the legitimate user to be able to recreate the hash, it has to be stored in some way. For example, bcrypt hashes have the cost included as the second parameter:

$2a$04$BsM7V0W/.V5z.p//XMUJeu.C537J/XoMYYKuCV8vDBq65KgKiDH4.
$2a$12$noxpk3amerDxXofuz4ViS.nOsnK4TWqXnmlfj6Y8b71ERVeZ7Bj5G

In these (which hash the same string as before), the cost for the first example is 4 (2^4 key expansion rounds), and for the second is 12 (2^12 key expansion rounds).

For other algorithms, it's usually part of "common representations", else it has to be stored in code, which tends to be more difficult to update should advances in hash calculation mean that increased work factors should be used. If you've only got the raw hash, without the other parts, the only way is to brute force your way through possible work factors...


There aren't any. Access control is not based on having a strong primitive that you layer everything else around (like how confidentiality and authentication are done).


Peculiar, but you're not the first person to ask about it, and there's even a suggested implementation for CSRF protection there + the code hosted on github. I can't really vouch for this mechanism though, haven't really inspected it too closely.
Interesting question. It does seem to me that phpbb went a little over-the-top with the implementation, but there's some logic behind it. The salt alone wouldn't be enough, because in the phpbb case, the user_form_salt value is a static per-user value, which doesn't change for that particular user. This means that once this value is known/disclosed (and there are probably many ways in which this value can be leaked or obtained), then all user forms can be compromised. Forever (or more precisely for the duration of this salt, but it doesn't change typically). The method implemented there has the advantage that the value constantly changes, yet it is 'reproducible' by the server for checking without having to store it anywhere. It uses existing stored data + some random elements to generate the CSRF token. I am not too sure but am guessing that using, e.g. hash/HMAC of the time with the some internal (not-exposed) random session variable as key, would achieve the same result.

Lastly, just a short note about your comment regarding XSS and CSRF. You said that

  An XSS vulnerability would permanently compromise the CSRF protections if the form salt was used directly whereas with a hash of time and the form salt protects against that scenario.

Basically, an XSS vulnerability has the potential to compromise ANY CSRF protection. If the attacker is able to execute code with the user session, they have access to all form data, however well protected it may be.


Main problem with sharing the same private key between several servers is that it implies that, at some point, necessarily, the private key travelled. The more a private key travels, the less private it becomes. But, of course, that's a general comment; actual context details matter.


Why doesn't DNS spoofing work against HTTPS sites?

Assume you managed to poison the DNS cache for securesite.com with an IP that you control. Now, when the client visits https://securesite.com, it will resolve to your IP address. As part of the SSL handshake process, your server will need to send a valid certificate for securesite.com which contains the public key.

At this point, you have 2 options.

1) Send the legitimate certificate. This will check out since the certificate is signed by a trusted CA. The client will then encrypt the master secret using the public key. It breaks down at this point, because without the private key, you cannot decrypt the master secret and thus you can't finish the connection setup.

2) Send a self signed certificate. However, since it is not signed by a trusted CA, a warning will show on the client's browser. If the client choose to proceed anyway, then you have successfully carried out the attack.

DNS spoofing will generally not work on HTTPS websites unless the client chooses to ignore the warning signs or if you manage to obtain the private key for the site.


Why is the x509 standard for certificates called "x509"? What is meaning behind "x" and/or "509"?

X.509 is a standard number/index defined by ITU-T, telecommunication and standartization commitee.
X stands for Data networks, open system communications and security standards track and every standard has a number. X.500-X.599 standards define directory services (such as DAP, LDAP, etc.). And 509 is just a number of standard in X track.


Full disk encryption on dual boot system (Truecrypt/Veracrypt)

In an ideal world, I would like to introduce a third boot loader, loaded before Grub, that handles the decryption of the system partitions

As this would be a nice solution, the problem is that a bootloader does not pass a mounted (decrypted) partition to an operating system. It is loading the kernel into memory, starting it and passing a few parameters to it. However, you can encrypt your Grub boot partition and embedded a crypto key into the initramfs for Linux and LUKS (GRUB early crypto disk feature [1]). You could probably implement a similar solution for grub & VeraCrypt & Windows, e.g., grub loads a crypto key file from the encrypted boot partition into memory and VeraCrypt using it later. In that solution, you only have to enter one password during boot. To the best of my knowledge, this does not exist. And if you have mounted your boot partition, your unencrypted keys lie on the partition. So your ideal solution would be only possible with hardware encryption/BIOS/UEFI today.

Alternatively, you could let one party do the encryption for both operating systems, but this only works with virtualization. E.g., you could install Fedora and Windows on a Xen Hypervisor and let Xen do the disk encryption. You probably need non-virtualized hardware in Windows for running CAD programs, but this is not a problem anymore with PCI pass-through [2]. This is pretty complex to set up and requires deeper knowledge in Xen but has the advantage that both systems can run simultaneously. The performance overhead with hardware virtualization is pretty small today. A good starting point is [3].

[1] https://wiki.archlinux.org/index.php/GRUB#Boot_partition
[2] https://wiki.xen.org/wiki/Xen_PCI_Passthrough
[3] https://wiki.xenproject.org/wiki/Xen_Project_Beginners_Guide


Are the elliptical curves in ECDHE and ECDSA the same?

However regarding the usage in browsers is there any difference between the curves used in ECDHE and ECDSA?

No, there probably is not. As the key establishment and certificate verification is likely to be in the same crypto API it is pretty likely that the same curves are supported (or not).

  Do browsers support the same curves for every elliptical curves algorithm?

That's pretty likely because of the same reasons.

  Do they possibly even always used the same curve for ECDHE and ECDSA in TLS_ECDHE_ECDSA?

The curve for the ECDSA part depends on the certificate used. The key in the certificate is static while the ECDH keys are ephemeral. So it is likely that shorter curves are used for ECDH than ECDSA. There is not a direct connection between the two in the protocol, so although the same curve may be used, it is certainly not a given.


CSRF tokens in Single Page Applications (JavaScript/Angular)

In order to implement CSRF protection, you need a token that is secret in the sense that it can't be calculated by an attacker. You can use a modification of the encrypted token pattern from the OWASP CSRF cheat sheet.

You can either use a shared secret key between the front-end and back-end or a public/private key, storing the public key on the front-end and the private-key on the back-end. You then encrypt the user ID and timestamp on the front-end to use as your CSRF token and verify it on the back-end. Instead of encryption you can sign the data using an HMAC or a digital signature. All of the options (asymmetric encryption, symmetric encryption, HMAC, and digital signatures) will produce the desired token properties of being easy to verify but effectively impossible to predict.

The OWASP document suggests that you encrypt the user id, timestamp, and a nonce, but I believe that the nonce is unneeded. See this question and the comment on the OWASP discussion page for more information.


Is there a way to make Tor network your full VPN?

One of the easiest ways to do this, is through the use of visualization.
Where your Host machine runs the TOR client, and starts the virtual environment.

Details of this on the tor.stackexchange.com

Example post :
Running a virtual machine (VM) that can only connect through Tor

This allows you to run apps and sessions inside your virtual environment just like you would on your regular host OS, while safe in the knowledge, "anything and everything in this environment is using the TOR network,"


From the access logs of a service (nginx, Dovecot, etc.), you cannot see whether you were affected or not. Unless you have previously captured all SSL traffic, you cannot see whether you got attacked in the past either.

The pattern to match in a packet capture is very simple:

A malicious Heartbeat request is sent.
An overly long Heartbeat response is returned (for buggy versions).

If the Heartbeat request is not encrypted (i.e. it got sent before the handshake is completed), then the data in the transport layer (UDP, TCP or an extra application-specific layer) is:

18       # Content Type Heartbeat
vv vv    # TLS version (e.g. 03 01 is TLS 1.0, 03 03 is TLS 1.2)
ll ll    # Record length (length of the following data)
01       # Message type (1 = request, 2 = response)
xx xx    # Payload length
[payload]
[at least 16 bytes of padding]

If the payload is not exactly the length xx xx (big-endian), then you were possibly attacked. It would be successful if you get a response back:

18 vv vv    # Same record layer header
ll ll       # Length of following data
02
xx xx       # Same length as requested
[data of length xx xx]

An example command (which requires root) that captures all future data from network interface eth0 until interrupted:

tcpdump -i eth0 'tcp port 443' -w ssl.pcap

You can use Wireshark to investigate the file ssl.pcap. The display filter ssl.heartbeat_message shows all Heartbeats requests and messages. Note: sometimes the SSL filter does not get applied. In that case, right-click a packet, click Decode as.. and select SSL. Since git commit 3f81af22e0116a2f83c0298de7874959b3967da2 (11 April 2014), you can also use the expert filter ssl.heartbeat_message.payload_length.invalid to target malformed Heartbeat requests (if unencrypted).

As for encrypted heartbeats... it is not common to see heartbeats, so when you got one for TCP connections, it already becomes suspicious. Some hints for encrypted heartbeats that may help:

A heartbeat request followed by gigantic heartbeat responses is a sign of a vulnerable server that was successfully exploited.
A heartbeat request not followed by a heartbeat response may signal an attempt to exploit the server, but the server is patched and does not respond.
A heartbeat request followed by an encrypted Alert may signal an attempt to exploit the server, but the server does not run OpenSSL and rejects the invalid request.
A large number of subsequent heartbeats (even if it is small) may be successful exploitation attempts with small payload lengths.


How do I program a function to generate a secure Block Cipher Encryption-Key?

Most block ciphers want a totally random string of bytes as the key. So read the key from /dev/random dd if=/dev/urandom  count=1 bs=256 (or whatever cryptographic RNG you have easy access to).

For ciphers other than block ciphers, for example RSA or ECDHE (on curves other than ed25519), keys are not just random bytes and in fact have a lot of mathematical structure inside them. These algorithms have complicated key generation routines, so you'll need to go find the specification for the algorithm you're trying to implement. These keygen algorithms have been tested by many mathematicians over the years, and as long as you follow them exactly, you should get a secure key.

For example, Wikipedia describes the general RSA keygen algorithm here, but I'm struggling to find an original source technical spec. Maybe that's because what I want is the PKCS#1 spec, which is pay-walled by the RSA company?

https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Key_generation


Can a Rainbow Table find multiple plaintext passwords to match a given hash

Can't a second plaintext string be found which hashes to "482c811da5d5b4bc6d497ffa98491e38"?

Yes - it's even easier than you fear with MD5, which is broken; e.g. it is possible to generate collisions on purpose, although I'm not sure whether it's already possible to generate collisions without controlling the input at least partially.

You may want to google "birthday paradox". It asks: "What's the chance that two persons in a room share the same birthday?" and it's relevant to your question.

It will also give you the math to calculate the chances of hash collisions given the size of the hash function output and the number of elements/passwords you expect to hash. I think a rough estimate that's often used is that you're likely to see collisions after hashing n passwords, where n is the square root of the your hash function output space. So, with your example of a 128 bit hash, that would roughly start to happen after 2^64 hashed passwords (which I'd think is still infeasible to do with today's hardware iff md5 isn't completely broken yet, so there's probably no need to panic yet, but I'd start walking calmly towards the next exit...).

  And thus, can be entered as MY password into adobe.com, and thus gain illegal entry via a legitimate login?

Probably not, since Adobe should know better than to use MD5 to hash passwords and not even use a salt value.

Passwords aren't hashed using bare-metal fast hash functions such as md5 or sha1 or even sha256 any more (at least not by anyone who wants to keep them safe in today's world). These hash functions are much too fast and can be implemented on hardware such as graphics cards parallel gpus (or even more specialized hardware) which can then hash millions or billions of candidate passwords per second  (depending on the hash function used) to brute force a password. You can try it out yourself using a program such as hashcat.

Better options for hash functions are hash functions designed to be slow, pbkdf2, scrypt and bcrypt for example. They do hundreds of thousands of iterations to slow themselves down. The number of iterations can be configured to account for faster CPUs.

Also, passwords aren't hashed "naked". Usually you salt them; e.g. add a random salt value to them; this will make the creation of rainbow tables much more difficult, since now one table must be calculated for each separate salt value.