Why would a heap buffer overflow cause a crash on only some Windows 10 systems?

As someone already pointed out: Don't expect undefined behavior to be reproducible.

That said, there are a lot of variables. Of course there are the obvious ones (like CPU architecture / 32 bit or 64 bit mode; exact versions of the OS or other software involved (like .NET); etc.) but there also are the more subtle ones. Like how much memory the process is given at a time when it asks for some or even how much it asks for at a time.

So if you check how much virtual memory the process has on different machines before crashing, and the numbers are different, this can be a good reason for it crashing on one system but not the other.

How much memory the process is given at a time can depend on a lot of different factors like how much physical memory is available, how much swap space is available, which swap strategy is used, how the memory is currently allocated, etc. If you tested it on a machine with 16 GB of ram 10 times with it currently using 1 GB of ram for the OS and other applications and the process not crashing, you didn't really reproduce that behavior reliably. You kept the variables relatively constant. It might very well crash all 10 times on a machine with the exact same software but only 4 GB of ram and using 3 GB of it.


What is the difference between claims and capabilities in access control?

Claims and capabilities are both evidence-supported tokens, but they are totally different in terms of intent.

In a capabilities-based access control model, a capability is a token which demonstrates a capability, i.e. a right to perform an action on an object. An important thing to note here is that the capability does not contain any notion of identity, but rather the permission itself. Possession of the capability token is considered evidence towards being able to carry out an operation.

Claims are similar, but they're about identity. A claim says "I am this person", and is usually comprised of sets of evidence to demonstrate that fact. Kerberos tokens work on this model. Claims are combined with access control lists (ACLs) applied to objects. An ACL might say "user X has permission Y for this object". The user makes a claim to be user X, and provides evidence to prove this fact. If the evidence is accepted, she is allowed to perform operations which require permission Y.

In summary, the main difference is that a capability is a token which provides proof of being allowed to perform a privileged action, whereas a claim is a token which provides proof of identity, which can in turn be used to show proof of being allowed to perform an action in the context of a particular ACL.


Why add "***" in user-agent in this malicious code?

It could be due to a (previous) bad code or to avoid warnings/errors in responses.

stripos returns the possition of second parameter in first one, starting indexes at 0, so in a bad code if (stripos($ua,'android')) the condition would be skipped as false in the case the string started with android.

Correct solution would be using === and !==, but prepending a string that wouldn't match prior to the test string, makes any match to be at least at value 1 (3 in this case), avoiding the need to use !== false.

It also covers the case where user-agent is missing to avoid any kind of warning/error at running time.


If device is infected, can new devices get malware from associated social media accounts?

If you download the social media apps on the new phone from authoritative sources, I'm not sure how malware from another device could infect your new phone.

2FA would not help, because you would be logging into your accounts, and if there was some way to transfer the malware automatically, then it would happen after you used 2FA. Same thing for "changing passwords".

Using the same network will also not matter. Social media apps do not transfer data on the local network: they connect to servers on the Internet.

In short: malware does not work like that.


Can hackers go undetectable with a valid certificate with SSLSplit

TL;TR: having a certificate signed by a trusted CA is not enough if certificate checking is done right.

Only if all of the following points are true about the certificate sent by sslstrip then transparent man in the middle attacks are possible:

The certificate must be signed by a trusted CA: this is easily possible.
The certificates subject must match the name in the URL: you usually do not get a certificate with a matching subject for a domain you don't control from a publicly trusted CA.
The attacked site does not employ certificate or public key pinning, i.e. builtin pinning like done for some important domains by the browsers or explicit pinning using the HPKP header.

Note that these points rely on the client doing a proper job with certificate validation. But older versions of PHP, Python, Ruby... don't do it and developers often switch off validation because it is annoying during testing or because they rather use self-signed certificates (which is fine if you have an explicit pinning in your application).


During the handshake, the client and server send each other "random values", which are sequences of 32 random bytes. The "client random" is part of the ClientHello message, while the "server random" is part of the ServerHello message.

In both cases, the first four bytes of the random value encode the current date and time (number of seconds since January 1st, 1970, 00:00 UTC). The reason why they do so is a bit unclear and has been lost in the mists of Time. The best explanation we can come up with is the following: if the client or server does not have a good source of randomness, then at least the inclusion of the time will make sure that they don't reuse the exact same "random" value. Of course, lack of a good random source is likely to induce other weaknesses (e.g. if using RSA-based key exchange, the client generates the random pre-master key, so the client MUST have a strong PRNG at hand).

In order to validate the server's certificate, the client should have an approximate knowledge of the current time, since certificates and CRL have expiry dates. This does not require that the server knows the current time; neither does it need any precise synchronization between client and server.

It has been argued that SSL can be (ab)used as a way to obtain the current time: simply connect to a SSL server; do the full handshake so that you know that you are talking to the right server; use the server's notion of time (from the first four bytes of server_random as current time). This is not reliable. From my own measurements, about 15% of deployed SSL servers are either wildly off (by years), or simply don't follow the standard and use random bytes for the first four bytes of server_random. In any case, a client shall not use the server time for purposes of validating the server's certificate: the client must validate the certificate to be sure that it talks to the right server, and the client must be sure that it talks to the right server to be able to trust that the received server_random really comes from the expected server and thus contains the right time. There is an intrinsic chicken-and-egg issue here.

From the raw SSL/TLS protocol point of view (as specified in RFC 5246), certificate validation is out of scope: the server sends some certificates to the client, and, somehow, the client gains knowledge (with some high degree of certainty) of the server's public key. In practice, clients do that by performing certificate validation, which requires (at least) a notion of current date. This need for a local clock is a known problem for embedded systems (at least, for embedded SSL client that cannot contain an hardcoded copy of the server's expected public key).


Plausible PayPal phishing... with no evidence credentials were stolen

Yes it's possible especially if the housemate was already logged into PayPal or checks "keep me logged in", the attacker may have found a way to hijack the session , run a script to hook the browser , or an exploit is possible as well.

Then the attacker logged in and probably changed your email , and/or password and/or 2 factor number to control your account.

Check your transactions to ensure nothing else was sent or received.


How to generate all possible combinations of a forgotten password

This is called a rule based attack.  Password cracking tools such as Hashcat and John the Ripper can be used to crack passwords in this manner.


CRL date formats and conversion from GMT to epoch

RFC 5280 §4.1.2.5.1 and §4.1.2.5.2 state Validity times must be in Greenwich Mean Time (Zulu).

I don't know.  A better way than dumping text to a file?  I'm not clear what you're looking for here.

Using C, you can use strptime() to convert the string into a time structure, and strftime() to convert that time structure into epoch seconds.  This modified example comes from man strptime:

#define _XOPEN_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

int main(void)
{
  struct tm tm;
  char buf[255];
  memset(&tm, 0, sizeof(struct tm));
  /* Because strptime doesn't actually handle timezone */
  setenv("TZ", "", 1);
  tzset();
  strptime("Oct 8 15:04:56 2020 GMT", "%B %d %H:%M:%S %Y %Z", &tm);
  strftime(buf, sizeof(buf), "%s", &tm);
  puts(buf);
  exit(EXIT_SUCCESS);
}

And as you can see, it prints out the epoch time for the time string you've provided:
$ ./foo
1602169496
$


Leaking details about the user in web application

It is a form of SSRF or CSRF (depending on how it is rendered), if it is not cached, it will need to fetch the image from the URLwhen viewed.

By setting the image URL to a URL the attacker control, they can possibly obtain the victim's source IP, referer URL and more from the request received to that URL.


Is there any use in an AIA Extension in a Certificate directly issued by a Root CA?

Well, theoretically, you would never need to need the AIA.

RFC 5280 mandates, that you send along each necessary certificate. And optionally, you may send along the Root CA cert as well.

And that's the only certificate that is optional.

Now not everybody configures their servers correctly. And this is where AIA comes in.

If only the end entity certificate is sent along, then the client software will have more work to do. And some client software can do a thing called AIA chasing.

It will look inside the certificates it has and use AIA to download additional certificates. And if this doesn't lead to a usable path within 10 tries or something, then path building fails.

And building a path means: finding the certificates that lead to a trusted root CA.

If it leads to an untrusted root CA, then you can't trust the leaf certificate either. Either way, you will arrive at a decision about that leaf certificate. And that's what you want.

Related: InfoSec-SE: Steps to find out whether a SSL certificate is trustworthy

Edit 2015-04-28: AIA presents a root. You decide on trust.
What AIA chasing can help you with is to find one (or many) root CA. What it does not do is help you decide whether this CA is worth your trust.

But it will get you a root CA.

And even if it gets you a root CA that you don't trust, then it's still helpful, because then you know that the answer is "I'm not going to trust that". And then you don't have to keep on looking for an answer.

Further reading

RFC 4158 - Internet X.509 Public Key Infrastructure: Certification Path Building.
Whitepaper that discusses the, then new, AIA extention back in 2002: Steve Lloyd, Oasis PKI Forum, Understanding Certification Path Construction,


Keyloggers are usually programs which run in background on the users operating system. There are lots of ways to install these on the users machine. Some examples are:

