Which encrypted USB stick is the better option?

What is your threat model? A compromised machine? Do you have infinite budget for this?

If the question is if using a hardware keyboard is more secure than providing the password via software the answer is (usually) Yes. As you noted, a software pin would be vulnerable to a keylogger sniffing the drive password.

However, note that if you unlock this USB in an infected computer, it could as well make a copy of all the files in the usb drive instead of only the pin (or even better, wait until you unlock your Keepassxc database, then exfiltrate the decrypted contents from memory), so it's not too reassuring that a thief got all the protected contents, but was unable to steal the safe passcode, albeit technically you were slightly safer.

On the other hand, perhaps the only thing you care about is that your maid is not a spy which modifies the designs of the new nuclear power plant so it blows up, in which case entering a pin in a hardware keyboard to get read-only access would protect you.

Another point which may compare against the hardware keyboard is the social context in which you will unblock the drive. If you will have to unblock the drive in front of others, how easy will it be to conceal the passcode from them? A good typer can often input in the computer keyboard a long password well-known to him quick enough that other people will probably not obtain it. Whereas a short pincode could be noticed more easily (but perhaps you could unlock it when hidden behind the computer with the excuse of connecting it to a rear port).

You mention that you will (always?) carry that usb with you. While not related at all to its security, you may be interested in how comfortable would be to carry each of them, as the hardware keyboard necessarily results in a bigger stick.

Discretion may be another factor you may be interested in, as a usb stick with a hardware keyboard really stands out.

Or quite the opposite. You goal to get an encrypted usb may be to impress other people (eg. some prospective investors on your company) showing how secure you handle everything, so it must have an external keyboard but also a biometric reader, but it doesn't matter if it's unreliable and they actually allow anyone.

All of this without taking into account the actual security of the encryption itself (Is the drive lying and storing the files unencrypted? Is the algorithm of drive A better than the one of drive B? Are they even implemented properly?). I would recommend having an extra layer of software encryption to counter that (eg. the KeePassXC file in the drive is additionally encrypted, as probably are those certificates).

As the main risk to an encrypted usb drive is unlocking it on an untrusted computer, an alternative to storing your files on an encrypted usb would be to use a small smartphone —completely disconnected— dedicated exclusively to save your passwords and other files (setup disk encryption and all other perks). Being a separate device, you can retrieve the password there and then type it into the not-so-trusted computer for actual use, without fear of compromising the rest of passwords stored there.


Display all packets but not these TCP packets?

The Whole != thing doesn't work very well. If you notice your expression filter text area is yellow when you do that.

Try this instead.

!(tcp.dstport == 3389) && !(tcp.srcport == 3389)

I recommend reading the wireshark user guide. Section 6.4.4 specifically references the problem you had.

User Guide -- Filter Section


Is there a security risk in having my bookmarks publicly accessible?

Yes storing your bookmarks in a public domain could be a security concern. Whether you think the risk is acceptable is down to personal appetite levels though.

Some risks could include:

