Help with scope clarification of PCI requirement 8.5.15 Section 8.5.15 reads:

If a session has been idle for more than 15 minutes, require the user
to re-enter the password to re-activate the terminal.

Section 8 Accompanying note reads:

These requirements are applicable for all accounts, including
point-of-sale accounts, with administrative capabilities and all
accounts used to view or access cardholder data or to access systems
with cardholder data. However, Requirements 8.1, 8.2 and 8.5.8 through
8.5.15 are not intended to apply to user accounts within a point-of-sale payment application that only have access to one card
number at a time in order to facilitate a single transaction (such as
cashier accounts).

The contradictory statements are:

applicable for all accounts
to access systems with cardholder data

and

are not intended to apply to user accounts within a point-of-sale
payment application that only have access to one card

The way I read this is that the requirement does not apply to any account that has nothing to do with credit card or administrative functions that could lead them to gain access to credit cards. So, for example, an account with a function to send e-mails to my customers would be out of scope.
Would appreciate it if someone could help validate-invalidate my interpretation and clarify why I'm wrong if I am.

Yes, your understanding is pretty close.

That accompanying note is intended to clarify exactly that point: those requirements apply only to accounts that have access to multiple cards.
I.e. a cashier application, that accepts a single card at a time (and cannot access historical data!), is out of scope.
I.e. your account that can only send emails (assuming there is no access to the customers CHD) is out of scope.


Received a strange text message. What is it? This morning I received the following text message from a Gmail account:
v3s5f3rs4f3gs3.nf5j4k8j4k3o.solar?G$1?V&?KL?O=$HO?&S?K0?$1T
A couple of my friends got it too.  I have an iPhone and it didn't do anything, but on android phones, it shows up as a link (both were smart enough not to tap it).
What is this message?  I'm guessing it's some attempted SMS hack similar to the infamous iMessage bug a few years back that bricked some peoples' iPhones.  Does anyone have any details?

.solar is a top level domain (TLD) so I checked the WHOIS for nf5j4k8j4k3o.solar.

Property
Value

Name
nf5j4k8j4k3o.solar

Created
2021-03-19 09:58:10 UTC

Registrar
NameCheap, Inc.

Your text can be broken up as follows:
v3s5f3rs4f3gs3.nf5j4k8j4k3o.solar?G$1?V&?KL?O=$HO?&S?K0?$1T

Value
Description

v3s5f3rs4f3gs3
Sub-domain

nf5j4k8j4k3o.solar
Domain

?G$1?V&?KL?O=$HO?&S?K0?$1T
Query parameters

It's definitely a link, and given how garbled it appears and how recently the linked domain was registered, this is unquestionably a phishing attack. The sender is counting on the recipient to click the link.
I'd suggest that you report the domain to the registrar via abuse@namecheap.com. The associated domain ID is:
a54f6533a1a3416eb6f07a953dee0931-DONUTS


How secure is this way to use open VPN I have installed openVPN using the following link

http://www.vpnbook.com/howto/setup-openvpn-on-ubuntu

I would like to ask is it really secure .

the password is available for everyone and the configuration files also are public

so can I consider this a secure connection . and if not how i can make it really secure

The guide isn't very good. More of a quick guide and it assumes a significant amount.

