What does C=il mean/stand for in OpenSSL and this error?

C in a DN is country code, so C=IL is Country=Israel.

Error 18 means that the cert was badly generated, or is not configured properly on your host, so it's hard to diagnose that error message without more context. It found a self-signed root certificate (ie "0 depth"), but was not happy about it for whatever reason.

My immediate guess is that you need to add this root cert to your OS trust store. The OpenSSL Verify will try and chain the cert you provide back to a cert in your trust store. If it can't, then you'll get an error message like the one above.

EDIT addressing comments:

The OP exported a cert from Firefox's trust store and is attempting to verify it using openssl. The root cert that it chains to is not in the OS's trust store, so openssl is reporting: A) error: cannot establish trust in the root, but B) the cert is otherwise cryptographically valid.


Benefit to using PBKDF2 on key generated by RNGCryptoServiceProvider?

"PBKDF2" begins by "PB" which means "Password-Based". This is for passwords. A password is not just a sequence of letters; it is a sequence of letters that a human can remember and type. A 256-bit key, generated as keys should be (with a cryptographically strong PRNG), is not a password, even if you encode it as letters.

Another way to say it is that the core of the functionality of PBKDF2 is to cope with the inherent weakness of passwords: since they can be managed by human brains, they are weak and can be brute forced. A proper cryptographic key (like the one you generate with RNGCryptoServiceProvider) does not have this weakness, and thus has no need for PBKDF2.

Now there is a tangential use: PBKDF2 is not only PB, it also is a KDF. It has a configurable output length. As such, if your source key is shorter than what you need, then a KDF, in particular PBKDF2, can be handy to obtain as much key material as you wish. For instance, you have a 256-bit key, but you need to encrypt and to have checked integrity, and for that you would like to have a 256-bit AES key and a 256-bit key for HMAC. To turn a 256-bit master key into 512 bits of key material, you need a KDF. However, PBKDF2, with its password-specific idiosyncrasies (input is letters, not bits; there is a need for a salt), is ill-suited in general for such jobs. SSL/TLS uses for such jobs a custom function (which has been quite thoroughly investigated, since SSL is a high-profile target for cryptographers) which it calls "the PRF".


NMAP NSE script stopping after 900 seconds (15 minutes)

The documentation for ssh-brute.nse mentions:
unpwdb.timelimit
https://nmap.org/nsedoc/lib/unpwdb.html#script-args

unpwdb.timelimit
The maximum amount of time that any iterator will run
before stopping. The value is in seconds by default and you can follow
it with ms, s, m, or h for milliseconds, seconds, minutes, or hours.
For example, unpwdb.timelimit=30m or unpwdb.timelimit=.5h for 30
minutes. The default depends on the timing template level (see the
module description). Use the value 0 to disable the time limit.


Encrypt symmetric key or message first PGP?

The step explained in the paper is correct. The confusion you probably are facing is with the key exchange step I guess.

Let me explain it further.

Let A be the sender and B, the recipient.

A generates the message - M
A generates a pseudorandom session key - K Key for symmetric encryption
A encrypts the message M with  session key K - E(K,M) Message encrypted with symmetric encryption
A encrypts the session key K with public key of B - E(KBPUB, K) K encrypted with public key of B so that B can retrieve K with it's private key.
A appends the results of step 3 and 4 and sends it to B -  E(K,M) || E(KBPUB, K)
B receives E(K,M) || E(KBPUB, K)
B retrieves K from E(KBPUB, K) -> K = E[KBPRIV, E(KBPUB, K)] Retrieving K by decrypting it with private key of B.
B uses K to retrieve M from E(K,M) -> M = D[K, E(K,M)] Decrypting the symmetrically encrypted message.

Your confusion is in the 3rd and 4th steps. Te order of 3rd and 4th steps doesn't matter as you see from the above.


How to effectivily block torrents on my network?

You have a number of ways to restrict torrents:

Blocking ports: this doesn't work, because p2p traffic can use pretty much any port (even ones below 1024)
Deep inspection: looking at traffic and blocking based on type can help you a lot, however encrypted traffic all looks alike
Destination filtering: this may also help a bit, but you'd have to maintain a large blacklist
Volume: if a user is downloading/uploading large amounts of traffic then investigate
Controlling the applications installed on the computers on your network through Group Policy or a real world policy. Disallow all p2p applications, and if anyone breaches the policy don't let them use the network/fire them/fine them/whatever


Does the version next to pending refer to kernel version for which the fix is released?

Yes- more precisely, the version next to "pending" refers to the version of the package within the lineage in which the fix is included.
There are lots of binary packagings of the upstream kernel sources for different hardware platforms and other use cases- "linux", "linux-mako", "linux-snapdragon", etc- and there are also many release lineages- Ubuntu 12.04 LTS/14.04/etc- of all those packages that are maintained concurrently.
So the upstream bug may need to be fixed in multiple packagings of the same sources across multiple lineages. Because of the complexity, a triage process is used to conduct the relevant classifications and track work. This page reports on the state of that triage process for this particular bug.
This can be traced as follows:

pick one of the packages- "linux"- and one of the lineages- "Ubuntu 12.04 LTS".
The table indicates that the state of the fix for that package in that lineage is "pending". The version of the package that will contain the fix within that lineage is "3.2.0-109.150".

to confirm, follow the lineage link for the package- https://launchpad.net/ubuntu/precise/+source/linux

scroll down to the "Releases in Ubuntu" section of the lineage-package page, and find the specific fix version, which has its own page: https://launchpad.net/ubuntu/+source/linux/3.2.0-109.150

on that page is a changelog. In that changelog includes a reference to the CVE (CVE-2016-5696), the particular fix that was made, and the person who made it

The CVE page is confusing because it is automatically published from a complex data model that tracks the interrelationships between upstream sources and their packagings within and across lineages. It follows a template that is optimized for authority, not necessarily for readability.
The classifications, like "DNE" or "pending" refer to the triage and release workflow that Ubuntu follows. States on that page are:

"DNE" means that the package does not exist within the lineage
"ignored" means that energy is not being expended for determining whether the problem exists in the particular package within the lineage, because support has ended for one reason or another. See for instance the linux-lts-quantal package, in the Ubuntu 12.04 LTS lineage. Support for that particular package (a backported hardware enablement package) in that lineage is beyond end-of-life.
"needs triage" means that the package within the lineage is still supported, but work is needed to determine if the reported problem actually exists within that package-lineage pair. See for instance the "linux-goldfish" package in Ubuntu 16.10.
"not affected" means that the underlying source code vulnerability exists in the particular package within the lineage, but triage determined that for some other reason the issue will not occur. See for instance "linux-mako" within Ubuntu 16.04 LTS.
"needed" of course means that triage has determined that the package within the lineage is affected, but work to apply the fix to the particular package within the lineage is still needed. See for instance the linux-armadaxp package within the 12.04 lineage.
"pending" means that the work needed to apply the fix to the particular package within the lineage has been done, a version has been cut, and a release is in the works.
"released" means that the fix for the package within the lineage has been released


Does theft of the webserver's private key allow retro-active decryption of previously logged transmission?

Retroactive decryption is possible for all connections that used RSA key exchange, but not for all connections that used DHE or ECDHE. Non-PFS key exchanges are not allowed for http2 and are deprecated in tls1.3, but are sadly widely deployed.

In September 2016, SSL Pulse [1] surveyed 139,141 sites and of those, 17,504 had no PFS cipher suites enabled, 43,422 had some PFS cipher suites enabled, 39,616 used PFS with modern browsers and 38,607 used PFS with most browsers.

1 - https://www.trustworthyinternet.org/ssl-pulse/


Can/do botnets brute force "high value" users of services like Gmail?

Gmail requires CAPTCHA solving when it detects suspicious behavior for an account, even if the requests originate from several IPs.

There is always a balance to be set between user experience and user security. If a celebrity uses Gmail, she'd rather enter a CAPTCHA each time than having her emails publicly disclosed. Moreover, even if not yet "default on", 2 Factor Authentication should be used for any sensitive accounts, because it greatly decreases the risk of the account being compromised.

In my opinion, delays of any kind should not be used for web application, because they only add to user frustration and also help in building DoS attacks.


Is the approach safe?

No - not if I understand your threat model.

Depends on your threat model. If you never ever want the server (or db or db-backup) operators to be able to decrypt the files, never ever give the server the file encryption key.

In your model the clearest threat is I can brute force guess the password of the registered user. Once I do that, I can decrypt the file encryption key, and the file itself.

update

Thinking about the password a bit more and more threats to this approach:

in general, a user derived password is not safe. One way to think about this is eventually the pw will be compromised. Maybe phishing, keylogger, finding it written under a keyboard, or brute forced. So say I get a copy of the database, now I simply wait for the pw over time (or actively try to hunt for it). Once I have it, I decrypt everything the user’s uploaded that’s in my copy.

We built this differently. (to prevent that threat)

We based our build off send.firefox.com.

When a file is uploaded, it is encrypted client side, and stored on the server. The encryption key is stored on the generated URL and not sent to the server.

The url is sent to the recipient, and the url can only be used once, and expires in 24 hours.

We added to this - after you upload a file, we return a system generated passphrase (two common 5th-grade-level english words).

To download the file, you need the secure link, and to know the passphrase.

The beauty is there isn't any user registration required.


How to manage passwords in a multi-tenant surrounding?

Authenticating an user in a multi-tenant application is not fundamentally different from authenticating in a single-tenant one. Before you know who that user is and which permissions or capabilities or roles he has, you don't know which subset of data should be available to him. Once authenticated, you can limit the data exposed to him, using whatever controls your application supports (e.g. filtering, permissions, encryption).