The attacker learns about a vulnerability in the victims web browser which allows to download and install arbitrary programs from the web, and then tricks them into visiting a website they set up to abuse that vulnerability ("drive-by download").
The attacker sends them an executable file which installs the keylogger when executed, and then tricks them into executing it. Common methods do this is through email attachments which masquerade as documents (invoice.pdf.exe) or by masquerading the program as a legitimate installer for another software. It's not difficult to create an installer which pretends to install, say, Mozilla Firefox (and maybe even does this), but also installs other software without the user noticing.
Speaking of vulnerabilities: An attacker could also combine methods 1 and 2 and send them an actual document file which is crafted to exploit a vulnerability in the program they use to view it.
The attacker could put it on an USB device which installs the keylogger when connected to a computer. They then place that device where the victim will find it, hoping that they are curious about the content and connect it to the target machine.
Get physical access to the machine and install it the normal way

About how to get the data from the keylogger back to the attacker: Many keyloggers will use the internet to contact the hacker and send them their logfiles. There are many different protocols and techniques which can be used for this to improve stealth and traceability in this case, and listing them all would go too far.


This concept is used in the IMSI catchers you have heard about law enforcement using.

They spoof cellphone towers and cause all the phones in their range to register with them.

They also downgrade the encryption so they can retrieve text and voice in addition to the metadata.

The best example that  talked about the details was shown at DEFCON.

Hacker Spoofs Cell Phone Tower to Intercept Calls

Here is a Google search that talks to this issue:

https://www.google.com/search?q=defcon+fake+cell+site+gsm+downgrade


I suppose in principle that the DNS entry leaks a tiny amount of information, but assuming your DNS servers are tied down against third-party zone transfers, the only way to extract this from the DNS is to know it exists, so no information leakage there.  Most ssh attacks come from bots stepping through the whole IPv4 space looking for responses on port 22, and DNS entries have nothing to do with that.

I would probably name it something innocuous, though: ssh-gateway-to-the-vital-code-repository.example.com is not a great idea.

As you note in passing, there are a bunch of other measures well-designed for securing a jump box (including non-standard sshd ports, rate-limiting, disallowing password-based authentication / requiring 2FA, hardened OS).  I'd put a lot more time into them than into worrying about my DNS entry.


It is not. There are bunch of problems here:

You has function produces 32-bit value, which is nowhere near sufficient for password hashing. For such short hashes it's feasible (and easy) to simply find colliding password (i.e. password that's different from the original but still hashes to the same value);
Function looks simple enough to be "reversible" in the sense that for given hash value it might be easy to compute matching password (again, this will be not the original password, but a colliding one);
Function is fast and doesn't require much memory, which is considered a disadvantage for password hashing, as it allows use of GPUs/ASICs.

It's almost never a good idea to invent your own crypto, including password hashes. There are various well-studied alternatives that are considered secure so you should probably use them (examples: PBKDF2, script, bcrypt). If those functions don't work for you for any reason please specify why and what other constraints you may have. This information is important as it gives context for your question which is currently missing.


Software defense against cold-boot attacks

There are several lines of defense:
The obvious ones are to set BIOS password, (as you mention) use full disk encryption, do not use sleep mode, lock mode and especially not hibernation - encrypt it in CMD (Windows 7):

  fsutil behavior set encryptpagingfile 1