A targeted attacker can build up a profile of sites you visit, allowing them to pull of phishing attacks easier and other similar social engineering attacks
A bookmark could include querystring data that identifies something you would not want to be made public. Such as an ID for a transaction for example.
You might include a bookmark that you would rather not be made public (maybe you've seen a job at a competitor you want to read later on)


Is a temporary local hotspot on an Android device secure enough for my purposes?

It is unclear why you would think a phone hotspot is any more or less secure then any other form of WIFI hotspot - thr risks are pretty similar.

I guess there is an additional risk of the phone falling into the wrong hands and the password extracted, but this is probably a relativrly small risk, and not that different from the passphrase being extracted/brute forced from decrypting over-the-air handshake data etc.

In both cases you still have protection of using HTTPS, which is likely a more effective security measure then trying to control the WIFI environment. Likewise, in both cades the security used to protect the WII setup is more important then the device providing it/upstream provider.

There are at least 2 fairly easy things you can consider to boost the security of your network -

Run a VPN between the devices and your server /server gateway and ensure data from the devices traverse that VPN.
Run your own CA and remove other root certificates, and, if you are worried about fakr/unauthorisrd data, use client side certificates to authenticate the client back to the server.


Security in handling of user data by mSecure

Is it reasonable? Yes. Is it secure? I can't tell.

I can't tell because security is in the details. The general idea is good but if you badly implement any part it could be insecure, even if the idea was good. So let's focus on the idea here.

Their encryption scheme is based on two parts. A part that you know, the master password, and a part that you own, the account key/email address. Basically, from a security point of view, the account key and the email are nearly the same thing here. If you have access to the email you can get the account key and if you have access to the account key then you don't need access to the email.

In conclusion, what they are trying to say is that they are using two factor authentication. Instead of using a phone for two factor authentication
or another device that you carry around they are using the account_key and email as the second factor. I don't see anything wrong with this idea.


Strange 'agetty' process running on my VPS.

Those are default Linux "consoles" or virtual terminals (VTs), Alt+F1-F6. I don't remember seeing a system that didn't have them installed by default.

You'd disable them by removing them from your init/systemd/upstart/whatever scripts. Documentation for your Linux distribution probably mentions that.


Security differences between fb connect and openid connect

In short: Privacy.

Facebook Connect's service provider is Facebook. Since Facebook is the provider of such service you depend not only on Facebook's reliability but also on Facebook Connect's not being blocked as well in the same countries where Facebook is blocked (censored to be precise).

Moreover, Facebook learns plenty of information about your behavior that you may not want to reveal to Facebook itself (they may offer the service for free but certainly they will analyse your authentication patterns...).
You also depend on Facebook not censoring that particular service you want to use it to log in with.

Facebook Connect is simply an authentication layer like OpenID Connect where Facebook is the sole provider, but it is not open unfortunately. Technically they are likely to offer similar features but unless Facebook reveal any more details, we don't know. If you use Facebook Connect you are relying on Facebook and trusting Facebook. If you use OpenID Connect you rely on an open protocol, with all the public scrutiny that it implies.


Is Google's Hangout using encrypted communication?

Google Hangout uses SRTP (Link):

"All traffic back to the client from our conference servers will originate from the same port that the client is sending to, and be directed back to the port that the client is sending from.

The UDP traffic consists of STUN, RTP, and RTCP packets, with SRTP encrypted data payloads."

And check this for more info: Link


Why is a bad idea to use a common password form?

Reusing passwords across multiple sites is very problematic as a password exposure on one site leads to a password exposure on all of your accounts that used the same password. What you are proposing seems better than using a static password across multiple sites, but it is still rather predictable. If someone discovers one of your passwords they can likely guess many of your other passwords. No matter how careful you are with your passwords, they will be discovered. Sites get hacked and password lists are published.

The only way to ensure password safety is to use unique random passwords that have a provably large entropy (a measure of randomness). This answer discusses randomness as related to password generation.


How to prevent private data being disclosed to unwanted audience over internet?

There are steps people can take to minimize the amount of personal data given to websites.

For example instead of giving your credit card data every time you buy something many sites permit you to use PayPal.

If you are required (or want to in order to gain access) to give a credit card number, you can simply use a Controlled payment number. That way the site never gets your real credit card number.

Here is how to create one.

The real point is that most people do not take the time and effort to fully protect themselves. They much prefer "fast and easy" to prudent and cautious. Protecting yourself takes time and effort as well as research and learning.


How can CPU designers prevent information leaks from speculated execution?

Fixing Meltdown is simple: if the CPU is performing speculative execution, don't read data from protected areas of memory.  The fact that Meltdown is almost exclusively Intel-only shows that it's a design flaw, rather than an inherent side effect of speculative execution.

Fixing Spectre in the general case is much harder.  Spectre is about inducing a program to speculatively malfunction, then observing side effects of that malfunction.  You cannot get rid of all the side effects: even if you could roll back all the caches, buffers, tables, and whatnot, there's the simple fact that speculative execution involves speculative execution.  Running speculative instructions takes a (somewhat data-controllable) amount of time, which can't be undone short of figuring out time travel.

What can be done is to greatly increase the difficulty of inducing a speculative malfunction.  Currently, most CPUs have no concept of "process", and use only part of the address when performing lookups in the branch prediction table.  If branch prediction data is tagged to indicate which process it belongs to, or if the branch prediction table is flushed on each context switch, the ability of one program to mis-train the branch predictor's actions for another program are effectively eliminated.  Similarly, if branch prediction is performed using the full address, a program can't attack itself (for example, Javascript wouldn't be able to use Spectre break out of a web browser's sandbox).


How can I use a unique salt for each user

But how do I know which hash (of all the other hashes in the database) to compare to the user input?

Each user has a row in your database with entries for columns: (1) username; (2) bcrypt output.

Also, if bcrypt could check if it matches without a salt, couldn't anyone do that?

bcrypt can not check without the salt.

However, how do I know which salt to use out of all the salts in my database?

The brcypt output looks like this:
$2b$[cost]$[22 character salt][31 character hash]

So, the bcrypt salt and the bcrypt hash are both stored in the bcrypt output entry that is in your database (and associated with a given username by row).


Short Answer: Mostly Likely Not. Your Traffic will be encrypted.
However, it is possible to read the data by other means.

If the sniffer is some type of malware on either your machine or the receiving end as it could view the data before the payload is encrypted or after its de-capsulated.

If the attacker obtained the SSL certificate and is performing some kind of MiTM attack.

If the encryption key was obtained by other means.

If there is a zero day exploit that can be used against SSL, TLS to obtain sensitive traffic.

Edit:
In addition to your added comment, you would be somewhat correct. Snort is an opensource IDS/IPS and if the data being inspected by the system was encrypted snort would be unable to read any signatures off the traffic. However if there was any suspicious/malicious traffic that could be emanating from the network that could be related to an attacker obtaining the data snort would probably identify the exploit signatures coming and going.


Mac sending hundreds of packets to gateway

Short and simple:

The symptoms that you described fits myscan, read about it here (search for 10101).

You should run a bot-scanning tool and mitigate it.


Are there types of malware that are so time-intensive to detect that AV vendors simply choose to not detect them?

...that they simply choose to not even try to detect because there is no efficient method to do so?

AV does not specifically choose to not analyze some malware since it is too hard. If it would know up-front that this is malware but too hard to analyze than it could simply block it based on this knowledge.

AV simply has limited capabilities and therefore cannot find every malware. These capabilities are limited because the signatures and heuristics are based on knowledge of existing malware. They are limited because the user expects a quick response so that amount of time an AV can spend for analysis is short. They are limited because malware might show its malicious behavior only in specific environments and AV cannot simulate every possible environment. They are limited because it is not always clear if a specific behavior is just unusual or actually malicious - and the user does not like it if the AV blocks innocent software.

But AV or the programs calling AV (like inside a firewall) do usually choose to not analyze files which are unlikely to contain malware in the first place. These might be files of specific types, i.e. something which looks like an image although an attacker might fool the analysis system using polyglots. Or it might be files which are too large, although attackers can exploit this limitation by specifically hiding their malware in large files.


Shellcode getting segmentation fault on vmware

You are executing ARM machine code on an x86 machine. Of course it won't work. If it is giving SIGSEGV (which happens when a general protection fault, #GP(0), is raised) instead of SIGILL (which happens when an illegal or unknown instruction is found) despite being compiled for a different architecture, then the first few bytes of the ARM shellcode must have been interpreted as legal x86 machine code. The x86 ISA is extremely complicated, and any random assortment of bytes has a non-negligible chance of being technically valid x86. While it may have been decoded correctly, it does something totally unintended, which just so happens to trigger a general protection fault before anything that can't be interpreted as valid x86 is reached.


Does removing user interaction create a secure sandbox that nullifies XSS?

While there's a input that anyone can modify, not sanitized and returned to the user we will have a XSS vector.

The "classic" example is the select that receives the option through the URL:

...
Select your language:
<select><script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script></select>
...

So if a malicious user instead of send a standard answer like:

http://www.some.site/page.html?default=French

Send a request like this:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

The user cookies will be shown on the alert.

Some links for reference on DOM Based XSS and how to prevent it.

https://www.owasp.org/index.php/DOM_Based_XSS
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet


Php Wso Shell and Simple Shell returns Blank Page - Why?

In the PHP realms the blank page you are encountering is also known as the WSOD (White Screen Of Death, most probably in reference to Windows' Blue Screen Of Death).

This issue happens when the PHP engine encounters an low level irrecoverable error while no output has been produced yet. The most common cause of the issue it when the PHP file contains a syntax error making parsing fail.

This syntax error is usually caused either by the webshell using a syntax not supported by the PHP version running server-side, or by an incorrect invocation of your PHP code (this is mostly true for PHP injection techniques, but your question gives me the impression you are simply uploading a raw PHP file).

Note that while this are the most common causes, there can be other causes as well, mainly related to specific settings which may have been applied on the remote server.

The solution to get around this is to limit your features to the ones you really need and implement them in a way supported by the remote server. This can be manually attempted by trying to manually create PHP one-liners such as <?php eval($_GET['cmd']); ?> which will attempt to execute any command you provide as cmd GET parameter.

BTW, if you like you can also give a try to my own attempt to write a PHP web-shell targeted at just getting the job done and done right. I wrote it out-of-frustration of several issues I encountered with other more "featureful" web-shells. Feedbacks are welcome ;).


XSS found in the United Airlines website

The CSP will block your JS from a third party website. However, in the event that you manage to find a CSP bypass, XSSObject.proxy will override those functions anyway, because a javascript src runs on the page it is called.


Best practice for using Veracrypt on Dropbox

Unfortunately, I think the answer should be: Don't use a VeraCrypt container with Dropbox, at all.

According to https://www.veracrypt.fr/en/Modes%20of%20Operation.html

  The mode of operation used by VeraCrypt for encrypted partitions, drives, and virtual volumes is XTS.

And also

  In 2010, XTS mode was approved by NIST for protecting the confidentiality of data on storage devices [24]. In 2007, it was also approved by the IEEE for cryptographic protection of data on block-oriented storage devices (IEEE 1619).

However, Dropbox is not a regular "storage device" or "block-oriented storage device"!

In conclusion, as long as VeraCrypt is using XTS, it shouldn't be used with Dropbox. Also, see this question Is it safe to have a TrueCrypt container file synced with DropBox? as well as the blog post You Don't Want XTS.

To quote from the latter mentioned blog post:

  Remember that disk encryption is designed to counter an attacker with very limited capabilities. That’s why it falls to “Evil Maids”: the threat model doesn’t really accommodate attackers with multiple bytes at the (physical) apple. But whatever margin of safety XTS gets you on physical media probably goes out the window when you stick a Truecrypt volume on Dropbox. From the vantage point of Dropbox, attackers have far more capabilities than the XTS designers planned for.


If someone has my email address can they get my IP address?

The question was answered in the comments and summarized here in case someone else comes searching with similar questions.

The email address on its own won't reveal IP address of Sender.

One needs to have access to email sent from given address and email service provider has added to headers sender's IP address. One should note that many service providers do not add IP address of sender. Further, this applies to only emails sent out from a fixed line connections like Broadband or Leased Line etc. Emails sent out of mobile phone connections usually carry the service providers IP address and location information is out of reach for most people.

Edit: As @scott commented one can always find the incoming mail server IP address for the email address in question. If the given domain is hosted on mail services like GSuite, the IP address of incoming mail server will reveal very little or nothing.


Any alternative available for RSA? Is the web still visible to NSA?

There is nothing in the "Snowden revelations" which even hints at any special NSA ability at breaking RSA. Even taking all that Snowden says as gospel, NSA is still at the same point as everybody else, meaning that breaking 1024-bit RSA is "theoretically feasible" but subject to the building of a very special machine whose design has been roughly sketched, which would cost a substantial number of millions of dollars, and, crucially, which would need quite some time (months...) to break every single key. For a 2048-bit RSA key, just forget it.

According to all the Snowden-powered information, when NSA "breaks SSL", they do it sensibly, i.e. not by punching through the cryptography upfront. Instead, they bribe the hosting sites to put spying hooks directly on the clear data, SSL notwithstanding. This is way cheaper, works reliably, and does not require invoking sci-fi level supposed cryptanalytic advances or alien technology.

Building and using RSA-breaking technology for mass-SSL spying would strike me as an extremely inefficient use of budget by the NSA.

Nevertheless, there are alternatives to RSA, and some have been part of SSL since the days of SSL 3.0, two decades ago. With the standard core protocol (called TLS 1.2 these days), you have the DH_DSS and DHE_DSS cipher suites, which involve Diffie-Hellman for key exchange, and DSA for signatures (with DH_DSS, the server's certificate contains a DH public key and the issuing CA contains a DSA public key; with DHE_DSS the server's certificate contains a DSA public key and the DH key pair is produced on-the-fly). Elliptic-curve variants have also been defined. Modern browsers and Web servers support DHE_DSS and elliptic curve variants thereof.

Historically, these alternatives were developed not for security, to fix some perceived or alleged weakness of RSA; they were put into SSL because at that time, RSA was still patented in the USA, and none other than the US federal government needed a patent-free but secure protocol for its own usages.

Now that the RSA patent has expired (more than 12 years ago), everybody does RSA. Yet alternatives are ready, and will be used if RSA appears broken. Which it currently does not, even against NSA.


The simple answer is that any malware that exploited your computer could potentially change a browser homepage. In fact it is easier to do that than a lot of more serious exploits so this may be all it has done.

It could have been a co-worker out to cause trouble or mischief.

The problem is that aside from carrying out a bit of forensic analysis, you can't really tell out of all the possible ways this could have happened which one it actually was. Nor is it really that useful. Your browser can get to many malicious sites - many are created every minute, and if you hit one of them before your antimalware/antivirus knows about it, you can be compromised.

The downside for you is that you should consider your computer unsafe, as you don't know what else the malware has done. Time to wipe and rebuild it.

Then patch it up to date, check your firewall and Antivirus solutions, change your passwords and just chalk it up to experience.


There are a few reasons why EAP is preferred over PSK:

PSK requires the use of a (relatively) low-entropy password, which is (relatively) easy to bruteforce.
PSK requires the passphrase to be stored on the server, which may result in key theft.
EAP allows clients to authenticate using different credentials in each direction, so a server might authenticate itself to the client with a completely type of credential than the client uses to authenticate itself to the server.
EAP allows clients to authenticate using their own digital certificate, which is much more secure than a password. The user just has to unlock their certificate (or certificate store) using their password on the local device.
IKEv2 supports EAP-only authentication, which theoretically allows any form of add-on authentication mechanism to be used.


SSLv2, enabled on a SSL server, is a potential vulnerability only if all of the following are true:

There is some client who wants to connect to that server and exchange sensitive data through that SSL tunnel.
The client agrees to use SSLv2 too.
The client and server don't implement the version rollback detection system described in RFC 2246, section E.2.

Under all these assumptions, then an attacker may force server and client to use SSLv2 even though both support SSLv3 or more. This in turn may imply some weakness depending on the underlying protocol (the biggest issue with SSLv2 is lack of verified termination, so attackers can force silent truncation, which is a problem if the underlying protocol is not self-terminated).

Given what you say, it is highly improbable that these "SSLv2 support" is a problem in your case.

However, a more interesting question is: what are these servers anyway ? Why would a machine operate a network service, ready to do SSL, if there is no intended client at all ? Why not switching off these unused services ? The issue is not a question of SSLv2 vs SSLv3, but more a question of having network-capable services open for no good reason.


He knows the wep password because he set it up in the first place.

Firstly, WEP? If you are using WEP, anyone who knows how to download some tools and owns a laptop will be able to  see your network traffic. WEP is terrible.

  Can he actually see the websites I visited? The URLs? What else can he see?

Basically, if the guy is on the same network as you, he can see everything you do. If the websites you are visiting is being served through HTTPS, he will not be able to see the exact data you are sending but he will still be able to tell where and when you visit the site.


OpenSSL x509: Is there an order in subjectName fields?

In the subjectDN field of a certificate, there is the certificate owner distinguished name, which is nominally ordered. Its definition really is a SEQUENCE of SET of name elements, so it is an ordered sequence of unordered sets of elements. It is quite rare to have several name elements in the same set (I have seen it done to put the Common Name, First Name and Last Name together, as three elements with the same level).

The ordering of elements in a distinguished name relates to why such names were defined in the first place: as an indexing path into the Directory. The Directory can be envisioned as a world-wide structure that references everything; its main problem is that it never actually existed. Shrunk, diluted, local versions of the Directory do exist: they are called LDAP servers (or "Active Directory" in the Windows world). For some usages, you may want to mind the order of fields in the subjectDN if the software that uses the certificate will really connect to some LDAP server and use the subjectDN to get more data about the certificate owner. This is a rare case. In fact, even in Windows + Active Directory (which is very keen on using LDAP), when a certificate is mapped to an account, the account is usually located with the UPN, which is a Microsoft-specific type of name located not in the subjectDN, but in a Subject Alt Name extension; the subjectDN is then really used only for display purposes (the Common Name element of the subjectDN is shown to the human user).

When using certificates for SSL servers, the order of name elements in a distinguished name does not bear any specific meaning. The issuerDN of a certificate must be identical to the subjectDN of the certificate of the CA that issued it (and in particular must have the elements in the same order), but beyond that there is no order to follow. The SSL client (Web browser) will (at most) extract the Common Name element, regardless of where it appears in the sequence, and disregard all other elements.

To see the order of name elements in a subjectDN, you can use openssl asn1parse as indicated by @StackzOfZtuff in his answer. Making the issue more confused is RFC 4514 (that replaces the older RFC 2253): this is the standard representation of a DN into a string, to be used in LDAP context. For some reason, the string representation was defined to list the name elements in reverse order:

   Otherwise, the output consists of the string encodings of each
   RelativeDistinguishedName in the RDNSequence (according to Section
   2.2), starting with the last element of the sequence and moving
   backwards toward the first.

Nevertheless, when using openssl x509 -text -noout to display the contents of a certificate, OpenSSL will show the subjectDN and issuerDN as strings in a format which is very close to RFC 4514, except that it follows the order of appearance of the name elements in the encoded certificate, not the "reverse order" mandated by RFC 4514.

"Names" may also appear in the Subject Alternative Names extension. That extension is defined to contain a SEQUENCE of GeneralName, i.e. it is technically ordered. However, nothing in X.509 attaches any semantic to the order of names; in fact, this extension is defined to use a SEQUENCE OF and not a SET OF mostly because encoding a SET OF with DER rules is more expensive (you have to sort the names lexicographically). The order in which the various names in a SAN extension appears has no influence whatsoever on the validity of a certificate, and should not change anything in application behaviour.

Of course, any given software may fail to do things correctly. In a SSL context, it is common for several names of type dNSName to appear in a SAN extension: the browser will scan all the names until it either finds a name that matches the expected server name (as it appears in the URL), or runs out of names, whichever comes first; this behaviour, implicitly, does not ultimately depends on the order of names.


buffer/heap overflow - register of what is executed

will ESP point to the start of the exploit codes (which will be some combinations of shell codes and gibbersih)?

Actually, its the EIP that will point to the start of the exploit code instead of ESP. In a classic stack buffer overflow, ESP will continue to be where it would have been with/without exploit code. The only thing that you overwrite is the EIP changing it to a different address in memory - where you've already 'planted' your exploit code somehow.

To illustrate lets see the diagram of a stack and note values of various registers:

Lets assume there is a exploitable buffer in the callee function where an arbitrary amount of data can be provided (gets, rougue srtcpy etc.).
The attacker calculates the exact number of bytes before the place on stack where the return address (EIP) is stored. So the input could be of form (each block corresponding to each red line below).

AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA 0834FD4C

where 0834FD4C is the new instruction pointer attacker wants to plant at the saved EIP location and preceding A's are just pads to reach to the EIP (remember stack grows down).

After the overflow, lets say the stack looks like this:

At this point, attacker has successfully planted the new EIP. Whenever the callee function returns, the ret instruction will pop the saved EIP (now 0x0834FD4C) to %eip register and the control flow will resume from this memory address and will start executing whatever instructions it finds there. Again, the attacker has to make sure that he has planted the exploit code at this location beforehand.

Post callee return:
EBP : Can change or cannot change based on what attacker provides in the data of overflown buffer. Remember that since he has to tromp EBP before he reaches EIP, certainly he'll have to provide a value for EBP as well. Generally the attacker will be diligent enough to enumerate the stack to determine the current EBP and plant it into the payload so that it remains the same as before. For eg. he could(and should) provide something like:

AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA 082376ED 0834FD4C

Where 082376ED is the existing EBP. This will make sure that it is not changed to an arbitrary value in the mission to overwrite the EIP.

EIP : It is changed to the new value

ESP : It will revert back to the same value irrespective of buffer overrun or not.

So after the function returns, you'll live in the stack frame of the old caller but will be executing some other code.

Smashing the Stack for Fun and Profit  is an excellent source for any further information.


Answering your questions:

No is not the same. If you don't set on a container access to docker socket, that means the container will not be able to create, check, delete or other actions on host docker containers, that's all. But in the container the root user can still "break" its software.
Running only one container per Virtual machine means that if somebody hack your container and escape from it in someway, it will access only to your VM. It could be a good practice but excessive in my opinion. You can create containers on different networks to isolate them although in this way if they escape they will access to all containers.
To run containers "not privileged" is more secure than to run them as "privileged". That's obvious.
To run container as root means the processes in the container will be with all the privileges in the container. To run container as privileged means that container will have all the privileges even on the host. This is usually done in some special cases... let's suppose you have a container that needs access to physical wireless network interface on host. For sure that will be needed to be launched as privileged or the container will have no access to the device.

Hope it helps.


Use isc-dhcp-server. Read the manual for info on options and blocks in the configuration file. You may just as well use unbound, or dnsmasq. I recommend dnsmasq, it's very versatile.


Is there any way to prove that VPN doesn't collect data?

No, there is no way for a VPN provider to prove they don't record any data. They have to process your original traffic at some point and can't prove afterwards that they deleted it without any copies.

Let's say you use the VPN to hide your communication with a plain HTTP website from your ISP. Here, the VPN doesn't magically create an encrypted tunnel between you and the website. It only adds encryption between you and the provider. Your request to the website will eventually leave the provider's infrastructure in its original form and could be recorded by anyone on the way. Since the provider has to handle your data, there is no technical way for them to not (temporarily) know it.

So, you can only either end-to-end encrypt or trust the brokers on the way. Other anonymity solutions such as the Tor network solve the trust problem by routing traffic over multiple nodes of which the majority is expected to be trustworthy and assumed to not collude with each other.

That said, just because they can't prove it doesn't mean there are no trustworthy VPN providers. When choosing a provider you should research their reputation, the jurisdiction they operate in and read about how they intend to keep your privacy and claim to handle your data.


Password checking in the context of symmetric encryption

If the encryption scheme uses CBC and you alter one bit of the encrypted data, then, upon decryption, this will have two effects: it will garble the corresponding block, and it will flip the corresponding bit in the next block (16 bytes further, with AES). It will not alter the rest of the data. This is quite unlike to what happens if you flip one bit of the clear data, when encrypting: that one would alter all the subsequent blocks, till the file end.

For other modes, things vary. Flipping one bit of encrypted data just flips the same bit of the clear data with OFB and CTR modes. With ECB, it alters one block exactly. With CFB, it will modify all subsequent blocks.

For the authenticated modes, CTR is often used internally (e.g. with EAX) but the point is moot because the integrity check will detect the alteration and report it (it is still up to the application to get rid of whatever it decrypted in that case).

Including an explicit password check is customary (e.g. OpenPGP does it) and it does not weaken the encryption, if done properly. Basically, the password must first be slow-hashed (with a salt), and then a hash of the resulting key is used as checksum. In any case, no sane attacker will decrypt the whole file for each password that he tries: he just decrypts the first two or three blocks, to see if he finds a realistic-looking file header. We cannot rely on decryption speed as a substitute for the slow hashing.


If you don't trust the device manufacturer without a full hardware and OS audit you can never be certain. For all you know the device could have cached the encryption key in a separate piece of flash buried under another chip on the board - or even a full clone of the user space.

I would be surprised if any modern android device is using non-standard android encryption. If they are if anything its likely to be a flagship device with an unusual hardware encryption module. So the odds are if you can verify this then the question falls back to do you trust google/android and the prior question you referenced - How secure is wiping an encrypted Android device?.

If the device is using non-standard encryption you need to ask yourself why do you not trust the manufacturer. Are you expecting malicious behavior or incompetence? If you are expecting a malicious manufacturer then it is already end game. For all you know they have been transmitting your personal data away from the device throughout its use.

For incompetence there are ways to reassure yourself. For example write random data (to avoid any risk of compression) to the device until full. Then read this data back and compare against what was written. If they match you can be reasonably confident the full disk space has been overwritten.

There is one possible caveat. Flash memory has a limited lifetime. As it degrades the device can detect this and decommission certain blocks. Without modifying the storage control firmware decommissioned blocks will no longer be readable/writable to - meaning for older devices there is risk that old data is still contained and available to a determined opponent with access to a forensics lab.

However the odds of randomly decommissioned blocks containing useful confidential information - especially on a priorly encrypted device - is extremely slim. For any individual that does not consider themselves extremely high risk (and if you are you aren't going to be worrying about this - destroying the NAND chip is going to be a far better option than the second hand value of the device) I'd argue there is very little point considering this.


Routing traffic through compromised host

I suppose you are looking for something called "pivoting". At least if you want to utilize the compromized host to further look into the attached network. There are quite a lot of ways to do it. One of them would be metasploit for example and you can read about it here.

Other options include using SSH to forward your requests (see SSH-Portforwarding) but that only applies if SSH is present and only in a limited number of cases this is really useful. If you really do want to connect to a number of remote hosts through that machine I suggest either use metasploits routing or utilize a proxy server that you put on the server via your already existing shell.


HTTPS content can be cached by the browser, and apparently will be cached, unless explicitly instructed otherwise by the server. See this answer for details and links.


Is it possible to spy on Tor browser within local network?

This answer is based on the assumption that the adversary is able to monitor the traffic to/from your device, but has not compromised your device.

In that case, the adversary may be able to see that you are using Tor, because they'll see connections from your device to nodes on the Tor network.  But, that person won't be able to determine which sites on the Tor network you or visiting, and won't be able to see the information that you are exchanging with those sites.

See https://www.csoonline.com/article/3287653/what-is-the-tor-browser-how-it-works-and-how-it-can-help-you-protect-your-identity-online.html for more info.


TLS: could the resumed session and the original session in the same connection?

There is no problem in having several sessions on a single connection -- of course not simultaneously, but if, within a connection, a new handshake is performed (a "renegotiation"), then that new handshake may resume an existing session, including the one which was active before that new handshake. As for any session resumption, this works only if both the client and server agree, and remember the session parameters in some way (if session tickets are used, the server's memory may actually be offloaded on the client).

However, this raises the question of why you would renegotiate, if that is only to keep the current session running. A common case of renegotiation is when IIS (Microsoft's Web server) is configured to use certificate-based client authentication. IIS, by default, uses client certificates on a per-directory basis, not for the whole server; thus, things go normally the following way:

The client connects to the server. A "normal" handshake is performed, with no request for a client certificate.
Once the handshake is done, the client sends the HTTP request. At that point, the server learns the exact target path for the request (up to that point, the server knew, at best, the intended server name, through the SNI extension, but not the full path).
If the target path is configured to use client certificates, then the server buffers the request, and initiates a new handshake (HelloRequest and so on).
The client responds with a ClientHello and normally tries to resume the ongoing session. However, the server refuses, and instead initiates a new session. This is so because the whole point (in that situation) of starting a new handshake is to ask for a client certificate, and this can happen only with a full handshake, i.e. with a new session.
Once the new handshake is completed and the client authenticated, the buffered request is processed (this is safe as long as client and server implement the secure renegotiation option, which was designed exactly for that usage).

The point I am making here is that the client really tries to resume the same session, as is allowed by standards, and the server rejects the resumption because it triggered a new handshake precisely so that a new session may be opened. In practice, performing a new handshake but resuming the same session can be done by people who feel that they must "renew keys" for some ill-justified reason; we are more in the domain of Tradition than Science here. Conceptually, doing a new handshake with the same session could be used as a way to exchange some new TLS extensions, but there currently are hardly any defined extension for which such a thing makes sense (but extensions are, by definition, open-ended, so this may be useful some day).


Using the etag to get the data

Knowing the etag alone will not help you with getting the secret resrource, assuming the server is properly implemented. The browser will check with the server to see if the etag is valid (using the If-None-Match header).

When Alice makes the request, she will be authenticated so the server should respond with 304 Not Modified, prompting the browser to load the resource from the cache.

But when Bob makes the request he is not authenticated, so the server should respond with 403 Forbidden. The browser will then not load anything from the cache (and if Bob is using a different browser than Alice, there wouldn't be anything to load anyway).

All this rests on the assumption that Cache-Control is set to no-cache (or absent). If not, the browser would load the resource directly from the cache without checking with the server. If Bob and Alice are using the same browser Bob would then get Alice version of the page, even though he is not authenticated.

Stealing the resource from the browser cache

As you point out, instead of just stealing the etag Bob could simply steal the actual resource from the cache.

Modern browsers protect against this in various ways. Unless Alice and Bob are using the same OS user or Bob is root or admin (depending on the OS) this could not be done without leveraging some exploit.

Still, if the resource is really sensitive and you expect your users to access it on computers that are shared with non trustworthy people, you should consider setting Cache-Control: no-store disabling all cache.


Bypass Local File Inclusion(LFI) prevention filters

I don't think you can do it, unless there are insecure and exploitable symlinks that allow bypassing the '../' removal filter and are reachable down from the current directory.
In other words, I believe that LFI filtering is adequate.


RDP vs. VNC when looking them from security side

RDP has some issues, but these are broadly mitigated by getting the config right. Wicked Clown demonstrated a wonderful privilege escalation attack from restricted user to admin in less than 5 minutes at the recent B Sides London security conference which relied on a common misconfiguration - paper here. TLS can provide a strongly authenticated tunnel - which will help.

An alternative could be VNC - which also has potential issues, however using an SSH tunnel for this gives you a much better position with respect to security as you can use strong mutual authentication.

The key point to look at is what your key risks are - if you are worried about an attacker pretending to be a user, SSH or TLS with certificates gives you the authentication and encrypted tunnel part of the puzzle, is a good idea, however you still have the risk of an attacker stealing the mobile device:-)


Security Implications of Neglecting the Extra Byte for NULL Termination in C/C++ Arrays

String Termination Vulnerability

Upon thinking about this more, using strncpy() is probably the most common way (that I can think of) that could create null termination errors.  Since generally people think of the length of the buffer as not including \0.  So you'll see something like the following:
strncpy(a, "0123456789abcdef", sizeof(a));
Assuming that a is initialized with char a[16] the a string will not be null terminated.  So why is this an issue?  Well in memory you now have something like:
30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66
e0 f3 3f 5a 9f 1c ff 94 49 8a 9e f5 3a 5b 64 8e

Without a null terminator standard string functions won't know the length of the buffer.  For example, strlen(a) will continue to count until it reaches a 0x00 byte.  When is that, who knows?  But whenever it finds it it will return a length much larger than your buffer; lets say 78.  Lets look at an example:
int main(int argc, char **argv) {
    char a[16];

    strncpy(a, "0123456789abcdef", sizeof(a));

    ... lots of code passes, functions are called...
    ... we finally come back to array a ...

    do_something_with_a(a);
}

void do_something_with_a(char *a) {
    int a_len = 0;
    char new_array[16];

    // Don't know what the length of the 'a' string is, but it's a string so lets use strlen()!
    a_len = strlen(a);

    // Gonna munge the 'a' string, so lets copy it first into new_array
    strncpy(new_array, a, a_len);
}

You've now just written 78 bytes to a variable that only has 16 bytes allocated to it.
Buffer Overflows

A buffer overflow occurs when more data is written to a buffer than is allocated for that buffer.  This is no different for a string except that many of the string.h functions rely on this null byte to signal the end of a string.  As we saw above.
In the example we wrote 78 bytes to a buffer that is only allocated for 16.  Not only that, but it's a local variable.  Which means that the buffer has been allocated on the stack.  Now those last 66 bytes that were written, they just overwrote 66 bytes of the stack.
If you write enough data past the end of that buffer you'll overwrite the other local variable a_len (also not good if you use it later), any stack frame pointer that was saved on the stack, and then the return address of the function.  Now you have really gone and screwed things up.  Because now the return address is something completely wrong.  When the end of do_something_with_a() is reached, bad things happen.
Now we can add a further to the example above.
void do_something_with_a(char *a, char *new_a) {
    int a_len = 0;
    char new_array[16];

    // Don't know what the length of the 'a' string is, but it's a string so
    // lets use strlen()!
    a_len = strlen(a);

    //
    // By the way, copying anything based on a length that's not what you
    // initialized the array with is horrible horrible coding.  But it's
    // just an example.
    //
    // Gonna munge the 'a' string, so lets copy it first into new_array
    strncpy(new_array, a, a_len);

    // 'a_len' was on the stack, that we just blew away by writing 66 extra
    // bytes to the 'new_array' buffer.  So now the first 4 bytes after 16
    // has now been written into a_len.  This can still be interpreted as
    // a signed int.  So if you use the example memory, a_len is now 0xe0f33f5a
    //
    // ... did some more munging ...
    //
    // Now I want to return the new munged string in the *new_a variable
    strncpy(new_a, new_array, a_len);

    // Everything burns

}

I think my comments pretty much explain everything.  But at the end you've now written a huge amount of data into an array most likely thinking that you're only writing 16 bytes.  Depending on how this vulnerability manifests itself this could lead to exploitation via remote code execution.
This is a very contrived example of poor coding, but you can see how things can escalate quickly if you're not careful when working with memory, and copying data.  Most of the time the vulnerability will not be this obvious.  With large programs you have so much going on that the vulnerability might not be easy to spot, and could be triggered by code multiple function calls away.
For more on how buffer overflows work.
And before anyone mentions it, I ignored endianess when referencing the memory for the sake of simplicity

Further Reading
Full Description of the Vulnerability
Common Weakness Enumeration (CWE) entry
Secure Coding Strings Presentation (PDF automatically downloads)
University of Pittsburgh - Secure Coding C/C++: String Vulnerabilities (PDF)


Wordlist generator for known words in passphrase

Using custom rules within john-the-ripper John you can write variations of the password. Using John The Ripper to create variations of a known password.


In a typical system, there are several "usernames". There is the name that the user types to begin the login operation. Then there can be a "display name" (to be added to forum posts, automatic emails...), a contact email address, a billing name, a cardholder name... It makes relatively little sense to protect one of these names without dealing with the others, since they all contain, on average similar information (it may sound surprising, but, given the choice, many people will prefer to use their own true name for all these purposes).

The "login name", i.e. the username which the user types to begin the login operation, servers the following role: it allows the server to efficiently locate the user-specific data. The server may have thousands of users, in a large database, and it is inconvenient to scan all of them upon each login attempt; you want to quickly find the "user identifier" from which you can get the hashed password for that user.

Login names are not usually considered to be secret data (if they were secret data, we would call them "passwords"), if only because it is normal and expected that the login name is similar to the user's administrative identity. Nevertheless, if you want to somehow hide the list of login names, you must use a deterministic injection: that's a transform, such that given twice the same login name, you get the same output (that's determinism, it is required for the "find the user-specific data" part to work, and it must be understood server-wide), and two distinct login names will yield distinct output (the transform must be injective, or at least should not allow collisions to appear with a non-negligible probability). There are several solutions:

You can use a hash function such as SHA-256. You get worldwide determinism (that's the same SHA-256 for everybody) and almost-injection with high probability.
You can add a server-wide salt if you want to nullify any advantage an attacker may get from precomputations. The salt must still be the same for all login names on your server, because of determinism. The salt is equivalent to choosing your own, server-specific hash function. Note that an attacker who got the list of hashed login names will still be able to do a parallel attack on all the names (for each potential user name, the attacker hashes it -- with the server-wide salt -- and compares the result to all the hashed login names); thus, this specific salt does only a part of the job normally performed by a salt (but you cannot avoid it, because you need determinism).
You could make the salt secret; then, it is no longer a salt, but a key, and the hash function is no longer a hash function, but a Message Authentication Code (such as HMAC). This will do you any good only if the attacker can get access to the database but not to the key (so that's a restrictive attack model). Keys entail key management, something which is never simple, especially in the presence of multiple front-ends (they share the database, thus they must share the key -- and secrecy is not utterly compatible with sharing).

Remember that all of this is about a second-level defense: the model assumes that an illicit read access was achieved by the attacker (and that's already a big worry !). While such read accesses do occur in practice (that's why we hash passwords), we must not forget that this should not be the primary line of defense; on the other hand, every hash or encryption adds complexity, which is the well-known nemesis of security. So there is a trade-off, and the usual wisdom is to avoid complexity if it would serve only for secondary protection of data which is already semi-public anyway (i.e. the login name).

As for the details, the rough outline of the scheme you suggest would work (you are free to consider as "password" the concatenation of the login name and the password typed by the user, if you wish -- it will not make the scheme weaker). However, do yourself a favour: don't invent your own hashing. For the hash of the login name and of the password, rely on bcrypt or PBKDF2. Your user-specific key encrypted with the user password is really the result of a Key Derivation Function; there again, you'd better use a proper KDF like PBKDF2; you would just have to store the user-specific salt. Both the "hashed password" and the "encrypted user-specific key" can be used as the basis for a dictionary attack (aka "trying potential passwords"), so they must include the same level of protection (many iterations to make the processing slow, a salt to thwart parallelism).

I would still consider it a poor trade-off: much added complexity, for little extra security.


Key rotation for shared secret keys - recommendation

If your shared secrets are of sufficient entropy there is no need to rotate the key to protect against brute force attacks. For example, if you're using AES-128 to encrypt the data in transit, then if you have a completely randomly generated 128 bit key this will be infeasible to ever brute force.

One area of concern could be your backup procedure. Is it guaranteed that any backups of your systems could expose the secrets to those that should not have access? For example, where are they physically stored and is logical access restricted by ACLs or encryption? This is one reason why key rotation might be useful - to prevent any old backup data that is discovered by an attacker from being used to attack the current system.

The other area of concern is your encryption algorithm isn't of high enough strength. An observer on the connection may be able to capture enough traffic to calculate the key. It would be recommended to use a strong, secure cipher though, rather than rotating keys.


Bypassing AV and IPS can be done through meterpreter or any other RAT. Most of the time meterpreter is handy because first it is open source and second it is implemented as a reflective DLL which insert itself in the exploited process without touching the disk.

AV solutions can be bypassed easily through the Veil Evasion project while reverse_https meterpreter can bypass the IPS since the connection is encrypted. You have the option of Stage Encoding for encoding the second stage metsrv.dll as well which can bypass a lot of IPS solutions. Also, the stageless meterpreter over HTTPS is very handy in bypassing the host and network based detection solutions as well.

However, sometimes meterpreter being a synchronous payload where the user needs to interact with the session becomes difficult to manage e.g. when client side attacks or campaigns need to be executed over large periods of time. In such cases, you always have the option of using Throwback, Pupy, or the Cobalt Strike's Beacon payload. The advantage of these payloads is that they are asynchronous in nature and all of them are implemented as reflective DLLs which means they can be used with Metasploit through the payload/windows/dllinject/ payload type. And since these payloads are not used as often as the plain meterpreter in the Metasploit source tree, they can bypass many AV and IPS solutions out of the box.

Lately, the payloads implemented in pure Powershell can bypass AV as well as IDS/IPS. Powershell Empire is one such payload implemented in pure Powershell.

One thing that was missing from Meterpreter is to script the actions in the first stage without contacting the handler. Such a thing is now in the main source with Python meterpreter, and in the coming days, the functionality will be ported to other meterpreter payload types as well. Take a look at my answer at Techniques for Anti Virus evasion for a list of techniques for bypassing AV for further explanation on the topic.


How can one prevent HTTP-authentication Brute Force Attacks, on PHPmyadmin with CSF-LFD?

Add these lines to your Apache Config to log failed authentications

/etc/apache2/conf.d/phpmyadmin.conf:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{userID}n %{userStatus}n" pma_combined
CustomLog /var/log/apache2/phpmyadmin_access.log pma_combined

Then create the fail2ban filter:

/etc/fail2ban/filter.d/phpmyadmin.conf

[Definition]
denied = mysql-denied|allow-denied|root-denied|empty-denied
failregex = ^<HOST> -.*(?:%(denied)s)$
ignoreregex =

Now add the jail to /etc/fail2ban/jail.local

[phpmyadmin]
enabled = true
port = http,https
filter = phpmyadmin
logpath = /var/log/apache2/phpmyadmin_access.log

Restart apache and fail2ban:

service  apache2 reload
service fail2ban reload


Public Key Cryptography has two basic primitives -

Encryption - data encoded using the Public Key can only be read using the Private Key

Signing - data that can be decoded using the Public Key must have been written using the Private Key

As you can see, these are really just two sides of the same coin, both depending on the Private Key being Private and the availability of the Public Key to other parties.

  How does PV verify the data if it had been signed with PE's private key?

If the data decodes using PE's Public Key, than it can only have been encoded using PE's Private Key, therefore verifying that it "came from" PE.


No, it's not malicious.

From what I've looked into, it's rather widespread, and seen on PCs that have no indication of infection.

If you open Chrome and go to chrome://settings/searchEngines, you'll see the Query URL for Google.  It'll probably look like "{google:baseURL}webhp/".

If it was going to a different domain, it might be worth more investigation, but your query is still going to Google's server.  Unless Google's search was somehow compromised (seriously doubt it), you have nothing to worry about.

Please ignore the fearmongering from the general public.  I've seen a ton of pages talking about the "webHP virus".  These are unfounded, and written by people that don't understand what they're talking about.


Is it safe to submit personal information over a website with a gray (not green) https?

Danger Will Robinson, Danger!

The form on the site is not secure, and any data sent through that form will be in plain text. This means anyone listening to this communication will have a plain text copy of any data sent to that address.

If you don't know what data is sent there then you can't know if it's safe. Without code review you wouldn't know, and probably shouldn't trust the form. If it sends anything pertaining to secret or PII information, run away. Without a secure connection you can't be sure anyone is getting a copy of your data and should avoid sending it.


Unable to see client to server traffic in MitM attack

There's a typo in your first arpspoof command (missing the p)

arpspoof -i eth0 -t victimip gatewayip

Check if that command is failing. If so it would prevent you from intercepting I need direction of traffic like you're observing.


Did KeePassX ever have an audit funding?

The  news page from KeePassX lists several new versions, but there is no text about a funding campaign. Also if you search the web, you won't find anything. So I assume there was no funding campaign so far.


It should be:

    [xxx@box ~]$ openssl enc -des-cbc  -k "whatever" -iv 0 -in file.enc -out file.dec
    [xxx@box ~]$ strings file.dec
    Salted__
    [xxx@box ~]$


How to translate "openssl enc" command to nodejs crypto api

OpenSSL commandline enc does password-based encryption (PBE) by default. This means the key, and IV if applicable which it is for CBC, is derived from the 'password' input by a Password-Based Key Derivation Function (PBKDF); the key is NOT the same as the input. And it uses a particularly poor PBKDF; for details see my attempt at a canonical. Further, the default hash in the PBKDF has changed, and you don't specify which OpenSSL release you use(d) -- but the rand command you posted is an invalid form that was accidentally accepted by the old ad-hoc command parser and is rejected by the standardized parser in 1.1.0 up, so your release must be one that used MD5 for the enc PBKDF.

Incidentally this means most of the entropy in your rand 64 was wasted; the MD5-based PBKDF cuts the entropy to 128 bits (or very slightly less, for technical reasons), and the extra cost of using AES-256 instead of AES-128 also is wasted and doesn't add anything to security. Using 1.1.0 up, or specifying -md sha256, would avoid this specific problem, although there is really no point in using PBKDF/PBE at all for a fully random 'password'.

It happens that nodejs' older (and deprecated) crypto.createCipher (NOT createCipheriv) uses almost the same poor PBKDF as older OpenSSL enc: EVP_BytesToKey with MD5 and 1 iteration, but with no salt, which differs from the OpenSSL default and makes the PBKDF even weaker -- but that doesn't matter for a random 'password'.

If you want or need to be compatible with exactly that openssl enc command, you'll have to code the equivalent of EVP_BytesToKey (for 1 iteration, which is fairly easy), and use createCipheriv with the resulting (derived) key and IV, plus write OpenSSL's Salted__ + salt header. See https://stackoverflow.com/questions/50181685/nodejs-createcipheriv-like-openssl for one example.
If it's enough to be compatible with enc -nosalt on older releases (and enc -nosalt -md md5 on all releases), you can just use createCipher with the password, which must be printable chars e.g. hex as you did in your first example.
enc can encrypt and decrypt with 'raw' key and IV, not password-based. Since your key is fully random that's secure. If that is sufficient, just use createCipheriv with a suitable key and IV. If you reuse a key it is vital the IV be unique (for CTR or OFB) and unpredictable (for CBC and CFB) for each use of a key, but if you use a different key every time it doesn't really matter what the IV is and you can even use a constant (such as all-zeros, which is convenient on the enc side). Pass the key and IV in hex to the enc options -K (uppercase!) and -iv. Note OpenSSL can't itself read these from files, like -pass file: or -kfile for a password, but in most Unix shells you can use file contents in an option like

    openssl enc -aes-256-cbc -d -K $(cat key_hex_file) -iv $(cat iv_hex_file)
    # or
    openssl enc -aes-256-cbc -d -K $(xxd -p key_bin_file) -iv $(xxd -p iv_bin_file)
    # (in most cases it is necessary or prudent to doublequote "$(cmd)"
    #  but here the output is _only_ hex chars so not needed if sane IFS)

Meta PS: we have lots of other Qs about nodejs crypto, and about OpenSSL enc, but I couldn't find a good dupe for the combination.


How can a git repository be sanitized efficiently and effectively?

Run a tool such as GitRob or truffleHog to find sensitive information in your repositories and then use BFG to remove the data from your GIT history.

  Replace all passwords listed in a file (prefix lines 'regex:' or 'glob:' if required) with ***REMOVED*** wherever they occur in your repository:

$ bfg --replace-text passwords.txt  my-repo.git

That all being said, please make sure to roll any credentials and keys that you discover in published repositories — it is best to assume those have been compromised.


Adding false network tools / signatures for malware defense

This is done, in a way. The WannaCry malware for example checked whether or not the domain iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com was registered and could be resolved. If it was present, the malware shuts itself down. The domain was registered in order to slow the spread of the malware.

Other malware may check for the presence of a certain file on the computer. If the file is present, the malware will terminate itself. This is sometimes done to prevent multiple simultaneous infections, and is sometimes done as a lazy way for the malware author to neutralize it on their own systems.

So why do antimalware systems not populate your computer with these signatures? Simply because, if the malware is known in advance, it is far easier to simply block it directly with signature-based detection. As for opportunistically placing debugging tools on the system to fool the malware into thinking it is being analyzed, simply not enough malware attempts to detect that. It would not be a cost-effective approach compared to, say, hardening your system. Another reason is that some malware detects debugging by spawning a child and mutually debugging each other, as only one debugger can be attached to a process at any given time. Fooling this kind of anti-debugging behavior would require attaching a debugger to every program that executes, in hopes that one of them will be malicious and will summarily terminate itself.


Are there any holes in this security design?

Yes.  The first problem is that you are writing your own crypto protocol.  Please don't do that. Use TLS or SSH instead.

Second, there are many books written about writing secure protocols, and even common problems in protocols.  Your algorithm has them.

Third, you do nothing about out of order traffic, modified messages (you mention encryption but you don't mention integrity checks), your mode of encryption is not defined (and may have problems), your initialization vector is not described (and may have problems), you don't mention compression, you don't do anything about removed messages, you don't track messages from a previous conversation with the same key inserted in this conversation, you don't define how temporary your temporary key is.

Fourth, you are using public key crypto, which is slow.

Fifth, you have no threat model.  Your post originally had no definition of what you're actually trying to achieve (though you've added that in a comment).

And since I'm not really a crypto expert and see all these flaws at a glance, imagine how many flaws there really are that experts would see.

Please don't create a new, flawed protocol.  Use one that already exists for what you want.


[1:2463:7]: Intrusion Signature
EXPLOIT IGMP IGAP message overflow attempt
[Classification: Attempted Administrator Privilege Gain] [Priority: 1]
05/29-19:44:02.238185: message explaining the possible consequences of the the attack.

249.94.153.251: Source IP: this is the IP address where snort believes the attack come from.

249.94.153.77: The destination IP: this is the IP address of the attack target.

IGMP TTL:255 TOS:0x0 ID:9744 IpLen:20 DgmLen:502 MF Frag Offset: 0x1FFF   Frag Size: 0x01E2: Basically, in this attack the attacker creates and sends a malformed IGAP packet, and if decoded by a vulnerable version of Ethereal/tethereal, can cause a buffer overflow and the subsequent execution of arbitrary code. So, this data describes information about the IGMP packet that triggered the alert. Like Time to Live (TTL) and Type of Service (TOS) for more information look at http://www.tcpipguide.com/free/t_IPDatagramGeneralFormat.htm

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0367][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0176][Xref => http://www.securityfocus.com/bid/9952]: these are additional links that provide more information about the vulnerability that make this attack possible. The Common Vulnerabilities and Exposures (CVE) system provides a reference-method for publicly known information-security vulnerabilities.

For other snort signatures look at https://www.snort.org/rule_docs/

I hope this will help to understand snort alerts


Access an ftp server gives me the passwd file though no shadow

On typical systems, the file /etc/passwd doesn't actually have passwords in it, but rather shows the mapping between usernames and user IDs. In order to see usernames in any directory listing or other context, you must have access to that file. Otherwise you can't tell which username a given UID matches to.

In your case, the server isn't giving you access to anything even remotely important. Instead, you've been stuck in a chroot environment where your process can't see out of its own little sandbox. Nothing in there is security-sensitive.

But as mentioned, without access to the passwd file, you can't tell which user owns a given file, right? So they make up a passwd file just for you. It lists "root" at UID 0, and you "Anonymous FTP" at UID 109. And nothing else.

There are other users on the system, of course. You're not seeing the real passwd file. And there are other files and processes and all sorts of interesting stuff. But that's outside your sandbox. As far as FTP is concerned, all of that stuff doesn't even exist.

See: chroot.


Is exposing the default plesk page dangerous?

Well, it tells people you don't really know what you're doing, in that it reveals that you use Plesk (or any web hosting panel in general).

Whether disclosing this information publicly is "dangerous" or not is debatable and down to definitions, but I can tell you that if I were scanning for something to hack, seeing a web control panel like Plesk would tell me that I've found something that's likely to be poorly configured and insecure, but also likely to be a low value target. (The typical server running Plesk is a cheap VPS with minimal resources and no professional administrator.)

At the same time, I suspect it would be almost trivial to suss out that information anyway, with or without the presence of that parking page. So, I'd say that the dangerous thing here is using a web control panel at all, as opposed to understanding and properly administrating your web server.


Will the “Tor Browser” maintain a safe & anonymous internet connection over a computer's sleep/standby-and-resume cycle?

While your computer is asleep/standby, it will be disconnected from the internet. When it wakes it will probably try to reconnect straight away (depending on system settings).

If TOR browser loses connection, it will try to reconnect as soon as the internet is available. To check your TOR status just visit https://check.torproject.org

It doesn't matter if you close-and-restart TOR browser, TOR browser will not let you browse the internet without being connected to TOR, so your anonymity is safe.

The easiest way for you to test this is:

Load TOR browser
Sleep computer
Wake computer
Load https://check.torproject.org - It will inform you of your anonymity.


Don't allow access to phpmyadmin page over the network? XAMPP Windows

If I was running phpmyadmin and wanted to restrict access to localhost, I would use the Apache web server and would use the Order, Deny, and Allow directives to govern access. For example:

<Directory "/my/restricted/content" >
Order Deny,Allow
Deny from All
Allow from 127.0.0.1
</Directory>

If you don't use Apache but your web server has something similar to Apache's mod_authz_host you should be able to set up a similar access restriction.


Can an unloaded malicous.dll placed on the "drive by download " directory be remotly exploited?

Following on from communication in comments you seem to be asking about standalone executables. I.e. if a user has downloaded a zip file containing an application, extracted it directly to the Downloads folder (i.e. not in ~/Downloads/Program/).

Assuming a loaded dll is in the same directory then if it were to be replaced with a malicious copy odds are that the exe would load it without realizing. There are mechanisms - such as signing - to avoid this risk. Its also worth noting that to replace the file from most mainstream browsers without user consent should not be possible. Not to mention if you can replace the library why can't you just replace the exe?

When an executable attempts to load a library if an explicit path/manifest is not given the system is going to search a list of potential locations in a somewhat standardised order. This is documented for windows here - https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

If for some reason an executable attempts to load a non-system shared DLL that it isn't shipped with then there may be a higher risk. The directory the executable is in would usually be the first search location. This means that should this DLL be injected into the downloads directory then it would be picked up. I suppose an example might be a program that only offers certain features if another software package is installed - for example offering Microsoft Work integration if Office is installed.


How to prevent sharing SSH private keys by email

TL;DR: use smart cards.

To prevent distributing the key to other persons you need to prevent that the user has read access to the key in the first place. The key is used in SSH for authentication. The authentication process involves cryptographic operations (signing) which need to have read access to the key. In order to protect the users key against reading by the user these cryptographic operations need to be separated from the user in a way that the user can solely initiate the operations and can get the result back. This separation can be done for example by using a user process running with different permissions or even a process which runs on a separate hardware.

A special case of separate hardware are smart cards which are essentially tiny computers running a minimal operating system with some protected storage of cryptographic keys. A user can authenticate against these smart cards by a PIN and then use the card for example to sign some data using the keys stored on the smart card. This is sufficient for authentication which essentially means to prove that the user is the one owning the private key to a specific public key.

Smart cards are designed to be tamper resistant and unclonable which means it should be practically impossible to extract the key or to create another smart card with the same key. This is true even when faced with design bugs like the recently detected one with Infinion chips where errors in the operating system on the card led to the generation of weak private keys (keys created outside the card and only stored on the card were not affected). But note that smart cards only protect against cloning and reading and not fully protect against sharing the key: several users might still share the same smart card and PIN, but they would all need to have physical access to this single card which makes sharing harder.

Several SSH implementations have support for authentication with smart cards. Details can be easily be found by using a search engine, e.g. search for openssh smartcard or similar.


keytool -importkeystore gives error when using openssl pkcs12 -export with -passout pass:mypw option

openssl command:
I don't see anything wrong, so you have the PKCS12, but you can’t convert it to JKS.

keytool command:
You don’t put pass: before the PASSWORD like in OpenSSL.
keytool -v -importkeystore -srckeystore keystore.pkcs12 -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS -deststorepass 12345678 -srcstorepass 12345678


Fragile digital watermarking algorithms suitable for PDF embedding

The majority of PDF readers will stop reading the PDF data stream upon hitting the %EOF token, and anyway would ignore comments starting with %.

So, it would be perfectly feasible to calculate HMAC-SHA1 and append the resulting hash to the PDF file.

This is not, strictly speaking, a watermark -- but it is invisible and fragile, as requested.

Your resulting PDF file would end in something like

...
startxref
179091
%%EOF
%0xde7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

from which integrity can be straightforwardly calculated.

With the help of the pdftk tool, you can also be able to uncompress a PDF, manipulate its Adobe Metadata stream (if there is one), and embed inside it a XML HMAC - or even a comment:

3 0 obj
<<
/Subtype /XML
/Length 1381
/Type /Metadata
>>
stream
<?xpacket begin='ï»¿' id='W5M0MpCehiHzreSzNTczkc9d'?>
<?adobe-xap-filters esc="CRLF"?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='XMP toolkit 2.9.1-13, framework 1.6'>
...
</x:xmpmeta>
<!-- 0xf7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8 -->
<?xpacket end='w'?>

endstream
endobj

The stream length will be changed; if there is enough slack in the XMP object, you might circumvent this, but there's no need, since pdftk in compress mode will be able to recalculate it and output a valid PDF.

In this latter case, the HMAC information will be compressed and not be directly readable. You will need pdftk (or the iText library, or...) to uncompress the PDF back and recalculate its MAC.

The procedure would be as follows:

uncompress the PDF to a stream and attach to the stream
read the stream one long line at a time and use it to build the HMAC
if a row is found in HMAC format, ignore it for HMAC calculation and store its HMAC value in SavedHMAC
on EOF, if checking the HMAC just compare HMAC and SavedHMAC
if embedding the HMAC, repeat the uncompress, this time embedding the HMAC row appropriately, then recompress the PDF. This can all be done without writing anything to disk.

You can do the same with a PDF object embedded in the PDF stream, e.g. using the iText library, but this would be much more complicated to be made fragile. PDF objects are largely independent from one another, so you would need to again recourse to something similar to HMAC, this time at object level, and then embed the value as e.g. 100% transparent text, or text outside the page boundaries (I know eBook publishers that employ one or both techniques).

Also with iText, but these are not fragile, are algorithms that modulate spacing of text objects on the page. Most text objects are not aligned to an integer multiple of the page unit:

24.4801 0 Td
[(w)4001.47(atermarking)]TJ
59.7 0 Td
(algorithms)Tj
46.9801 0 Td

and you can easily determine the minimum step that will be visible to the naked eye, e.g. 0.005. Then simply round all text positions, in the order they appear, to the nearest odd multiple of the step, if you want to encode an 1. Or to the nearest even multiple of the step, if you want to encode a 0.

Such a watermark will survive copy and be present independently on each page; with the addition of suitable error recovery (turbo code, Reed-Solomon...), it will also survive the removal or addition of some (not too many, of course...) objects on the page. It is also possible that it will survive printing and be recoverable from a scan of a printed page.

You would do this by implementing a iText RenderListener, whose renderText method would capture the textbox origin and "modulate" it as requested before it being sent to the appropriate PdfCopy.


Risk classification of authenticated XSS

If you are assigning risk ratings such as low/medium/high, then I usually start off by classifying stored XSS as high risk:

  There are different roles/groups of users, but the part of the site    is only accessible by a specific group (with different roles).
  Authentication cookies have the HTTPonly flag

These may be mitigating factors for reclassifying it as a medium risk. The question lies whether horizontal privilege escalation offers an attacker any advantage.

e.g. is there private data an attacker could access only available within the compromised session.

If all users in the group can see and affect the same data, then I would not classify it as high risk.

I'm slightly confused by your wording though

  specific group (with different roles)

If these roles have access to different things then this would probably be enough to leave it as a high.


Why we are still required to move the mouse when generating the keys in VeraCrypt?

I think you need to look at the history of the codebase to understand why it's there in the first place. VeraCrypt descended from TrueCrypt, which was built at a time when the CSPRNG in Windows used an unspecified method of generating data:

Because CryptGenRandom is the de facto standard CSPRNG in Win32 environments, its security is critical for Windows users.

The specifics of CryptGenRandom's algorithm have not been officially published. As with any unpublished random number generation algorithm, it may be susceptible to theoretical weaknesses including the use of outdated algorithms, and a reliance for entropy gathering on several monotonically-increasing counters that might be estimated or controlled to an extent by an attacker with local access to the system.

As to whether it's still necessary by today's standards, well that is obviously a matter of taste. I managed to find a high-level statement about CSPRNG in .NET. I've been unable to uncover any sort of specification for the CSPRNG built into Windows, after about 10 minutes of searching through the Microsoft documentation.
Here's a good discussion about CSPRNG for readers that have yet to consider this aspect of information security: Pornin 2010 https://stackoverflow.com/a/3532136


Can a good SSO protocol be built around a server signing tickets rather than validating them on demand?

To some extent, what you suggest exists: it is called X.509 certificates.

The main problems with signed tokens are:

Control latency: once a token has been signed, it cannot be promptly canceled; you have to wait for expiration of the token. Or you implement an online revocation check (which is called OCSP in the case of X.509 certificates), which brings you back to the "online authentication server" model.
Clock synchronization: to enforce an expiry date, a verifier must have a reasonably accurate clock, which can be a challenge in a security context. Indeed, modern operating systems know NTP out of the box, but NTP is not protected.
Signed tokens to authentication, not authorization. The B server wants to be sure that it is talking to the right client, but also wants to know whether that client is allowed to access the service. It is not easy to fit a generic authorization matrix inside a signed token. About everybody who tried to work with X.509 certificates tried to use them for authorization, and regretted it.

With an online authentication server, that both A and B talk to, that authentication server can act as a big kill switch, with immediate cancellation and also possible fine-grained authorization control.


How secure are Windows logins tied to physical human fingerprints?

WBF
In Windows, at least as of 2019 in Windows 10, uses the Windows Biometric Framework (WBF) to verify a user identity.  Capturing the data is done through an interface through this framework, and that driver could potentially be exploited, but let's assume it's vulnerability-free and an attacker is only able to work with the data that is captured.
WBS
The Windows Biometric Service performs some security immediately by separating applications from accessing the data directly.  It requires applications to be authorised with certain privileges to access data and uses Biometric Units (BUs) to expose devices through a standard interface.
Security
Trusted Platform Module (TPM) is used to ensure that given the hardware software cannot produce valid authentication without biometrics being supplied.
When the sensor is first detected, a secret is shared between the biometric sensor and the TPM which is never seen again by Windows.  For the actual authentication event, WBF opens a session with the TPM and gets an arbitrary number that can be used once (a nonce).  This nonce is sent to the sensor, which attempts a match, which if successful is passed to a HMAC utilising the nonce and the identity of the user - the HMAC expires after a few seconds, which is why you readily need to re-authenticate.  The point is that no sensitive data is held by Windows.
The rest of your questions are then answered by the strength of the HMAC hashing algorithm - the minimum is SHA-1, and a variety are available as defined in RFC3278 and RFC3279.
The last thing to note is that devices have to be marked as secure, and the documentation states that this comes from meeting the following requirements:

The matching engine of the sensor must be isolated from the normal OS (for example, using a trusted execution environment)
The sensor must support secure input of samples to the isolated matching engine; the content of the samples must never be exposed to the normal OS
The matching engine must support secure credential release by implementing the new v4 methods
The sensor must support presentation attack detection


In postgres LDAP authentication, are passwords encrypted?

PostgreSQL LDAP authentication mechanism does not provide by itself security guarantee. The password used for DB is either plain text based or MD5 hashed. Your communication protocols do. But even if the communication is encrypted using SSL, it is better to hash your passwords with MD5 since you can always be sniffed or trapped using  other methods.


How to store an AES Key? an Initialization Vector(IV)?

You describe very little about why you are using symmetric encryption, but in general, you use the same key but a different IV for each encryption operation, provided encryption and decryption takes place on the same device.

The IV is not a secret value but it should be randomly generated using a CSPRNG.  This is very important.

It is common practice to prepend the IV to the resulting ciphertext so that it can be easily retrieved during decryption.


Protect Raspberry Pi's physical sd card to be swapped

You must use Full Disk Encryption on the sdcard used to boot the Pi. Using it, if the attacker gets the sdcard away, it will not be able to read its contents. This will protect the 802.1x credentials stored in the card.

Second, use 802.1x authentication on the network. 802.1x requires login and password for the client to get an IP address. Without a valid login and password, the Pi will not be able to join the network even if the attacker plugs the network cable on it.

With this, you will have to connect a keyboard and monitor to the Pi, to enter the disk password and the 802.1x credentials. If this Pi is to run a secure environment, keep a know good disk image somewhere else and reflash the card every time the Pi is shut down. This will prevent the attacker from coming in, shutting down the Pi and backdooring the bootloader (the Evil Maid attack). This is required, unless you want the attacker to get the 802.1x credentials and full disk encryption key at the same time.

Bonus point: nobody without valid credentials will be able to get to an unsupervised room and plug in a laptop.

Forget MAC address authentication, it's trivial to change the MAC.


Does my PGP key really need to match the e-mail address for which I'll be using it?

Depends on how you are using PGP.

From version 10.0 of the PGP Desktop client, the encryption and decryption is seamless and automatic from an Outlook rich client.

If your email address is the same as what is in your PGP key then you can email with a simple rule like anything you set Sensitivity to Confidential > Encrypt. Any encrypted received to this email address will also be decrypted automatically. When rolling out to non-technical users we found this a major benefit.

You can always not associate your real email address with PGP key and encrypt the contents manually. Or put the data in a document, encrypt that and email in clear text. Vise versa for receiving encrypted email.

You are right it does not effect signing. Although again if you submit it with an email address to the open PGP global server, it gets signed by that key and if the receiving party has imported the PGP global key, they will get a nice blue border around the email saying this email signature has been verified. Otherwise it will be  red and say this the signature cannot be verified. Does not effect cryptographic validity of the signature just the UI experience

So it is a really a convenience vs. email enumeration trade-off. Considering that email address is used as a username in many services, and at least gmail spam filtering is extremely good (I also use the unsubscribe.com service because I'm lazy). Personally I would not have a problem with associating my email address with my PGP key and publishing to the global server.


Google's Mail Delivery Subsystem sending DSN (Failure) caused by spams sent on my behalf

You should configure SPF.

The e-mail indicates that someone at Vodafone (92.209.25.61) sent a mail with a mydomain.com address as sender. This should not be allowed, since only your mailservers should be allowed to sent such mail and 92.209.25.61 is not one of them. SPF makes it possible to publish which mail servers you want to allow to sent mail from mydomain.com, using DNS records.

After you have configured that, servers that support SPF will drop the message or mark it as spam if it does not come from one of your mail servers, and you will no longer get the bounce messages.


Is this spam SMS containing an audio file dangerous?

My guess is that the sender is trying to exploit the recent StageFright vulnerability, but since you have the latest Android security patches, you just got a dumb audio file.

If the attack had been successful, it would have gained root access to your phone and removed all traces of the original sms.


sqlmap: Test injection in Basic Authentication?

Without looking at the code and just making assumptions based on your results, I think that the authorization features of sqlmap are just there to allow you to perform tests while authenticated. They are likely not intended for this type of use.

However, Authorization is just another HTTP header, and sqlmap does support testing arbitrary HTTP headers.

So you could do:

--headers="Authorization: <base64_encoded_credentials>"

Unfortunately, this does not solve the base64 encoding problem. I would likely solve this one of these ways:

Modify sqlmap to base64 encode the custom header field before making the request, or change it so your original method can be used as an injection point. The latter may be worth a pull request to the project, as others may use this feature.
Build a quick middleware proxy using something like Flask. You'd point sqlmap at the local HTTP server, which receives the request, modifies the headers as desired, and forwards it to the original destination. I've used this approach successfully before to use sqlmap against non-HTTP targets.


You do not know how far the problem goes, which means "cleaning" is not what you should do. You need to install from known good backups.

No scan will give you a perfect answer (meaning that no errors means nothing). You need to know that the files you have are the ones you expect.


I think 80 bits is just a reference to the general lower limit of what's considered computationally infeasible to brute force.

From wiki:

  In 2002, distributed.net cracked a 64-bit key in 4 years, 9 months,
  and 23 days.

  As of October 12, 2011, distributed.net estimates that cracking a
  72-bit key using current hardware will take about 45,579 days or 124.8
  years.

Alternatively, by my calculations using the hashcat benchmarks it would take about 3 million years to brute force 80 bits using SHA256 on their "PC4".

  how much it’s expected to grow with time

It would be the same as brute forcing any other random value, however in the case of predictions it's also relevant how long that prediction is likely to be of value to an attacker.

80 bits is probably excessive if your prediction is about something that happens next week, about 54 bits would keep an attacker busy until then.


Detect changes in /boot when using full disk encryption

This is exactly the problem that Secure Boot was created to solve. The problem is that if you don't have a chain of trust going all the way back to POST, then you can't guarantee that there hasn't been tampering. (And even then, "guarantee" is an exaggeration).

You can checksum the boot partition at startup; perhaps use the checksum as part of the key for the next step. It's not completely tamper-proof, but without hardware-based crypto integration nothing will be. Just do your best with the tools you have and make sure you understand the limitations.


MD5 as X.509 Signature hash algorithm with TLS 1.2 and SChannel

TLS 1.2 was defined in RFC 5246.  That RFC does mention the use of MD5 as a possible hash algorithm and does not explicitly forbid it.  However, that RFC has been updated by RFC 8446, which specifies TLS 1.3.  That RFC modifies the requirements of TLS 1.2 and says the following of the SignatureScheme extension:

Some legacy pairs are left unallocated.  These algorithms are deprecated as of TLS 1.3.  They MUST NOT be offered or negotiated by any implementation.  In particular, MD5 [SLOTH], SHA-224, and DSA MUST NOT be used.

It is therefore completely forbidden to use MD5 for a signature in either TLS 1.2 or TLS 1.3, and the IANA has removed these algorithms from the specified list, so   they are no longer part of TLS.  As a result, the server can't send certificates that use MD5 because “all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in [the client's negotiated] extension” and we've just established that MD5 is no longer valid in this extension.
It is also forbidden to use MD5 by the CA/Browser Forum, which regulates the Web PKI, although that doesn't prevent internal CAs from using it.  In any event, responsible parties are not using MD5 for any purpose.
The part you mentioned from the RFC is a little different.  In TLS 1.0 and 1.1, the PRF (pseudo-random function) used to generate session keys from the negotiated secret used a combination of MD5 and SHA-1.  This use was not insecure, but it ended up causing practical problems for cryptographic proofs of the security of the function, and in any event, nobody wanted to keep using MD5 and SHA-1.  As a result, the PRF was switched to use a single hash algorithm, which is much easier to reason about and model cryptographically, and avoids obsolete algorithms in favor or SHA-256 (or, in some cases, SHA-384).


I'm not a PHP developer, so I don't have any specific recommendations, but from my experience I can give some general guidance that may be useful.

First, buy the newest PHP security specific book you can find.   As established as PHP is, and as soft as the technical book market has been for the last decade, there aren't a lot of options, but there are a few out there.   "Securing PHP Web Applications" from 2008 is the newest I've been able to find. The newer books will not only have more up to date information on PHP, but also more information on current attacks and threats.

Second, for more general PHP development education, look for a book with something like "Advanced" or "Technical" in the title, like "PHP Advanced and Object-Oriented Programming" (I have no idea if that specific book is any good.)  Beginner books (in any language or technology) are notorious for including disastrous shortcuts for the sake of simplicity, and rarely if ever worry about best practices...They're designed to show you how to get something working with the least amount of code possible, and it's almost always terrible code.   Advanced books have the luxury of being able to target readers with prior knowledge where best practices are more important than absolute simplicity, and you're far more likely to find a book that incorporates good security practices.

Third, (and this may be obvious) don't rely only on a book for your security information.  Internet resources such as the OWASP website will always be far more current and provide a greater amount of detail around current security practices and threats.