A multi-tenant system has the same needs, except that now the user belongs to an organization, and all the data in you DB is partitioned around that organization. You might want to have stronger protections inter-tenants than intra-tenant, but it's still a matter of discovering who the user is and what data he can access.

The article you linked suggests one approach, using encryption as part of its defence-in-depth:

  When an end user logs on, the application uses impersonation to access the database using the tenant's security context, which grants the application process access to the tenant's private key. The application (still impersonating the tenant, of course) can then use the tenant's private key to decrypt the tenant's symmetric key and use it to read and write data.

But notice that this assumes the user is already logged in (and thus is authenticated with the system); before that happens, there's no way the system can know which tenant he belongs to. Unless of course all users from the same tenant had some sort of shared credentials used first to authenticate the tenant, then use their individual credentials to authenticate themselves, but this opens another can of worms.

So my suggestion would be having a single database table for all users, where an username (or pair tenantname-username) and the associated credentials (password hash, public key, OTP key, etc) authenticates the user and then uses the information "who the user is" and "which tenant he belongs to" to unlock access to the rest of the data. And make sure nobody but the service provider has access to that table's contents.


Is it reasonable to provide admin access for a PCI vulnerability scan?

Is this a standard part of vulnerability scanning as far as PCI is concerned?

No, it's unusual, and having worked with 4-5 different auditors, I've never been asked for that.

It's much more common for the auditor to request certain evidence - either the auditor 'rides shotgun' while you gather the evidence, or they trust you to gather the evidence - from a statistically significant sample of hosts.

First of all, there's the responsibility issue.  If you give them admin credentials, and then they do anything wrong while poking around with your servers, and cause downtime or damage, that's a big problem.  A good auditor will be even more interested in avoiding that than you are!

But secondly, and more importantly, let's see what SAQ A-EP is asking them to do:

For patching, the expected testing is to "Review policies and procedures".  For critical patches it adds "Examine system components" and "Compare list of security patches installed to recent vendor patch lists".  In my experience these have always been satisfied by providing the installed patch list to the auditor.  The more stringent auditors I've dealt with required me to gather that evidence in front of them to prove its provenance.

I have had auditors who asked me to run an information gathering script on a sample of hosts - which we did, after examining the script, and running it on non-production hosts first to make sure it didn't cause problems.  But, again, they had no interest in running it themselves, and didn't ask for any access to the servers.


It appears that Microsoft.com does indeed run using standard HTTP rather than HTTPS (TLS/SSL secured). However, their website can be accessed using HTTPS if you enter: https://www.microsoft.com. This causes the main page to display over a secured connection.

That said, their security essentials page (http://windows.microsoft.com/en-us/windows/security-essentials-download) is not accessible using HTTPS and results in a 404 Not Found error (if your browser even lets you open it).

I do not know why Microsoft would use standard HTTP instead of secure HTTPS, but it appears that they do. It seems like a poor set-up on their part, but I do not believe this means either you or they are compromised.


Yes, there are ways to bypass this security measure. As pointed out in a comment:

var iframe = document.createElement('iframe');
iframe.srcdoc = '';
document.body.appendChild(iframe);
iframe.contentWindow.alert.call(window, 'hello');

The problem is that successfully blacklisting individual functions in such a complex language is an exercise in futility. Trying to prevent real-world attacks by blacklisting is downright quixotic.


I've noticed issues with ReCaptcha not being a good stop for spam registrations on some of my personal sites as well.  In many cases, I try to use some bit of information that would be unavailable to the spammer but would be available to community members.  Since most of the sites I've put up myself are gaming related, it's typically been some question about the game that is phrased in a way that a simple Google search couldn't find.  (For example, leaving out the name of the game and asking an otherwise generic question or even asking what game it is for.)

I realize that this might not work in all cases, but there also isn't really a good one size fits all solution for fighting spam registrations.


On an embedded system with no external input, can haveged provide entropy?

This will depend on the exact system.

Haveged is highly dependent on the rdtsc instruction. For the vast majority of embedded systems in production today this is going to be extremely difficult (to the point of effective impossibility) to estimate.

With a basic enough stripped out OS (or no OS) on a single core CPU where the execution of every line of code on the device is both predictable and independent of external state then it may be closer to realistically possible.

Although on a device with absolutely no external input (other than power up/down) i'm struggling to see the use case for an CSRNG?


Which version of nmap are you using?

Run

nmap --version

to find out.

If the version in your repository is outdated you can grab the sources and compile them on your own:

$ tar zxvf nmap_6.47.tgz
$ cd nmap_6.47
$ make
# make install

You can also increase the verbosity level by setting the -v [1..6] flag in order to get a better view of what nmap is doing. For example:

nmap -sT -p 22000-23000 -v 6 x.x.x.x


I have to admit, this is pretty bizarre. This is what I found.
beinternetawesome FAQ
It sounds like you have Parental Controls set.
Parental Controls
How SafeSearch works
When SafeSearch is on, it helps filter out explicit content in Google's search results for all your queries across images, videos, and websites. While SafeSearch isn’t 100% accurate, it’s designed to help block explicit results, like pornography, from your Google search results. Learn more about how to stay safe online at safety.google.
When SafeSearch is off, we'll provide the most relevant results for your search which may include explicit content when you search for it.

SafeSearch can be turned on for:
Personal accounts or browsers
Children’s supervised devices and accounts using the Family Link app
Workplace or school devices and networks

Turn SafeSearch on or off
Go to Search Settings.
Under "SafeSearch filters," check or uncheck the box next to "Turn on SafeSearch."
At the bottom of the page, select Save.

Change your child’s SafeSearch settings in the Family Link app
The SafeSearch setting is on by default for signed-in users under 13
(or applicable age in your country), managed with Family Link. Only
parents can turn the SafeSearch setting off. Learn more about Search &
your child’s Google Account with the Family Link app.


Is Bitlocker secure against theft even if the TPM is hacked (assuming the machine is hibernating)?

First of all, to the comment by André, from what I understand, full disk encryptions are exactly for the case of an attacker gaining full physical access to the hardware, like in the case of a (notebook) theft.

As for the rest: a hybernating computer should be vulnerable.

This is after some research the best article on the topic: https://securingtomorrow.mcafee.com/mcafee-labs/release-windows-10-questions-bitlocker-arise/ .

If the system is hibernating, it can be awoken again, and then any of the described attacks like "cold boot" should work.

Also, if the TPM gets hacked (though I am not sure if that is very realistic, or if there are known weaknesses in some TPMs) that would also be a bad thing.

Still, I think those attacks are no thread for everyday security, since their effort is fairly large, meaning that in most cases, no attackers would make those efforts unless there are reasonably high (information) rewards.


Aren't password managers still incredibly risky?

Password managers introduce different risks, they do not eliminate all risks. It is debatable if a password manager is generally more inherently risky than dozens of memorized passwords. Does the risk of a central password outweigh the risks of having dozens of poorly implemented passwords? It might all depend on the implementation.

Password managers automate the process of creating and 'remembering' unique passwords with maximum complexity, and can automate the renewing of passwords on a regular basis. Not only that, but they can highlight the fact that you are not on the login page for the website you think you are on. All these benefits are difficult to pass up, but you need to ensure that your password manager is properly secured.

You are correct in saying that by putting all your eggs in one basket, you run the risk of wide-spread access. But there are ways to mitigate that risk. For instance, some password managers require 2-factor authentication to access passwords.

"Risky" is always in the eye of the beholder. What is acceptable to one would not be to another. Each person/organization needs to make that determination for themselves.


I've just purchased a VPS to use for developing and managing my clients hosting packages. What necessary steps do I have to take?

If you're running cPanel and have root (which it reads as if you do), install this free script, called CSF:  http://www.configserver.com/cp/csf.html

There are several tools to check your servers security and in most cases, this software will tell you where to go, to "harden" your cPanel install.  It's not a end-all-be-all to your cPanel security but it most definitely goes a long way!  Good luck.

Oh... one more thing.  If you don't use CSF (or anything else) the first thing I'd do is change your SSH port and disable root's access to SSH (make sure you have a new user created to join the sudo'ers and wheel groups).  That's basic Linux stuff right there.  You can lock SSH down even further by disabling password auth. into SSH, only allowing keys to gain access to SSH.  Just my 2 cents.  :)


Do client certificates need to be trusted by the client?

No, the client certificate is only validated by the server and the server certificate only by the client. Thus any kind of trust regarding the client certificate or its signing CA is only needed at the server.

... It's a single certificate, with no intermediate
... the pem files do not contain the public CA certs that signed the client certificate

I would suggest that the first statement is wrong, i.e. that the certificate you got was actually signed by an intermediate CA and you did not include the necessary chain certificates. The root certificates itself should not be send because these have to reside as trusted at the side which is doing the validation, i.e. the server in case of client certificates.
I would suggest that you'll find out which CA they have as pre-trusted at the server side and compare this with the issuer of your certificate. If they don't match then chain certificates are missing. If they match than it might be a problem with the setup on the server side, i.e. that they don't have the necessary CA configured as trusted by the server for client authentication.


If the bitcoin network was cracking bcrypt, what cost factor would you use?