Keep your important files in an encrypted container. A successfull cold boot might get into the FDE but not the container inside (correct me if I'm wrong)
Make sure you have DDR3 RAM, it has the lowest memory persistance for this attack, older types are a lot slower.
If you can, enable Power On Self Test (POST) in BIOS, it will attempt to zero out memory.
ECC memory will reset the memory during initialization. Check if you have it in CMD (W7):

  wmic MEMORYCHIP get DataWidth,TotalWidth

If the TotalWidth value is larger than the DataWidth value you have ECC memory.

If you are physically hindered from shutting your PC down you may use remote shutdown software from smartphones. The ideal way is a an Android which binds the shutdown initation to a e.g. pressing up/down volume x times. This way you can shut down the PC with your hands in your pocket.

This is a golden nugget from a Blackhat paper. Unfortunately I don't have the slighest clue on how to implement this.

  BIOS BOOT:  Remnants of encryption keys can be recovered with very high probability, unless your master disk keys are stored in the physical address range 0x7c00– 0x7bff.
  A disk encryption filter driver loads very early in the boot process and can allocate this memory range for its exclusive use.
  512 bytes is enough room for multiple disk encryption keys, or for an AES 256 key schedule.
  Any attempt to boot to ANY alternative operating system or device will overwrite the keys stored in this address range.

In the very same paper they discuss your question:

As for a software solution (I have not tested) but I can see that HWiNFO has an alert function, however I was not able to find RAM temp, but I didn't try very hard.

Lastly (something I have no experience with) you can "permanize" your hardware state by using Epoxy to make it difficult to remove hardware and/or difficult to introduce new hardware.
Sidenote: for those of you with a stationary PC, a chassis with screws and DDR3 memory is plenty of obstacles to prevent cooling of ram if you start shut down before attacker attempts anything.


"If encryption has not been implemented, a comparable alternative has been implemented"

Disclaimer; I haven't done HIPAA work for over a decade, and reality may vary from history.  I welcome comments and alternative answers from someone currently working in the space.

The encryption specifications of HIPAA are "addressable", which is to say, they're not "required".  You can choose to do something else as long as you document in writing that you believe your alternative is a "reasonable and appropriate security measure":

  In meeting standards that contain addressable implementation
  specifications, a covered entity will do one of the following for each
  addressable specification:

  (a) implement the addressable implementation specifications;

  (b) implement one or more alternative security measures to accomplish the same purpose;

  (c) not implement either an addressable implementation specification or an alternative.

  The covered entity’s choice must be documented. The covered entity
  must decide whether a given addressable implementation specification
  is a reasonable and appropriate security measure to apply within its
  particular security framework.

So, you can choose to implement encryption, or to lock the drives in a drawer, or to do nothing at all - as long as you document that your decision that it is a "reasonable and appropriate security measure."

Now, in reality, you'll want to implement solutions that your auditors agree are reasonable and appropriate, or it goes on the report as a gap.  Your management will want there not to be gaps on any audits, or their susceptibility to fines goes up.  And when something bad happens, those documents that accept the risk of doing it otherwise become even more important.

So the best answer I can give you is to get a reputable auditor to review and approve any alternatives you consider.  HIPAA is known for being hard to implement for this reason.


How do you properly make a backdoor shell with netcat using UDP?

Have a quick look at a related netcat query on serverfault here - this may help. UDP does not behave as well as TCP.


When passwords of a website leak, are all leaked passwords equally easy to read?

As others have mentioned, "most sites" hash the passwords, they do not encrypt them. But a site can choose to do whatever they want. Some sites have encrypted passwords and some have stored the password as plaintext. Obviously, if they are stored as plaintext, then there is no difference in how long your password is.
But let's assume that the site did what they are supposed to do and hashed the password with a salt. The length of the password does make a difference to the ability to brute force a guess of what the hash might be, but that assumes that the password is random.
A hash of a 100-characters-long password that is well-known will be cracked very quickly. And that's a factor that a lot of people forget to account for. Length makes it more difficult to guess if you are having to guess each character at a time. But if you are using a dictionary of well-known passwords, then length is no longer a protection if your password is in that dictionary.
So, your question is a good one. Not all passwords can be cracked as easily as others, and length can be a factor in how difficult it is to crack, but the overall factor to consider is how guessable the password is. Length can make it harder to guess, but not by itself.


Is hacking back a valid security technique for companies?

We had this debate at our local OWASP chapter last night about whether a honeypot should strike back.  We did talk about some legal and moral issues however decided it was not a good idea because:

The majority of attacks are coming from dumb clients on botnets or through automated tools, so what are you actually achieving by taking out yet-another-dumb client?
The focus of your business should be aligned to your business objectives - fighting cybercrime (unless you work for a police authority) should not form part of that.
If the attack becomes serious and you need to go to court; evidence that you "struck back" would not look good and could work against you.  If you are going to spend money in this topic then spend it on forensic tools so that it strengthens any legal action
Circular attacks:  consider if you accidentally strike back at another tool that has strike back capability?  then you're just eating up bandwidth unnecessarily.


Kali Linux metasploit and android attack by PAYLOAD

For Android platforms, when using the metasploit-framework project, you will need to utilize meterpreter as an APK installation in order to establish persistence.

The androidpayload is available here -- https://github.com/rapid7/metasploit-payloads/tree/master/java

A more-detailed post explaining all of the dependencies can be found here -- https://blog.ask-a.ninja/?p=39


So, either you find a mechanism to find all the executables that you want to be able to run as root, or allow your user to run everything as root:
user ALL=(ALL) NOPASSWD: ALL

Run this from cron and use the output to update a file in /etc/sudoers.d.
If you want to be sure that a program is not updated by the user, install using a separate homebrew user. In that way, your user is not able to change the programs (only the user homebrew can update the programs and all programs are owned by him).


Do Meltdown and Spectre affect other Intel products such as SSDs?

No, those types of hardware should be fine. It is somewhat unlikely that the microprocessors on such devices are even capable of speculative execution (for Spectre) or are vulnerable to the particular pipeline bug that gives us Meltdown. Even if the microprocessors were vulnerable, though, the code they are running is generally fully trusted, whereas Spectre and Meltdown require that the processor run untrusted code (such as in a browser's JS engine, an operating system's least-privileged/non-supervisor ring/mode, or a hypervisor's guest OS) on the same CPU where the data the attacker wants to steal is handled. No untrusted code execution on the microcontrollers probably * means no way to steal data from them, and thus no need to patch them against issues like this.

* There is a way to attack some devices with Spectre-vulnerable processors over the network, without running local code on the devices themselves. However, it is unlikely this attack could be carried out by untrusted code on a computer, and fully-trusted code can read anything it wants to off the disk anyhow.


Is it okay for (iOS) browsers to interpret application/octet-stream as HTML+JS?

My question: Is that okay?

Ignoring the given Content-Type and instead guessing what it might be is a bad idea. This can for example result in bypassing external filters (like firewalls or proxies) which rely on the Content-Type for the type of analysis they do. And it would not be the first time if some parts of the browser use the original Content-Type for their decisions while other parts use the guessed Content-Type, which might result in bypassing browser internal restrictions and filters (like XSS protection filter or similar).

Apart from that such unexpected behaver differently from other browsers (and from the standard) is a nightmare for developers and can also cause security problems. Just imagine that the site offers a ways to upload various files which then get offered for download as application/octet-stream, in the hope that this will result in a download. Instead the iOS browser might interpret the file as HTML+JS which essentially results in a stored XSS.

It is recommended to forcible disable such guesses by setting X-Content-Type-Options=nosniff" in the HTTP header.


Is the enforcement of only allowing signed application to run in a Windows server a safe rule in a prod environment?

No, it isn't secure.
Signing a application does only provide traceability and unmodifiability - the created application can be traced back to the person who signed it, and the application cannot be modified without invalidating the signature.
Anyone who has the Money and possibility to go through the process of getting a code signing certificate will get one. And once they get it, they can sign anything with it, including viruses and malicious software.

Thats why Windows still warns you when trying to install signed software, but it displays the signer's Company name and subject name in the dialog box where you have to accept the installation.

To gain security, you also need to add a step called "Authorization". This means you need to scrutinize who is "approved developers".

Combining code signing with authorization, can be a effective step against malicious software instead of relying on a Whitelist. Instead of just saying for example "Microsoft office is okay to be installed", you can instead let for example end users, without administrator rights, install anything that is signed with "Microsoft", and still have security against malicious software.

Maintaining a list of approved software developers are much easier than maintaining a list of approved software, because then you can even allow users to update the software without needing elevated rights.

However, practically, its not a good solution, because most users need to run small softwares from time to time. It can be a simple thing like some software required to view a webpage related to the work the person is doing, or the person are trying to access the Company bank account for the first time and the bank needs to install some "security authenticator application".

So regardless of if your'e whitelisting software names, or if you are whitelisting developer names for signed software, such deployments are only suitable in high security Environments where its also practical to say that the computers are strictly for one purpose only. In these cases its common to install very restrictive launchers too, like "Kiosk launchers" to prevent the computers from being used to anything else than they are intended for.

To make a analogue comparisation:

Code signing is like ID-cards. Requiring every visitor to a building to show their ID card does not really add to security, since unauthorized indivuals could still enter the building using their own ID card.

To add to security, you need to also introduce a "authorization" step, where you check if the name of the ID card does match a access list or guest list of whoever is authorized to enter the building. This keeps unauthorized indivuals out from the building.


You need to url decode it first. There is a character in the middle %2B that is a ;.

Check this out.

QGluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwiMCIpO0BzZXRfdGltZV9saW1pdCgwKTtAc2V0X21hZ2ljX3F1b3Rlc19ydW50aW1lKDApO2VjaG8oIi0%2BfCIpOztwcmludCgiaGFvcmVuZ2UuY29tUVEzMTcyNzU3MzgiKTs7ZWNobygifDwtIik7ZGllKCk7

turns into

@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo("->|");;print("haorenge.comQQ317275738");;echo("|<-");die();


Is CSRF token validation required for http method other than POST and GET?

In modern browsers, requests with methods other than HEAD, GET and POST can't be sent cross-origin without a CORS permission.

If your application verifies that the request method is, say, PUT, an attacker can't forge that request in a CSRF attack, unless you explicitly give permission, e.g. with an Access-Control-Allow-Methods: PUT header.

See also: Examples of access control scenarios


What format is an decrypted RSA private key in, specifically in OS X Keychain?

I'm reading between the lines of the chainbreaker docs and your OP (having not tried the tool yet myself), and it seems like the private key should be fully present under "Decrypted Private Key" in raw hexadecimal format. The rest seems to just be a novel display format for the metadata.

Put simply, I believe you need to convert the raw hex key into base64 which is how we are used to seeing RSA keys in plaintext. This answer explains it fairly well:  https://www.reddit.com/r/crypto/comments/2hcd4z/converting_a_hexadecimal_private_key_into_a_pem/ckrgs8k/


Uninstalled Nvidia 3D Vision.

Didn’t realize 3D vision was the drivers for their 3D glasses. Thought it was one of their critical 3D graphics drivers. It made sense for that to sync with something as convenient as mDNS.


How come iOS exploits/jailbreaks are worth so much in the "0-day trade"?

Any exploit worths much more before the vulnerability is known (AKA, 0-day) than after. The reason is simple, there are no available patches for an "unknown" vulnerability, so the exploit works in every device using the vulnerable software given the proper conditions for the exploit to work.

Once the vulnerability is known (publicly, or to the authors of the vulnerable software) the patch is developed, this may take some time but is happening. Once the patch is available the exploit only works on outdated software, which is much less than before it's patched

That explains why it worths more as a 0-day than as an exploit abusing a known vulnerability. The specific price for an iOS 0-day exploit worthing 1.5 million USD is probably cause Apple was paying up to 500.000 USD last year for a 0-day in their devices, if the "legal market" raises the price the "dark market" will raise it too, if not why would someone sell a new exploit in the dark market with all the legal implications it has if the company already pays more without any legal implication?

Edit: Just as a reference (Real price may vary) you can check how much it's estimated to worth an exploit before and after the vulnerability is known here, and you'll see that proportion between both prices remains aproximately the same for every CVE


SSL authentication unexpectedly failing - could this be caused by SSL Inspection/Fortinet?

The first thing is to communicate with your client: ask if they have a Fortinet appliance that is configured for SSL inspection on purpose. This is the only way to distinguish this from a genuine man-in-the-middle (MITM) attack, as anyone could make a self-signed CA that appears as a Fortinet appliance.

After that, you have the following choices, but this should be discussed closely with your client, comparing pros & cons regarding both security and maintainability.

Add an exception for your entire server to bypass the transparent HTTPS proxy. While the SSL inspection protects the users inside the organization while they surf freely on the Internet, a server should only make connections to trusted web sites.
Add exceptions for the sites the server needs. This is more restrictive: it may add some security, but also needs more maintenance as you might occasionally need to ask for more exceptions.
Ask your client for the public CA certificate of the Fortinet appliance and install it to this server's trusted root certificate authorities. This has its risks it the private key for the appliance gets compromised. Also, you need to do this again if the client upgrades or replaces the appliance with another. At that point you must remember to remove the old CA certificate, too.

They should know if they are performing SSL inspection, as they must have done the same for all the client computers. In some countries they would also need a consent from their employees.


Is there a website or free downloadable program to identify and remove malware from an ISO file?

it could issue updates through fully functioning bitmap

So you're talking about stripping out steganography rather than neutralizing malware - in which case you'd get some mileage out of converting the file format (then possibly converting it back again). However it is technically possible to embed the content in such a way that it is still recoverable (IIRC the hidden WoW user id is extractable from a photo of the screen in addition to a direct image grab) e.g. if the image is of a barcode, then converting the format is not likely to disrupt the value embedded in the bar code.


If clients broadcast SSID's anyway, does it make a difference if AP is hidden or not?

First, we agree that hiding the SSID is not a security feature. But it can be handy sometimes because the attacker needs at least one connected client to a hidden network to send de-auth and get the SSID.

Most important, hiding the SSID might affect client's privacy. Because the client is broadcasting a trusted network SSID, so a rogue AP can be set by an attacker, and then he might be able to set mitm. "only if the network is set to open auth"

Check this answer for more,


Yes, this is possible. It is not an easy task, though, and you are not likely to be a target.

There are series of equipment which are shielded so that such attempts are more difficult. They follow sets of standards called TEMPEST.


Installing profile on "Good" Mail application give someone admin permission on my iPhone

This is a pretty standard message associated with MDM's and commonly seen with Bring Your Own Device (BYOD) plans.

The reason you're seeing this message and your company requires you to hook your phone up to the Mobile Device Management software is because they don't want unprotected company assets. This means if you leave the organization or go rogue, they want the ability to remove company property from your phone. Almost all modern MDM's allow for "select wipe" which will only remove content that has been pushed from your MDM profile, however it should be noted that an administrator of an MDM can remotely wipe your entire device should they see fit or make a mistake.

Safe is a relative term - the question you should be asking yourself is "Do you trust Good?" and "Do you trust the person who administers the server?" There is always an inherit risk with data collection anytime you connect any device to the internet, that risk doesn't just exist within MDM software.


Protecting third-party credentials in a web database in light of weak passwords

This makes no sense.
There is an interesting basic difference between passwords and TOTP/HOTP.
TOTP is a symmetric algorithm. The server and the client share the same information. They share the OTP secret key, the synchronized time and the last timecounter to avoid replay.

In contrast the password authentication mechanism does not share information. The user knows the password, but the server does not know the password. It only knows the salted and maybe peppered hash of the password. I.e. the server does not have all necessary components to get to know, what the user knows - i.e. the password!

Again, in the case of TOTP the server has all information. The user does not have any additional information. This means if you want to use TOTP to encrypt something on the server, the server will also have all information to encrypt/decrypt this. And this means that the encrypted data and the encryption key (or the information you use to create the encryption key) are located on the server.

The question is, which threats you want to mitigate.

Mitigating the threat of sql injections and stealing the database can be faced by using an application level encryption key, that is not stored in the database. In this case this is even better than creating an encryption key from any TOTP material, which is probably also stored in the database, since the attacker would get the encrypted data and the information to create the encrpytion key when he stole the database.


Stack Overflow on ARM : Null Bytes Issue

Why would you need a specific FP ? The saved FP is there to be loaded back into the corresponding register by the vuln() function when it exits; but that function does not access it in any way, so it could have any value. The loading back of FP is for the benefit of whatever code will execute immediately afterwards: normally the caller of vuln() (who wants to get his FP back), but, in your case, your exploit code, since you hijack the return address. It is then up to you to deal with a non-sensical FP value (that's your code: you can make it recompute an adequate value of FP with a few zero-free opcodes).

Edit: this article, especially section 2.4 ("Getting a known value in a register") might be enlightening.


What does Frank Abagnale mean by "Level 4 security" in his talk at Google?

It is probably the level of assurance that the authentication is correct: https://developer.mobileconnect.io/level-of-assurance

  A Level of Assurance, as defined by the by ISO/IEC 29115 Standard,
  describes the degree of confidence in the processes leading up to and
  including an authentication. It provides assurance that the entity
  claiming a particular identity, is the entity to which that identity
  was assigned.

  At Level of Assurance 2 (LoA2), there is some confidence in the
  asserted identity of the entity. LoA2 is used when moderate risk is
  associated with erroneous authentication. Successful authentication
  will be dependent upon the entity proving, through a secure
  authentication protocol, that the entity has control of an agreed
  credential.

  At Level of Assurance 4 (LoA4), there is very high confidence in an
  asserted identity of the entity. This LoA is used when a high risk is
  associated with erroneous authentication. LoA4 provides the highest
  level of entity authentication assurance defined by this standard.
  LoA4 is similar to LoA3, but it adds the requirements of in-person
  identity proofing.


Is it wrong to collect and store IP addresses?

There should be no problems with this from a legal/personal information perspective, as if you are using IP ranges in aggregate to understand stats per country you are not storing information about an individual.

Your problem may be that you rely on the IP data to give you results - remember the IP address you see a connection coming from may have nothing to do with the individual connecting. They may be routed through intermediaries, or their ISP may be routing connections strangely, or their company may route internally to a point of presence in another company etc.


Tomcat application arbitrary file read exploitation

The fact that you're already able to read from web.xml in the /WEB-INF/ directory should be more than enough to give you an idea of which other files you can read. The purpose of web.xml is to have path mappings for Tomcat to understand where to pull specific documents from, so you should be able to take advantage of those path mappings within web.xml to read additional files. Essentially, you should be able to parse the contents of web.xml in order to get the locations for Java source/.class files, and from there you should be able to include those via the bug, and decompile the java bytecode (if they're .class files that you're pulling from the web.xml mappings) in order to pull potentially sensitive data such as SQL/LDAP credentials.

If I'm doing a bad job at explaining this, check an old HackerOne report from my security team. We are exploiting a very similar bug in this instance, and we included the contents of web.xml, appended a ? to the end of the URL to prevent an extension from being added, and then wrote a script to parse the contents of web.xml to get the path mappings for various sensitive .class files containing java bytecode: https://hackerone.com/reports/413193

I'd suggest doing a directory bruteforce on /WEB-INF/CLASSES/* if you (for some reason) cannot pull the mappings for files from web.xml, although you should be able to do that no problem. Check our HackerOne report that I linked. It's a step-by-step guide of how we exploited an almost identical security flaw to what you are currently describing. If you find that report useful, be sure to thank Dominik Penner and Manny Mand, former members of a security group I operated which was responsible for finding those vulns (Dom aka zer0pwn and Manny found this, I'm just the guy who ran the group).

tl;dr - Essentially, this is a file disclosure bug but without the ability to traverse back to the root/home directories. You're limited to the directories you already mentioned, although these directories often contain java bytecode in the form of .class files, and such files often contain credentials for stuff like SQL or LDAP... so despite your directory traversal attempts being limited, you should be able to use web.xml to map out the paths for .class files containing bytecode, then if you're lucky you can include those files and grab potentially sensitive info after decompiling the bytecode.


Identifying HP Printers with NMAP and then using results in Python/Perl

This functionality already exists in Nmap, in the pjl-ready-message NSE script. Here's an example usage:

nmap -p 9100 --script pjl-ready-message --script-args pjl_ready_message="your message here" 192.0.2.0/24

The script already checks for a real PJL service before sending the command, so you probably don't have to check for OS fingerprint results.


Is my (Chrome) email address available to websites when I'm logged into Chrome?

No. Chrome doesn't disclose the email address associated with your Gmail account to websites without your consent. This would constitute an information leak vulnerability you could report to Google's VRP.

That said, they may be able to determine if you're logged, e.g. via timing attacks.

Even extensions need the chrome.identity API permissions to access your email address and other information about your account.


How does SSH defend against keystroke-timing attacks?

SSH does not actually defend against keystroke timing attacks. To my knowledge, no actual case of password recovery through timing analysis of a SSH connection has been spotted in the wild; however, since nobody in particular would have kept me informed if that had been the case, what does it prove ?

This report claims that the Song-Wagner-Tian attack is too difficult to pull off on a practical network, because the latency implied by the network masks the delays between key strokes. One may notice that the purported attack relies on a learning phase in which delays between two specific letters are first gathered (for a specific victim); that phase looks hard to do in practice. Another vexing issue is that an oft-typed password usually has its own delay patterns; that is, when you type the same password again and again, the delay between, say, a 'v' and a subsequent 'o' occurring in the password will be quite distinct from the delay measured when the "vo" letters appear in a non-password text that you also type.

Note: SSH includes some random padding, at least four random bytes (see the standard), but this is meant to avoid some potential weaknesses of the used block cipher. It does nothing about timing.


I clicked a Grabify link. Is my phone hacked now?

TL;DR: Don't worry, your phone is not hacked.

Essentially they send you a tracking link and they know from which IP address this linked was accessed. They then can match this IP address to your ISP, and might infer a more or less precise location depending on how your ISP assigns IP addresses. This is the kind of information which are visible by any website your visit, i.e. these are not actually secret private information. While the attacker could for example try to DDoS you it is likely more to just scare you in this case. Don't be scared.

You can try yourself what the "attacker" and also any website you visit can see. Just create your own link at grabify, visit it and check the result.

I've tried myself and for example the location is way off  (another town) and the claimed device name is actually only its IP address again. Not actually impressive and nothing to worry about. Depending on the capabilities of your device this might also include the battery level etc. Again, these information are not really secret but might be used to scare you since you don't expect the "attacker" to know this and wonder what else they know. Best check yourself.


Try a single line port specification without spaces, like such:
$ cat ports.list
21-23,25
$

That works as expected:
$ nmap -p `cat ports.list` host.example.com

Starting Nmap 7.60 ( https://nmap.org ) at 2021-03-25 15:07 UTC
Nmap scan report for host.example.com (192.168.1.17)
Host is up (0.00089s latency).

PORT   STATE  SERVICE
21/tcp closed ftp
22/tcp open   ssh
23/tcp closed telnet
25/tcp open   smtp

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds
$

Note that in the answer you reference, he used 'tr' to translate one-port-per-line into single-line-comma-delimited.


Do browsers allows pages loaded on one tab to access/intercept/inject data in other tabs?

Very common implementation is sharing sessions in the same process. E.g: you are logged into your bank account in tab A. When you copy the URL and paste it in the tab B (of the same browser-window), then: you are still logged in. The situation should be different when you start another process of your browser and paste the URL into another browser-window.

Does it mean, that website A opened in tab A has access to the session from any other tab? The answer is simple: no, because of the same origin policy. Malicious websites cannot interfere with other websites (even there are opened in nearby tabs).

Another idea could be stealing data/content from website opened in tab A via XMLHttpRequest. XMLHttpRequest opens the link to our bank, scans for sensitive content and sends it to the attacker. Well, this scenario is still fictitious. Why? The same answer here: same origin policy again. However, there is a possibility to increase the chance of success in this scenario (e.g Zone Policy in IE or MSXML 3.0 [http/https]), but IMO it's still very unlikely.

Well, the main danger which should be mentioned in this context are:

CSRF
Tabnapping

CSRF:

Let's look at a simple scenario. You are logged into your bank, which has no CSRF-protection. Meanwhile you switch to another tab (or even close your tab with the website of your bank - the most important here is that you didn't log out, your session wasn't destroyed and it says that you are still logged in). Another tab sends HTTP requests to your bank. As website has no idea if reqests are generated by script or by human, it accepts them. So unauthorized commands/requests were transmitted to your bank.

Tabnapping:

It's pretty new kind of phishing attack. There is a JS-script put on normal-looking site which detects if your tab is active (focused) or not. You switch to another tab. Then JS replaces the favicon and title (now they look the same as your bank's favicon and title). When you click back on the fake tab - you will see changed content (which looks the same as the website of your bank).


Integrity check against package repository?

Have a look at SecureApt they check updates on checksums and also on pgp keys you give your trust to.


Linux command to wipe files on an SD Card?

Flash storage is inherently different from spinning disk storage at a physical, and operational level.  Unlike spinning disks, flash storage has a limited amount of write cycles.  The solution to increasing the lifespan of the media to something usable that storage makers have come up with is called wear leveling.  Essentially what this means is that when you write to a logical block on the disk twice, you're in all likelihood writing to two different physical blocks in the storage media.

The answers that claim that simply re-writing to the blocks is sufficient don't take this into account.  You asked specifically about SD Cards, which according to this answer is sometimes implemented in SD cards, and other times not.  So it's not so easy to give you a straight answer.

In addition, before physical block can be re-written to, it has to be erased first.  This takes some extra time, and reduces performance. To make matters worse, the flash device has no idea which blocks are in use, and which aren't unless it's told  This is what the trim command is used for.  In a nutshell it tells the underlying media which blocks it can free up, so that the storage media can then perform the erase operation in the background during idle time.  The trim command is specific to the ATA/SCSI bus, and again, you asked about SD cards.  I don't know if there's an equivalent command for the SD card market, but it's something you should keep in mind.

The end result is that erasing in Flash storage isn't as simple as erasing a spinning HDD.  The fact that you can't be assured you're writing to the same physical sector complicates matters greatly.  The best you can hope for for erasing a file on an SD card is to write to every single sector on the drive.

Even this isn't perfect.  Some manufacturers have spare sectors available when one sector wears out the logical block gets mapped to a new sector. So it's possible that even over-writing all logical sectors won't over-write all physical sectors.  (BTW, the same is true for spinning disks).


Why does my web server receive so many TCP resets from some clients?

There is a few things that could be going on. Its possible that this is related to ECN on firewalls which can cause this, but I can assure you this in probably not any type of flooding attack or DDOS.

One reason a device will send a RST is in response to receiving a packet for a closed socket.

It's hard to give a firm but general answer, because every possible perversion has been visited on TCP since its inception, and all sorts of people might be inserting RSTs in an attempt to block traffic.

But as I said before, this looks more like a firewall is throwing up requests. I wouldn't be to concerned. You could do a more verbose look into that SRC see who's doing what.


Where should I put ssl cert (backend or frontend)?

Ideally, the connections from the Internet to your front-end and the connections from your front-end to back-end both need to be protected using SSL. Whatever is serving your front-end / back-end applications would most likely support SSL termination. Your front-end is most likely served by a web server like Nginx or Apache. You need to get the web server to listen over port 443 and setup SSL there.

If your back-end application is secure and isolated behind a firewall, and if (and only if) it's configured to receive traffic only from your front-end application, you can optionally skip setting up SSL between the applications. This is NOT recommended, however. Certificates are cheap if not free these days and you should aim to set it up wherever possible. There are even performance benefits to this and this lets you use fast, modern transport protocols like HTTP/2 or SPDY.

Depending on your setup, you could even terminate the SSL at the load balancers if you use them. May I ask why your back-end app is open to Internet?


You could put the captcha in the app.

App requests captcha
Server provides captcha
App displays captcha and returns user response to server
Server generates token and sends to app, the app can send that token with any requests


The short answer to your stated question is that not knowing the IV makes AES, or really any block cipher in a proper operation mode, that much more impossible to brute-force, by basically making the IV an extension of the key. For AES-256, the 256-bit key plus a 128-bit IV basically requires your attacker to correctly guess a sequence of 384 bits, requiring a worst-case 2^384 attempts. Putting that in perspective, a computer running at the electron level at 100% thermal efficiency, given every photon our Sun will produce in its remaining lifetime, would only be able to try about 2^218 keys before the Sun goes black dwarf.

However, the IV is needed by both sides in order to encrypt/decrypt in any mode that uses one, and so, like other specifics about the encryption scheme except the actual key that would be shared between parties during negotiation (such as algorithm, mode, block size, key size) the IV is considered public information. It's possible to hide it, in the same ways that the key can be securely exchanged (offline, public-key crypto), but it isn't necessary.

With that question answered, I must say that there's a lot of information you haven't provided, that makes it impossible to answer the broader question of "is this scheme secure". For instance, how is the user's password related to the key (are you using a KDF or other "key-stretching" scheme?) What mode of operation are you using for the AES encryption (some modes are more secure than others, and some are effectively broken). EDIT: CBC mode isn't a terrible choice (there are worse) but care must be taken to ensure that your code cannot be used as a "padding oracle"; a "black box" that will tell an attacker whether a particular ciphertext message, when decrypted, is properly padded. That can be used to reverse-engineer the plaintext message from the known ciphertext without knowing the key. Since this is solely a server-side process and so no client code is available to use to decrypt, an attacker would need to penetrate pretty far in to be able to turn your server code into a padding oracle, but never assume; if you have a good implementation available to you, I would choose an authenticated mode, such as GCM or CCM, which will resist padding-oracle attacks.

I will also say that this scheme appears to be server-side only; if the key and IV are stored on the server only, then all encryption and decryption must happen there, which would mean that unless you're using something else such as SSL to send data to the client, the security of this particular piece is pretty moot.


A bind_tcp payload doesn't require a LHOST because it doesn't initially make an outgoing connection. Instead, it listens (binds) to the specified port.

Perhaps you are wanting to use a reverse_tcp payload, this would require a LHOST and LPORT to be specified to connect to.


This sounds like a job for public key crypto. Sign messages from the devices worth an embedded private key. Then verify in the mobile app and on the server they report to.

I would propose:

Embed a unique private key in each hardware sensor.
Provide a certificate from a private certificate authority (that you create) with the device.
Put the CA's public key in the phone app.
Use the private key in the sensor to sign every data event, and include  the identity of the sensor and the date/time, and a unique identifier in every event (to prevent replay attacks). Also include the certificate with the event.
Using the signature and certificate, the phone app can verify the event comes from a legitimate sensor, without having any way to tamper with the event.
The app passes the entire event+signature+certificate to your central server, which can use the unique ID, and date/time to verify that the event hasn't been duplicated.

You also need to consider your attacker: Are they only going to look at the phone app, or will they try to subvert your sensor. Can they alter the readings before they get signed (e.g. hair-dryer on a thermometer :-) )


Would my IP be recorded when I visit a website

The website admin certainly knows your IP Address. If they didn't they couldn't send you the website you requested. Whether or not they record your address or try to track you is entirely up to them.

The same applies for the hosting provider as well as everyone between them and you, starting with your ISP.

The domain name registrar doesn't know anything about who visits the domain. However, the DNS server does. Sometimes the registrar will also host your DNS, so they might find out information about who visits the site. However this is probably very rare in practice because normally they wouldn't handle DNS requests directly from users. DNS is a distributed system, so usually the DNS host just talks to other DNS servers that are making requests for users and don't pass along end-user information.


How to do a privileges escalation with ping?

A SUID binary is not inherently exploitable for privilege escalation. The problem is when there is a vulnerability in the software (ex. many CTFs have a SUID binary that contains a buffer overflow vulnerability that can be exploited for privilege escalation) or an administrator sets the SUID bit on a binary that should not have it set. An extreme example of the latter would be an admin setting vim to SUID with owner root, allowing users to execute bash commands as root within a vim session (:![shell command]).

A quick reference check on this led me to this article on Linux privesc. You may find the section 3. Exploiting SUID Executables helpful.

The ping utility requires the binary to be owned by root and the SUID bit set because it sends/receives ICMP requests using "raw sockets" which only root can do. You would need to find either a vulnerable version of ping (I assume this is why @Arminius asked for the version) or a way to inject code/commands. Personally I have never been able to leverage ping in pentests or CTFs for privilege escalation, but that certainly doesn't mean it's not possible :)

A famous similar example is older versions of nmap which supported the --interactive mode. If the SUID bit was set (many scans such as the default syn scan -sS "require raw-packet privileges") then you could drop to a root shell from the interactive mode. More info is in the privesc link above on this if you're interested.

If you are looking at a CTF challenge, I typically start looking for obvious non-default SUID programs (ex. /opt/myprog/test.bin) first, and then come back to the "normal" suid programs like /bin/ping as a last resort after other checks are fruitless.


How many people are required to build your own 24x7 security operations center (SOC)? Rough costs?

As the others mentioned this can only be established when you know more requirements.

These might include but not be limited to:

Region
24x7?
scale/type of work involved.  (I.e. how much work/ how often ?)

For a rough idea you could sketch out how the current incidents you mentioned would've been ideally dealt with, and how much work this would've taken from how many people - with generous estimates as always on time actually required.


Do payload sizes reveal URLs when HTTPS is deployed on news, blogs, etc?

Yes, if the site is public and its content is known to the attacker, the attacker with access to the encrypted traffic can find out which page on the blog the user visited just by measuring the size. The website could remedy this by padding all lengths of all pages to the maximum, and always including the same number of images, each with padded sizes. The images also need to be loaded by the browser on the same time for all pages.


I bet there's a small piece of code hidden somewhere that takes care of deobfuscating the real payload from the image and then executing it; that allows the attackers to have a very small piece of malware that they can easily hide somewhere in an otherwise unoffensive PHP file, while keeping the big and not-so-sneaky malware in an image which allows it to go unnoticed most of the time, unless someone knows what to look for.

For the "how to use" part, find a way to embed PHP code in an image (it may be as simple as a PHP file renamed to .png to something more sneaky like steganography that won't be noticeable just by looking at the displayed image), then create a little piece of code that takes care of deobfuscating your actual payload and then executing it.

Also I've read somewhere that badly configured web servers can serve image files as text, which results in a big mess of Unicode characters when viewed in a browser, but what's interesting is that PHP code in these "images" will get executed.


How secure is the Windows Credential Manager?

The Windows Credential Manager is anything but secure. It's "secure" at the user account level, which means that any process that the user ever runs and the user themselves must necessarily be trusted in order to call this system "secure" with a straight face.

The only semi secure way of using the Windows Credential Manager is to store values pre-hashed, then verify those hashes. However, since any elevated process the user runs has full read/write capability on that user's credential store, it simply can't be trusted at all.

Lets think about "secure" in the sense of locking an application locally. Let's take the example of a content filter that locks the settings page to keep the kids from enabling adult content, using the Credential Manager to store custom credentials. The same user, trying to bypass this, can do so easily. A user can visit the Credential Manager in the Control Panel and, though the values show up in asterisks, (*****), they can simply erase the value and replace it. Delete your hash, put in their own they're in.

What's even sillier is that the Control Panel will show asterisks, but if you use code accessing the applicable APIs, you can get the values in plain text. So passwords are not safe, hashes and such you verify to lock something are not safe. It's not safe, it's a piece of garbage and I've struggled for a long time to understand its usefulness, except for Microsoft to apparently have plain text copies of all of your passwords they can sell to the NSA.

Note
I realize there are measures you can take to encrypt contents before storing them, hashing them correctly etc, but my criticism still applies because doing these additional things is creating security, not the Windows Credential Manager. My problem with the Windows Credential Manager is that it advertises that using it through its provided GUI and or API is secure.


Is downloading Windows ISOs from TechBench downloaders safe?

You have essentially answered your own question. It appears that TechBench is simply providing an interface to download these "hidden" files from Microsoft's servers.

Given that Google Chrome says you're downloading from https://software-download.microsoft.com/, you're getting the file straight from Microsoft over a secure connection. So yes, it's safe.


Brute-Forcing DVWA login page with hydra

The check to look for a failed login is what's not working.

In the link you included their failed login included "Login failed" somewhere in the POST response. I'm guessing when you fail to login at your login.php the string "Login failed" isn't returned in the response. You need to figure exactly gets returned in the case of a failed response (and update your command to look for that) or you will keep getting these false positives.

Did you just copy that last part from the example?
:Login fauled


Can I initially hash passwords with SHA instead of hashing them with bcrypt to decouple requests from slow crypto functions?

Bcrypt is run many times to intentionally slow it down. Perhaps you need to adjust the number of rounds of bcrypt you are running? This answer has some information on it.

While what you propose may work, I can't say that implementing a variant of standard password handling is a good idea. While I have specific concerns, such as the SHA hash staying in the DB too long and the security of the encrypted queue, I generally don't see the need to vary from the standard. If it's taking too long, reduce the number of rounds used for execution. If it's inexplicably slow, figure out why. Don't just decide that you can do better than decades of security best practices. It's not likely to turn out well.

Perhaps you want to post another question (likely on StackOverflow) asking about help with finding the performance problem. That seems a much better idea.

Sorry that I can't agree with your proposal...


Why doesn't openssl s_client correctly validate google.com:443?

On OpenSSL 1.0.1f

$ openssl version
OpenSSL 1.0.1f 6 Jan 2014

$ openssl s_client -connect www.google.com:443
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---

On OpenSSL 1.0.2e

$ openssl version
OpenSSL 1.0.2e 3 Dec 2015

$ openssl s_client -connect www.google.com:443
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---

So looks like there is a change in behaviour from the version which you have. You could either specify the CApath explicitly or upgrade to a newer version.


XSS breaking out of JSON.parse and href attribute

You can't do it. Vue uses the DOM to set the href attrib, so it's not hard-coded from the server in a way that could fool the HTML parser. It's simply impossible to set an attrib with the DOM in a way that "breaks out" of the attrib, or starts a new attrib as though you had raw HTML source; all invalid characters will be logically escaped, even if the raw values in the dev tools make it look like the attack should work.

If you did any of the templating on the server (perhaps in an attempt to pre-render) then it's a problem, but as-is, you're safe.

note that data: and javascript: urls could still be an issue, but you've probably already got protection from that setup, given your apparent level of expertise.

EDIT: responding to comment

consider a simple page that uses the DOM to inject content:

   xss

If you look at the developer tools inspect view, you might see something scary like this:

">xss

It appears there's a


Is a web application firewall necessary if the application is secure?

When deploying security, it is often a good idea to apply multiple layers. Just because you have a lock on your bedroom door doesn't mean you don't put one on the front door to your house. You may also apply a generic set of WAF rules in front of multiple applications.

A WAF may be part of a larger suite for IDS/IPS, it could also help with the performance of the application if the WAF is inline so that the application doesn't waste resource on the blocking, logging, db queries, etc.

You also make an assumption that the organization has the resources and skill to gain reasonable assurance about their application's security. If it's a third party application or has third party modules, those components may not be easily upgraded or it may be closed source or against the license to modify the program.


What applications are at risk from "Backwards Unicode Names" and what are the mitigations?

Doubt if we can classify this as a vulnerability. This is a case when support of legitimate feature fails to provide protection of usability in proper form. There are some languages where text direction is from right to left. Unicode consortium had sincere intentions to make support of such languages. By the way, topic itself is not new. About Unicode exploitation there were released two papers by Chris Weber:

Exploiting Unicode-enabled Software
Visual Spoofing Attacks and Defenses

I would say that you should point attention to any modern desktop application that supports Unicode - there is a high possibility that it is subjected to such attacks.
Going further, want to admit that incorrect or bogus implementation of Unicode can lead to any type of bug starting from visual spoofing till buffer overflows.

Unicode advises following document to be read: http://www.unicode.org/reports/tr36/tr36-9.html.


How can this be possible? (malware autoinstall on chrome)

Given that the malware seems to target flashplayer.exe I'd expect that the malware uses vulnerabilities in Adobe Flash to attack the system rather than a vulnerability in the underlying OS or the browser.

Adobe flash has been shown to be extremely buggy, and it has been widely attacked as a result. Although Adobe have worked hard to fix the bugs there are still plenty of unknown bugs that can be exploited. Also, many people are not updating flash to the latest version, so there are millions of systems out there.

An attacker also has the benefit that flash works on many operating systems, so vulnerability in flash can lead to compromises on Linux and Mac systems as well as Windows systems.


State forces installation of SSL root CA, how to evade / mitigate?

There are a few options that you may have available:

You can check to see which sites have been potentially MITM'd by checking the cert tree for each site you visit. Click the lock icon, view the cert, then look at the issuing certs until you get to the root. If the root is the state root that you installed, then they very well could be monitoring any of the data you sent as if it is HTTP instead of HTTPS. This at least gives you some insight into the situation.
Put some trust in some of the sites you visit. Not all sites send password information in plain text, so the fact that the state can see that data doesn't necessarily mean that they have your password. This can be done using JavaScript client code that can do DH, and also hash passwords (among other methods). Not the most satisfying point to make, but it's something.
Use a VPN. While using the VPN, you can use a browser that doesn't have the root certs in question, so you will get a giant warning if you happen to encounter a site that has been MITM'd by them or anyone else. Of course, if they are doing more than HTTPS filtering, they may be attempting to block VPNs. This may also raise a red flag and make it obvious that you are working around their monitoring.
Use TOR. TOR effectively hides your traffic like a VPN does, but it can be a little stealthier about it and make it less obvious that you are trying to work around the state monitoring. There's a constant give and take between states that try to block or identify TOR traffic and the TOR developers. If your country isn't working as hard as another, then you likely get the most benefit.
Use a service like Amazon Workspaces, in which you make use of a remote desktop running in a cloud in another country. You are sending keyboard and mouse info, and you get back display and sound. These services often use their own protocols (like PCoIP in the case of Workspaces) which are often encrypted and don't look like traditional web traffic.

Bottom line: if your government wants to see what you're doing online and have demonstrated a willingness to use technology to do that, then they are likely going to adapt and evolve the technologies they use to enforce their desire. For you to evade them, you will have to be willing to adapt and evolve just a little faster. You must also be willing to take the chance that you may be caught, and face whatever actions are associated with that. I'm not suggesting that you do anything--just listing a few options that you could choose... or not. There are many options I didn't list, and many new ones are being created all the time. Good luck, and stay safe!


Is there a way to hide HTML source code yet keeping it effective?

You cannot hide HTML and expect the browser to be able to interpret it. The browser needs full access to the HTML in order to display all parts of the site. As soon as the browser has access to it, the user can also gain access to it.

On a further note, JavaScript is also not able to "hide" the content of the site and still make it accessible to the browser, and thus the end user, for the exact same reason.


Passwords are concerned with system access. They are used to verify that you are who you say you are (example: logging into email), or at least that you are someone that is allowed to access the resource you are trying to access (example: a code to open a door).

The important thing about passwords is that they are fed into a system, so extra measures like lockout (too many wrong attempts) or 2-factor verification (texting a code to your phone) can be implemented.

Keys, in the context of cryptography, are not passwords, they are used to change a message (plaintext) into an unreadable form (ciphertext). Think about it like this: you have an encryption machine. You feed your plaintext and your key into the machine and get scrambled letters and numbers out (the ciphertext). You secretly share your key with your friend, then you can send him your ciphertext, and it doesn't matter who sees it. Since your friend had the key, he gets your ciphertext and feeds it into his decryption machine along with his copy of your key, and the machine prints the original ciphertext.

This is a little more difficult to secure: there is a principal in cryptography that says you must assume that an enemy has intercepted the ciphertext and has a copy of the encryption and decryption machines. So he can try as many times as he's like to guess the key and there's nothing you can do to stop him.

The above describes a symmetric cryptosystem, where you kept the encryption key secret because the same key is used to both encrypt and decrypt the message (like locking a deadbolt on a door). This is different form asymmetric cryptosystems, in which the encryption key (the key used to lock the door) is different from the decryption key (the key used to unlock the door). This has the advantage that 2 parties don't need to secretly share the key before communicating. For example, I post to an online forum

"Bill, what's your address? - Please encrypt the answer using the encryption key 103234".

Now, Bill can encode his answer and post it for all to see, but because only the encryption key has been shared and I kept the private key to myself, so only I can decrypt it (not even Bill can decrypt it, even though he already knows the plaintext). Furthermore, now anyone can send me messages that only I can decrypt.

Note on terminology: an encryption-only key is usually called a "public key" since everyone can see it; a decryption-only  key is usually called a "private key" since you don't share it with anyone.

Technical note: while asymmetric cryptography seems superior, it is a LOT more computationally intensive (bad for, say, encrypting terabytes of info) compared to symmetric cryptography


An HMAC key is a symmetric key, i.e. a bunch of bytes. The "symmetry" relates to the following important fact: the very same key is used both to produce a HMAC value over some message, and to verify the HMAC value over the message. In that sense, HMAC is not a digital signature algorithm (but some people are nonetheless talking of "signatures" about HMAC, which is both wrong and confusing).

Distributing symmetric keys is a complex endeavour for two reasons:

A secret value which travels is "less secret" because travel implies extra risks of exposure.
A secret can remain secret only if not too many people are aware of it. Therefore, if n people must be able to do symmetric cryptography with each other, you more or less need a shared secret per pair of users; so there will be n(n-1)/2 symmetric keys in the whole system.

To make things easier, public-key cryptography was invented. It is also known as asymmetric cryptography; when used with digital signatures, the key used to generate signatures is distinct from the key used to verify signatures; they are mathematically linked to each other, but it is not feasible (or so we hope) to recompute the signature generation key from the signature verification key. Therefore we can afford to make the latter public, hence the name.

Public-key cryptography makes the key distribution problem substantially easier:

The public keys are public, so confidentiality of transfer is no longer an issue.
Each user only has one public/private key pair, so there are much fewer keys altogether in the whole system.

Now public-key cryptography makes key distribution easier, not easy. You still have to come up with something which allows user to make sure that they use the right public keys. This is where PKI comes into play: a PKI is a system to distribute public keys.

So how would things go in practice ? Consider SSL/TLS, often used in combination with HTTP, yielding HTTPS. When a Web browser connects to a HTTPS-powered Web site:

An initial "handshake" procedure is performed, where the server shows his certificate to the client (the browser). This is PKI. The certificate contains the server's public key, and is signed, and that signature is the incarnation of the PKI. The client verifies a bunch of signature and is finally convinced that the public key it sees really is the genuine public key from the intended server.
Using the server's public key, more asymmetric cryptography occurs (this time a key exchange, possible based on asymmetric encryption, not signatures), which ends up with a nice result: client and server now know a shared secret value, and nobody spying on the line would be able to rebuild that value.
The shared secret value is then expanded (with a Key Derivation Function) into several symmetric keys, which the client and server will use to encrypt and MAC whatever data they then want to send to each other. In SSL/TLS, the usual MAC algorithm is HMAC.

The complete picture is that PKI is used to distribute public keys, and these public keys are then used with asymmetric cryptography to dynamically create a shared secret, and that shared secret is then used with symmetric algorithms such as HMAC.

So you do not distribute HMAC keys directly with a PKI; there is one intermediate layer.


Is it safe to share a LastPass master account?

It is a lot less secure. You have the equivalent of a password-protected file filled with passwords.

Everyone with access to this resource:

has all the passwords contained within it, whether they have a legitimate need or not
can change any stored password maliciously or mistakenly and confuse (delay) all other users

Moreover, when someone on your team leaves, then the master password needs to be changed and all remaining users need to be updated with the new credentials. If a user is skipped or misses the update, they are locked out.

Per-user control solves all these issues. You can:

share the appropriate passwords with the approved people
provide read-only access to passwords
revoke the single user's access to the password repository without affecting the rest of the users


How do PGP keyservers synchronize the keys?

Key server synchronize using different protocols, forming a network of more than hundred servers all around the world involved.

E-Mail Synchronization

The "old" way of key server synchronization is based on the key servers sending e-mails to each other. Whenever a key server receives new information he doesn't know yet (either uploaded by a user or received from another key server), he forwards these information to all other key servers in his synchronization list.

SKS Protocol

Because the old e-mail based protocol doesn't scale very well (especially with the number of servers in the synchronization list), a new protocol was defined for the Synchronizing Key Server (SKS), which is based on set reconciliation.

These key servers "gossip" with each other in a given time interval. From a very basic point of view, set reconciliation orders the keys in a so-called partition tree, which allows to find the differences easily without transmitting a lot of information. Only the modified keys are then exchanged.

MIT and University of Mainz Key Servers

For SKS keyservers (and also Hockeypuck, which is another implementation of the SKS protocol), the gossip partners can be retrieved by fetching their statistics page, available as http://[keyserver]:11371/pks/lookup?op=stats. Looking at the statistic pages of both the MIT key server and the one of the University of Mainz, one will realize they even have a direct, mutual synchronization agreement (look at the "Gossip Peers" column).

The key server of the CCC Hanau on the other does not directly gossip with the one of the MIT. If you upload a key to any of these servers, the other will not get aware of it directly, but through the intermediate server of the University of Mainz (or on any other synchronization path).

Visualizing the Whole Key Server Network

The SKS keyserver pool crawls the key server network periodically, and provides a dot file of the key server network (of all servers in the SKS pool, not including synchronization links based on the old e-mail synchronization algorithm).


With an SSH host key the client has to already trust the host or has to accept the fingerprint on the initial contact - of course only after validating that the fingerprint matches the expected one. When using a certificate the host key is instead put inside this certificate and the additional features of the certificate like subject, issuer and signature of the issuer make it possible to derive trust into an yet unknown host key from trusting the issuer. It also makes it possible to have a limited life time of the host key and to revoke it. Essentially using a certificate makes using a PKI possible which make everything more scalable.

If you understand how certificate validation works in the browsers you can also compare it to self-signed certificate vs. CA issued certificates: the simple host key is comparable to a self-signed certificate, where one explicitly needs to add the trust to each browser. The host key inside a certificate together with a PKI is instead similar to the CA issued certificates we have in almost all cases when accessing a https-URL. In these cases the trust in the server certificate is derived from the trust in the root CA's located in the trust store of the browser or OS, i.e. only these root CA needs to be known up-front but not each server certificate.


How secure is AES-256-CBC with user provided password and initialization vector

My suspicion is: you're doing it wrong™.

This is why I think so, from the top of my head:

The variable holding the ciphertext is called hash.
You are encrypting the user name.
This looks like an XY-Problem.
You do not (show how you) derive the key from the password (the openssl_encrypt password is the key, according to the docs. So unless you are deriving a key from the user supplied password, that's not going to work out.)
You are not using a CSPRNG to get an IV for AES-CBC.

  But now someone told me that by defining the IV I weaken the encryption as that would make the password sort-of useless.

That someone was right. See the linked question on crypto about using a CSPRNG with AES-CBC to learn more.


How to block BYOD users from installing malicious versions of a common app?

Android uses a code signing system to prove who the author is of any particular app. This means that you can trace any Android APK back to the Google account of the developer (or company) who did the build.

Since this is built in to the core of Android, I would assume that MDMs use it as part of the app whitelist process. ie any version of the same app signed by the original developer is ok, a version signed by anybody else is not ok.

As mentioned by @schroeder, exactly how the whitelisting is done probably differs from MDM to MDM, and is undoubtedly proprietary information. For a more concrete answer, you should contact the customer support of your MDM vendor.


How are chosen plaintext attacks against ECB implemented in the real world?

Sounds like you're well on your way to figuring this out. I've never exploited ECB chosen plaintext, but I recently did a padding oracle exploit, so I've got some idea how you would do this.

The basic idea is to brute force one byte at a time.

Just suppose we have a simple example where there is no other data inserted so it's just "[username][secret]". First, set your username to 16 A's. Then you change the last character to a B. In fact, go through all the 256 possible values for the final byte, and keep a record of the cipher texts.

Now set your username to 15 A's. The plaintext block will consist of your 15 A's, and one byte from the secret. The ciphertext will match one of the ciphertexts you previously generated, and from that you can deduce one byte of the secret.

Now set your username to a 16-character value: 14 A's, the one byte of plaintext you know, and cycle through the 256 possible values for the final byte. Record all the ciphertexts. Next step is to set your username to a 14 A's, and nothing else. From the generated ciphertext you can deduce the second byte of the secret.

Carry on and pretty soon you have the full secret!

In a practical scenario there are likely to be other things that make exploitation harder, but this is the basic idea.


Google Chrome - How to save usernames only

An option is a custom GreaseMonkey script.

The majority of password fields are typically of input type password. GreaseMonkey could look for any such fields and when they are updated by Chrome instead of the user, XOR in a Base64 symmetric key before Chrome dispatches the form.

This way the GreaseMonkey script could ask for the symmetric key when you start Chrome and it is stored in memory until Chrome closes; Chrome has no persistent copy of the real passwords; and yet you only need to remember one password. The symmetric key can be stored in any truly secure password store the rest of the time.

Although all this does assume that Chrome's built-in password store is actually weak. I don't recall any article saying it is.


Create a new database + user with php script -- Secure

Best practise would be to not do that.

I'm a developer that works on a seriously complex system. We have several different teams working on multiple interconnected systems that all works towards the same database, almost. We have split some data over multiple databases, generally separated by country, for performance reasons. But they all have the same design and are created manually when need arises.

I fail to see that you have a system so complex that it would require you to have separate databases. MySQL can handle many rows.

So instead of splitting databases, or even tables, per client, just connect each row with a client_id. Then you don't have to have extra sensitive credentials in your code and can safely follow the "Least privilege"-principle

If you still feel that you absolutely, without a doubt, need to have a database per client, consider these points:

Does it really need to be made automatically, or can you not do it manually whenever a new client is added?
Make sure the file is not accessible from the outside, which applies to any type of credentials you might need.
For the love of god, don't post your credentials on github.


How practical/important is the Lucky Thirteen TLS attack?

I point you to this particular blog post by Matthew Green which gives a good description of the attack. In particular this quote.

  But there's no way this will work on TLS! It'll kill the session!
  Please recall that I described this as a practical attack on Datagram TLS (DTLS) -- and as a more theoretical one on TLS itself.* There's a reason for this.

  The reason is that TLS (and not DTLS) includes one more countermeasure I haven't mentioned yet: anytime a record fails to decrypt (due to a bad MAC or padding error), the TLS server kills the session. DTLS does not do this, which makes this attack borderline practical. (Though it still takes millions of packet queries to execute.)

  The standard TLS 'session kill' feature would appear to stop padding oracle attacks, since they require the attacker to make many, many decryption attempts. Killing the session limits the attacker to one decryption -- and intuitively that would seem to be the end of it.

  But actually, this turns out not to be true.

  You see, one of the neat things about padding oracle attacks is that they can work across different sessions (keys), provided that that (a) your victim is willing to re-initiate the session after it drops, and (b) the secret plaintext appears in the same position in each stream. Fortunately the design of browsers and HTTPS lets us satisfy both of these requirements.
  To make a target browser initiate many connections, you can feed it some custom Javascript that causes it to repeatedly connect to an SSL server (as in the CRIME attack). Note that the Javascript doesn't need to come from the target webserver -- it can even served on an unrelated non-HTTPS page, possibly running in a different tab. So in short: this is pretty feasible.
  Morover, thanks to the design of the HTTP(S) protocol, each of these connections will include cookies at a known location in HTTP stream. While you may not be able to decrypt the rest of the stream, these cookie values are generally all you need to break into somebody's account.
  Thus the only practical limitation on such a cookie attack is the time it takes for the server to re-initiate all of these connections. TLS handshakes aren't fast, and this attack can take tens of thousands (or millions!) of connections per byte. So in practice the TLS attack would probably take days. In other words: don't panic.

  On the other hand, don't get complacent either. The authors propose some clever optimizations that could take the TLS attack into the realm of the feasible (for TLS) in the near future.

You ask:

  How difficult it would be to take out of a lab environment into a known LAN, or from a known LAN to a WAN?

As the attack involves measuring very small timing differences, it might be slightly difficult to exploit outside a lab environment.

  How difficult and how necessary would it be to defend against this attack given that I don't necessarily have control over the software? Are there methods of randomly padding and delaying HTTPS responses to avoid timing attacks?

There appears to be little an end-user can do to defend against this attack. System administrators can help mitigate this by updating their SSL implementations, switching to the RC4 ciphersuite (as a temporary measure) and using AEAD ciphersuites like AES-GCM.

  How does this interact with current attacks against SSL/TLS such as BEAST? Does it provide an amplifying effect?

Like the team behind the attack suggested, the attack can be enhanced by combining it with BEAST-style techniques.

  How important is this result when considering future implementations?

The attack really is nothing new when it comes to theory, it is common knowledge that you should always encrypt first before applying the MAC.


How can a user detect when a web server is phishing his credentials?

I protect myself from look-alike phishing sites by using the Lastpass  browser extension to store my passwords. Lastpass will by default only enter credentials on the correct domain, and it is much simpler for a computer to parse the domain than a human. If you are about to enter credentials into the incorrect domain, Lastpass provides a warning:

Lastpass has many other security features as well, such as enforcing unique passwords for all websites.


What to do about company that sent my password information in plaintext?

What you can do, is to reduce the risks to yourself, with reasonable means. By order of importance and least effort:

First, use a unique password for this company, do not reuse it elsewhere, even in part. That way, when the company leaks its database, your other accounts will stay safe.

Second, apply this advice for every website, because you never know, they could be insecure, too. Use a password manager to remember all those passwords; it can even generate new ones for you.

Third, as much as possible, limit the amount of identifying information to send them to the strict minimum. For example, use a dedicated e-mail address, or a redirection to your main address. You can open an (online) bank account just for them.

Fourth, call your bank and your debit/credit card provider (Mastercard, Visa...) to inform them that this company does not store your banking data securely and that you suspect they are not compliant with local laws and PCI-DSS. Tell them you are afraid this put your money at risk. Maybe they will do something, but most probably not: they might just let their insurance cover the costs in case of an incident. But at least you will have done what you can.


Allow visiting website B only if you visited website A first

You can use some authentication scheme, where clicking that button will make server generate the token that is signed or maced and make the second server trust that. Then you can pass that as a parameter in the URL, but this scheme will allow anyone who gets the token to use that (I am not sure if you are doing that for security or as a some UI feature).

Another simple solution if your users are authenticated is just add a database entry after the first logon to the site A and then read it on the second site.


Short answer: yes you are right and you can do this.

To be on the safe side however, you must ensure not to lower the HMAC function security by using it properly and not putting wrong expectation on the function used.

By design HMAC functions expects one parameter to be a secret key, and the other being a message which could be public (you can find more information here and there). This means that the arguments are not be freely interchangeable, the exact order depending on the language used.

A secret key is a key:

Which is composed of computer chosen random characters,
Whose minimum length is the length of the resulting hash,
Which is never known by the remote user, even a part of it,
Which cannot be controlled or influenced in any way by the remote user.

Depending on your actual need and implementation, all parameters you will provide to the HMAC function may not be usable as a secret key:

primary_key might be a service or domain name for which you will need to derive several keys, in which case it might be a public string accessible to the end-user,
keyn (key1, key2, etc.) may also be a predictable string corresponding for instance to the internal service for which the key need to be generated.

Applied to your question, we have then the following possibilities:

None of the parameters can be considered as a truly secure key but one of them is a password or equivalent: if your primary_key is a user provided password (ie. a potentially human generated random string), you can remain safe by using a password dedicated hash function. Such primary_key may be vulnerable to dictionary attacks & co., but this threat will be mitigated by the use of a proper hash function at the expense of the application performance (such hash functions are designed to be slow).
None of the parameters can be considered as a truly secure key and they do not even include a password: an example of such situation would be if primary_key reflects or is deduced from user's provided domain name and keyn contains the name of the service or server (or is deduced from such info) for which the final key will be generated. Then consider your system as flawed, end of story. Your system is wrong and not secure.
One of these parameters can be considered as a secure key: pay attention to pass this parameter through the proper argument where the secret key is expected by the HMAC function. Not doing so may impair the cryptographic strongness of the HMAC function. For instance, let's say that primary_key is a service or domain name, while keyn is a secure key, compared with your question you may need to revert your arguments: key1 = HMAC("secret_key_1", primary_key);, refer to your language documentation in case of doubt,
Both of these parameters can be considered as secure keys: Then you have the highest security you could expect from this scheme, the arguments can be passed in any order without increasing or decreasing the security (the resulting keys will be obviously different but with the same security properties).

As a side note, HMAC RFC also mentions the possibility to truncate the resulting hash to reduce the information available to an attacker who would try to deduce primary_key starting from a hash. The same RFC admits however that while some research "show some analytical advantages of truncating the output of hashed-based MAC functions", "the results in this area are not absolute". As far as your initial keys are secure, I have the personal feeling that you may have more to loose in such truncation due to shorter resulting keys. In all case, this RFC recommends to keep the leftmost part of the resulting hash and to keep at least half of it.


SSL/TLS certifcate secure on Chrome but not on Firefox

Yes, there is a difference. On Windows, Google Chrome uses a built-in Windows Certificate Store when identifying the trust. Mozilla uses its own trust certificate store. Apparently, your internal CA is installed on Windows, but not in Firefox browser. You have to install your private root CA certificate into Firefox browser.