First assumption is that you know to run a console as root to actually do the installation and configuration. The result of that should be that the configuration files are not public but rather all belong to root or a separate OpenVPN limited user (sorry, I can't remember which off the top of my head).

Therefore, normal (non-admin) users of the box should not have access to the sensitive files. But don't forget that any computer where people have unrestricted physical access cannot really be fully trusted.

Furthermore, using a service like VPNbook, you are putting a lot of trust in the service. You can never really know what happens at the other end of the VPN. Remember that the traffic is only encrypted between your PC and some terminating computer at the other end. After that, anyone with system level access can read anything. Don't assume either that this would protect you from being traced online, it will not.

A more secure setup requires you to control the other end of the VPN and to control every aspect of the PC.

At @Phillipp commented, you need to give us more information about what your security concerns are for us to be able to comment further.


SAQ-A vs SAQ-D Scope I've received notice from our risk management group that they believe our website falls in scope for SAQ-D.
We utilize third party vendors for all of our payment processing - and on the website essentially just provide static links (href="ourcompany.someprocessor.com") to direct them to the payment processing sites.  There are no forms on our site where any customer data is collected, we do not post any information over to the vendor (100% of the process takes place there) - nor do we receive any callbacks about any transaction that takes place there.
So my read on it is that we fall under SAQ-A.  We have explicitly tried to take steps NOT to fall in scope of SAQ-D/etc.
The argument that the risk management group is making is that the potential exists that someone could hack our site - and change the link from the valid link to some nefarious CC processor.  While a legit concern - I do not believe that it changes our status as requiring SAQ-A.
Am I off base on that?

You seem to fall under SAQ A.  Let's review the list of criteria that determine a SAQ A merchant:

SAQ A merchants confirm that, for this payment channel:

Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;

You don't say this explicitly, but it's implied.

All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers;

You state this explicitly.

Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;

You state this is the case.

Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely
on a third party(s) to handle all these functions;

This is implied by what you've said.

Your company has confirmed that all third party(s) handling acceptance, storage, processing, and/or transmission of cardholder
data are PCI DSS compliant; and

This is what you've said.

Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.

It's highly unlikely a processor would give you receipts with cardholder data.

Additionally, for e-commerce channels:

The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated
service provider(s).

And this is what you say you're doing.
I agree with you, it sounds like a SAQ A environment.  I would push back and ask the risk management group to explain which criteria of SAQ D they feel you fall under.  The chance that someone could hack your website and change the link is not something that triggers a SAQ D categorization; if that was the case there would be no SAQ A at all.


Is it possible to separate DRA decryption abilities? In the name of separation of duties, I was wondering if there is a simple (or even not-so-simple) way of dividing the ability to decrypt an EFS encrypted file such that it would require two DRAs to decrypt the file, while still enabling the owner of the file to decrypt it by him/her self. Is that possible?

If there are alternatives to EFS which have this option, that would also be useful information.

Yes this is possible, but I do not believe EFS directly supports it. There is a secret sharing technique called Shamir's Secret Sharing which provides information theoretic secure sharing of a given secret where an arbitrary number of individual parties are required to calculate the original secret. From the Wikipedia article, one of the properties provided seems to describe what you want perfectly:

  In organizations where hierarchy is important, we can supply each participant different number of pieces according to their importance inside the organization. For instance, the president can unlock the safe alone, whereas 3 secretaries are required together to unlock it.

In your situation, you would want to use the secret as the file encryption key. You could split the secret so two any two DRAs are required to decrypt a file, but the owner of the file has enough "parts" of the secret that they can derive the final secret required to decrypt it without any other information from the outside. A simple implementation would the open source ssss or sss utilities.


Keeping secrets from root on Linux I am looking for ways to harden a linux system so that even when gaining full root access (through legit or non-legit means), some secrets remain inaccessible. But first a little background.

Many of the different linux security models (SELinux, TOMOYO, etc.) concentrate on limiting what processes can do by policy and making sure they do not need full root access. They aim to keep any exploits contained so other parts of the system can not be compromised. However, it seems that these do not directly tackle the case where full root has already been gained - or, even further, keeping secrets from the valid root user. It seems that usually these can be just turned off by the real root at runtime.

Another approach is to limit the ways of gaining full unrestricted root - for example not allowing all access to a remotely connected root user, but requiring a login from the physical console. However, this is not my goal either - the assumption is that any such protections have been overcome already and the root is as legit as it can be.

It is obvious that anyone with physical access to the machine can get everything stored on the harddrive and possibly also everything stored in memory. It is also obvious that if the root user has the power to modify binaries or kernel images, no security promises can be given after reboot. I am only interested in attacks that can be done without rebooting the system.

Also, during the start up process, secrets will most likely be transmitted in through many places and many security critical functions are needed. It is ofcourse great if secrets can be protected during the start up process as well, but what is enough for me is a step during start up where elevated privileges can be dropped and after which there are no ways of regaining them.

So, with these limitations, what are the ways on Linux to prevent the full root user from accessing some secrets?

Can there be files on the filesystem that are not accessible even to the full root by any means, but accessible to some processes? Some currently running processes, or even new processes started by the processes currently having access?
Can secrets be kept in memory by running processes so that even the full root can not gain access to them by any means? Can these secrets be transmitted to new processes by some means that the root cannot affect?

This is a hard question to write so that I get answers relevant to me, so I will try to edit the question to be more specific if necessary.

Obvious things coming to mind that need to be limited would be:

Disable access to /proc/mem
Disable access to /proc/<pid>/mem
Disable access to /proc/<pid>/fd/*
Disable module loading (only after some modules have been loaded, preferably)
Disable ptrace access to any process

Actually, it is possible to restrict root if one is prepared to define such a restriction as fundamentally trusting the operating system. This can be done using SELinux (that I know of) and presumably other such systems. The best such example I have seen of SELinux used in such a way is Russell Coker's Play SELinux Machine.

As a brief overview of how it works, the name "root" is not special in Unix. The UID 0 is. UID 0 is taken to mean "trust everything I say". This applies specifically to the standard access model used on Unices, Unixen or however you pluralise "Unix".

LSM, or Linux Security Modules, allows you to hook into just about everything and audit/deny actions as you see fit. In the case of SELinux, SELinux permissions are checked after Unix permissions, so your flow looks like this:

Event ----> Has Unix Permissions? ---> Has SELinux Permissions? ---> Let it happen

The next stage to understand is that there are, or have been historically, different versions of the SELinux Policy. Before I get into that, understand that in SELinux:

inodes have types, suffixed _t, which might also be called domains; and
users have roles, suffixed _r.

Combined, they control what action a user in a given role may do, and what a process in a given domain may do.

Now, there are three main SELinux policies:

targeted. This is the default policy for desktops like Fedora. The idea of targeted is that critical system services and daemons are run in domains, but a lot of what you the end user does is run in unconfined_u:unconfined_r:unconfined_t. No prizes for guessing what that means - if Unix permissions work, SELinux is effectively pass-through.
strict. This policy involves removing unconfined_u entirely. This is not an easy process, especially on the Linux desktop (i.e. init 5). Specifically, the X11 security model is not great and often requires unconfined_t for some applications. You can do this, but I would expect working with X11 to be harder (although not impossible) especially when executing GUI applications that require root. There is a project underway to provide support for SELinux-like functionality in X, called XACE (X Access Control Extensions).
MLS. MLS stands for multi-level security and means the end of the permission string: user_u:system_r:httpd_content_t.s0-s2:c5-c7, i.e. those s and c numbers actually mean something. Specifically they form a no read up, no write down setup such that unless the process is running as a certain level, the information they can see will be limited. The idea of this level of information is to protect classified assets—SELinux was originally developed by the NSA, presumably for this purpose.

So that's your background. Now, according to the web pages (see FAQ) root is UID 0 on the play machine; however, root is set to run as user_r and not sysadm_r in the strict policy. This means the user will not be allowed to execute administrative functions from the shell.

What would be interesting to know, then, is the status of the other processes that do require root. Presumably such processes have been appropriately labelled and have policies that allow them the access they require. The question then becomes how do you administer the system and can any of these processes launch a shell in that user's context. If that can happen, you can still manage an exploit.

Since the play machine is currently down (at time of writing), I'm working on assumptions here; but essentially, you would need a process running in sysadm_r and with UID 0 as your target for an exploit. Assuming such a process exists and is exploitable, you could still get to root. As for still being able to admin via root, there are two options that I can think of:

Either there is a trusted transition of some sort that means root then can transition to sysadm_r (less secure) or
On different runlevels, a different policy applies, so to admin the machine one sets the runlevel to 1 and the policy does not restrict root. I'm guessing here.

Summary

If your question is "can I easily and safely do this now?" the answer is no. If your question is "I am prepared to learn about SELinux, get down and dirty with my distribution and put up with quite a lot of things not working" the answer is it is possible to constrain root much more than your average install. That said, this does not in any way make you invulnerable to exploits—it does not make it impossible for a user to circumvent this extra access control either in software or physically.

So yes, you can make things invisible to root; however, the extra technical burden aside, the same caveats apply as to any access control setup on any normal user—there is no silver bullet.

Oh and blatant self-promotion: you might like my blog post on storing secrets in software. It's on the security stackexchange blog, so I don't feel so bad about promoting that. Essentially, as you can see, there are mechanisms to make life a lot more difficult for an attacker (and you), but in the end, it's a case of "turtles all the way down" i.e. fundamentally impossible to do.


Dump SSL traffic from a Java applet I have a smartcard that can be read by websites using a Java applet (see http://www.springcard.com/online/applet_pcsc/). I would like to monitor and is to replay packets going from this java applet to the network. The problem is that it uses SSL. I tried to make IcedTea plugin (the open source version of oracle's java plugin, since oracle's one do not work properly with the card on my system) use a proxy (to catch the traffic on Burp Suite) and tried a passive sniffing with Wireshark, but it cannot decrypt SSL.

How can I capture and decrypt the SSL traffic? And if I can't is there a way to get the data before it gets encrypted by java (since everything runs on my machine, I can perform pretty much any manipulations)?

paj28's solution works. I had to go to IcedTea's configuration and add the Burp certificate to the list of certificates and then configure IcedTEa to use Burp as a proxy. I don't now why but IcedTea seemed to mess up (refusing to launch the applet) at first, but after a few attempts it works!


Can BIOS firmware log keyboard input? If so, is there any way to detect and prevent it? Recently I purchased a server board made by Lenovo with a "Intel Management Engine" inside BIOS.

It is said that it is able to intercept and redirect keyboard input, even if an operating system is running. The whole BIOS firmware was not open-sourced, so it is possible that there are backdoors inside. And now we know Lenovo was doing some nasty things these days.

I just examined my BIOS chip using flashrom utility in Linux. It said my BIOS has a 12288KB (~12MB) flash chip. That's too big for a BIOS!!

So, I'm feeling very wary. Maybe the extra space can be used to store users' keyboard input? And these data may be exported later by law enforcement or a hacker? That's too terrible!!

Is there any way to check if my BIOS is logging my keyboard input? And any way to stop it?

I'm currently using a USB keyboard plugged in on-board USB connectors, and I think these actions may help:

Use an external PCI/PCI-E USB controller card
Use a Bluetooth dongle + Bluetooth keyboard. (Some initramfs tweaks may needed, in order to recognize them at boot time, and input disk unlock password)
Write a new password input program for cryptsetup: Print a on-screen keyboard with random letter sequence, and use arrow keys to select them.

Since the BIOS is generally the first thing that runs in a computer, using a PCI/PCI-E USB controller, bluetooth, or on screen keyboard would only "protect" you if the attacker didn't consider these cases.

This is still a problem because you're depending on whether or not the attacker did attack something rather than whether or not they can attack something.

While you can still count the number of BIOS attacks that have ever been published with your hands, technologies like Intel TXT can allow administrators enforce and audit BIOS security.

Unfortunately, this doesn't protect end users from nefarious code distributed by Lenovo themselves (which they now have a track record of). Essentially the only way to identify and prevent some sort of BIOS based keylogging attack is to:

Dump and Examine the BIOS yourself.
Use hardware from a vendor you trust more.

Ethical Disclaimer: My job involves Intel TXT


From a credential flow perspective, whats the difference between FIDO UAF and FIDO 2.0 Web Services? The FIDO Standard allows for devices and authentication schemes to be certified as UAF or U2F.  This allows for flexible unified authentication, and optional second factor enrollment and registration.

Deployment:

Chrome has built in FIDO U2F support.
Firefox support is in progress.  Extensions exist, however since direct hardware USB access is needed, users should take caution of loading these.
Internet Explorer will not be implementing U2F and instead will support FIDO 2.0 Web API's in Passport.

Question

How different is the W3C FIDO 2.0 Web API's from the current enrollment for Relying Parties as described here and in this script?

Great question :) A quick note to explain the long silence about that: Nobody was really able to answer this question until recently because there were many debates about possible links between FIDO "1.0" and "2.0" (mainly because there were no real details about FIDO 2.0 for a long time...).

First, your question details are kind of outdated (that's normal). Inside FIDO Alliance technical discussions, FIDO 2.0 is not really used anymore and the link about the real updated w3c submission group is done with a new name: "Web Authentication" or "WebAuthN", and you can follow news here : https://www.w3.org/blog/webauthn/

You can forget every article about first old "FIDO 2" Microsoft implementations, this was purely experimental (* cough * marketing BS * cough *) and done even before the first specifications draft was available. Now Microsoft is really part of the ongoing "WebAuthN" work so MS documentation is currently being updated from time to time... but there are simply no real existing implementations for now as specifications have still to be be finalized. It will be done "soon" (later this year).

Now the real - still partial - answer you can get to this date (2017-02-23)...

The very recent 4th public Working Draft of "WebAuthN" (ex-FIDO2) is available here : https://www.w3.org/TR/2017/WD-webauthn-20170216/
and you can see this is the same as the last official release (https://www.w3.org/TR/webauthn). You'll be able to find info there about new credential registration and authentication assertion verification... and for the first time, you'll find a new section "FIDO U2F Attestation Statement Format" that is the first step of finding a missing link between FIDO U2F and WebAuthN (ex-FIDO2).

(I don't think there is or will be any kind of compatibility between UAF and WebAuthN but let's consider WebAuthN as the new non-messy UAF)

I hope it helped :)


Avoiding repeaters in radio-communication Suppose a sender and a receiver communicate over some radio channel. Is there a way to prevent packets sent and received are not being repeated/forwarded by a MiTM? That is, when the agents are out of range and the packets are supposed to be lost, no MiTM may effectively repeat those packets.

I've thought about packet timing, but the hardware is low end so the clocks could be inaccurate. I've also thought about DH key exchange and encryption, but the MiTM could still blindly forward whatever encrypted packets captured.

I guess an analogy is GPS. If packets from an arbitrary satellite are repeated, triangulation won't be meaningful.

So, is there any way to stop packet repetition?

Edit

The application is indoor navigation using sensor beacons for a robot to navigate around the space. These devices use low end hardware so the clocks may not be accurate, but many sensors are used rather than 3 as in the traditional triangulation. The threat of forwarding packets from unreachable beacons could confuse the robot about its location.

The classical situation for radio-frequency repeaters threats concerns all radio-based identification/authentication systems (RFID cards, etc.), the goal being to establish a tunnel between the actual card located at a distant place and the authentication mechanism (a door lock for instance).

In such case, the goal is not to exactly to use timing (such authentication token just have no clock at all!), but to establish a challenge between the two involved parties and evaluate the latency by measuring the time needed for this challenge. If both parties are in a short range as expected, the latency should never go over some threshold, while if they are out-of-range with some relay retransmitting the signal, the latency may go over this range.

However, this solution is valid only if there is some protocolary communication between the involved parties, and if the considered threat involves a minimum distance between them to induce detectable latency.

The other solution becomes completely implementation dependant, and consists in trying to detect anomalies:

Assume that each satellite, sensors or whatever bears a unique ID. The fact that the unexpected signal from F is received while A, B and C are also received may be detected and considered as an abnormal situation. This would require some mapping, some memory of the previous signal encountered while in learning mode, or some other special disposition which allow to deduce this anomaly using some algorithm if the ID can be disposed in a way matching some law (ID would merely be actual coordinates for instance).
Following the same principle, if the robot is constantly listening radio information, signal strength may also be used to detect any brutal change in the signal strength of some sensor while the signal of the other sensors remains unchanged: this would clearly indicate an issue.
Or something else, in your description the sensors communicate with the robot. Why not also include sensor-to-sensors communication in your scheme? The presence of repeater in such a network would inevitably create new connection nodes in your network, thus raising an alert.

These are a few ideas which came to my mind. However, as stated in the different comments, there does not seem to be any well-known standard at this level, so unlike what is recommended in usual cryptography you will most probably have to "roll your own" here in a way or another.


How to save one password for all users without hashing? I am working on a plugin for site A that logs in to an external site B.

The plugin needs to store the password to site B, but I can't use hashing because I need to send the login information to B. I can't store additional information on the user's device either, because there is only one password for all users of site A. The admin sets the password and the script always connects to site B using that information for every user. So it has to be accessible 24/7. Plus the plugin should be usable by others also using their personal versions of site A. So it would be good, if the administrator doesn't have to do much/anything at all to configure the plugin and the password could just be set easily.

I read about a solution using a VM, but that's just not applicable here.
Is there any way to save the password without creating security issues?

My understanding of your situation:

Site A is internal and each user has their own account.
Site B is external where the institution has one user-account that everybody shares (I'm picturing access to academic journals or something).
You want to make a plugin for Site A that pulls content from Site B into Site A -- and therefore needs to automatically log into Site B.

Correct?

Naively I see a number of options:

Ask the user to type in Site B's password every time you need it, that way you're not storing it anywhere.
Ask the user to type in Site B's password once and store it in their local browser cache. This is less secure in exchange for more convenience.
The admin embed the username / password to Site B in the source code for the plugin. This is the highest convenience, but the least secure because someone could reverse-engineer the password out of the plugin (how hard this is depends on which language the plugin is in, whether the plugin runs on a server or in the browser, etc).

Basically, either you store the credentials in the plugin, or you don't.

A more complex option:

How does Site B's authentication mechanism work? I assume when you provide the correct username / password, Site B returns you some sort of authentication token? Is it possible to stand up a small server that holds the credentials, logs in for you, and returns you the token?

Like this:

Browser plugin --log-me-in-plz--> your server --[username/pass]--> Site B

               <-- auth-token--                <--auth-token--

To be honest, it sounds like your real issue here is that everyone shares one username/password. You are trying to secure something that's weak to begin with.

Have you talked to the people who run Site B? Is this the way they intend you to use their site? Do they have any other auth mechanisms besides this shared username/password? Can you get each user their own account?

Your situation seems a bit like being asked to install security systems in a mansion, but being told by the owner that they never lock the doors and they don't want to have to type in any security codes. The correct answer is to go back to the customer and say "I can't secure this, anything I do will be security theatre at best".

Given this, maybe your organization will be ok with option 3 above and just accept that if someone is determined enough, they can get the password out of the script.


Is it secure to store confidential data on basic HTTPS AUTH? It's a website backend. Since it will only be accessed by two persons, is there any disadvantage on using basic http auth? The website is under https.

edit: as the title points, there's confidential data inside.

Basic auth has a few issues that were fixed in digest auth, but they mostly don't apply since you're using TLS (which should handle replay attacks and encryption of the secret values).  It still might be a good idea to use digest auth anyways, because it's not worse.

Both of these authentication methods are still fairly primitive.  The most notable weakness is that they don't include any sort of brute-force protection: an attacker can try potential credentials as fast as your web server will process them.  This puts the onus on you to implement throttling in another system, like fail2ban.  Similarly, there are no direct audit logs, so you need to make sure that your web server is configured to log authentication accesses, and create a system that can filter and search these logs in case you need to check later to see.

Other than that, there are standard UX/security concerns that may not matter much in your case, since you only have two users.  One of these would be whether you have a shared password for everyone, or different user accounts; if it's the former, you have to (securely) distribute a new password any time you want to revoke someone's access, whereas with the latter you have to design a system that automatically updates the digest file and reloads your web server (or do this manually).


Identifying an unknown hash During some of my research work I encountered an unknown hashed string. What I am curious about is the algorithm used to generate it. A factor that makes it interesting - the string contains an asterisk, that acts as some sort of a delimiter. Here is an example:

i6ygOQQhiUbOFeUbzI2L33*cwsrXsCuZu0CQOPhKrZbii8ynu7qx9g

The asterisk does not have a fixed position, so another example of a valid hashed string is this:

NHudTnpSWRDKXAvLwtsAA0HAnCOFe4aLRiL4e8Y5cWYLYVI*hdMRlQ

I ran these values through HashID, but it was not able to identify the algorithm. Any of you security experts ever encountered something like this? Any pointers as to what might be the hashing method?

Looks like the first part is a base64'd 128-bit hash, likely MD5, and the second part is a base64'd salt.

In hex:

Hash: 8baca03904218946ce15e51bcc8d8bdf
Salt: 730b2b5ec0ae66ed0240e3e12ab65b8a2f329eeeeac7d8

If you have other examples of the hash, it'd be easy to verify this.


When do I use NIST AES key wrapping? Key Wrap constructions are a class of symmetric encryption algorithms designed to encapsulate (encrypt) cryptographic key material. The Key Wrap algorithms are intended for applications such as (a) protecting keys while in untrusted storage, or (b) transmitting keys over untrusted communications networks. The constructions are typically built from standard primitives such as block ciphers and cryptographic hash functions.

What are the advantages of using AES Key wrapping instead of ordinary AES, for example CCM mode (Counter with CBC-MAC)? What are the pros and cons?

Could someone point me to good readings/papers about AES Key wrapping,
other than my primary resource, NIST Key wrapping specification?

Or, could someone shortly explain how it works?

The key wrap algorithm can be envisioned as an extended Feistel scheme which uses AES as the round function, combined with a running state which serves as a rough MAC. If you look at the algorithm definition, you will see that for each of the s rounds, one 64-bit block of data is updated, with a combination function which includes an AES invocation and another 64-bit block. The blocks are also "rotated" so that the next round updates another block, and so on. This really is akin to defining a big block cipher operating over the complete plaintext as a single "block".

As symmetric encryption systems go, this one is quite inefficient, because it involves an average of 1.5 AES invocation per input byte (12 AES invocation for a 64-bit block), whereas GCM would use only 0.0625 AES invocation per input byte (one AES every 128-bit block). It also needs to process each input byte several times, so the entire plaintext message must be fully buffered: this will be inadequate for bulk encryption.

The key wrap algorithm was designed to protect keys and suffers from some ritualistic overkill: a lot of accumulated AES invocations on the hope that it will make so much scrambling that the result will be strong. This is not a bad bet; if we look at it as an extended Feistel cipher, then there is some empirical data that many rounds will bring security. This should deserve some decent analysis, though, and, to my knowledge, this has not occurred yet. This is probably related to the fact that this key wrap algorithm appears not to be much used in the wild.

Good properties of the AES key wrap algorithm include the following:

It does not need randomness. Randomness is a scarce resource on many embedded systems, so having a scheme which is secure without it is nice.
It does not need state. No EEPROM or Flash bit to modify, if only to keep a counter.
It is deterministic. This means that wrapping the same plaintext with the same key will yield the same sequence of bytes. Determinism is mostly neutral, but occasionally useful in some protocols.
It uses a single primitive, which is "the AES": code size is also a scarce resource on embedded systems.
It has low size overhead: it adds only 64 bits to the input size, and includes a MAC, so that's about the smallest than can be achieved.

Bad properties are mostly these ones:

The algorithm is inefficient, with a high CPU cost per byte, and the need for full buffering. This is why the algorithm is meant for key wrapping, where "keys" are short entities, keeping the wrapping costs under reasonable limits.
Despite its 12 years, the AES key wrapping algorithm did not benefit from a lot of analysis or even attention from the cryptographic community, probably because of its restrictive use cases.


Cannot overwrite EIP in basic exploitation example I'm trying to replicate a simple buffer overflow for which I have the following code (strcpy_ex.c):

#include <string.h>

int main( int argc, char** argv ) {
        char buffer[500];
        strcpy(buffer, argv[1]);
        return 0;
}

which I compile by using:

  gcc -m32 -z execstack strcpy_ex.c -fno-stack-protector -o strcpy

The goal is to achieve a shell by exploiting the buffer overflow flaw when filling the buffer with more than 500 characters.

From the literature I've read, I expected to overwrite the EIP in order to change the execution flow and make it point to a memory address where my shellcode resides. In order to achieve this, I attempted to fill the buffer with "A's" followed by "B's" to locate where the overwriting takes place:

(gdb) r $(python -c "print 'A'*500+'B'*500")
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/Examples/Buffer Overflow/strcpy $(python -c "print 'A'*500+'B'*500")

Program received signal SIGSEGV, Segmentation fault.
0x565555ec in main ()

Unfortunately, it seems I have not managed to overwrite EIP. I expected to find a value 0x42424242 in EIP, but I did not.

(gdb) i r eip esp
eip            0x565555ec   0x565555ec <main+76>
esp            0x4242423e   0x4242423e

Additional information about the ASM instructions:

(gdb) disas main
Dump of assembler code for function main:
   0x565555a0 <+0>: lea    0x4(%esp),%ecx
   0x565555a4 <+4>: and    $0xfffffff0,%esp
   0x565555a7 <+7>: pushl  -0x4(%ecx)
   0x565555aa <+10>:    push   %ebp
   0x565555ab <+11>:    mov    %esp,%ebp
   0x565555ad <+13>:    push   %ebx
   0x565555ae <+14>:    push   %ecx
   0x565555af <+15>:    sub    $0x200,%esp
   0x565555b5 <+21>:    call   0x565555ed <__x86.get_pc_thunk.ax>
   0x565555ba <+26>:    add    $0x1a46,%eax
   0x565555bf <+31>:    mov    %ecx,%edx
   0x565555c1 <+33>:    mov    0x4(%edx),%edx
   0x565555c4 <+36>:    add    $0x4,%edx
   0x565555c7 <+39>:    mov    (%edx),%edx
   0x565555c9 <+41>:    sub    $0x8,%esp
   0x565555cc <+44>:    push   %edx
   0x565555cd <+45>:    lea    -0x1fc(%ebp),%edx
   0x565555d3 <+51>:    push   %edx
   0x565555d4 <+52>:    mov    %eax,%ebx
   0x565555d6 <+54>:    call   0x56555400 <strcpy@plt>
   0x565555db <+59>:    add    $0x10,%esp
   0x565555de <+62>:    mov    $0x0,%eax
   0x565555e3 <+67>:    lea    -0x8(%ebp),%esp
   0x565555e6 <+70>:    pop    %ecx
   0x565555e7 <+71>:    pop    %ebx
   0x565555e8 <+72>:    pop    %ebp
   0x565555e9 <+73>:    lea    -0x4(%ecx),%esp
=> 0x565555ec <+76>:    ret

Due to the simplicity of the code, shouldn't EIP be overwritten immediatly after the buffer is filled?

Even if in this situation it should not make any difference, I would like to clarify that ASLR is off.

What am I missing?

Regarding platform:

# uname -a
Linux kali 4.9.0-kali4-amd64 #1 SMP Debian 4.9.30-2kali1 (2017-06-22) x86_64 GNU/Linux

I may be missing something really here, but the easiest way for exploiting this, is that the strcpy() call is in another function.  This way, you overwrite the stored return address, essentially giving you control to EIP.

Your main function doesn't really return into a space that you control.

Make the code something like:

#include <string.h>

void vuln(char *arg) {
    char buffer[500];
    strcpy(buffer, arg);
}

int main( int argc, char** argv ) {
    vuln(argv[1]);
    return 0;
}

The overflow will happen when vuln( ) is finishes and fetches the stored (but overwritten) return address to drop you back in main( ).

That should get you started.


Is it possible to defeat the OS detection capabilities of network scanning tools? Network scanning tools such as nmap have the capability to infer operating system version based upon lower-level system details. EG: TCP/IP stack behavior, etc. Are there any known methods to trick these tools to either report the wrong OS or to confuse them so they cannot correctly detect an OS?

There are a wide range of ways to trick OS identification functions, and they work to varying degrees, depending on how much functionality is built into the tool.

For example, nmap doesn't just use one identification mechanism, but a few which feed in to it's confidence %age announced in it's OS identification.

  Nmap sends a series of TCP and UDP packets to the remote host and examines practically every bit in the responses. After performing dozens of tests such as TCP ISN sampling, TCP options support and ordering, IP ID sampling, and the initial window size check, Nmap compares the results to its nmap-os-db database of more than 2,600 known OS fingerprints and prints out the OS details if there is a match.

Some tools look for only one signature, for example banner grabbing, so will be easier to fool - by simply spoofing the banner or signature.

So if you want to fool OS detection, you will want to look at a pretty comprehensive set of TCP frame sizes, keepalive functionality, packet number sequences, service banners etc etc

And change them all... this can be pretty difficult.

Instead, do you want to think about using some kind of proxy - depending on how it is configured, the scanning tool is likely to identify the OS on the proxy, which may be enough to reduce or remove the risk you are trying to mitigate.


What happens if an attacker steals my sim card number? The Sprint chat guy asked for my sim card number (ICCID) and I'm a little concerned about how sensitive it is. One possibility I can think of is being able to intercept SMS 2-factor Auth.

The really secret stuff is stored inside of the SIM card in the form of an authentication key. The ICCID is not really very secret at all, it just uniquely identifies the SIM card but provides no way to perform the authentication process without the authentication key.


How dangerous is an unsecured printer to a network? I have booted up a brand new printer and me being curious I checked out it's web-interface by typing its IP address in the URL. Poking around, I notice a few things.

There is no password set for administrator account. I can go to the tab and it will say "Administrator password : Not set" (explains why I cant find a login to admin button...)
Overall weak configuration of protocols and such. I am not yet a master of all the basic protocols (but getting there, any sites you found useful would greatly be appreciated. I've been using Wikipedia) but clicking through all the settings for the protocols they were all configured without passwords and next to no security.

My question is the following:

If a company did this with their printer; rolled it in, powered it up and left it there, how dangerous would it be to the network it's connected to, if somebody found a way to exploit it? Also does the type of printer (MFP, Scanner, General printer) change how dangerous it is?

Securing a printer with a password might not necessarily help at all. Some printers may be reset to factory defaults via SNMP over the network or SNMP commands embedded in print jobs. Some printers even might provide back doors(1, 2).

Some printers have universal computing capabilities (PostScript, Java) and services that can be accessed over the network. This may give rise to vulnerabilities that affect the network itself, e.g. cross-site printing, print job manipulation, or file system access. For an overview you might read Jens Müller, Vladislav Mladenov, Juraj Somorovsky, SoK: Exploiting Network Printers.

(1) http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-0788
(2) http://cve.mitre.org/cgi-bin/cvename.cgi?name=2012-4964
(3) https://www.nds.rub.de/research/publications/sok-exploiting-network-printers/


Would my USB interface be infected if I attached and immediately detached an infected USB device? Two days ago, someone gave me their pen drive to copy some songs from. As soon as I inserted the drive into my laptop's USB interface, Windows Defender immediately warned me that the drive was infected, so I immediately removed it without opening any of the files it contained.

I have since run the Windows Defender Antivirus Quick Scan and Full-scans several times and all looks good in that it reports the threats to have been removed.

Question

However, I am still concerned about one thing: is my USB interface now infected? That is, if I insert another pen drive into it that doesn't have any virus, will that get infected too?

I ask this because the Get-MpThreat and Get-MpThreatDetection powershell commandlets from the Defender module list a link to the drive letter in their Resources property. Please see the results below.

PS C:\> Get-MPThreat

CategoryID       : 5
DidThreatExecute : False
IsActive         : False
Resources        : {file:_E:\Removable Drive (8GB).lnk->[CMDEmbedded], file:_E:\Removable Drive (8GB).lnk->[CMDEmbedded],
                   containerfile:_E:\Removable Drive (8GB).lnk}
RollupStatus     : 1
SeverityID       : 5
ThreatName       : Worm:Win32/Gamarue!lnk
TypeID           : 0

CategoryID       : 34
DidThreatExecute : False
IsActive         : False
Resources        : {file:_E:\ \aacaccaeeaaceacaceaeccceaceecacaea.aacaccaeeaaceacaceaeccceaceecacaea}
RollupStatus     : 1
SeverityID       : 5
ThreatName       : VirTool:Win32/CeeInject.XX!bit
TypeID           : 0

PS C:\> Get-MpThreatDetection

ActionSuccess                  : True
AdditionalActionsBitMask       : 0
CleaningActionID               : 3
CurrentThreatExecutionStatusID : 1
DetectionSourceTypeID          : 3
InitialDetectionTime           : 07-12-2019 16:19:03
LastThreatStatusChangeTime     : 07-12-2019 16:19:08
ProcessName                    : C:\Windows\explorer.exe
RemediationTime                : 07-12-2019 16:19:08
Resources                      : {file:_E:\Removable Drive (8GB).lnk->[CMDEmbedded]}
ThreatStatusErrorCode          : 0
ThreatStatusID                 : 4

ActionSuccess                  : True
AdditionalActionsBitMask       : 0
CleaningActionID               : 2
CurrentThreatExecutionStatusID : 1
DetectionSourceTypeID          : 2
InitialDetectionTime           : 07-12-2019 16:18:36
LastThreatStatusChangeTime     : 07-12-2019 16:19:06
ProcessName                    : C:\Windows\explorer.exe
RemediationTime                : 07-12-2019 16:19:06
Resources                      : {containerfile:_E:\Removable Drive (8GB).lnk, file:_E:\Removable Drive (8GB).lnk->[CMDEmbedded]}
ThreatStatusErrorCode          : 0
ThreatStatusID                 : 3

ActionSuccess                  : True
AdditionalActionsBitMask       : 0
CleaningActionID               : 9
CurrentThreatExecutionStatusID : 0
DetectionSourceTypeID          : 1
InitialDetectionTime           : 07-12-2019 16:19:27
LastThreatStatusChangeTime     : 09-12-2019 14:48:32
ProcessName                    : Unknown
RemediationTime                : 09-12-2019 14:48:32
Resources                      : {file:_E:\ \aacaccaeeaaceacaceaeccceaceecacaea.aacaccaeeaaceacaceaeccceaceecacaea}
ThreatStatusErrorCode          : 0
ThreatStatusID                 : 106

I am running Windows 10, version 1903, build 18362.476.

With Windows Defender, if real-time protection is enabled, files are scanned before they are accessed and executed. The scanning scope includes all files, including those on mounted removable devices such as USB drives subject to your local configuration. The files are only scanned, they are not executed. As long as they are not executed, they won't infect your Windows machine (your USB interface).

For other pen drive to "catch the virus" you would need to copy the infected file(s) or you would need to have an active malware/virus already in your Windows machine doing so. As long as your Windows machine is not infected and as long as you do not copy the infected files into the other pen drive yourself, your other pen drives won't catch the virus. The usb interface itself cannot be infected other way then by infecting your Windows machine OS or your PC installed software including your Windows usb inferface driver. Anyway this would require executing the infected file first.


Sucpicious process running in CentOS server Following is the output of the "top" command. I have clipped the result. Here, I want to know the detail of the process called httpd.pl.

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    23546 user 20   0 55596 5428  808 S  0.7  0.1   0:01.52 httpd.pl

This looks suspicious for me, because when I do lsof -p 5182, it shows following output, showing that the process is opening port 39331:

COMMAND   PID     USER   FD   TYPE    DEVICE SIZE/OFF    NODE NAME
httpd.pl 5182 user   3u  IPv4 168936033      0t0     TCP *:39331 (LISTEN)

I have used few commands to find out from where it is running, but I was unable to find. I have used following commands so far:

#ls -l /proc/PID/cwd
#cat /proc/PID/environ | tr '\0' '\n'
#ps -p PID -o command

However, none of them shows the exact location. It shows / as cwd but there is no such file called httpd.pl there. Also a friend of mine told me that httpd.pl may be a fake name, because it is trivial to change a process name:

-bash-4.1# cat testing.pl
#!/usr/bin/perl
print `ps $$`;
$0="my_name_is_httpd.pl .. honest";
print `ps $$`;
-bash-4.1#

-bash-4.1# ./testing.pl
  PID TTY      STAT   TIME COMMAND
 6762 pts/0    S+     0:00 /usr/bin/perl ./testing.pl
  PID TTY      STAT   TIME COMMAND
 6762 pts/0    S+     0:00 my_name_is_httpd.pl .. honest
-bash-4.1#

Things to look at:

/proc/PID/exe may be a symbolic link to the program binary, or it may be a broken link (eg. if the program binary was deleted, or if it's a kernel process).

/proc/PID/cmdline should be the command line used to start the program.

/proc/PID/maps may contain interesting information, since programs and their libraries are usually loaded by memory-mapping the disk files involved.


What Country, State and City should I choose when requesting an SSL certificate? I am really confused about the country, state and city I should select when submitting an SSL certificate. Should I provide the location of my servers or my current home address?I can always reissue a certificate, but can this somehow cause problems in future?
This may sound as a trivial question but I couldn't find any info.

Generally speaking, in the certificate request, these values do not matter. What matters is what appears in the resulting certificate, and the certificate contents will be chosen by the CA, not by you. The certificate request is a vessel to convey your public key to the CA; that request uses a format (normally PKCS#10) that includes a space of a "subject name", but this field must be understood as, at best, a polite suggestion to the CA.

The CA, upon receiving the request, must make sure that it comes from an authenticated customer (e.g. the request is sent through a Web-based interface with client authentication), and will fill the certificate with values that characterize that authenticated customer, according to the CA certification policy. The CA might allow you to specify some of the fields through the request, but most will simply ignore the name in the request. They know it comes from you, and they will put your name.

If the CA actually lets you choose the country, state and city in the certificate (either by specifying them in the request, or through some other out-of-request configuration), then the intent is that these information qualify the organization that owns the certificate (e.g. the country, state and city where you chose to put your corporation headquarters). In any case, Web browsers won't validate any of these values, and won't show them to the user (except to users who click on two or three "show me the details" buttons successively). To sum up, the values don't really matter, but you don't want to put anything too embarrassing here because some inquisitive, nosy people could actually have a look at them.


Setting up communication between internal database and hosted web server by third party I am trying to figure out the best and most secure way to do this, if it is possible to do it safe and secure.

Small company. We have a hosted web server from a third party that serves our client web app with bare minimum of data in the database on the server. Want to start offering more features through the portal which would require developing the app to access our more comprehensive data on our internal database. Company doesn't want to put the data on the third party server.

I am thinking one way to do this would be to open the 3rd party server on the database port and only permit traffic from the office IP to that port. On the internal server, open the port for the database only to traffic from the 3rd party server IP.

1) Would this be considered a reasonably safe configuration?

I am neither a network nor security guy, so just gathering information on best practices and getting input on the setup.

I know there can is IP spoofing where an attacker can make their IP look like anyone else's. They'd have to know what IP is exempted beforehand. However, an authentication key between the servers can be setup so even if the IP was spoofed, both ends of the connection would need the key.

2) Would this just be an SSH key?

EDIT 1:

To be perfectly frank, no on at the company is a real understanding regarding security. The don't want our sensitive data on a 3rd party server because they think it is just floating around for anyone in the aether to grab. Basically like googling 'Microsoft', or something, someone can just be like 'my_company data' and get our data. The other reason is practical. The data needs to be immediately available as we are constantly working with it. Having to upload and download from a remote server would be slow and get annoying really quick.

Also, I should add this does involve sensitive information that should not be made public. What it is if a client wants to calculate the 65th percentile for a given item, that request gets sent from the client web app running on the 3rd part server to the internal database where the raw data is to calculate the percentile. The result is sent back to the client web app and presented there. They shouldn't have access to the data directly because it is confidential.

That being said, I was reading about REST API's a little. Some of what I was reading was saying that REST API's may not be the best when sensitive information, or authentication, is required and that SOAP should be used.

Would this be considered a reasonably safe configuration?: No.

The hint here is Company doesn't want to put the data on the third party server. I assume there are good reasons for that. The problem is that if you directly let the web server on the remote host directly access your local database, it just means that the external server gets a direct access to you internal database server.

Database servers are honestly secured, but they are not meant to be direcly under the threat of direct attacks. So when you ask about best practices, this is not one. Definitely.

The correct way would be to build a minimal REST web application in a DMZ inside your internal network. It should be accessible from the external server that will send requests to it, and this relay will has direct access to the internal database. You have to apply standard rules (SSL) to secure the communication between the remote host and the relay, install the minimum on the relay (the more software, the higher risk), and allow as few users as possible to access it.

That way even if an attacker could take control of the remote host, he will still have to pass the local relay before directly being able to attack the database. Ok the requests could already be harmful, but IMHO far less that a direct access.


Guid salt - string vs bytes[] Recently I got into passwords hashing (SHA256, HMAC-SHA1, PBKDF2, etc.) and one "statement" I've been reading over and over again, stuck in my mind and I can not find a satisfying answer.

"When we say “Guid” above, we mean “the 16-byte array representing a Guid” – not “Guid string form”." from (http://securitydriven.net/)

What is the difference behind using GUID as a salt as the 16 bytes array it is (.NET) and concating a GUID in string format (which in UTF8 is 36 bytes) to the plain-text password and initialize the hashing process afterwards? And why is the first mentioned considered more secure?

Simply put, you want to maximize the amount of entropy for a given length of data, when doing most cryptographic tasks.

You have (at most) 16 bytes of entropy in your GUID - probably less (some of the bits are deterministic), but we can ignore that detail for the current discussion. When using the GUID's byte[] representation as a salt, you have 16 bytes of data. That's at most 16 bytes of entropy / 16 bytes of data = 1 byte of entropy per byte of data, assuming a completely random GUID. Now assume that you use the string representation. That's 36 bytes of data, but still at most 16 bytes of entropy. That results in less than half the entropy per byte of data (about a 0.44 entropy/data ratio compared to the compact byte[]), which is problematic for some hashing algorithms.

When might this come up?

To take a contrived example (just off the top of my head - I would not actually recommend doing this), consider bcrypt. bcrypt is a password hashing algorithm which, for technical reasons, limits the password to 72 bytes. It does include its own salt, but let's suppose for the sake of argument that you don't trust its salt (again, this is not advice, just an example).

So, you decide to prefix the user's password with a GUID, before feeding it into bcrypt. If you've used the byte[] version, that shortens the effective upper limit on password length by 16 bytes. So, the user can supply a 56 byte password, at most. That's fine - that's still more than 50 ASCII characters, which is a common length people use when they've got a password manager and are a bit paranoid.

Now, let's suppose you had used the string version instead. You've still got the same amount of entropy, but now, you eat up 36 bytes that the user could have been using to pad out their password. They're now stuck with a 36 byte password at most.

And that's just an example off the top of my head; I'm sure there are other cases where using the string version would hurt you.


What happens to data in the Secure Element when a device is Jailbroken? I want to store a key in the SecureElement within a non-Jailbroken device.

What happens when a device is Jailbroken? Knowing that the private key can't be extracted, can the key be used to sign or encrypt date when it transitions from non Jailbroken to Jailbroken state?

Is the Secure Element Cleared/Erased? Cryptographically inaccessible?

Are you asking about iDevices running Apple iOS? The Secure Enclave is not cleared/erased or inaccessible when a device is jailbroken.

The architecture of the Secure Enclave and its security implications is documented here -- http://mista.nu/research/sep-paper.pdf -- and many assume it has been broken into, but nobody is saying for sure. Here is the full prezo from BlackHat US 2016 -- https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf

There are other components, such as the Kernel Patch Protector (Apple's use of TrustZone), which was thought to reside in the Secure Enclave but it actually on the ARM Elx -- http://technologeeks.com/files/TZ.pdf

Here is an early article on the Secure Enclave as we first saw it in the iPhone 5S -- https://blog.fortinet.com/2013/09/16/iphone5s-inside-the-secure-enclave

What we know today is that the apps that connect to the Secure Enclave can be bypassed in many ways, but not in one key way: the TouchID mechanism to access the device through the lock screen -- but only the lock screen. If TouchID is used via an app, then it likely can be bypassed whether the device is jailbroken or not.

Some of the Apple TouchID and Apple Pay security architecture was first discussed here -- http://www.slideshare.net/0xroot/demystifying-apple-pie-touchid

What we know is that the GlobalPlatform AIDs (application identifiers) can be cloned from one device to another by attaching to the passd process (this can also be done on a jailed or jailbroken device), as discussed here -- https://www.blackhat.com/docs/us-15/materials/us-15-Fillmore-Crash-Pay-How-To-Own-And-Clone-Contactless-Payment-Devices.pdf -- https://www.blackhat.com/docs/us-15/materials/us-15-Fillmore-Crash-Pay-How-To-Own-And-Clone-Contactless-Payment-Devices-wp.pdf -- https://infocon.org/cons/SyScan/SyScan%202015%20Singapore/SyScan%202015%20Singapore%20presentations/SyScan15%20Peter%20Fillmore%20-%20Crash%20and%20Pay_%20Owning%20and%20Cloning%20NFC%20Payment%20cards.pdf

We also know that the keychain can be dumped in numerous ways for both jailed and jailbroken devices as seen here -- https://github.com/juuso/keychaindump -- and here -- https://github.com/n0fate/chainbreaker -- but also iCloud and other authorization tokens -- https://github.com/manwhoami/MMeTokenDecrypt

Most-everything can be extracted regardless of the Secure Enclave and regardless of the device being jailed or jailbroken.


'Trusted CA Certificates' and 'Trusted remote Certificates' What is the difference between Trusted CA Certificates and Trusted remote Certificates?

Trusted CA certificates are validated by a third party, called Certificate Authority. In a cryptographic sense, CAs are a trusted third party (TTP) validation authority in a public-key infrastructure (PKI):

  The primary role of the CA is to digitally sign and publish the public
  key bound to a given user. This is done using the CA's own private
  key, so that trust in the user key relies on one's trust in the
  validity of the CA's key. When the CA is a third-party separate from
  the user and the system, then it is called the Registration Authority
  (RA), which may or may not be separate from the CA. The key-user
  binding is established, depending on the level of assurance the
  binding has, by software or under human supervision.

In a nutshell, they provide for an easier to establish trust of a client to the server they're connecting to, and the root certificates (CA public keys) used to verify such CA issued certificates come pre-installed on many web clients (browsers, email clients,...) by default, meaning they can be used in a transparent way, where no additional user interaction is required.

The assumed levels of end user's trust in connecting to the right server usually boil down to what is called certificate validation type:

Domain validated certificates: These are most frequent, mainly because they're usually the cheapest CA issued certificates. These are usually validated by sending an authentication token via email to the CA that issues the certificate, and are only validating what their name implies - that the user is really connecting to the domain that the certificate was issued for.
Organisation validated certificate: These certificates carry an additional information about the organisation they're registered to, and in some cases that can be helpful in establishing required trust. Most web clients don't assume much greater trust in such validated certificates than domain validated, and don't visually differentiate between them either.
Extended validation certificate: As the name implies, these certificate type owners are most rigorously validated. They are not cheap and are supposed to provide for the highest levels of trust of the end user that the certificate owner is indeed the one they're supposedly connecting to. Criteria for issuing such certificates is described in more detail here. An added advantage is, that they're also clearly marked in most web clients by a green address bar, a green lock, or similar.

Now, what you describe as trusted remote certificate is also known (or perhaps better known) as a self-signed certificate, that the end user manually installs to the list of trusted certificates in web clients they use to communicate with the server that issues them. That is, provided they trust the issuer of such a certificate, since they don't provide for any third-party validation of its owner of any sorts whatsoever. They are still useful, as they can be used to encrypt the communication between the client and the server (most commonly for transport layer encryption), but the trust level is something left to the end user to decide. Such certificates are of course free (i.e. can be signed by open source tools, such as e.g. OpenSSL).


How are SHA1 and MD5 considered to not protect against collisions? SHA1 and MD5 hash functions are considered to not protect against collisions while SHA2 is.
Is it the size of the message digest that makes this or the algorithm itself?
If it is based on the message digest why did it take longer for the MD5 to be proven that it does not protect against collisions than SHA1 given that SHA1 has a bigger message digest?

It also has been shown by Christophe De Cannière and Christian Rechberger in "Finding SHA-1 Characteristics: General Results and Applications" where a 64-round SHA-1 was presented, found using unoptimized methods with 2^35 compression function evaluations. It still needs to proceed to the full 80 round of SHA1 to be complete but it still proves that collisions are really really possible.

So more or less what creates the collisions? Is it only the message digest? What is the reason in choosing MD5 over SHA1?

I hope I am not asking too many questions in one

The Algorithms are broken : We can manually generate false certificates given only the md5 signature, for instance.

Many weaknesses have been found is SHA-1 to this day, but as far as I know, you can't yet generate a false certificate matching a SHA-1 hash. However, it is being considered obsolete, security experts think this weakness may soon come, and are banishing SHA-1-signed certificates by 2016

Also, optimizing SHA-1 calculation is not cool : it eases bruteforcing a SHA-1 hash. As I found on the internet some time ago, "Hash algorithms are like sex : Faster is not better"


Can someone use WiFi snooping to see data I send through Tor Browser when I'm not using SSL? (NOTE: I've read other similar questions, but I'm not at all certain about this, therefore I'm asking.)

I travel a lot, and I generally use public WiFi spots and hotels/hostels/boarding houses etc. access points.

I'm a reporter. Sometimes I send my communications to email services and websites which don't use SSL cryptography (no https, just http), and though I KNOW this is not smart, I have no alternative.

What I want to know is if someone locally sniffing the network could read what I send to unprotected (no https) websites. If I send multimedia, pictures, audios etc., can they see/listen to them? Can they see what sites exactly I'm loading?

If so, what would take them? Just being connected to the same network? Having direct access to the router?

Is there anything I can do about it?

Again, I'm talking about people using the same network, snooping locally, and thinking about the data just after it leaves my PC and after it leaves the end node.

Thank you!

When you use Tor, all data is encrypted between your computer and the exit node. As long as the exit node isn't on the same network that you are on (very, very unlikely to occur), the data will be protected from the local network. Note that meta data such as the fact that you're using Tor and rough estimates of how much data you are communicating may be observable, but the contents of that data will not.

As you are talking about using unencrypted communication, the clear txt data will be completely exposed from the exit node onward. Perhaps the biggest threat here is of a malicious exit node snooping or even modifying your data.


Understanding the security of a federated public key scheme using WebCrypto I am proposing this scheme for federated authentication and WebCrypto. I am not sure if something like this (or better) exists, please do send me related material.

Entities

Alice's Browser, BROWSER
Bob's server, BOB
Alice's server, ALICE

Background

Identities are domain names and each server has access control list on each resources.

Bob writes in the access control file "alice.com" can read "/foo"
Alice wants to read foo

Protocol

tl;dr version:

Alice's Browser tries to access a resource on Bob's server, Bob replies with unauthorized message and a nonce
Alice generates a key in her browser with webcrypto and keeps that in memory
Alice uploads her key on her website
Alice signs the nonce, the address of bob server and the address of her key
Bob receives the message and checks if the location that alice mentioned has the public key that verifies the signature

Diagram

1. Alice's Browser tries to access a resource on Bob's server

BROWSER   -------------- GET /foo ---------------------->  BOB
BROWSER   <------------- RESPONSE 401 {nonce} -----------  BOB

2. BROWSER uses WebCrypto to generate Pub/Priv key pair

3. Alice's post her new key on her server

BROWSER   -------------- POST /keys/nonce -------------->  ALICE
                         { Pub }
BROWSER   <------------- RESPONSE 200 -------------------  ALICE

4. Alice's Browser signs the location of the key, the nonce and
   the Bob's Server origin

BROWSER   -------------- POST /foo --------------------->  BOB
                         Sign(location, nonce, bob)

5. Bob's server gets the advertised location

          BOB -------------- GET /keys/nonce --------------->  ALICE
          BOB <------------- RESPONSE {Pub} -----------------  ALICE

6. Bob's server verifies the signature

BROWSER   <------------- RESPONSE 200 -------------------  BOB
                         {set cookie}

Questions

Is there any pitfall I am not seeing?
Can any attack happen in point #4 of the diagram?
Does this scheme exist or have a name?

What you are describing is very similar to PoP/RFC7800 (Proof-of-Possession Key Semantics for JSON Web Tokens). (It's also somewhat similar to what AC/DC (Authorization Cross Domain Code) is trying to do.)

With PoP, the proposed steps 1 & 2 are the same: BOB (called Recipient) issues a nonce with the 401 response, Browser (called Presenter) generates a Public/Private key pair to send to the server ALICE (called Issuer).
Step 3 is also very similar - Browser/Presenter sends the request with the public key to ALICE/Issuer.

PoP and your proposed protocol diverge slightly after Step 3 -- whereas you're storing the public key + signed nonce on ALICE's server, in PoP, ALICE/Issuer simply signs the public key and returns it in the response (in a JWT). The Browser/Presenter then forwards the JWT from the Issuer, adding the nonce (which it signs itself with its private key), to the Recipient.

The Recipient can then verify several things: a) that the Browser/Presenter is the one that received the initial nonce (this prevents client token hijacking), and b) that the Browser/Presenter really holds the JWT signed by the Issuer.

  Is there any pitfall I am not seeing?

Both your proposal and PoP accomplish the following:

They protect against client token hijacking by verifying that the Browser/Presenter is the same one that received the nonce in the original 401 Unauthorized response.
They verify that the Browser/Presenter was authenticated correctly to the Issuer -- with your proposal, because the Issuer permitted the POST to /keys/nonce, and with PoP, because the Issuer returned a JWT, signed by itself, that included the browser's public key.

What your proposal does not address is the following important issue:

Given that you're talking about an in-browser application (the Browser/Presenter), how does that application authenticate with ALICE/Issuer? That is, given that the Issuer accepts a POST to /keys/nonce, presumably it has verified the client and has authenticated the user. But how? OAuth2 and OpenID Connect (with which PoP is designed to work) have very specific mechanisms for authenticating public (in-browser) client apps to the Issuer, with redirect protection and so on, because it's not an easy task, and prone to a lot of security holes.
It's likely that you're intending to use some sort of cookie mechanism, but if the browser-side app/Presenter is running from a different origin than the Issuer, how is the issuer going to authenticate it?

This is relevant for in-browser apps, but also especially relevant for native apps, mobile apps, or traditional server-side web applications. How does the proposed scheme attempt to address authentication with those?

  Can any attack happen in point #4 of the diagram?

Not that I can see, although you don't even have to do a POST here, you can do a plain GET and include the Sign(location, nonce, bob) part in the Authorization: header, bearer token style.


Is there a term for a "Master + extension" style password scheme? I personally have (and preach) a password system using a "root" password shared amongst many passwords, plus a unique password component.

So for Gmail my password might be correcthorsebatterystaple + F00@$DF and for another application it would be correcthorsebatterystaple + 3p1cp@$$w0rd. The idea is you get a large amount of entropy out of the root password while easily remembering it (because it's always the same), but since it's not all of the password, if someone has one of your passwords, they still don't have them all. The unique part of the password is easier to remember because it can be shorter while still a very large character count and large amounts of special characters.

Is there a term for this sort of root + unique password scheme?  I'm trying to look for good articles about it or any potential pitfalls of it but I have no idea how to refer to it. It's also very hard to explain at first.

I don't really know if there is a term for that. But I propose Smurf passwords.

As an adaption of the term Smurf Naming Convention. Seen on New Programming Jargon, jargon No. 21, by Jeff Atwood.

Note that this term has (IMO) no negative connotation, and it is kind of funny, so it would be easier to remember it


Where is the TOTP secret key stored on client applications? I'm new to concept of TOTP, but as I understand, 16-character base32-encoded shared secret is stored in the client application(for example Authy, FreeOTP)? This means that if I remove the application, the key is lost and I can no longer generate my one-time passwords?

For the Google Authenticator app on Android, the shared secret is simply stored inside a SQLite database file that can only be read by the Google Authenticator app. If you have a rooted Android device, you should be able to view that file and the secret it contains easily.

As for other apps or other platforms, I am unclear about the implementation but I would be surprised to see if it's stored in any other fashion.


Is data exposed in a CSRF attack? I am wondering wether a CSRF attack, will disclose the information being sent back in a GET request.

I need to send a social security number out, to the client a few times, and it is NOT anyone else should ever be able to receive. The data is guarded already by HTTPS, but I know that won't stop a CSRF attack.

The request itself will not change anything in the application, but the data must not leak.

How can this be exploited? And what measures can I take to prevent it?

A CSRF attack means that a website tricks a user into making a page request on another website they didn't want to make. This can be used to trick the user into performing an action on that website they don't intended to perform.

I could, for example, ask you to click this amazing link (really, it's cool!), and accidently cause you to delete your account on example.com (just an example - there is no such script on example.com). When I would have more control over this website, I could use a script- or HTTP redirect, so no social engineering would be necessary. But any response to that action would be sent to you, not to me. That means when the action is non-destructive and only reads information without changing it, a CSRF would be pointless. In the worst case the user would wonder why they are suddenly redirected to the website showing their social security number.

But there is one way for a website to gain information from a different website in the context of the user: xmlHttpRequest. Normally, same origin policies apply and prevent xmlHttpRequests from crossing domain-borders. But this restriction can be overridden by the Cross-Origin Resource Sharing settings on your webserver. When you accidently enable CORS for the other website (or all websites), they can send requests in the context of your users to your website and read the response. When you want to know how to check or change the CORS configuration on your webserver, refer to its documentation.


Risks of exposing .htaccess file I have an Apache server on Windows 7 using XAMPP running php in cgi mode. One of the users can modify the .htaccess file to restrict the access to the webpage for some ip addresses and configure other settings. He cannot view the source of the php files stored in the server, and I don't want him to be able to do it.

Since php is running in cgi mode, adding php_flag engine off to the .htaccess file does not show the source code of the php files, it just displays an internal server error. However, I am concerned that there might be another way to access the source of my files.

Is there any way to view the source of the php files modifying the .htaccess file if php is running in cgi mode and php_flag does not work?
In case there is some way to view the source, can I fix it or the only option is to use an alternative solution and not exposing the .htaccess file?

Yeah, you have risk exposing the .htaccess file to other user which are not in your trust circle although you are using php in cgi mode but I am not sure how capable are other user out there. For example rule like this expose your php code in text.

<FilesMatch "\.php$">
    SetHandler text/plain
</FilesMatch>

So what I suggest is don't give full permission to .htaccess only give permission to module which are requested or necessary.

For example don't allow modules  such as mod_mimes, indexes etc to other user.

Don't use

AllowOverride All

Instead mention module which you want to permit

AllowOverride AuthConfig mod_rewrite

Hope it helps.


How to verify if router firmware is legitimate I have read that router firmware is supposed to be patched. How do I verify that the firmware update is indeed a unmodified version of the firmware?

I know about signature checking, but how would I do this in regards to my router?

There is no generic way to check if a downloaded firmware is the original one. A vendor might provide tools for this or not. But a properly designed update process would already include that the firmware is signed and that the signature is checked by the router. This does not mean that the update process for your particular system was designed as such. For specific information please refer to the vendor of the product you use.


What's the safest way to enter information on a website? On-screen keyboard you have to work with a mouse? Copy and paste? Type a string of random characters and then delete the extraneous ones? Something else?

On-screen keyboards are not a solution as any key logger may even capture screenshots, which defeats even randomized on-screen keyboards. (source)

  The bottom line is simply this: you should never assume there's a way
  to bypass keystroke loggers. They could easily be more sophisticated
  than your attempts to work around them.

  By far the only sure way to deal with keystroke loggers is simply not
  allow your machine to be compromised in the first place.
  (source)

Probably one of the best ways to protect yourself is to be sure that whatever you are running is free from loggers. For example, you could use a live DVD (easy and cheap).

There is an upcoming "kickstarter" product that seems to simplify that process by embedding a micro board inside a keyboard, which can be booted instead the current OS or in a container inside the current OS:

  SilentKeys is a Plug'n'Play USB keyboard that
  protects you both off-line and on-line. Keep control over your privacy
  and safeguard your computer from viruses, snooping and hackers.
  Protect your keystrokes from key-loggers. Go anonymous at the push of
  a button. Encrypt your data and safeguard access to Paypal, Facebook,
  bank as well as all your on-line accounts and credentials.

https://www.kickstarter.com/projects/preevio/silentkeys-a-keyboard-that-protects-your-privacy-a

I'm still not familiar enough with that project so I can not recommend it nor explain more details about it. I just thought its interesting (I'm not in any way related to that project).

NOTE: My answer is based on the idea that you are looking for a solution in which you can't trust the computer which you are using (like in a public place). If you are talking about your own personal computer, then I would strongly suggest you to use Linux and install tripwire. That piece of software will notify you if any of your OS files is modified in any way. It may not be 100% effective against in-memory key-loggers but it gives you a greater knowledge over what is being modified in your system without your consent.

Update (2019)

Some years have passed and re-reading my answer, I feel that I'm missing some important points:

There are software and hardware keyloggers. Software keyloggers can be deployed remotely to any device (not just public computers), so your best protection (which is not 100% safe) is to keep your devices updated, validate downloads checksum, do not install anything that you don't know, avoid using devices or connecting into networks that you don't own or you don't trust, etc.

If your device has an infected BIOS, and if we assume that the malware is able to "see" everything you input, none of the methods suggested in this answer would keep you safe.

Now, about hardware keyloggers, those are more difficult to deploy. Even the "DVD" method won't protect you if the keyboard has been tampered. If we go deeper into hardware, we can talk about the possibility of using malicious chips which could potentially steal information.

Bottom-line: Hackers get more creative with the years so the best thing is always assume you may be hacked and your passwords stolen. Have a backup plan and don't keep everything in the cloud.


How is an authorization server supposed to require client auth for confidential clients? The OAuth2 password grant_type states,

  If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.

Let's assume that I have both confidential and non-confidential clients. This seems like a very plausible assumption: I have some third-party developers, who run server side applications, and they are thus issued a client_id & client_secret pair; I also have a mobile application and a web application; obviously these can't keep the client_secret confidential, as they're published publicly.

So, in the case of a public client w/o a client secret, the above "If the client type is confidential" is false, and they don't authenticate with the authorization server as described by §3.2.1.

However, as a server,

  The authorization server MUST:

  require client authentication for confidential clients or for any client that was issued client credentials (or with other authentication requirements),

Okay, but given that the above text means that only confidential clients will send their credentials, how is this possible? If I don't see credentials on the request, how do I, as an authorization server, know that this is a public client, as opposed to a confidential client that has failed to supply authentication?

Note that in "OAuth2 Simplified", there is an example grant_type=password request that includes a client_id, but not a client_secret; does OAuth require that at least a client_id is always specified during grants? (And thus, the authorization server could identify the client, and thus, whether they need to fully authenticate.) Does the RFC state this anywhere?

According to section 2 - client registration a client is registered with the authorization server before initiating any of the flows.

Client registration includes specifying the client type (confidential or public), and is subsequently assigned a client ID. So when the authorization server receives a request for a given client ID, it knows whether it is confidential or public.

For authorization code and implicit grants, the client ID is a required field.

Use of password credentials grant is not recommended, and does not actually require client ID - I mean you're passing your actual credentials directly to the token endpoint, who cares about client ID or client secret!


Site is being redirected to Viagra store; all the usual suspects turn up nothing I have a client's site (http://changewise.biz) being redirected to a Viagra store (mywifeishappy.com). We've gone through all the usual suspects but cannot find the culprit that's causing the redirection:

First thing we checked all the .htaccess files; all clean.
Checked robots.txt; again, nothing.
Checked all 522 PHP files for malicious code (this is a WordPress site running at RackSpace); we did find a line of code that has a base64decode of some code in the wp-options table of the site. 76 instances of this, all of which were removed, with still no joy.
Went to Google Webmasters to have Google re-index the site, in case it was holding faulty index data about the site; this may take a while.

What's strange is that when I access the site via its direct URL in my browsers (http://changewise.biz) I see it fine. When the client does this in his browsers, the site ends up at Viagra. And - when both of us Google "changewise" and click the link that Google returns in its SERP, the site is redirected to the Viagra store.

Anyone with any ideas about this? I've spoken to RackSpace tech support and they can't offer any ideas; they don't see any other vulnerabilities in the hosting setup. Client is very frustrated, as am I.

I noticed that from a Google search, if I take the referer (www.google.com) out of the web request to changewise.biz, it does not redirect to the spam site.

If I do not take the referer out, I get the spam site (and subsequent requests always get it since it is then cached in the browser).

So I think it is not faulty old Google data, but something in your site that looks at the referer.

Your site is serving the following http response when refered from google.com:

HTTP/1.1 301 Moved Permanently
Server: Apache/2.2
Content-Type: text/html; charset=iso-8859-1
Date: Fri, 25 Apr 2014 14:10:26 GMT
Location: http://mywifeishappy.com/
Connection: Keep-Alive
Content-Length: 305

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<title>301 Moved Permanently</title>

Moved Permanently

The document has moved here.

<address>Apache/2.2 Server at www.changewise.biz Port 80</address>


How safe is your data when it passes from your laptop to your 4G wifi hotspot? I would like to create a private mobile hotspot on my smartphone that I will connect to with my laptop to do online banking.  My laptop will connect to my smartphone wirelessly, then my smart phone will transmit the data over the 4G network.

I use my (Android 8.0.0) smartphone quite liberally when it comes to surfing the web.  I don't navigate to any obviously dangerous/obscene sites, but I use it browse various sites like reddit, imgur, facebook, article sites, forums, etc.

I have a paid subscription to BitDefender which I use to scan my phone for malware.  What I'm worried about is potentially having some virus or malware on my phone that will spy on my laptop's data as it 'passes through' my phone before being put on the 4G network.  Is this possible?  Or is my laptop's data already encrypted before it arrives on my phone and thus 'shielded' from any potential malware on my phone?  Is the latest version of Bitdefender a reliable form of protection from my concerns?

For Wi-Fi using the standard WPA2 Personal encryption, any device which knows the PSK (password) will be able to both sniff and inject data for any other device connected to that network. This means that a mobile phone, if connected to the same AP, will be able to tamper with connections from your laptop.

However, if you are connecting to a banking website which is using HTTPS, then it may not be a risk. If that is the case (which it really should be), then encryption will take place between your browser and the bank server, and your mobile phone will not be able to read or tamper with the connection.


Can I intercept and impersonate a server over an HTTP wireless connection? Let's assume I have a strong enough antenna at exactly the same frequency as the victim. If it sends a request over unprotected http to the router, could I then listen to that request and respond to it before the router does? Would I need the MAC address of the victim too?

You can set up your own compromised AP that poses as the original AP, often called Evil Twin. If you can make the victim connect to yours instead of the real one, maybe by  DoS'ing the legitimate access point (AP), then you will have control over any traffic the victim produces. You can see this in action in this video by hak5.


Token-only vs. login-token authentication While working on the auth schema for my application's API, I had a question pop in my head.

Is there a difference between authenticating by token alone, or by a login-token pair? Right now, my token generator does use the user's login, and that's why I've been thinking about a single parameter in the API request responsible for the user's logging in.

However, while not being an infosec expert, I can't help but think that this might be less secure than asking the user for both his login and his token, as in theory a malicious user, coming into a possession of someone else's token might be able to use it.

Another factor in this is that the specifications require the tokens to provide permanent access, as in they cannot expire.

So to re-iterate:
is a login-token pair being required with a request going to provide more security opposed to the token being the only required thing?

Edit 1: It seems to me also that if I were to use the pair, it would be too much like regular login-password auth. Am I wrong in thinking that?

If you are using tokens to provide permanent access, then tokens are not very different from your userid. They become even less secure than a normal password because the user at least has an option to change their password regularly.
As for login token pair vs token being the only required thing, I am borrowing the accepted answer from a related question: Two passwords from one account

Not really. It's essentially one password, with a press of the return key as one character.
It adds complexity to the log in process, which isn't generally a good thing (users would probably choose one good password, and one quick to type password). Don't forget @AviD's rule: "Security at the expense of usability, comes at the expense of security"
Depending on how the passwords were stored, they would slightly decrease the ability of attackers to brute force accounts, since an attacker would need to break both parts. I doubt that this balances out the usability issue though.

Answer to your Edit, yes. It will be similar to regular login password authentication.


DNS packets during ARP poisoning I carried out an arp poisoning attack from my virtual machine to real machine with cain and able and collected data with wireshark from real machine. While I was investigating data with wireshark I came across a data flow as picture.

What does it mean? I was expecting only an ARP storm. Can I use information in this picture to detect an ARP poisioning attack? Or cain and able using a different trick?

In short, that scan doesn't show you any layer 2 information. You're interested in what MAC address the computer associates with a given IP address.

ARP poisoning affects network layer 2, or the ethernet layer. While the computer still sends the message to the same IP (layer 3) address, the packet ends up at a different layer 2 address which is purporting to own that IP. It purports to own that IP address by poisoning ARP in an attempt to associate that IP with a different MAC address.

Once that computer has, for example, taken over the IP of the DNS server it can serve invalid DNS records or any other devious service it wishes to run.


Suricata - How to use TCP Flags? I wrote the following rules:
alert tcp any any -> 192.168.6.4 any (msg:"SYN"; flags: S;)
alert tcp any any -> 192.168.6.4 any (msg:"FIN"; flags: F;)

The SYN rule is matching. The FIN isn't. I can't find a part in their documentation for TCP Flags.
I want to detect packets, where the SYN,FIN,PSH,ACK flags are set. How do I do that?

alert tcp any any -> 192.168.6.4 any (msg:"FIN"; flags: F;)

flags: F matches packets where the flag is exactly FIN.
But if you want to match the end of the connection you usually encounter packets which have both FIN and ACK set - so your rule does not match. To match packets where at least FIN is set but other flags might be set to use flags: F+.

I want to detect packets, where the SYN,FIN,PSH,ACK flags are set. How do I do that?

To match exactly this combination use flags: SFPA


Using a minimal set of certificate authoraties It been known for quite a while now that SSL is more of a security-illusion than a real one.

As it's not completely useless, and there's no real alternative at moment (though convergence looks interesting), I'd like to try using a "minimal" set of CAs, assuming that the biggest 3 will cover ~70% of the internet, and all common websites in particular.

My question is:
Is there such a minimal CA set?

Short answer: No.
I think you won't be happy with only three CAs. Lots of clicking around certificate warnings. This will not make your browsing safer.

Also reconsider what you are trying to achieve. I'm assuming, that you want to protect yourself from rogue and/or exploited CAs. So that means CAs that will issue certificates for google.com, etc, when Google never asked them to do that. And those certificates could then be used to eavesdrop on google.com visitors.

So, yeah, if you exclude obscure Dutch/Turkish (re. DigitNotar hack, re. Turktrust hack) CAs from your trust store, then you won't be affected if that CA is hacked. -- As has in fact happened in the past.

What you won't be protected from, is if a Sub-CA, subsidiary or reseller of your trusted CAs is hacked. This has also happened in the past. (Comodo Brazil for example.)

So what will help now?
What will however protect you, is if you use a browser, that supports certificate pinning.
Like Google Chrome for example. They have built in "Pin-Sets" for certain sites. (Google, Facebook, Twitter, etc.)

They will not a allow a certificate issued by other than a few trusted CAs to be accepted.

What workarounds exist, but are too bothersome?
What I tried for a while is the "Certificate Patrol" Firefox extension. (Last updated in 2011.)
It alarms you, when you see new certificates for a site. And then asks you to answer yes or no.

I found it too noisy to be useful for me.

There is a nice write up in chapter 5 of this PDF here:
2013-12-03, Mariana Isabel Oliveira Taveira & Thiago Sobral Marques da Silva,  SSL Certificates and HTTPS -- Issues in the current Web Trust Model for Digital Certification

What might help in the future?
What might also help in the future is "Certificate Transparency". Where the concept is that even though fraudulent certificates may be generated, at least there will be an audit trail.

And that certificates without audit trails are rejected right away. The idea being that when a CA hack is discovered:

(a) the cleanup can be done much easier. All issued certificates are in the audit trail and can be revoked in bulk.
(b) this may make it easier to discover a CA hack in the first place. As all audit trails are public.

CT is in the process of being phased in -- again leading the effort is Google Chrome -- but it is not being enforced anywhere yet.

That being said, if you really want to go ahead and create a 3-CA-trust-store then read on below.

Three largest CAs: Comodo, Symantec, GoDaddy
This article says the three largest surveyed (what ever that means) are Comodo, Symantec and GoDaddy.

W³Techs.com, Usage of SSL certificate authorities for websites (Archived here.)

So you could try to make your minimal CA set with those three CAs.


Strange certificate in keychain I've found a strange certificate in osx keychain.

I don't remember installing it and it is marked as "it was signed by an unknown authority".

It was installed in my login keychain and it "seems" to be related to Akamai, but it doesn't seems to be correctly signed at least...

Is it possible to have it installed by error? As it wasn't set to "always trust", can have it been used by applications without showing an error? Is there anyway to see its installation date?

It is possible that some software that you might have gotten from the torrents or another pirated source installed that certificate onto your computer. It is not impossible since you would be providing your root password during installations.

Yes, it is possible that you installed it unknowingly. But no, without having "always trust" set, it would ask you for authorisation every time, or so it should!

I doubt it is possible to figure out when the cert was installed.