Short answer: if you compare the speeds on x86, the maximum cost in PHP of 31 (2^31 iterations) would be secure enough for a strong (random 8 char) password. Not that it would be usable, one hash would take ~ 200 hours to generate on a desktop.
Long answer:
(large margin of error due to lack of accurate hash performance data, no specifics on password strength and lazy approximation.)
The cost of raw brute-force can vary with a factor of billions between a 6 letter password and a length 10 password with numbers and special chars. (26^6 = 3.0E+8 for lowercase, 94^10 = 5.3e+19 for mixalpha-num-all) Hashing speeds can vary with implementation.
So if the user picks one of the 1000 most commonly used passwords, it's as good as a 3 digit pin number, making the question practically irrelevant.
To this end, the answer is "as much as you can, we can't save everyone from themselves"
But let's make a back-of-the-napkin calculation to get an idea. Let's assume the database sets a strong minimum requirement of "as good as 8 random chars"
With a character set of all lower- and uppercase ASCII chars, all digits and special characters that would come to 6161234432565770 combinations
Now let's get an idea of the hashes' performance. The only side-by side comparison i could find that came close was this:
https://pthree.org/2014/12/26/sha512crypt-versus-bcrypt/
It states that the default work factor of 10 is about equal to 80.000 rounds of SHA512crypt
.
Now SHA 512 only costs about 120% of the time 256 takes
So that makes bcrypt with cost(10) approximately equal to 100.000 rounds of SHA256.
BCrypt's cost is defined like this:

The two digit cost parameter is the base-2 logarithm of the iteration
count for the underlying Blowfish-based hashing algorithm  and must be
in range 04-31, values outside this range will cause crypt() to fail

cost(10) = 2^10 = 1024 iterations. so bitcoin's algorithm SHA256 is about 100x faster per iteration.
Assuming BitCoins network can do 2.14E+18 SHA256/second, that would come down to 2.14E+16 iterations of BCrypt/second.
The keyspace of the length-8 random password in charset mixalpha-numeric-all is about 6.16E+16

So at 1 iteration, it could bruteforce such a password in < 3s. the minimum for PHP is a cost of 4, so 16 iterations.
At the default cost of 10, it would take nearly an hour.
At the maximum cost of 31 it would increase another 2^21 = 2097152 hours, which is a little under 240 years.

This is quite an infeasible brute-force, and could for the moment be considered secure.
The maximum amount of 'cost' in BCrypt would suffice against the entire current BitCoin network if the password is moderately strong.
However, the comparison of BCrypt vs SHA512 mentions cost(20) already takes > 3 minutes on a workstation, making such large costs impractical for now.
extrapolating 2^12*3.12/60 =~ 213 hours


How to create an anti-flood mechanism without leaving VPN's out?

Have you ever considered protecting your site behind a service like CloudFlare? They act as a reverse proxy for your site and will scrub bad traffic at their edge nodes based on some very advanced heuristics. Even their free accounts offer a great level of protection because it's in their interest to drop malicious traffic so it doesn't pass through their network. Not only that but they have many advanced features like auto-minification of HTML/JS/CSS, CDN, analytics and more. I wrote a quick blog covering them after I started using them here.


How to decide whether an eshop is safe or compromised

On eu-store.wacom.com, some images from their Amazon CDN are requested over http instead of https. This can be solved by installing HTTPS Everywhere and turning on "Encrypt All Sites Eligible":

The gray padlock means all resources are served securely. So the webstore is most likely not compromised. They are still using an outdated cipher based on CBC and SHA1, so a nation-state power might still be able to intercept or even MITM the connection.


Excessive logons from domain controllers

There are a lot of things it could be.  For example, someone may have typed their username wrong in their WiFi settings on their cell phone, causing their phone to try to authenticate over and over again erroneously.  There are too many other possibilities without knowing every dynamic of your environment.


UUIDs do not generally guarantee unpredictability or any security properties.  As RFC 4122 says (section 6):

  Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example.  A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator.  Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee.  The ITU standard explicitly says that the use of cryptographic random number is recommended, which clearly implies it's not a requirement (p. 10):

  The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

And it turns out that some UUID implementations are not secure.  For example, at least some versions of Google's V8 Javascript engine use a non-cryptographic PRNG for random UUID generation.  The link describes how to attack such UUIDs—with a couple of lines of code, an attacker who sees one such UUID can reconstruct the PRNG's state when it output that UUID, which allows them to predict all subsequent UUIDs.

So I would not use UUIDs as cryptographic secrets—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing.  The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP.  For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.


I use Django a good deal and I did need to migrate 1.6 to 1.7 (although it was some 2-3 years ago).  During that time the most important difference in terms of security was django.contrib.messages, which was not aware of HTTPS only cookies in Django 1.6.  In other words, if you had something like:

MESSAGE_STORAGE = 'django.contrib.messages.storage.cookie.CookieStorage'

Instead of session storage, and the website was configured to send cookies only for HTTPS connections, then those cookies would be sent over plain HTTP anyway.

Extra note:

The Django release process states that once a version 2 numbers higher is released the security patches for a version cease, unless the given version is a LTS (long time support version).  Therefore Django 1.7 is not receiving any security updates anymore since Django 1.9 (and even Django 1.10) has been released.

You should aim to upgrade to Django 1.8 since it is an LTS version of Django.  Which will receive security updates 'till April 2018.


DNS poisoning and MiTM are not necessarily the same thing. You can poison DNS without then fowarding the traffic on to the real source. E-mail is a stateless transaction, you would just need to receive the transmission, in most cases there is no immediate reply. Now, of course if you forward the message to the real recipient they will respond and you can then capture the next reply back to the poisoned target.

In a basic setup this should work. Obviously this won't defeat messages encrypted with PGP or equivalent since those are at a higher layer. I need to check back after some research, but I think that there are some peer-to-peer trust protocols or similar which would detect that a rogue was in place, but those are not basic/standard.

Edit:
Actually this could work both on the SMTP and POP/IMAP side. Obviously doesn't work if IP addresses are used without name resolution.


Vulnerability management and assessment tracking solutions

I am using Database (Based on mysql and PHP). It is more valuable and easy to maintain. I don't like to use excel Spreadsheet. Therefore i have database and updates are done by manually.

All attributes which you have mentioned are included in  my database and additionally i have been added how remediation was done or why it was not done.

Best Practices of Vulnerability Recordings are below.

Record all related Details about Vulnerability and remediate action.
do vulnerability assessment at least once a quarter, and compare with
previous result.
According to second line, your records should be able to compare with previous result. therefore DB is more useful than excel sheet.
Do VA with Different methods and all details are needs to be recorded separately.
Record analysis are very important, Again database more helpful than excel sheet.
when you conduct Audit, result needs to be accessible without any delay and again database will be provided more flexible accessibility than excel sheet.
Main thing, Vulnerability Scan results are very sensitive and confidential data. It needs to be stored in high secure environment. Database will be provided high secure environment than excel sheet.


Why should I go to SHA512withRSA signature for my Android apps?

One should stop using MD5 and SHA-1 for digital signatures.
MD5's colliding messages can be found in less than a minute and there are online libraries to produce; corkami and hashclash. Also, SHA-1 is already shattered, that finding two colliding documents are no longer infeasible, and the attack is faster than the generic collision attack O(280). Even before the attack, it was removed by NIST
s recommendation for the signatures.
Secure signature schemes require the hash of the message and this is first introduced by Rabin; he introduced the hash ( it was then called compression) to prove the security of their signature scheme that we call now the Rabin Signature Scheme. Some so-called it, hash-then-sign paradigm, however, it is better not. Since the hashing is part of it.
What is the danger of collisions in the digital signatures is this;

one can create two colliding messages before the sign, and represent you the document that you wanted, then used the other one in the courts. Some other good examples of hash collision attacks can be seen in this question

You should use at least SHA256 or SHA512. Apart from the generic collision resistance differences ( SHA256 has 128-bit and SHA512 has 256-bit collision resistance) and output size differences 256 to 512, they have a speed difference due to the fact that SHA256 is designed for 32-bit CPUs and SHA512 is designed for 64-bit CPUs. This can have an impact of around 20% speed difference (tested on 64-bit);
openssl  speed -evp sha512 sha256
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
sha512           21611.03k    70718.37k   124630.02k   221499.05k   246393.51k   251833.00k
sha256           29623.38k    65545.39k   190875.14k   159992.49k   170860.54k   210594.47k

There is another faster one, that is Blake2b ( another SHA3 finalist that Keccak won), also it has parallel version Blake3, and SHA3 also has parallelhash that can benefit from multiple cores. One can use them if available.
You can use both SHA256withRSA and SHA512withRSA, the difference is the collision resistance and the target CPU architecture.
512-bit is designed against the quantum attacks that Brassard et. al exhibited. It has cube-root attack that reduced the collision resistance of any 256-bit hash function to 85-bit security and 512 hash function to ~170-bit. Of course, the other costs are not considered (qbits and preparations). If you are not considering countermeasures against the Quantum attack, a secure hash function with an output 256-bit or more fine for you; choose SHA512 for 64 and SHA256 for 32-bit CPU, or simply choose SHA512 once for all.

note: Although the Chosen-Prefix collision attack on MD5 can accept different sized files the resulting sizes of the files must be the same due to the length padding of the MD constructions.


I would be extremely reluctant to make that assumption.  Lacking strong evidence that running the vulnerable version of Exim in this way is safe, I think you should assume it is unsafe.  In particular, I have not seen any analysis of the vulnerability to support your suggested interpretation.

I have seen a statement that the vulnerability "may permit anyone who can send you email to cause code to be executed as the Exim run-time user".  If this characterization is accurate, then it sounds like merely running the server on port 465 will not be enough to protect you.  Even if the attacker doesn't have the ability to authenticate to Exim, and even if we assume that there is no way to exploit the format string vulnerability before authentication (something that I'm not aware of any evidence for), there are still many ways that an attacker could send you email.  (There are also many ways that an attacker may be able to influence one of your legitimate users into unknowingly sending an email with contents of the attacker's choosing.)  Thus, it sounds like even if you took your steps, it may still be possible to exploit the vulnerability.

Bottom line: I suggest that you stop using the vulnerable version of Exim and just patch the sucker already.

P.S. For the future, if you want better answers: I suggest you link to the vulnerability report for the particular vulnerability you are curious about in your question.


Notifying users of a possible security breach

From a pure information security perspective telling users there was a breach makes the threat more immediate and seem more applicable to them, however there are other considerations, for example:

business: If an internal email gets leaked does the company want a security breach to be public knowledge?
human resources: if someone was able to use details in the internal email to determine who opened the attachment that person may be subject to abuse, or it may breach their legal or contractual rights

Really it's a management decision as to how these things should be dealt with, ideally in the form of a process that implements a policy that is derived from a strategy. If you don't have any of that then kick it up the chain of command and do what they say.


Would logging into Chase bank website be an example of Asymmetric cryptography?

Your question reveals the lack of some basic conceptual understanding in how cryptography and encryption works.

  Is using digital signatures an examples of using asymmetric
  cryptography?

Yes it is.

Asymmetric encryption means 2 keys are used to encrypt and to decrypt a message. A example of a widely used asymmetric cryptographic algorithm used for encryption of email is RSA.

Digital signatures use asymmetric cryptography to generate a cryptographic hash of the outgoing message to be sent using the sender's private key. The sender's private key is known only to the sender of the email. The receiver of the email uses the cryptographic hash to decrypt the message received using the public key of the sender. If the integrity of the message has been compromised, the resulting message will be different and the signature invalid / corrupted.

The public key of the sender is tied to the sender's identity through the assistance of a third party - A certificate authority - CA. This CA issues a certificate that uniquely identifies the public key as belonging to the sender of the message. The addition of the CA is to ensure that a hacker cannot impersonate the sender by substituting a fraudulent public key in place of the true, correct public key of the sender. An assumption here is that the certificate has not been revoked and listed on the CRL kept and updated by the CA.

The purpose of digital signatures is to guarantee integrity, non - repudiation of the message, and of authenticity of the sender.


S/MIME doesn't protect against a stolen password, right?

As far as I know, S/MIME doesn't use passwords, but private and public key pairs. So, the private and secret thing is user's private key. If private key is stolen, it can reveal the content.

If you want to prevent stealing privkeys you (or each user) should store them in safe place. If your privkey is stolen, you should asap revoke the certificate (with pubkey) and get new key pair.

S/MIME actually encrypts the message content with random symmetric key, which is encrypted by recipient's pubkey. Recipient then using his privkey decrypts the symmetric key and uses it for message decryption.


You didn't actually write a question in your question, but, assuming it's x86, then the argument for x must be put on the stack prior to calling into vulnFunc.  On x86-64, it's entirely possible this won't be vulnerable, because x is passed in a register, so it's unlikely to be anywhere on the stack, unless it is placed there by a side effect of compilation.


why is supporting digest authentication necessary instead of other more secure ways like applying non-reversible transformation to password?

Digest authentication is a specific algorithm to do authentication, not a storage method for passwords. So there is no "digest authentication ... instead of ... non-reversible transformation". Comparing one with the other is like comparing streets with cars.
Digest authentication requires though to store passwords (or something equivalent which can also be used for authentication) in a reversible way. So the real question is, why digest authentication is still used, even though it is known to be vulnerable against leaks of the stored passwords.
And the answer for this is, that security decisions are usually a trade-off, in case of digest authentication between securing passwords on the server vs. securing passwords in transit. Digest authentication can protect password on transit even if the connection is not encrypted, i.e. no TLS or similar used. Plainly sending username and password is instead not protected in this case. And there are still protocols which heavily rely on unencrypted connections, like SIP (voice over IP). In fact digest authentication is the standard authentication method defined for SIP.


Adding "Email or Username" in login page, is it safe?

The email and username are normally both considered to be public pieces of information so it shouldn't make much of a difference. Not having those pieces of information publicly available might slow down a hacker for the length of a Google search.

If you're going to make it public, maybe just add an extra digit onto the minimum password length to compensate.


What is the role of ARP poisoning when doing a DHCP spoofing attack

I just happen to be writing a series of articles covering such network attacks from a practical point-of-view. Here is the article on DHCP, ARP will follow.

DHCP and ARP are indeed two different attacks allowing the attacker to achieve a MITM within a subnet.

  DHCP Spoofing is done by a rogue DHCP server on the network which
  replies to DHCP requests from hosts(Attacker can run a DHCP starvation
  attack on the legitimate DHCP server to stop it from handing away IP
  addresses). The rogue server can spoof the gateway & DNS servers
  therefor all DNS & Traffic going away from local subnet will start to
  flow to the attacker. The attacker then forward the received traffic
  accordingly so the hosts won’t notice any disruption in connectivity
  and effectively pulling off a MITM attack.

This is right.

  In ARP Poisoning, attacker send spoofed arp messages to the network
  and arp cache of the switch will have wrong information so the switch
  starts to send traffic to the attacker (which should originally go to
  another host or default gateway)

The classical ARP attack doesn't target the switches but end-devices.

Each devices given an IP, need to obtain the corresponding MAC address to establish a communication. This is what the ARP is for.

The attack consists in forcing a device into resolving an IP as the attacker's MAC address instead of the legitimate one.

Nevertheless, there is also a less common attack targeting the switch, making it believe that a certain MAC address can be reached through the attacker's port instead of the legitimate one.
This attack is less convenient and reserved for situations where the previous one doesn't work (MAC address hardcoded in devices configuration for instance).

  DHCPDISCOVER, DHCPOFFER, DHCPREQUEST & DHCPACK are broadcast messages

DHCPDISCOVER and DHCPREQUEST are indeed broadcasted, the two other usually aren't.

  so typically all hosts in the local subnet will receive all this
  messages anyway. Even if the attacker has already done some ARP
  poisoning on the local subnet it won’t affect the process of DHCP.

It depends the degree of chaos the attacker has already spread in the network ;) , but fundamentally you're right: ARP is not related to DHCP here.

  ARP is used for resolving Internet layer addresses into link layer
  addresses.Since ahost does not have an IP address until DHCP process
  is completed ARP attacks seems useless on DHCP

I think of two cases where ARP-based attacks may be a good complement to DHCP-based attacks:

DHCP client messages are usually only broadcasted during the initial network configuration, when a network device is brought up (or when the legitimate DHCP server doesn't reply... DOS?). When a device needs to renew a DHCP lease, the DHCP REQUEST message usually isn't broadcasted anymore but is only a unicast message sent to the DHCP server which initially offered the lease.

DHCP MITM attacks are therefore usually only possible during the boot process of a device or when a running device is joining to the network.

Using ARP would allow to impersonate the DHCP server and intercept the client's DHCP REQUEST message. This may be for instance a way to push a new default router IP to a device where the MAC address of the legitimate router has been hardcoded, but its IP hasn't.
More fun: the case of DHCP DOS attacks. Check the DHCPig tool, it is a DOS tool implementing a DHCP starvation attack: the attacker leases all available IP addresses from the DHCP server so that no new address will be available for the other devices.

The core of this attack is basic and only rely on DHCP messages, but DHCPig adds a few features I like, and which involve ARP messages:

Using an ARP scan, DHCPig detects the other currently running devices and their IP and then sends a DHCP RELEASE message to the DHCP server, therefore marking their IP as free so they can now be stolen by the attacker.
Once the DHCP server has been DOSed-out, DHCPig can broadcast ARP messages which will simulate an IP conflict for each IP address composing the subnet. For Unix-like systems, this won't do much, but when Windows systems detect such conflict they immediately drop their current IP address and request a new one to the DHCP server... which is unable to fulfill the request, leaving the Windows client unconfigured. In other words, the ARP packets allowed to kick the Windows devices out of the network.


Changing the password regularly won't stop some of your problems (ex.: downloading porn or illegal stuff), as the users will still be anonymous and/or unidentified and/or non-customers.

To prevent that, you could change the way the login at your Wifi is made.

A common technique is to have a public Wifi that redirects to a login page. In that page, your customers will provide some information (ID? Name? Facebook login? A specific code delivered together with their order?). Once that information is provided, they'll be able to access the internet.

And yes, you can setup a proxy / firewall rule blocking some sites, some downloads, etc.

For example: http://www.dd-wrt.com/wiki/index.php/Chillispot


SQL injection with single statement query

Injecting a stack-query statement is only possible if the target application is using the MySQL Multi-Query interface.  The vast majority of SQL injection does not permit query stacking.  Query stacking is useful,  but you can access the database and even pop a shell without it. SQLMap can perform these attacks.

Query stacking is used more commonly in documentation about sql injection than in the real  world.  This is probably because it is easiest to explain sql injection using a query stacking demonstration.


Why should I sign git commits/tags? Should I sign both commits and tags?

Why is it useful?

Generally it is all about thread models.
And there are several examples in the past, where it would have helped. E.g. gitea introduced it after their bot account has been compromised.

It is useful to prevent modification of your source code on your git hosting service/server (GitHub, GitLab, Gogs/Gitea etc.) and at the connections to them.

What to sign?

Now for users of your software it may be useful to e.g. download signed release tags and verify them, so they can be sure you created the source code and stuff like that.
Keep in mind though that signing release tags helps nothing if you then distribute your binaries unsigned. In most cases users prefer the ready binaries and thus would not be able to verify their authenticity.

It may also make sense to sign git commits if users may regularly use the master branch directly for downloading/using the software. They may e.g. be more common when it's just a PHP project you can clone and it works out of the box than when you have to compile it, where many users may rather use compiled binaries.

However signed git commits may also make sense for developers, as you they can verify nothing malicious got introduced in a git commit (at least not without a committer/contributor doing that deliberately or signing off something accidentally). As such, if there is something wrong with a commit you can be sure it's the one who committed it that has introduced that. (as you can otherwise just set your git username and mail arbitrarily)
However, this is really only useful if all committers to the main branch do sign their commits and thus may be cumbersome.

Attention: Remember when signing git commits you have to do it for each commit. Some workflows accept that you create a feature branch and then sign only the merge commit, but this has to fit your workflow.
In any case this also means that you often have to use your private key and have it (unlocked) in your development environment. This may not be ideal from a security perspective.
In contrast to that when you make a release with a signed git tag, you likely do that not so often, so you can use a separate device/VM/sandbox/user/…, where you do not have so much untrusted development code running, but just clone/pull the repo (with git pull --verify-signatures obviously if you've signed your commits to make sure nothing has been mangled with it) or transfer the whole git repo somehow else (in an "integrity-preserving" way) where you can sign the tag with a signing key kept in a more secure place.
This way your signing key is at least not at risk of getting compromised if your development machine should get compromised.

Conclusion

Signing git tags is (IMHO) more useful than signing commits, as the first is what users of your software will mainly use, while the latter is mostly good for developers and has it's risks (as discussed above). Thus it makes also totally sense to use different git signing keys, one for your releases that is kept in a securer place/way and one you use to sign all your commits. It makes sense to use a personal git signing key for signing commits and, especially in bigger projects, have the release/tag signing key separated and shared among the project lead/some trusted people, who are authorized to make releases. This way users also don't have to have 50 keys of your developers in their key store, but just the one of your project. Especially as users likely won't recognize all your developers and may not be able to verify whether this if a real developer of your's or an attacker.

So if you can  sign git tags. It already helps very much for distributing your software securely to your users. Signing git commits may also be useful, but is likely not as important as signing git tags.


How does police or somebody find out that an Arp Spoofing attack was done?

Checking logs.  The great secret of dissecting what happened after an attack.  Pouring over logs to find the malicious activity and see what it is. If there are no logs, you can't tell.

Where to look for the logs is also half the battle because depending on the exact nature of the attack, you could need logs from the client, a server or a router or some combination of the 3.  It really depends on how the attack was performed.


Does knowledge of data structure compromise AES encryption?

First, AES is not something that you want to use itself.  AES is a pseudorandom permutation family, which is roughly academic cryptography jargon for ‘here be dragons—do not enter unless you are a wizard who can harness them’.

You want to use an authenticated cipher like AES-GCM or NaCl crypto_secretbox_xsalsa20poly1305, in which the dragons—along with other useful things—have already been harnessed into a useful security contract: if you pick a key uniformly at random and assign to each message a unique message number, for up to a gigabyte of data per message and about a terabyte of data total under a single key, then AES-GCM prevents an adversary who can intercept messages in transit from (a) learning what's in them in any more detail than their length, and (b) forging them.

(NaCl crypto_secretbox_xsalsa20poly1305 has a slightly better security contract—it's safer for much larger volumes of data, you can safely pick the message numbers uniformly at random, and it's designed to invite resistance to side channel attacks in software implementations, unlike AES-GCM.)

This security contract holds even if the adversary can choose the patterns of data in the message.  The modern standard for secrecy of a cipher (IND-CPA, or indistinguishability under chosen-plaintext attack, which authenticated encryption implies) requires that the adversary be unable to find any pair of messages whose ciphertexts they can tell apart with more than negligible probability, even if given arbitrarily many other plaintext/ciphertext pairs of their choice.


Ensuring all network services on a device use strong TLS cipher suites

What options do I have for preventing network services from allowing weak TLS ciphers?

Changing the application or the applications configuration is one option, provided that the version of OpenSSL on the device actually supports the stronger ciphers you want.

Changing OpenSSL and restricting the available ciphers is another one, but make sure that all applications on the device actually link against this modified OpenSSL. And it is not trivial: you cannot simply forbid for example MD5 as long as you want to allow TLS 1.0 or TLS 1.1 since it is actually used there even if not needed for ciphers. So you might try to remove support for specific ciphers, but this might actually break unmodified applications on your device.

You might also need to use a newer version of OpenSSL to support the configuration you want, in which case you not only need to make sure that the applications are linked against the new version but you should also recompile the applications since the API might have changed. And, some API changes have actually introduced behavior changes, which means that you should properly test if the applications still work as expected, even in edge cases.

Changing some global OpenSSL config will not help since this does not specify which ciphers are supported by the application.

Another option in some cases is to have some secure reverse proxy on the device which only allows safe configuration and which "shadows" the weak configuration from the older application. But if this works depends on the specific use case.


How to perform penetration testing of Blackberry mobile applications?

Regardless of the platform, a basic mobile penetration test should cover the OWASP Top 10 for mobile.


How do I setup honeypot server on Windows 7?

We cannot provide a complete step-by-step tutorial. You will have to figure some things out on your own. If you cannot, then running a honeypot is simply too dangerous because you ARE exposing yourself to a hacker and you need to know what you are doing.

1. Set up a protected environment for the honeypot

This is best done with a second cheap computer/laptop, but this can also be done with a virtual environment. I use VirtualBox: it is free and works very well. Once you get this going, then you have a choice in operating system. Linux really is the best choice here for the number of excellent and free honeypots available as well as the few resources it needs to run, which makes it perfect for cheap hardware or a virtual machine.

2. Choose a honeypot

You need to know what you want to do with your honeypot in order to make a choice here. 99% of them are free and on Linux.

3. Configure your router and firewalls (hardware and software)

This is where you can really hurt yourself if you do not know what you are doing. The honeypot you choose will determine what ports you need to open up and direct to your honeypot. You also need to make sure that traffic from your honeypot does not get directed to anywhere but the outside. No step-by-step tutorials here. You have to know. Get someone who does know to verify your configuration. Even I do that with my firewalls, and I'm a professional.


Security Benefits in Replacing Windows Desktop Programs with New Windows Store Apps for Higher-Risk Uses?

The main purpose of the store apps is to enable users to use the same set of apps wherever they go, by using their Microsoft account as the login credentials. So, as far as the password is secure and that the user account is properly signed out/locked when the PC is not in use, the user information remains secure. Further, it lets the app publisher to verify the legitimacy of the license of the software being used. So there is no possibility of cracks/hacks, making the application secure from the backdoors created by cracks/hacks.


Looking for information about the job from security consultants

REF: your question "Do certifications mean anything for an 'untested' applicant (someone directly out of school)?"

There is one "certification" that is worth big dollars in the security field; namely if you are a US citizen who can pass a security clearance. There is a definite premium for this among government contractors and with the federal government itself.


Credit Card details shown in full after payment on online store

It is not PCI compliant (emphasis added):

  Never store the personal identification number (PIN) or PIN Block. Be sure to mask PAN whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed. This requirement does not apply to those authorized with a specific need to see the full PAN, nor does it supersede stricter requirements in place for displays of cardholder data such as
  on a point-of-sale receipt.

Two threats come to mind:

Shoulder Surfing
Browser cache


Is it possible to send a cURL request with SSL without the private key?

This should be a comment, but its a bit long...

You seem to be missing a basic understanding of how ssl works. It is relatively simple to configure your own certificate authority and use that to produce server and client certificates/private keys, then you just need to swap in the appropriate files when you go into production.

Its straightforward but perhaps beyond the scope of a description here.

You've not said what the trust model is (specific client certs? Client certs signed by a specific CA? Specific common names signed by a range of CAs?). It's likely that you may have to tweak the openssl config.

Will you be running more conventional ssl off the same server? That adds a lot of complications and you might be better considering a secod installation of ssl to handle one of the 2 types of traffic (e.g. using stud).

The encryption you are using is considered insecure.

You can convert the format of the files using openssl from the comand line.


Dropbear SSH server use-after-free vulnerability

The latest Open-WRT version is 2 years old now. If you have not upgraded individual services, then you will need to perform this upgrade.

From Dropbear:
"Security update 2012.55 — releases from 0.52 to 2011.54 are potentially vulnerable to code execution as root by an authenticated user if a command="..." option is used in authorized_keys. Release 2012.55 fixes the problem."

Also, consider switching to another router OS replacement that is under more active development, like DD-WRT.


Can you start a shell with a service account in Windows?

Yes you can start a shell with a service account . Can they login all depends on what permissions and checkboxes the admin selected when he created the account so yes again it could've be possible  . In many cases I've seen service accounts poorly setup and granted extremely high amount of privileges such as Remote Desktop or local admin or domain admin thus they are highly coveted by attackers so the attacker can laterally move across your network . So protect services accounts by limiting their access and giving them crazy long secure passwords.


No, you can not decrypt it unless you know the private key of the server. If it wasn't so, HTTPS would be sort of pointless.

There are two things you can do, though:

You can see what domain the user has visited - these are not encrypted.
If a key exchange without perfect forward secuirty is used (such as RSA, but not Diffie-Hellman) you can store the data so it can be decrypted if you in the future should for some reason find yourself in possession of the servers private key.


Sending password from client app to server with Java

Use TLS for the connection to the server.

The purpose of securely hashing a password is to make it more difficult to attack if the database is ever stolen. It is not designed to prevent sniffing the plaintext password. In order to securely communicate with the server over a hostile medium, you should be using TLS. This will prevent interception on the wire, while the server-side PBKDF2 will prevent the password from being trivially recovered from the contents of a stolen database.

You might be tempted to additionally hash it client-side. Unfortunately, that would not prevent an attacker from recording the hash being sent from the client and using it to log in later. TLS provides protection for a large number of threat models, and explicitly takes into account this issue. It will prevent an attacker from simply replaying whatever credentials you are using. The only scenario when client-side hashing would be beneficial is if the server is hostile but the server has no control over the code that the client executes, or if the server is too low-powered to perform a proper slow KDF and some heavy processing must be offloaded to the client. Either way, you should use TLS.


From your description, it seems that example.com is properly handling the user-supplied value (ie you are not injecting into the given script / e.src, which is why what you tried didn't work). You can inspect the DOM of example.com to verify this.

Instead, example.com treats the value properly as string and passes it on to tracking.com which in turn handles it insecurely (you could verify this by directly visiting https://tracking.com/container/?utm_source=[INJECT], but given that it's out of scope, I'd try to avoid that; if you still have the HTTP logs from your accidental triggering on tracking.com, you can likely check those).

Given the above, and assuming that tracking.com isn't trusted by example.com in some other manner (eg accepting or sending interesting postmessages, CORS, etc), the SOP will prevent most malicious actions.

What you are left with is often called a frame injection. It might allow:

If example.com has sensitive GET parameters on a page where it frames tracking.com, and if it does not take measures to protect these, you may be able to log those.
You may be able to bypass some Clickjacking protections (see here).
You might be able to navigate away from example.com via top.location.href="http://www.evil.com"; (akin to tab nabbing)
You could inject your own content in place of the ads from tracking.com (defacement).
you may be able to steal focus from example.com via this.focus(); and log user keystrokes in the hope of intercepting sensitive information from inattentive users (if it works it will impact usability on example.com, so it's a very noisy attack, with a bit of application-level DOS thrown in).

If you want to test any of these, I'd probably redirect traffic to tracking.com to a host I control via /etc/hosts to avoid further hitting out of scope domains.

Whether you want to report this to example.com depends strongly on the program. Some would likely consider it out of scope (tracking.com is the vulnerable site after all) or informative (eg the tab nabbing impact example). But if you can show impact on example.com and especially if you can show how example.com may prevent it themselves (eg preventing referer leaks), it might be worth a try.


Is Threat Risk Assessment the same as Threat Risk Modeling?

Risk Assessment is described as

  Risk assessment determines the value of the information assets, identifies the applicable threats and vulnerabilities that exist (or could exist), identifies the existing controls and their effect on the risk identified, determines the potential consequences and finally prioritizes the derived risks and ranks them against the risk evaluation criteria set in the context establishment.

in the ISO/IEC 27005:2011.

A Threat Risk Assessment does exactly that, but with focus on threats towards an organization/system/software (whatever you set as your scope).

To give an example, if you would perform a TRA for your blog an outcome might be:

Asset: webserver

Threat: abuse of rights

Vulnerability: All admins have access to the admin control panel (or whatever this is called in wordpress)

Control: Gee, I don't know?!?

Effect on Risk: lowers likelihood by X%

Now you are done with the risk assessment (in a nutshell). After you have completed this for all your assets within the chosen scope, you model your threats. This means, that you try to 'think' like an attacker who wants to harm you/your system. How would he/she try to accomplish his/her goal? If you can't do that yourself, you hire a consultant, an IT-security expert or you visit Sec.SE and ask a question:

  You: "Heyyy guyzz, how would an admin abuse his rights, if he was,
  like, an admin on my blog?" (not you obviously)

You get a sophisticated answer that describes how this admin would do that.

  Sec.SE: "Oftentimes administrators have more rights, than they need. Imagine a team of - let's say - 5 admins. Each admin has a specific role. Admin A is responsible for uploading new content, Admin B is responsible for moderating comments, Admin C is responsible for maintaining the database and so on. This obviously means, that each admin should only have the rights, that he/she definitely needs to have. You should definitely restrict the rights for admins in a way, that they are only allowed to do things, that they have to, according to their roles.

Now you have modelled(!) a threat and also established a control. Congratulations!


rate limiting and access filter for web application

Assuming you're running a Linux system, have you considered iptables?

Basically, you could use something like:

iptables -A INPUT -p tcp -dport 80 -m limit --limit 20/second --limit-burst 50 -j ACCEPT

And use some tweaks to whitelist/blacklist. This way you won't have to restart any service.
See this resource or this one, and This anwser on unix.stackexchange.com for further informations.

If you're not running linux, I'm sure pf can also do that.


Storing unencrypted, confidential data in client memory

Off the top of my head, I can think of four ways this strategy could fail. All can be mitigated to some degree through sound development practices and commonsense on the part of users, and a few would require some very targetted attacks, but they are risks nevertheless.

Eval

Storing confidential data on the heap will be risky if you intend to use eval, because code running under eval can access variables in the scope of the eval call, which might include your heap variables. Consider:

var creditCardNumber = 123456789;
var evalString = "window.alert(creditCardNumber)";
eval(evalString); // alerts the credit card number!

There are a couple of ways a malicious user might mount an attack:

If evalString is fished out of a database, an attacker might try and influence that data somehow
If your application uses third party code, an attacker might try and hijack that resource and use eval to grab the data and send it forwards (remember: code running from different scripts will still share the selfsame heap). This risk might be mitigated if the confidential data is somehow held in a closure rather than exposed directly on the heap, but such practices would be easy for a naive developer to break.

Remember that calling window.setTimeout and window.setInterval with string arguments are aliases for eval too.

Browser extensions

Browser extensions may be given the opportunity to inspect the contents of the JavaScript heap, directly or indirectly. For instance, Chrome provides a debugging API for extensions built as developer tools. Users must give permissions to use these extensions, though, and install them purposefully, so this might not be a simple way to mount an attack.

Reverse engineering

Even minified code can still be reverse engineered, so it's always possible for malicious users to reason about how you're performing encryption and the way your JavaScript application handshakes with the server.

Accidental exposure through third party code

You may be confident that your code never assigns creditCardNumber to something persistent like localStorage or serializes it to JSON and pushes it to window.name, but are you similarly confident about third party code? It might be worth checking if you're passing the object around, particularly if you're passing it to something that tries to perform caching.


clearly due to a certificate issue:
write:errno=104
...
SSL handshake has read 0 bytes and written 0 bytes

This is definitely not an issue of certificate validation. As you can see, it has send 0 bytes and got 0 bytes. This means the SSL handshake was not even started and therefore the client could have not received any certificates and therefore it can not be a problem with certificate validation.
In fact, errno 104 is ECONNRESET. This means that either the server closed the connection maybe due to problems with the setup or that the server was not even started or that there is some firewall between client and server blocking access. Given that the ECONNRESET happens before any data where sent I would suggest that the TCP handshake already failed, either because server was not started or a firewall.


website hacked by someone proxying over a tor router

Any of these tactics alone would probably be enough, unless the target is high profile enough to lead to a serious investigation by the authorities. If your blog or low-profile, low impact, application is pwned by an anonymous person (e.g. not immediately evident who it is), no investigation will probably happen in most jurisdictions.

A private person probably has slim to no chance of tracking down a user of e.g. a Burger King wifi on a given time, or to reveal a tor users identity. Remember that NSA is spending money targeting tor users to reveal their identities.


When to use the different types of Encryption / hash algorithm?

I think in general you'll need to understand the difference between symmetric and asymmetric encryption.  Symmetric algorithms are faster and stronger per bit of key length than asymmetric algorithms.  But symmetric algorithms require a pre-shared key and asymmetric algorithms do not.  So, in situations where strength and speed is required, and securely pre-sharing a key is possible, you would use symmetric ciphers like AES.

In practice, cryptographic hashes, symmetric and asymmetric encryption are combined to provide a more complete solution.  For example, asymmetric encryption can be used to exchange the keys for symmetric encryption.  This is how Secure Sockets Layer (SSL) works.


Has it been proven, that Google Home & Alexa do not record before their respective key phrases?

If you have a device in your room which can record data and which from time to time sends data to some server on the internet there don't need to be any kind of relationship when the device records data and when it communicates with the internet. It is perfectly possible that the device records data and only transmits these data later, maybe even only when receiving a command from outside.

The only way to be sure that this is not the case is to analyze the currently running software on the device and make sure that the software never gets replaced (or analyze it again then). But since these are proprietary closed source products which from what I believe have not received any independent and deep enough analysis and can also be easily updated by the vendor to a different firmware you just have to trust the word of the vendor who will likely assure you don't have to worry about anything.


If you do not see any other devices connected to the router, then these possibilities come to my mind:

If the data transfer between your device and the router happens by WIFI, your device is broadcasting radio signals, which can be received by anyone in the range and since they already know the wifi password, they can decrypt it also. you will not find this passive listener as they are not connected to the router. more information here
your own device is compromised, so every time you connect it to the network, it forwards traffic elsewhere.
Your router itself may be compromised, so that it is forwarding traffic elsewhere.

Analyzing the amount of Risk is up to you as it depends on what and how this WIFI network is used. but if this attacker uses your WIFI network for illegal activities then you are in trouble.


How to workaround Thunderbird 78's lack of support for encrypted mailing lists?

Schleuder is a group's email-gateway: subscribers can exchange OpenPGP-encrypted emails among themselves, receive emails from non-subscribers and send emails to non-subscribers via the list.
The consequence of this approach is that you need to really trust the provider that runs Schleuder: they could store and decrypt all emails that pass the lists, if they wanted.
For more information please take a look at this URL = https://schleuder.org/schleuder/docs/concept.html


Are these encrypted URL values safe or could they be guessed?

Unless the site now has access controls on the URLs (requiring that you first authenticate - prove your identity - and then that the server checks whether your identity is authorized to view that URL), no, it is not safe. Obvious problems include people sharing links through a site like this (without redacting the domain), browsers remembering the URL in their histories (on a shared computer), or somebody (insider or outsider) dumping and sharing a list of valid URLs.

The term used for this type of security vulnerability is a "direct object reference", when inputting an object's ID lets you access the object even if you wouldn't normally have access. The only true solution to the problem is proper access controls. Merely making it hard to guess the object ID doesn't solve the problem, although in the short term it may make exploitation harder. Putting secrets in the URL doesn't really solve anything; you need a system that relies on actual credentials.

Now, as for the enumeration: as the comments point out, that's a very suspect encoding. The repeated prefix indicates that, whatever else they're doing, they aren't using a secure hash (or not using it correctly). Given that they're presumably trying to map from a URL back to an object identifier, it's probably a reversible encoding anyhow.

Encrypting the URL query string with a secret key known only to the server will produce hard-to-guess links, although depending on the type of encryption used it may still be possible to flip bits and produce new valid URLs without knowing the encryption key (they'd need to add an integrity check, like an HMAC or an authenticated encryption scheme, to prevent this). Encryption, by itself, does not prevent an attacker from tampering with the ciphertext (and with some encryption schemes that tampering is easy). In any case, such a system is dependent on the key remaining a secret, making a single point of failure.

Encrypting the query string using a known key - for example, if the key is in that unchanging prefix - is completely broken. Figuring out the crypto scheme used would take a little bit of (educated) guessing and checking, but the space of possible systems would take very little time to search. Once it's known, crafting valid URLs is trivial.

The least-bad way to do this (there's no good way; for anything sensitive you simply must use authentication and access controls) would be to store reasonably-long (64+ bits; GUIDs are often used here), cryptographically-secure random identifiers for every row in the database. Then encrypt them, with a server-side secret key, before turning them into URLs. This avoids single points of failure (the random IDs are useless without the key, and vice-versa) for compromising the whole list of valid URLs, and also means you could do things like periodically changing the ID tokens to invalidate old URLs for those objects, or changing the encryption key to invalidate all old URLs. It'd be secure against bit-flipping the ciphertext because there's no way to say "assume this part is a number, then try flipping bits to produce another valid number"; the valid combinations of bits are an un-guessably-small part of the search space of possible identifiers, because the identifiers aren't sequential and are long enough that only an infinitesimal fraction of them will ever be used.

But, I must emphasize again: this is a much worse idea than just putting proper authentication and authorization in place. If you've done that, you can safely stick to simple incrementing numeric identifiers because guessing the next value doesn't gain an attacker anything.


Are Java applications vulnerable to CVE-2014-6321 (WinShock)?

The vulnerability (still undisclosed) is also described as "Microsoft Schannel Remote Code Execution Vulnerability", which indicates that it is an implementation weakness (namely, a probably boring buffer overflow), not a protocol weakness. Thus, there is no reason to believe that the vulnerability would be shared with any other independent implementation of the protocol.

(Furthermore, Java's implementation of SSL/TLS is not only independently developed; it is also written in Java, which is inherently resilient to buffer overflows, since all array accesses in Java are inherently validated against the actual array length.)


UNIX Servers: Possible intrusions or attacks that do not use any of the open listen sockets

Regardless of whether this should apply specifically to Unix, I would say that it is not safe to assume no access just because there are no open ports.

To wit, ICMP is usually listened to, even if no TCP or UDP ports are available.
And before you say, "But ICMP is just a simple Ping! It's irrelevant to attack using that!" check these out:

Ping of Death
Smurf attack
and of course, Ping flood

And while these are all pretty much historical (with the exception of the last), I wouldn't rule out additional, future attacks.

In addition, there are the indirect attacks, such as those that attack the infrastructure that the closed-off system would itself access - e.g. DNS poisoning...


Client Certificates from Public Certificate Authorities

What fields can I rely on in this case?

It probably depends. But since there are fields in the subject for email, organization etc it is likely that these are actually filled in with the clients information.

  Would I be able to just map the Subject Name to a user in my application and trust the CA/Browser bundle?

You should not just trust arbitrary bundles to authenticate your clients - see also next question. In case you want to use client authentication for external clients (not managed by you) you might trusted selected public CA. But for authentication of your companies employees it is probably a better idea to have your own company CA in order to have better control about revocation (i.e. integrated when somebody leaves the company) etc.

  Can "Public CA 1" guarantee that "Public CA 2" will not sell the exact same certificate to a different company?

No. You have to decide which CA to trust for client authentication.


I suggest the following changes

  Enter username/PIN
  Log in as user to smart card (if fails, return false)

Usually smartcard with digital certificates do not have an "username". The pin it is needed to unlock the private key of the selected certificate

  Check the validity of certificate (if not valid, return false)

Correct, this is needed to filter the available certificates. You can have several (I do not know if this is your scenario)

  Check if username equals CN in certificate (if not, return false)
  This step is usually done after digital signature, because you do not what certificate the user is going to select.

Also you are assuming that user is logged and CN contains the username. When using smartcards to authenticate the process usually is the reverse: The user selects the certificate, and the username is extracted from a certificate attribute (CN, SERIALNUMBER or a custom one)

  Generate random data and sign it using private key on smart card
  Check if the signature is valid (if not, return false)

Check revocation of used certificate
Extract username from certificate and check if it is authorized

  Return true


How to launch XSS code from an INPUT HTML tag upon page load?

Try this:

" onfocus="alert(1)" autofocus="

It will expand to:

<input type="text" id="search-text" name="query" value="" onfocus="alert(1)" autofocus="" />

Which will cause an alert box, demonstrating XSS.


Because the context of www-data is a lot less privileged than the one of root. For instance as a root user you can alter a lot more configuration files, add or remove users, read protected folders, etc...

As www-data you cannot do this, so even when exploited the attacker can only use all resources and files available to www-data. This helps contain the attack (obviously privilege escalation cannot be stopped if exploits exist).


NMap for getting machines connected to a network switch

Nmap is not the right tool for that.
"Machines connected to a network switch" is a layer 2 question.
Nmap is a layer 3 tool.


Tracing the location of a mobile IP from an email

The problem with this scenario is that emails are typically not sent from the device itself, but from a central service.

In order to do what you want, the investigators would have to make a few hops:

to the email service (gets the user account details, including the IP the user used to connect with)
to the ISP the device used at the time of sending (gets the general location of the connecting IP, or if lucky, the known IP of the user's home)

At best, using 3G/4G, investigators might get the cluster of towers the user was in the middle of. No exact location.

BUT, with all that info, it might be possible for investigators to breach the phone's data or the user's other accounts and determine the location of the device using the multitude of location services modern devices have (Find My Phone, Facebook, Instagram, etc.) (Insert a whole host of legal issues currently in the news, like Stingray).

Edit:

You don't specify the country (or reality) you are dealing with. There are some countries that have set up massive detection nets so that every mobile device is physically tracked no matter where it goes. That way, investigators can have a real-time, accurate map of a particular device at any time.


Is it possible to create secure streaming server

Updated using your assumption that you will trust your users:

Of your 4 criteria, 2 are easy:

people have to login with their credentials to see videos
different people should have rights to see different videos

You just encrypt and provide them with the decryption key. If you have a lot of users, key management could be annoying, but this is still an easy problem to solve.

The final two are also relatively straightforward:

it should be able to use CDN caching (videos can be pretty big)

So just encrypt chunks and use a streaming mechanism to stream chunks to the user population.

video should be viewed on different platforms and devices.

So write your decrypt method in a cross platform language.

All these are standard, solved problems.

Or alternatively, just stream everything over https - and just require that the users log in. After your update, this is going to be your simplest solution - authenticate users; provide them with access to the content they are allowed; deliver it using https: problem solved.


Encryption / Decryption algorithm generic across JRE (Sun/IBM)

The standard name documentation of the Java Cryptography Architecture (JCE) contains a section about implementation requirements. For both Java 7 and Java 8 it contains the following entries for Cipher with regards to RSA:

RSA/ECB/PKCS1Padding (1024, 2048)
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (1024, 2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (1024, 2048)

to make sure you got the right one, specify the complete string (excluding the key sizes within the parenttheses of course). So that would be "RSA/ECB/OAEPWithSHA-1AndMGF1Padding" for OAEP padding.

RSA is a set of internationally standardized algorithms (defined in the PKCS#1 standards and the RFC's derived from those standards). The implementations should confirm to the test vectors for any platform. RSA for instance uses big endian encoding, even on little endian platforms.

The Base64Encoder is a Sun internal class. It may even be inconsistent across implementations and it may disappear without warning. It is used a lot unfortunately so Oracle and others may decide to leave it in place, just in case. You should never ever use Sun internal classes. Many static code validators and even IDE's will flag this as an error.

For Java 8 compatible runtimes you should use the Base64 class. For earlier versions you should go with a library. The Apache Commons Codec is often used. Google Guava is used a lot as well and has a set of codecs too.

Base 64 has been around for a long time. It should not run any differently on 32 bit or 64 bit on any platform, as long as you are sure you use the same character encoding. UTF-8 encoding - compatible with US ASCII for base 64 - should be preferred.

Finally there are the Java Bouncy Castle libraries and provider. The Bouncy Castle libraries contain an ever growing amount of cryptographic functionality that can be used on any Java runtime. The provider is used to allow much of this functionality to be used through the Java JCA/JCE. And it of course also contains a Base64 class in the "lightweight" API.

As long as you use the API correctly Java is fully compatible on 32 and 64 bit, big endian or little endian processors. It should not even matter if you use Linux, Windows, MacOS. Android should be compatible as well, although it is not an official Java distribution.


whats the worst thing an Android malware is capable of doing?

There is no generic "worst". For some this might be that the device is permanently broken so they need to replace it (costs), for others it might be the loss of information on the device (value of data). For some the worst might be that sensitive information leak from the device, like access credentials or sensitive pictures etc and then get used later against the owner or for impersonation. And for others it might be that the device listens to all what their communication and transfers these to the adversary (espionage).
A potent Android malware could do all of this, especially if it can use some bugs to get root access (there were several of these in the past).


Simple buffer overflow trying to leak address of system()

Because you're not saying anything about RelRO, I'm assuming no RelRO (so no leaking of the address of strcpy because it isn't called yet). Yet, this doesn't matter much, here's why:

You say PIE is enabled, which in combination with ASLR will randomize the location of the binary in memory and thus the location of the PLT and GOT. Hence you cannot leak from the PLT or GOT because the locations are unknown.

There's a silver lining tho: You didn't say anything about the bitness. ASLR (and PIE) can be brute forced on 32 bit systems.

If you are on a 64 bit system, you are out of luck: The program is obviously designed to teach you the basics of binary exploitation and those are (successfully) mitigated by ASLR, PIE, NX and stack canaries.

If you want to learn the basics, you should deactivate the security features that mitigate those basic exploit techniques.


What are the security risks of using unencrypted (plain text) cookies
  to store this information, and what about for more sensitive
  information (ex. email, password, or even credit card number)?

There are many ways you are putting user data at risk. Few of think listed below.

There are many browser extensions that spy on user and their data. You are making their job easy.
The cookies can be obtained by sniffing. This reveals sensitive information to the attacker. (Of course this can be prevented by  setting secure flag on cookie and using https when visiting the site).
The crash dumps of programs (browsers) may contain this sensitive data of the user and potentially leak them.
Users may use public computers in internet cafe or kiosks. So, next user using that computer can see what I have done. Probably these cookies as well.
Also, as mentioned by @Matthew, users can easily tamper with these cookies using a cookie editor extension, and see how the application behaves. (Let's say I changed the firstname in cookie to another person's, does this give me access to their account?)

  Can other websites view the cookies my site creates?

Given the major browsers like Firefox, Chrome, this case will be considered a critical security bug. So, as long your users use a good browser your are good to go.


Are browser wrappers in software bad for users?

Web wrappers within an app has become quite common among applications and is not going to change anytime soon. The following measures will be helpful for securing the account used here

Login without password - For example, Google allows you to login using your phone, Microsoft allows you to authenticate from it's authenticator app. This will prevent anyone tracking your password.
Use Two Factor Authentication - Even if the entered password is compromised your account will be safe.
Don't reuse password of this account anywhere else.
Change password frequently (at-least once in six months).

  is this a trend that needs to be put to halt?

While the wrapper popup brings in some nice user experience, there are quite some alarming things such as hiding the location bar. Developers really need to stop hiding URL in authentication prompts. How am I supposed to know that I am on the right site.

Response to comments

  but that isn't any different from any web browser.

You cannot hide the URL bar in modern browser popups.[1]

References

StackOverflow - Hiding address bar in browser


Should I use urandom() or openssl_random_pseudo_bytes()?

The right way to generate a salt for password hashing is: do not do it yourself. Use a library which already does thing properly. See @Terry's answer for pointers.

For your exact question, it so happens that openssl_random_pseudo_bytes() relies on OpenSSL's internal PRNG, which itself feeds on what the underlying platform provides, i.e. dev/urandom, so it is safe. Strictly speaking, you should use the second parameter of that function to check whether OpenSSL did find a strong source of randomness on the local platform (see the documentation), but in practice, as long as OpenSSL runs on a Unix-like or Windows-like platform, things will be fine. So it does not really matter, for security, whether you call openssl_random_pseudo_bytes() or read /dev/urandom yourself. For maintenance reasons, I would prefer the former, which is simpler (only one call) and more portable (it will also work on Windows, whereas reading /dev/urandom will not).

Either way, applying SHA-1 on the output of openssl_random_pseudo_bytes() or /dev/urandom, is totally useless. Good PRNG already produce unpredictable uniformly random bytes (and if your PRNG is not good, then why are you using it ?).


Checking system integrity after clicking scam email link on Linux

Most of the standard security in Linux distributions prevent the worse incidents. I assume your mother does not browse as root. And if your distro has the latest patches applied, most of the time, you'r OK.
There are some integrity checks, like chkrootkit; you must stay of course up-to-date and it will not detect everything.
Further, more extreme measures would be to create a Trusted Computing Base, like they had (have?) on AIX. Store a checksum of every file and from time-to-time check if they are still correct. Be sure to update your signatures after each package upgrade.
You could also create a reference system and compare it with that. That is overkill for a single PC, ofcourse.
And you could look into mounting partitions as read-only. I've seen /usr on a read-only, and that kind of works. Keeping up-to-date with the system is horror though.


AES successful decryption using wrong secret key

CTR mode is a way to, in essence, turn a block cipher (which operates on "blocks" of data of a specified size, transforming them in a way that is deterministic based on the key and the input block, but contains complex internal math) into a stream cipher (which is, essentially, a secure pseudo-random number generator that you seed with the key and IV, generate a length of pseudo-random bytes the same as the length of your data, and then XOR them). Because the actual encrypt/decrypt operation (with regard to your data; CTR mode technically involves using your block cipher to encrypt successive numbers - the eponymous counter - to produce the pseudo-random numbers) is just XOR, there is no way for the algorithm to verify that the key is correct. Mathematically, there's nothing preventing you from taking plaintext stream PT, XORing it with pseudo-random stream PR1 (encrypt), and then XORing it again with a different PR2... you just aren't going to get PT back out again!

In fact, in general there's nothing preventing you from decrypting encrypted data with the wrong key. Some padding schemes (used to ensure that your data is a multiple of your block size, which is irrelevant for stream ciphers and counter-based modes of operation, so you aren't using one) include what amounts to a checksum that can be used to detect incorrect decryption (or tampering with the ciphertext) with decent reliability (worst case, with only one byte of padding needed, you'd still have only a 1/256 chance of a random key not producing a detectable error), but this is not secure; a competent attacker can bypass this check. In fact, often enough, an attacker can exploit this padding check to decrypt your message without knowing the key at all (via a padding oracle). There are some block cipher modes of operation that are what's called AEAD (Authenticated Encryption with Associated Data) modes, which include a cryptographic verification that the ciphertext was not tampered with between encryption and decryption, and that the same key was used for both (thus authenticating the decrypted message: you know it is the same as the message that was encrypted). The most common AEAD mode is GCM, which is also a counter mode (but does require additional space for the authentication data, if you want it to be any more secure than CTR). You can also authenticate the decryption in other ways, such as using an HMAC (Hash-based Message Authentication Code), which combines a cryptographically secure hash function with a secret key (can be the same as your encryption key) to produce a verification value (which needs to be sent/stored along with the ciphertext) that can be used to verify the key is correct and the message hasn't been tampered with. In general, though, encryption/decryption by itself provides no guarantee that the message out is the same as the message in, either because the ciphertext was tampered with or the wrong key was used! Encryption, as a general class, provides confidentiality of the data and nothing else.

  What am I doing wrong?

Trying to build some very weird cryptosystem when you don't actually understand crypto. Don't do that. Rolling your own cryptosystem is only slightly less of a bad idea than rolling your own crypto primitives, and while one might argue that it has a lower barrier to entry (you don't have to know nearly as much math, for example), you still don't meet it.

For example, I can't even guess why you think your IV needs to be encrypted, but if your use case actually requires it (unlikely), you're probably trying to do something that can't be done (at least, not securely). The IV is just to ensure that encrypting the same data with the same key does not produce identical ciphertext; its actual value is irrelevant so long as it is non-repeating and unpredictable (which is why it's typically long-ish and generated randomly) and certainly not secret. If you're expecting the IV to serve some other purpose than that, you're trying to use symmetric ciphers wrong.

A MUCH better idea would be to explain what you want your cryptosystem to do, and in the case that there's nothing which currently does that exact thing already and it's not impossible, let people knowledgeable the field design a new system to do it. Seriously, even experts screw up all the time. We're on the third standard for WiFi security (WEP, WPA, and now WPA2, with WPA3 coming out to address problems found in WPA2) and the fifth for TCP security even if you ignore the never-published v1 (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, and now TLS 1.2, with TLS 1.3 around the corner), and even if the original versions of those were designed by crypto amateurs (I don't actually know, and it seems unlikely, but those were different times), the intervening versions weren't... and we still found weaknesses in almost all of them.


Is this CA store related to Ubuntu or OpenSSL

OpenSSL has no own CA store although it has a default location where it will look for a CA store. On Debian/Ubuntu this default location is /usr/lib/ssl/certs which is a link to /etc/ssl/certs.

The file /etc/ssl/certs/ca-certificates.crt (note the leading '/' since this is an absolute path) is created from the certificates in /etc/ssl/certs using the update-ca-certificates program which is part of Ubuntu and Debian and run automatically on installation and when needed on software updates. The certificates which are in /etc/ssl/certs by default are part of the ca-certificates package.