Is it safe to use flex and bison as a protocol parser? I started writing a a simple protocol lexer and parser for STOMP using flex and bison. Does anyone know of any security issues that might result from this?

Edit: Added code.

%{
 /* Tokenizer for the STOMP 1.2 protocol. */
%}

%%
 /* Client commands. */
"SEND"                          return T_CLIENT_SEND;
"SUBSCRIBE"                     return T_CLIENT_SUBSCRIBE;
"UNSUBSCRIBE"                   return T_CLIENT_UNSUBSCRIBE;
"BEGIN"                         return T_CLIENT_BEGIN;
"COMMIT"                        return T_CLIENT_COMMIT;
"ABORT"                         return T_CLIENT_ABORT;
"ACK"                           return T_CLIENT_ACK;
"NACK"                          return T_CLIENT_NACK;
"DISCONNECT"                    return T_CLIENT_DISCONNECT;
"CONNECT"                       return T_CLIENT_CONNECT;
"STOMP"                         return T_CLIENT_STOMP;

 /* Server Commands. */
"CONNECTED"                     return T_SERVER_CONNECTED;
"MESSAGE"                       return T_SERVER_MESSAGE;
"RECEIPT"                       return T_SERVER_RECEIPT;
"ERROR"                         return T_SERVER_ERROR;

 /* Other tokens */
\x00                            return T_NULL;
\x0A                            return T_LF;
\x0D                            return T_CR;
[\x0D]?\x0A                     return T_EOL;
:                               return T_COLON;
[0-255]                         return T_OCTET;
 /* (T_OCTET - (T_LF + T_CR + T_COLON)) */
[\x00-\x09\x0B-\x0C\x0E-\xFF]   return T_SPECIAL;

%%

%{
 /* Parser for the STOMP 1.2 protocol. */
 #include <stdio.h>
 #include "../client_protocol_stomp.h"

 extern stomp_node_t stomp_frame_root;

 void yyerror(const char *str) {
     fprintf(stderr,"error: %s\n",str);
 }

 int yywrap() {
     return 1;
 }

 int yylex(void);
%}

%defines
%error-verbose

/* Tokens for header file generation. */
%token T_CLIENT_SEND T_CLIENT_SUBSCRIBE T_CLIENT_UNSUBSCRIBE T_CLIENT_BEGIN
%token T_CLIENT_COMMIT T_CLIENT_ABORT T_CLIENT_ACK T_CLIENT_NACK
%token T_CLIENT_DISCONNECT T_CLIENT_CONNECT T_CLIENT_STOMP T_SERVER_CONNECTED
%token T_SERVER_MESSAGE T_SERVER_RECEIPT T_SERVER_ERROR T_NULL T_LF T_CR T_EOL
%token T_COLON T_OCTET T_SPECIAL

%union {
    stomp_node_t node;
}

/* Map tokens and non-terminals to fiels in the yylval union. */
/* %type <node> factor term exp */

%%
expression     : frame { /* stomp_frame_root = $1; */ }
               ;

frame          : frame_command
                 frame_command
                 T_EOL
                 frame_octet
                 T_NULL
                 frame_eol
               ;

frame_command  : command T_EOL
               ;

frame_header   : header T_EOL
               | header T_EOL frame_header
               ;

frame_octet    : T_OCTET
               | T_OCTET frame_octet
               ;

frame_eol      : T_EOL
               | T_EOL frame_eol
               ;

command        : client_command
               | server_command
               ;

client_command : T_CLIENT_SEND
               | T_CLIENT_SUBSCRIBE
               | T_CLIENT_UNSUBSCRIBE
               | T_CLIENT_BEGIN
               | T_CLIENT_COMMIT
               | T_CLIENT_ABORT
               | T_CLIENT_ACK
               | T_CLIENT_NACK
               | T_CLIENT_DISCONNECT
               | T_CLIENT_CONNECT
               | T_CLIENT_STOMP
               ;

server_command : T_SERVER_CONNECTED
               | T_SERVER_MESSAGE
               | T_SERVER_RECEIPT
               | T_SERVER_ERROR
               ;

header         : header_name T_COLON header_value
               ;

header_name    : T_SPECIAL
               ;

header_value   : header_name
               | header_name header_value
               ;
%%

Bison and flex are reasonable tools to write parsers for protocols which fit in an LALR(1) grammar; but they are just tools like, e.g., a C compiler. It is still up to you not to do anything wrong with them. For that matter, bison and flex mean that you are about to implement your code with C or C++, languages which are known to be difficult to handle properly and prone to trigger security holes, especially because of pointer aliasing issues, manual memory management, lack of decent character string handling facilities, and unchecked array bounds. These are C issues, not bison issues, but you'll get them nonetheless.

LALR(1) parsing can be a bit confusing because you tend to get the "reduce" rules on a right-to-left basis. When you write the code attached to the grammar clauses, this can make things awkward (you have to handle the leaves of the syntax tree is a mostly context-free way).

The good thing about flex and bison is that they are systematic: they will implement all the corner cases of the grammar. That's a great property for security (most of secure coding is about covering all possible cases without forgetting any).


Is this enough to prevent xss? I'm working on a website where there is going to be a lot of user generated content. As an WYSIWYG editor I'm using tinyMCE. As a template engine, I'm using ejs.
In order to prevent XSS I decided to use xss npm package.
I'm using these custom  rulles:
const strict = {
  whiteList: {},
}

const withTags = {
  whiteList: {
    div: [],
    strong: [],
    em: [],
    br: [],
    ul: [],
    li: [],
    ol: [],
    blockquote: [],
  },
}

Let's say a user uses text area and submits this code:
<script>alert("hi")</script>

In my DB it's saved this way:
&lt;script&gt;alert("hi")&lt;/script&gt;

Now, when the content is rendered by ejs some content is rendered with escaped output (<%= %>). Rendered escaped output (html page) looks like this:
&lt;script&gt;console.log("test")&lt;/script&gt;
However, some content is rendered with ejs unescaped raw output (<%- %>). Html will look this way:
<script>console.log("test")</script>
I have 2 questions:

Because < and > are escaped as &lt; and &gt; is it safe to render ejs unescaped output?
Is what I'm doing generally enough for XSS protection?

Thank you very much!

First of all your data probably isn't saved in database the way you presented. In all likelihood it's stored there without any encoding (as it should be).
EJS in itself, when used correctly, takes care of encoding output for you so that you can safely construct parameterized HTML. But in your case you want to disable this protection to render raw HTML, so yes, you must be careful. There are a couple of security controls at your disposal.
1. DOMPurify
I haven't used the xss library personally, it seems to have a lot of downloads and probably it's not a bad option. But DOMPurify is probably better. It also doesn't require configuration and has built-in support for trusted-types (I'll get to that in a minute).
You would use it twice. First on server-side when the HTML is submitted by the user, and second on client-side when the HTML is rendered by EJS.
If you are serious about security then you will connect anomaly alerts from the server-side purification to your SIEM/SOC etc. Then you will know when someone has attempted an XSS attack on your website.
2. Sandboxed Iframes
Another client-side control that you can implement is sandboxed iframes. Instead of just rendering the HTML on the page, you create an IFRAME, give it a properly configured sandbox attribute, and then set the purified HTML as the content. Now even if something goes wrong with the purification, the malicious HTML would be isolated in its own world.
3. Content Security Policy
The coolest and (when used properly) most effective defence against XSS is CSP. How it works is that you give your website restrictions such as "do not execute scripts", "do not load images", etc. And then you allow the scripts that you do want to execute, and nothing else. Now if an attacker manages to inject a script, link, form, etc. on the page, it will not work because it hasn't been specifically allowed.
I've written about CSP at length here, you will even find specific examples for your case (NodeJS and EJS) with CodeSandbox examples on that article. And in general about XSS protection you can read more here.
Hope this helps!


What is the iptables rule to block all https traffic except to a single ip? I'm trying to configure a microservice for my web application, which is hosted at ip address X.X.X.X. The microservice should only accept https connections from this web app.

I've tested the microservice as working from the webserver with liberal "allow everything" ip tables rules, but my rules below (specifically, the last 2) aren't letting me through.

Here's the head of my iptables rules at the moment:

#allow current ssh connection so we don't disconnect ourselves
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
#allow ssh traffic
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -j ACCEPT
#allow ssh web traffic only from nominated webserver
iptables -A INPUT -p tcp -s X.X.X.X/32 --dport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -d X.X.X.X/32 --sport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

I've double checked the X.X.X.X ip is correct, and the web app's proxy has the same IP (it's nginx on the same server). What am I screwing up?

Edit: output of iptables -L:

target     prot opt source               destination
ACCEPT     tcp  --  X-X-X-X.rev.cloud.scaleway.com  anywhere             tcp dpt:https state ESTABLISHED

Does this mean that somehow my "source" ip isn't actually the source of the request I think I'm sending? (and is instead the scaleway VPS provider?)

If you just want a single IP then this should do it, in the most retentive way possible:

# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P INPUT DROP
# iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT
# iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT
# iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT
# iptables -A INPUT -m conntrack --ctstate INVALID --jump DROP
# iptables -A FORWARD -m conntrack --ctstate INVALID --jump DROP
# iptables -A OUTPUT  -m conntrack --ctstate INVALID --jump DROP

# iptables -A INPUT --in-interface lo --jump ACCEPT
# iptables -A OUTPUT --in-interface lo --jump ACCEPT
# iptables -A INPUT -p tcp -m tcp --source  X.X.X.X/32 --dport 443 -j ACCEPT
# iptables -A INPUT-p tcp -m tcp --source  X.X.X.X/32 --dport 22 -j ACCEPT
# debugging rules to help you set up.
# iptables -A INPUT -j LOG
# iptables -A FORWARD -j LOG
# iptables -A OUTPUT -j LOG

and if you don't care about ipv6 just drop all those too apart from lo.

Basically whatever is accepted for input will be tracked and the output allowed as it is releated.

If you need DNS then this is extra, but if you are able to log in the logs should help you see what you are missing.


Code-Signing: Why is the CA process different from web site certificates? I recently went to renew a code signing certificate. In preparation I went through our usual process (as for web server certificates) of creating a key pair and a CSR with OpenSSL. When I then went through the renewal process, I was not give a chance to upload the CSR.

Instead, after the CA had validated  my identity, I received a custom link. When I followed it, apparently a key pair was generated by my browser and automatically imported into my Mac's keychain. I did not even know this was possible before. The matching certificate was placed in the Downloads folder.

It is company policy here that private keys are created and managed by us. While I have not reason to suspect the CA does anything fishy, I still don't like that I can't really verify where the key came from.

An explanation of what I am missing here would be much appreciated; the CA's chat support was not able to explain it.

Edit: I have since read more through DigiCert's documentation and learned that if you chose "Sun Java" as your platform, I can actually provide a CSR and afterwards download the certificate as usual. Still would like to know if there is a particular reason for this and how it actually works.

You didn't miss anything. This is bad practice and the policy your company has in place has good reasons.

This also isn't specific to code signing; CAs (used to?) do this with TLS certificates for domains as well. To be clear: there is no reason to have the certificate generated in the browser or on the server. It's also not verifiable for the regular user whether the server does know the private key to that certificate, which is in itself a problem.

Now, however, this could be considered a usability feature as you do need additional software or skills to obtain a certificate.


How to code for "Establish and maintain control over all of your outputs" I was looking into this list (top 25 security issues):

https://cwe.mitre.org/top25/index.html#Listing

That led me to this list:

https://cwe.mitre.org/top25/index.html#Mitigations

That led me to wondering how can we code for M2: Establish and maintain control over all of your outputs ?

I understand M1, input validation but output validation? How do we do that?

Does this mean for example, that in a REST API we should validate the response objects we send?
If so, What should we do it the validation fails? Do not reply?

I'm probably missing the point here. Thanks for the help.
Can someone provide a code (pseudo-code) example?

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

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

IMHO your own link explains everything very well:

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


What should I use for authentication for my Django Rest API? I just read this article about why JWT's suck. I'm now uncertain what I should use for authentication.

For context: The API I wrote is mainly used by mobile Apps (iOS and Android). In the future it will also be accessed via a React Frontend.

In the past I just used DRF's build in Token authentication. The phone would then just store this token in the storage of the respective app.

Now I've recently been told, that this is not safe and that I should use JWT's. While researching JWT's I found the article above, which elaborates on why JWT's suck and basic session authentication is better. But as far as I know, when used as an API I can't use session authentication with DRF, can I?

So my question is? What tools of DRF should I use for authentication, so that it's safe?

I'm the author of that article, as well as the somewhat popular tech talk I give about why JWTs suck and are stupid (all of which @joepie91 has eloquently written about much better than I ever could: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/).

Given your application requirements (mobile app + JS front-end only app that both talk to a backend API), I'd suggest you use the OpenID Connect Authorization Code flow (w/ PKCE for your mobile app).

For your mobile app, specifically, I'd recommend using the fabulous AppAuth library: https://appauth.io/ (it has great libraries for both iOS + Android).

Now, you might be wondering why I'd recommend using OpenID Connect (and thus, JWTs) for something when I so publicly rally people against using JWTs: I'll tell you -- for most stuff it just does not matter.

Here's the thing: yes, JWTs are pretty awful to use when building secure apps. They're complicated, most libraries currently aren't spec complete, and using more advanced features like JWT encryption are almost sure to cause you massive headaches and compatibility issues between your services.

Furthermore, the entire reason JWTs have become popular for authentication is that they are frequently used to CACHE authentication and authorization data -- this entire practice is a big NO NO in the security world.

Caching sensitive data (like authentication and authorization data) is the worst possible thing you can ever do for security: you're trusting outdated information. ALL current auth systems built on top of JWTs suffer from this naïvety.

Once you've gone down the rabbit hole of trying to "speed up" your site/API by using JWTs, you've already committed a security sin and are now at risk.

Moreover, once people start using JWTs and realize they're at risk, they try to re-centralize everything (as one other commenter has suggested) and begin using revocation lists so that they can revoke tokens when bad things happen. This results in the same speed penalties as traditional session management, but with greater speed penalties due to JWTs being "heavier" than session cookies, and more fragile.

Sorry for the rant, but here's my advice:

If you want real security, you have to use server-side sessions. In your case, this would entail supporting session cookies from your API backend so that when your react app authenticates to your API, the API sets a secure cookie that the react app uses automatically each time it talks back to the API service to authenticate. You'd also need to use a cookie-based API from your mobile app (I'm not familiar with building native mobile apps, so can't comment on this component).
If you want simplicity and the same amount of security as just about every other major web app, using OIDC and go with out of the box open source solutions. This is the simplest way go currently and while it's not perfect, if it solves your problem then it likely isn't a big deal.

If you're building something sensitive, try to use server-side session cookies when possible. Otherwise? Don't sweat the details and go with the flow.


SHA2 certificate and TLS cipher suites compatablity I have a server which is configured to use TLS 1.0, 1.1 and 1.2. The server is configured with a certificate siged by SHA-512. The server supports only these cipher suites:

• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The client (browser) requested for the handshake and offer these cipher suites:

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The server has accepted TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 and presented it's certificates, which has has algorithm identifier SHA512RSAEncryption.

Does this mean the browser is able to verify SHA512 cert without any cipher suites in common?

The signature algorithm used for the validation of the certificate (SHA-512 in your case) is independent from the algorithm used as the HMAC in the ciphers, i.e. for the encryption (SHA-256, SHA-384 in your case).


Crossdomain.xml vulnerabilities <cross-domain-policy>
 <allow-access-from domain="*" secure="false"/>
 <site-control permitted-cross-domain-policies="master-only"/>
</cross-domain-policy>

I would like to ask two questions:

Is this crossdomain.xml vulnerable (the file is placed on the root of the host e.g. www.example.com/crossdomain.xml)?
How I can exploit or test similar files?

This crossdomain.xml policy file revokes all protection that the Same Origin Policy provides.

I use the crossdomain proof of concept tool,  which has a simple interface to test SOP bypasses.


How big should salt be? I will be using scrypt to store passwords in my application. As such, I'll be using SHA-256 and Salsa20 crypto primitives (with PBKDF2).

Having that in mind, how big salt should I use?
Should it be equal to the size of SHA-256 output: 256bits or should it be equal to number of bits I'll take from this password stretching function: 512bits?

Considering that SSHA as used by OpenLDAP has only 32bit salt and Linux crypt() uses 48bit salt my salts would seem fairly large...

In general: What is the rule of thumb for size of salt?

Related:

What should be used as a salt?

What is a good enough salt for a SaltedHash?

Salts must be unique; that's their one and only job. You should strive, as much as possible, to never reuse a salt value; the occasional reuse is rarely critical but should still be avoided). With reasonably designed password schemes, there is no other useful property in salts besides uniqueness; you can choose them however you want as long as you do not reproduce the exact same sequence of bits. Uniqueness must be understood worldwide.

(With badly designed password hashing schemes, the salt might have some required additional properties, but if you use a badly design password scheme you already have bigger problems. Note that a salt is not exactly the same as an Initialization Vector for symmetric encryption, where strict requirements like unpredictable uniform randomness typically apply.)

A common way to have more-or-less unique salt values is to generate them randomly, with a good generator (say, one which is fit for cryptographic usages, like /dev/urandom). If the salt is long enough, risks of collisions (i.e. reusing a salt value) are low. If you use n-bit salts, chances of a collision become non-negligible once you reach about 2n/2 generated values. There are about 7 billions people on this planet, and it seems safe to assume that they, on average, own less than 1000 passwords each, so the worldwide number of hashed passwords must be somewhat lower than 242.7. Therefore, 86 bits of salt ought to be enough. Since we kind of like so-called "security margins", and, moreover, since programmers just love powers of two, let's go to 128 bits. As per the analysis above, that's more than enough to ensure worldwide uniqueness with high enough probability, and there is nothing more we want from a salt than uniqueness.

Uniqueness can also be ensured through other means, e.g. using as salt the concatenation of the server name (the worldwide DNS system already ensures that everybody can get his own server name, distinct from that of anybody else on the planet) and a server-wide counter. This raises some practical issues, e.g. maintaining a counter value which does not repeat, even in the case of an ill-timed server crash&reboot, and/or several front-ends with load balancing. A random fixed-length salt is easier.


How to interpret this statement against 4096-bit RSA While I'd agree that double-sized RSA keys may pose more problems than the gain in security possibly justifies, I am having problems understanding the argument made here:
https://gnupg.org/faq/gnupg-faq.html#please_use_ecc

They state that RSA2048 corresponds to about 112 bits of security and RSA4096 to about 140 bits, and they state that the 28 bits improvement is "marginal".  But the way I understand this, is that the conversion from "key bits" to "security bits" is that it (as an estimate) takes ~2112 operations to crack a 2048 bit RSA key and ~2140 operations to crack a 4096 bit RSA key.
So in my eyes that still means that if they™ routinely solve the RSA2048 problem in one seconds by throwing all their CPU power at it, it would still take several years for the RSA4096 key. (Or: be slightly less paranoid and replace "one second" with "one minute" and "several years" becomes "several centuries").

Why would such differences still be called "marginal"?

Maybe the answer is that 112 or 140 bits is only for some brute-forcing (even though the naive brute force would be something like 1024 vs 2048 bis) - but wouldn't that rather imply that these numbers are inadequate to begin with as a means to describe the complexity/security?

The reasoning in the quoted advice is poor:

  The United States’ National Institute of Standards and Technology (NIST) states that RSA‑2048 gives roughly 112 bits of security and RSA‑3072 gives roughly 128. There is no formal recommendation on where RSA‑4096 lies, but the general consensus is that it would come in somewhere around 140 bits — 28 bits of improvement over RSA‑2048. This is an improvement so marginal that it’s really not worth mentioning.

  If you need more security than RSA‑2048 offers, the way to go would be to switch to elliptical curve cryptography — not to continue using RSA.

As stated in the question, even the 28‑bit (or 228 times) improvement in resistance to brute force from 2048‑bit RSA to 4096‑bit RSA is large (not marginal), enough for decades of brute-force computing progress, and could well make the difference between secure and insecure in say half a century.

Also, the 28‑bit figure quoted is significantly below general consensus, which would be more like 36±4‑bit. Factoring the public modulus of a properly drawn RSA key n with classical (non-quantum) computers is, as far as we know, best done by GNFS with effort

While the speed at which the o(1) term goes to zero is not known, projections on computing effort customarily neglect that o(1). Taking 3072‑bit RSA as baseline, that tells 4096‑bit RSA would be ≈18‑bit (not 12‑bit) harder, 7680‑bit RSA ≈64‑bit harder, and 15360‑bit ≈131‑bit harder. This nicely matches the figures starting from the 128‑bit security level in NIST SP 800-57 Pt 1 implicitly referenced by the citation:

If there is a consensus, it is that

If 4096‑bit RSA is broken in the next three decades, that will be by some groundbreaking progress in factorization algorithm, or (and) the advent of quantum computers usable for cryptanalysis (which currently do not exist, and remain highly hypothetical).
There is no compelling reason to believe that ECC would be less susceptible to such hypothetical progress; there are even convincing arguments that at the same security level (and increasingly at higher levels), ECC would fall before RSA to quantum computers usable for cryptanalysis.

One correct argument to be made against 4096‑bit RSA is that currently 2048‑bit RSA is more than safe enough, thus 4096‑bit RSA way overkill. But a reasonable argument to use 4096‑bit RSA is the possibility of quantum computers usable for cryptanalysis; or/and, the need to repel those considering such devices might materialize in the usable lifespan of the key. 4096‑bit RSA is fast enough to be usable from most applications of PGP/GPG involving a post-2010 general-purpose computer; key and ciphertext size is bearable; so why not?

My advise is that 4096‑bit RSA is a sound choice for long term security in PGP/GPG. It is safe, interoperable, simpler thus better audited than ECC, and there is some credibility in the arguments that it gives a better level of security against hypothetical quantum computers usable for cryptanalysis.

Note: I use quantum computer usable for cryptanalysis rather than quantum computer, because devices performing Adiabatic Quantum Computing (as in D‑Wave's 2000Q) are increasingly referred to as quantum computers, while I have not seen any serious claim that their technology could lead to something usable for cryptanalysis, contrary to the Intel/QuTech 17‑Qbit superconducting chip.
Addition: And now (2019) there are indisputably quantum computers competitive with classical computers on some simulation problems (even if their claim to quantum supremacy in this area is disputed), but still useless for any exact, deep, combinatorial problem like cryptanalysis.


Dealing with SSL Certificates on Products We are developing a product (device / system) that will be installed on customer sites. Many of our customers will (should) be concerned about security, and should be thinking about it seriously.

Our product provides an API via HTTPS, which is used by the built-in UI and is also open for use by customers.

I'm looking for information and advice on how to deal with the SSL certificates that are installed in our product when they leave the factory.

I would appreciate any input - have we overlooked or missed anything?

As It Stands Today

Currently (the system is in development) we are installing the same self-signed certificate into every development and prototype unit. This clearly has no chain of trust and the user will see a warning.

I believe that this is the same approach taken by other manufacturers (e.g: Cisco, Ubiquiti), but confirmation would be appreciated.

Options

 Customers will be able to provide their own certificates, signed in whatever manner they wish (publicly, or privately). This will give them the chain of trust, and will allow them to be sure that they really are connecting to *that* system.
 Installing a different self-signed certificate on each unit. I'm not sure there is any benefit to doing this over sharing a single self-signed certificate across all units, as the certificate is still untrusted.
 Installing a publicly signed certificate on each unit that leaves the factory. As far as I can tell, this will not work. Certificates are tied to a FQDN (possibly with a wildcard), and as such there is no way for us to generate and sign a certificate for the customer.

We are installing the same self-signed certificate into every development and prototype unit.

Installing the same certificate into every unit is about the worst security practice one could imagine when dealing with certificates. We now know not to release products with the default hard coded administrative credentials. We avoid default credentials because such credentials could be extracted once and used to compromise all devices that implement them. This is a very similar situation – the default certificate means the private key could be extracted once and used to compromise all devices that rely on this certificate.

Cryptographically, both self-signed and trusted third party certificates operate the same way. Each certificate is associated with a key pair consisting of a secret private key and a non-secret public key. If you know the private key, then you can perform every action associated with the public key and certificate.

The compromise of the default certificates has further implications than just compromising authentication. For TLS, depending on the cipher used, the certificate could end up being used to establish a shared secret. In such cases, a passive eavesdropper would be able to decrypt TLS traffic after seeing the initial handshake.

Sure, competent administrators will fix this issue by uploading their own unique certificates, but how many would actually stop at 'just make it work' stage by trusting the default certificate?
What you should do instead is generate a new key pair on initial boot or factory reset. This is how secure network devices operate. When generating new certificate, you also have to make sure that you have sufficient entropy available in the system and do not end up generating factorable keys.


In practice, does TPM SRK really be decrypted by EK first, before it decrypt its child keys I know that TPM SRK was generated when user take TPM ownership, and it is encrypted by EK public part. All the child keys under SRK need to be loaded into TPM and decrypted by SRK before use. (These are what the books tell us.)

However, it seems that different manufactures have different implementation design for EK & SRK. My question is: In practice, e.g. if SRK will decrypt a loaded child key, does it really experience an decryption process by EK private part first? You can also understand this question in another way: without any call/use, is the SRK stored in nonvolatile memory in encrypted format?

I ask this because I found that many TPM real products always have something different from what the books tell us. e.g. In some TPM, EK is empty, the customer need to generate EK by self before take TPM ownership; EK can be changed once in some TPM products; certificate generation uses SRK instead of EK public, etc. (all above examples happen on TPM 1.2. We do not mention TPM 2.0 here)

The SRK is not encrypted by EK. Both are not required to be encrypted at all. Their security are based on their physical protection and the logic of the TPM itself - no API are to provide their private portion.

The fact that some TPM requires some special operation to create EK after manufacturing is describe in the spec. Please see page 15 or so from Protection Profile PC Client Specific Trusted Platform Module TPM Family 1.2.


How do I write my own authentication protocol and add that to OpenWrt? I would like to add a ticket based authentication mechanism to my network. Can you give me brief idea where do I start, which language should i write the protocol in and how do i get those in my custom OpenWrt firmware. Thank you!
(Edit)
In a traditional mesh network seamless connection is hard to achieve since as the client moves from one MAP(mesh access point) to another so it needs to re-authentication once again which will cause trouble in applications like video call and voice calls.
I read a dozen of research papers and found out that ticket based authentication is one of the best solution for fast authentication  thereby providing a seamless connection.
[link to the paper] : https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0155064
This is something i am trying to implement.

Was looking for some guidance as to how can i start this.

You might want to consider writing a pluggable authentication module (PAM) that you can use with OpenWRT.  From the Wikipedia article linked above, you can see:

A pluggable authentication module (PAM) is a mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API). It allows programs that rely on authentication to be written independent of the underlying authentication scheme.

From the links below, tt looks like OpenWRT supports integration with PAMs:
https://openwrt.org/packages/pkgdata/libpam
https://forum.openwrt.org/t/installing-google-authenticator-for-ssh-openconnect-openvpn/31439


Security considerations for managing internal network from an external website With my previous network setups, I managed my network by connecting to the internal IP address of my router (e.g. 192.168.1.1).

I recently switched to google fiber and installed their "fiber box" (a combined router/modem, as I understand it) in place of my old modem and router. Connecting directly to the router's IP adress now presents a very minimal page that directs me to https://fiber.google.com/myfiber/ to manage my internal network settings. It is this external page that allows me to do things like assign static IP addresses and modify WiFi settings.

Is this something I should be concerned about, or is it just as secure as managing network settings "internally"? If there are risks, how can I mitigate them?

You are basically managing your network through Google. You define settings on Google's account page, and on boot the router pulls settings from them. This allows for example easy migration to a new/replacement router, as it just pulls the latest configuration on boot.

Because we're talking about Google I assume they've done their homework as far as securing the data in transit between your computer and their systems, and your router. I would expect everything to happen over HTTPS, so it is secure in transit.

Data storage on their systems should be secure as well, but if it isn't then you've got much bigger problems than your router configuration being accessible - your entire Google account would be at risk, including GMail, etc. So personally assuming you're fine with Google controlling your router and having access to your network, you shouldn't have anything to worry about.


Using TOTP instead of passwords for IoT device authentication I am trying to come up with a way to authenticate an IoT device to a server. Since the device is "un-monitored", I cannot expect a user to enter a password on the device whenever the device starts or reboots.

I am not overly worried about device theft, but I am worried about the device being cloned and the copy then impersonating the original.

The device will be running Android, and as I understand it, the Android keystore is difficult to copy (correct me if I am wrong). The keystore can be asked to HMAC-sign a value, without exposing the signing key.

If I use a regular secret key as the authentication password, that key can be extracted from the keystore and copied to the clone.
If instead, I use TOTP, I can present the current time value to the keystore and have it HMAC that value, then proceed with the rest of the TOTP protocol, as defined in RFC 6238.
I can use public-key encryption and have the keystore sign some value (like "yes, it's me"), and then have the server check that the signature is valid, but that would be vulnerable to a man-in-middle attack followed by a replay attack. I could have the device sign a challenge provided by the server, but that requires an extra network round trip for each authentication.

I plan on using TLS for all connections.

I saw the answers given in "What are the security implications of using TOTP for single factor authentication?", but I want to confirm that I am selecting a reasonable scheme for IoT.

Are my assumptions correct? Is there a better, more secure way to authenticate a device?

If we assume that the keystore is safe and keys can not be copied or extracted but it can perform HMAC-SHA(1) then you might think of using TOTP.

But I would also recommend taking a look at OCRA.
Here you can do real challenge signing. You either realy do only a challenge signing or you can add time or a counter. This way you would have no problems with a clock drift.

But why not use public key crypto? If the keystore can also store an RSA private key - I would probably go with signing the challenge with a private key.

If you are still going with TOTP or OCRA, you might also want to take a look at privacyIDEA, which can help you to manage all the secret keys of your devices.


Create a Secure QR Code Reward System? Ill gave you the following scenario:

A customer comes to a coffeshop and drinks 1 coffee. Then he put out a App from this Coffeeshop and opens the integrated QR Scanner. The worker shows him a QR Code and then the Counter goes 1 up on the App of the customer. If the Customer got 10 he gets 1 Coffee for free.

The Problem here is that the Customer could take a picture of that QR Code and could start a Replay Attack to gain free Coffees all the time.

How could be a System like this secure? What should the QR Code contain? And so on. Please help me.

You can’t secure a static barcode against copying. It’s not possible.

What you need to protect against this kind of attack is to have the customer enter/scan something dynamic. It has to be changed every time it’s used; it has to change in an unpredictable manner, so that dishonest customers can’t make up a value and fool it; and the back end system must refuse to accept multiple scans of the same code.

One way to do this is to display the QR code on a tablet mounted on the counter. Every time a customer scans it and their app posts a message back to the server, it validates the current code and then changes the QR code to show a new random number to the next customer.

This needs more security, of course. You have to somehow limit your customer records so he can’t just scan 10 barcodes in a row in one minute. You could solve this by only displaying a QR code after the cash register receives payment. Or you could limit the customer record to ignore multiple scans within a 30 minute window.

You could have the cash register print unique barcodes on the receipts, but thieves will pick up discarded receipts from the trash and scan them. It takes sophisticated back end logic to detect this kind of fraud.


Calculating password hashes in the browser? I just finally got into Keybase and was surprised to see this in the sign-up page:

Shouldn't password stretching and hashing be done on the serverside, as we normally don't trust a client?

The whole point of Keybase is that the user doesn’t and shouldn’t have to trust the server with anything. All proofs can be verified without the server. As the Keybase passphrase serves to decrypt the private key used to sign the proofs, the server can’t be allowed to touch it.

Also, one has to trust the client to provide a registration passphrase, so even on websites less peculiar than Keybase, allowing the JavaScript to do its own password hashing there would be perfectly fine. (Allowing a user to log in with the same one, though, would be a very bad idea, as someone could just pass the hash.) They don’t, though, because those sites need to be trusted with the user’s password anyways (see parenthetical), and JavaScript hashing is both slower and not always available.


Security Incident File Change Timestamp How can I obtain all timestamps of all files ( starting"/") on a Linux system in order to verify if a file was changed within a breach?

If I'm understanding you correctly and you want to get all files in Linux and their associated timestamps:

find / -printf '%Tc %p\n'

beware of date stomping tho.


Do you really need an access token and refresh token? When using a single page application, in what way is access token + refresh token more secure than a single token in a cookie with SameSite: strict.
Given the browser supports SameSite.

I completely understand that if you don't have the SameSite setting available that you need an access token and a refresh token.
It just doesn't seem obvious why you would need anything else than an access token with en expire time of lets say, a session that holds your token.

Your token either being a JWT or session id.

I assume this question has asked before, at the moment I'm just surrounded by so many contradicting opinions that It's driving me nuts.

Thanks for your time.

Introduction

The SameSite Cookie attribute prevents the browser from sending this cookie along with cross-site requests. The main goal is mitigate the risk of cross-site information leakage. It also provides some protection against cross-site request forgery attacks.
One of the two possible flags for the SameSite is "strict".
The "strict" flag will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. Not all browsers implement the attribute "SameSite".
In OAUTH 2.0 both access token and refresh token are defined in RFC6749.
Access tokens are credentials used to access protected resources.
An access token is a string representing an authorization issued to the client.
Refresh tokens are credentials used to obtain access tokens.
Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope.
Access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner.
Issuing a refresh token is optional at the discretion of the authorization server.
If the authorization server issues a refresh token, it is included when issuing an access token.
In the OAUTH 2.0 the token revocation defines a mechanism for clients to indicate to the authorization server that an access token is no longer needed.
This is used to enable a "log out" feature in clients, allowing the authorization server to clean up any security credentials associated with the authorization.

Answer

As written in OAuth 2.0 Security Best Current Practice 4.12

Refresh tokens are a convenient and UX-friendly way to obtain new
access tokens after the expiration of older access tokens.  Refresh
tokens also add to the security of OAuth since they allow the
authorization server to issue access tokens with a short lifetime and
reduced scope thus reducing the potential impact of access token
leakage.

As stated in the answer, the Access Token is more vulnerable then Refresh Token because it is seen by more parties. Resource Server could lead to the leaking of the Access Token, while the Refresh Token would still be safe because Resource Server doesn't see Refresh Token.
There are a few reasons why you might need to revoke an application’s access to a user’s account.

The user explicitly wants to revoke the application’s access the user doesn't want to use anymore.

The developer wants to revoke all user tokens for their application.

The developer deleted the application.

The service provider wants to disable a compromised/malicious application.

These explain OAuth security and vulnerabilities in more detail:
What is going on with OAuth 2.0? And why you should not use it for authentication.
OAuth 2.0 Security Best Current Practice


How can Stripe be PCI-compliant? According to the Stripe FAQ, they are PCI-compliant. Also, in their API documentation, one of the parameters to create a new card is the CVC (although, granted, it is optional). So, I assume they store the CVC for subsequent credit card transactions. But the PCI DSS strictly forbids you to store CVV, CVC etc.

So how can they be PCI-compliant?

(Disclosure, I work for Braintree, a competitor to Stripe)

At Braintree we also allow the CVV code to be passed in our API. You are correct that the PCI-DSS explicitly forbids non-issuers from storing the CVV. You are allowed to hold the code temporarily while waiting for the charge to be authorized. This is stated in PCI-DSS Requirement 3.2 (additional formatting is my own):

  3.2 Do not store sensitive authentication data after authorization (even if
  encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

It goes on to define sensitive data as including the CVV:

  Sensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions.

What this means is that service providers and merchants are allowed to take the CVV value, they just cannot keep it stored in their database for future use.

In the API you are looking at, the creation of a new vaulted credit card, the CVV is used to run a verification on the card. A verification is a type of authorization that ensures the account is active and able to be charged before we store it. After the verification is returned we discard the CVV. This allows us to give merchants a warning that the card their customer just added will fail the next time they go to use it.


What attacks are most likely against SSL/TLS web service sessionid? I am implementing a web api with which I plan to authorize access by accepting a username and password and system name and returning a sessionid which can be used on subsequent calls to authorize the caller.

The api is only available though SSL 3.0 or TLS 1.0.

What are the main attacks which would be possible in this scenario?

The answer and comments to this SO question seem to indicate that if the risk of attack is proportionally low, more complexity will not improve security but will add complexity. I would like to know the highest risk areas for attack to determine the appropriate counter-measures, if necessary.

The attacks against this system fall into three separate categories; Authentication, Session Management, and attacks against TLS.

The Mozilla Secure Coding Guideline for Authentication details
the following attacks of concern:

online & offline brute force password guessing
user enumeration
mass account lockout (Account DoS)
offline hash cracking (time trade-off)
lost passwords

The Mozilla Secure Coding Guideline for Session Management
details the following attacks of Concern:

Session Hijacking
Session Fixation
Brute Forcing Valid Session IDs

The OWASP Transport Layer Security Cheat Sheet details various
    ways that TLS/SSL can be made more secure.  Some of the concerns
    are:

Renegotiation DoS
Weak ciphers/NULL encryption method
Invalid certificate
divulging session id over an insecure channel


Why is hashing (digest) employed in digital signatures? A digital signature is the following process:
- Use message
- Hash it (giving digest), encrypt digest with private key.
- Append encrypted digest to the message.

Why not just encrypt the message with private key?

I assume that then attacker could just change something, we would be able to decode, but we would get different message than the sent one.
We also wouldn't be able to recognize that the message was changed.

Why not just encrypt the message and append the encrypted one to the original message?

I assume the message would be twice the size which is inconvenient for large messages.
Also public-private keys have the restriction on message length, which would lead to the need of breaking message into parts.

Are my reasons correct? Something else that I missed?

Why not just encrypt the message with private key?

As far as I know, it's just for efficiency. Encrypting with asymmetric algorithms is notoriously a time (and resource) consuming operation, particularly when the plaintext size is rather large (MB, even GB).

To avoid that, you just encrypt the hash, which has a much shorter length, and still guarantees that the signed file can't have been altered.

  I assume that then attacker could just change something, we would be able to decode, but we would get different message than the sent one. We also wouldn't be able to recognize that the message was changed.

In general, yes, only cryptographic hashes (and related techniques such as message authentication codes) allow you to recognize that the message hasn't been changed. However, with most modern algorithms an attacker cannot easily modify the ciphertext E(m) to a value corresponding to another arbitrary message m'.

  Why not just encrypt the message and append the encrypted one to the original message?

Do you mean m|E(m), i.e. plaintext concatenated with its ciphertext encrypted with the private key? If so, it's again mostly due to effiency reasons. As I have already said, encrypting a document asymmetrically is a computationally expensive operation. In addition, as you have correctly said, the size would be almost doubled.


Vulnerabilities of using HMAC of random ID as shared secret? Assume that a server has a random secret key, uses it to generate <id = random(), secret = hmac(id, key)> credential tuples, and hands these <id, secret> tuples out to clients freely (over a secured connection).

Are there any weaknesses in a client using its secret to symmetrically encrypt messages directed at the server?

For example:

1. Server setup

Server is loaded with random secret key

2. Credential given to client

Client requests credential over secure channel
Server generates a random id
Server generates a secret by HMACing id with its key
Server responds (over secure channel) with <id, secret> tuple

3. Client sends message to server

Client creates a message M to send to the server
Client generates M' by symmetrically encrypting M and then MACing with its secret
Client sends <id, M'> tuple to server over unsecure channel

4. Server gets message from client

Server receives <id, M'> tuple over unsecure channel
Server derives secret by HMACing id with its key
Server authenticates and decrypts M' using secret

To me, this provides the benefit of the server not needing to persist IDs or secrets, and is also fast (compared to generating RSA key pairs).

But I'm eager to hear downsides of using HMAC like this to generate secret keys?

I tried Googling this scheme but my Google-fu must not be strong enough (this question and answer seem sort of close, but this isn't "Key Derivation" proper, is it?). There must be a good reason why this isn't more common.

Also, is there a name for this?

HMAC is a fine candidate for generating keys like that.

After some digging I found this book, which calls the technique "Algorithmically Generating Symmetric Keys from One Base Secret", and which specifically recommends using HMAC: https://www.safaribooksonline.com/library/view/secure-programming-cookbook/0596003943/ch04s11.html

  [To create a key,] mix a base secret and any unique information you have available, passing them through a pseudo-random function (PRF), as discussed in the following section.

They later call the "unique information" the distinguisher. For our purposes this is equivalent to the randomly-generated id.

They go on to list several different options for a PRF, including hash functions:

  [...] a one-way hash is often good as a PRF.

They expand a little bit on the idea of using a hash function as a PRF:

  [...] you can concatenate a base key with unique data and pass the string through SHA1.

The above quote is similar in principle to the definition of HMAC. Indeed the authors cite HMAC specifically as a candidate:

  The easiest way to get a solid solution that will resist potentially practical attacks is to use HMAC in counter mode.

This quote is in the context of generating keys longer than the hash block size. Counter mode just means to append a sequential number to the distinguisher as you generate key data. The purpose of a counter is to keep the HMAC's input unique so that the concatenation of output blocks (for the purpose of generating a long key) isn't simply repeating.

For our purposes, there's no need to use counter mode unless the secret needs to be longer than the hash block size.

In the author's words:

  If a [generated] key is compromised, it should be impossible to recover the base secret.

They also mention an additional benefit:

  Multiple entities in the system should be able to compute the same derived key if they have the right base secret.

Q.E.D.


How can I change windows security settings using python? i.e. Password Requirements / Require Ctrl - Alt - Delete to log in I am writing code in Python 2 or 3 to script Cybersecurity functions. Functions such as Lockout Duration, Password Length, and other things that involve a lot of clicking that could easily be automated.

import subprocess
subproccess.call(x, shell = True)

I plan on using that format to run (or enter ((so I don't have to type only press the answer button))) commands in command prompt (with Administrator privileges). However, I have no idea how I should do this, especially the "Require Ctrl - Alt - Delete on Startup." Help would be greatly appreciated.

EDIT :
As of now, I thought of a possible solution to the password requirement part of my problem that I will investigate, but am still totally lost on the ctrl - alt - delete part. :D

You can set the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DisableCAD to have value 0.  The following command should (untested) do the trick:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DisableCAD /d 0 /t REG_DWORD /f


Hashed Database: Hash Functions Let's assume there is a database containing names and each name is hashed and the clear-text is deleted.

If an attacker were to steal this database, would he/she be able to get the list of names?

A hash function is one-way in the following sense: given the output, the fastest method to find a matching input is to try possible inputs until a match is found. You cannot get more one-way than that. However, this does not mean that hashing names and hoping for a match does not work; in fact, people names are depressingly not varied enough, it is easy to enumerate and hash them all. Since a hash function is public (no secret element) and deterministic (if you hash twice the same data, you get twice the same output), brute force on names will work. A PC with a medium-sized GPU can hash billions of strings per second.

The same problem occurs with passwords, which are limited by the average imagination of human users. When we hash passwords, we must do it with care. The same would apply to names, possibly even more so.


Could you anonymously upload a file on the internet if the threat model was the entire world trying to find your identity after you do so? Thought experiment: You need to upload a file, and the threat model is the entire world trying to find out who you are after you do so.

I know this is absurd, but bear with me, it's a thought experiment, where the scenario is the following:

You are a normal citizen, and you have a file (assume that you just have it, and the file doesn't have metadata or information related to you) that is somehow so compromising/critical that, if uploaded on the internet, the entire world would actively try to find out who you are. Everyone, military, every country's agencies, civilians, the grandma going to the grocery store, yes, her too, to the best of her ability. People who run TOR relays too, everyone.

Your mission is to upload it on the internet without your identity being revealed.
How would you go about it?

Update: File is in your pendrive, has a size of few MB, it's ok if it just shows up eventually. No-one should really guess what country you might live in. We can think of the uploader as average-citizen, with average knowledge of technology, and can follow instructions (for example, setting up Tails).
Assume that no-one had access to this data before.
The thought experiment is not realistic, because one could argue that no upload could be so critical as to motivate the entirety of humanity to find the identity of the uploader, and I would agree with that argument, but the thought experiment is aimed at exploring fairly reasonable routes of action if that was the case.

Tl;DR

Time is on your side.

Note: leave your own phone at home and preferably own a car without GPS.

Drive 100 miles from home and buy a cheap used laptop/Android device with functioning Wi-Fi in cash from any source with bad/non-existent record-keeping

If laptop then make sure it has the most common OS such as Windows 10
Make sure to park your car about 1-2 miles away from the transaction
If you can grow out your hair and a large beard then do so before this transaction; when the seller gets interrogated then they won't have a clear idea of your facial features. Just try not to make yourself look disheveled or sketchy
Re-format the device to factory settings if possible. Do not install your own copy of the OS
Don't try to install Linux thinking that it's more secure or anonymous because that would narrow down the search criteria to finding people with the knowledge to do such a thing unless of course you are not a person that knows how to do such a thing but were given explicit instruction for achieving such a task. In the latter case you should install Linux to further distance yourself from the main suspect.

Put a piece of tape over the webcam if laptop
Shave your face and cut your hair if applicable
Wait at least one year
Grow out your hair and a large beard again if applicable
Go find some free public Wi-Fi at least 100 miles from both you and the transaction location of the laptop/Android device and connect while outside the actual building; preferably with no surveillance cameras nearby. Park 1-2 miles away.

Alternatively, you could hide in plain sight in a heavily populated mall; in which case an android device would be less conspicuous than a laptop.

Upload the file

You may wish to pass through one or more VPNs

Shut down the laptop/Android device
Get back to your car and drive another 50 miles, remove the hard drive if laptop, and destroy it physically and dispose of it.

Destroy and dispose the laptop/Android device in a different location and drench it in bleach to remove fingerprints

Return home using a different route


Problems executing shellcode via nop-sled My shellcode instructions are changing during execution. I'm not sure why.

Here is what my shellcode looks like:

=> 0xbffff0b3:  nop
   0xbffff0b4:  nop
   0xbffff0b5:  xor    eax,eax
   0xbffff0b7:  push   eax
   0xbffff0b8:  push   0x68732f2f
   0xbffff0bd:  push   0x6e69622f
   0xbffff0c2:  mov    ebx,esp
   0xbffff0c4:  push   eax
   0xbffff0c5:  push   esp
   0xbffff0c6:  push   ebx
   0xbffff0c7:  mov    al,0x3b
   0xbffff0c9:  push   eax
   0xbffff0ca:  int    0x80

I step through my code and everything looks fine at first:

   0xbffff0b5: xor    eax,eax
   0xbffff0b7: push   eax
   0xbffff0b8: push   0x68732f2f
=> 0xbffff0bd: push   0x6e69622f
   0xbffff0c2: mov    ebx,esp
   0xbffff0c4: push   eax
   0xbffff0c5: push   esp
   0xbffff0c6: push   ebx

Suddenly, when I get to mov ebx, esp  , the remaining instructions change:

   0xbffff0b7: push   eax
   0xbffff0b8: push   0x68732f2f
   0xbffff0bd: push   0x6e69622f
=> 0xbffff0c2: mov    ebx,esp
   0xbffff0c4: das
   0xbffff0c5: bound  ebp,QWORD PTR [ecx+0x6e]
   0xbffff0c8: das
   0xbffff0c9: das

Here is how I compiled the program:

gcc vuln.c -o vuln -fno-stack-protector -z execstack

Any explanations on what is going on here would be great!

Your shellcode is on the stack. I presume that your esp register is set to 0xbffff0c4. You pushed 0x6e69622f (2F 62 69 6E), which corresponds to

2F        das
62 69 6E  bound  ebp,QWORD PTR [ecx+0x6e]

This pushes your broken instructions inside your shellcode. It breaks because of this. You can't push when you've got shellcode on your stack!


What prevents people getting charged over NFC in crowded places? I don't have an NFC-enabled device and I couldn't find any information about this in Google. What is it that protects me against an attacker with a portable NFC terminal charging payments by just bumping into me on the street? Do all NFC devices require user interaction to confirm payment?

I can see how a mobile phone might ask me to confirm the payment, but an NFC-enabled credit card is unlikely to have the input or output devices to prompt me for such a confirmation.

One major factor in NFC security is that near field is difficult to range-extend and so charge from a distance, but it has been demonstrated up to 115 cm. Which is not as crazy as the range extension for keyless car entry, but still significant.

There is nothing to stop the NFC being read from a card in the UK according to this study conducted recently by a security firm called ViaForensics.

On a NFC enabled phone the article states that the NFC hardware is switched off when the screen is not lit.

original link (broken as of 2015-oct-27)


Job laptop and VPN, security concerns for home network? I've asked if I could continue working from home. They said ok. The laptop belongs to the company with VPN on it. From home I'll connect the laptop to my personal network/rooter with wifi. When I'll deliver the laptop I'll change my personal/home wifi password. Is there any other security concerns for my home network while I am connected to the office VPN? They can see other devices of mine? Should I worry for something? They (the IT administrators) can access my home network?

Is there any other security concerns for my home network while I am
  connected to the office VPN

Someone from IT department of your work who wishes to gather info on your home network can do that using your laptop. (though this is so risky, you wouldn't believe the legal complications if you'll find out that)

  They can see other devices of mine?

ARP, packet broadcasting, etc makes it easy to collect information passively.

  Should I worry for something?

Unless someone took a personal interest of you, or there some kind of maniac trying to stalk you, no.

  They (the IT administrators) can access my home network?

Peculiar question. Network, yes. Shared files over the home network, yes. Sniff your traffic, yes. Get your wifi password, easily. Send something malicious to other devices, sure.

Guest mode, Access list, separated VLAN, whatever segmentation or control features your router have, you can use to segment your work laptop from home devices.


What is the PKCS#7 detached signature format? This website claims that (emphasis added):

In PKCS#7 SignedData, attached and detached formats are supported… In detached format, data that is signed is not embedded inside the SignedData package instead it is placed at some external location…

However, RFC2315 seems to define no such "detached" format.

SignedData comprises:

version = INTEGER 1
digestAlgorithms: SET OF DigestAlgorithmIdentifier
contentInfo, comprising:

contentType = data (OBJECT ID “1.2.840.113549.1.7.1”)
content: Data = the message that was signed

signerInfos: SET OF SignerInfo, each comprising:

version = INTEGER 1
issuerAndSerialNumber
digestAlgorithm: DigestAlgorithmIdentifier
encryptedDigest: EncryptedDigest = the low-level signature

Neither SignedData/contentInfo nor ContentInfo/content:data are OPTIONAL; and the former may only be one of the six defined types: data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData; I see no detachedData or any similar options. (Choosing digestedData does not resolve it, as ContentInfo/content:digestedData is also non-optional.)
What belongs in the contentInfo field of a detached SignedData object?

From section 7 of RFC 2315:
    3.   The optional omission of the content field makes
         it possible to construct "external signatures," for
         example, without modification to or replication of the
         content to which the signatures apply. In the case of
         external signatures, the content being signed would be
         omitted from the "inner" encapsulated ContentInfo value
         included in the signed-data content type.

So this "external signature" is a detached signature.


Buffer Overflow protections in custom library Does a custom library affected by a buffer overflow need to be compiled with protections even if it is linked against an executable which already has protections?

Compile-time protections in an executable do not confer protection to code in linked libraries, or vice versa. If you have an executable linked against a library, both the library and the executable must be compiled with protections if you want to protect the entire thing. If only the executable or only the library has the protections, then vulnerabilities present in the code that is not protected may be exploitable.


Physical machines not detected when scanning from a VM Some time back I asked about using metasploit on a virtual machine here. This question is a kind of 'part 2' of it.
My testbed set up consists of 3 physical machines: A, B and C. Each of them have 1 or 2 VMs running on them, each VM running in Bridged mode (this is what was recommended in that answer).
Say machine A has a VM which has BackTrack 5 r2 running on it, which i use to scan my network (Metasploit -> Armitage -> 'Hosts' tab -> nmap scan -> Quick scan (OS detect)). I notice that the VMs running on physical machines B and C are not detected by the scan. While another VM running on the same physical machine (i.e., A here) does get detected. I am not talking of just OS detection, but detection of the presence of the virtual machines itself- even though I can ping any of the VMs from any other.
Is it some limitation concerning the use of VMs for such an environment or some mistake in my approach?

Because you are running the scan from within a VM on MachineA, scanning the VMs on MachineB and MachineC and doing it in bridged mode, you ARE going to get odd responses. The host machines are going to make subtle changes to the traffic because the hosts are acting a little like routers. If you have firewalls on the hosts, they will cause their own interference.
Nmap uses TCP/IP stack analysis to perform OS detection. Although Bridged Mode is supposed to bypass the TCP stack of the host, there is still some interaction.
Zenmap
As for Zenmap, the UI gives you the commandline it is running in the "Command: " line. You can add to that with your own modifications like @MarkHillick suggested. (-Pn)


What to make of inconsistent TFA/2FA verification emails from AOL My parents use AOL (there's no point trying to migrate them at this stage) with two factor authentication. My father let me know that he recently received an identity log in verification email that looks suspicious.
The resolved client location in the email my dad received is marked as Brazil, which would imply to me his password's compromised by someone routing through Brazil and we should rotate his password and review his security.
However, the verification email itself is a bit suspicious to me. Maybe I'm being paranoid, but I resurrected my old AOL account, which also has TFA, so that I could trigger a verification email to compare it. There are some odd variations I circled in red.

In the suspect email (left) there is no "name" in the salutation (maybe just bad email templating), and the verification code is 8 characters long. In my trusted verification email (right) the verification code is 4 characters. Also, my name appears in the salutation (though purposefully obfuscated).
Although I'm sure AOL could be using variable length codes, their challenge form specifies 4 characters even when I used a couple different browsers/devices. Maybe our accounts are flagged for different verification code lengths somehow, but I keep consistently getting 4 characters.  I tried and failed to find any literature on pros/cons of variable verification code length or any official word on what length AOL uses.

The safe route seems to be to rotate his password and move on. However...
Is there anything possibly nefarious about the "suspicious" verification email?
The sender information, links, and overall formatting seem to imply the email is in fact legitimate. It's just weird to notice those irregularities.

Per Filipe dos Santos' note in the comments I reached out to AOL support. It took some prodding, but it sounds like 4/8/variable length TFA codes are possible, "For more security"

The missing salutation is odd, but probably more to do with poor formatting.
I'd say in this particular case there's nothing nefarious/suspect. This experience reinforces for me that consistent behavior and user messaging helps encourage trustworthiness.


Proper implementation of HIPAA within iOS app with several factors We are developing an iOS app that allows users to store/modify Protected Health Information (PHI) and the app needs to allow users to do so without an internet connection for large parts of the process. We will need to encrypt the data but are having a difficult time coming up with a solution on how to properly do so as we don't want to store the key in the code and the data would still need to be able to be accessed without a connection to a server.

Our working idea is to encrypt the data using the user's password (which would not be stored on the device) but we run into an issue where other users may need to modify/access that data on that device via their own login. (In the event one iPad breaks)

The ideas we've tried to work through but don't seem secure are:
- Storing a static key in code
- Storing a dynamic key given by the server in a local sql database
- Storing the dynamic key given by the server in the iOS keychain

We were considering having both users login upon data retrieval and encrypting it with both passwords but we run into user-related issues where the data could be locked if one user isn't on duty or not nearby.

Question: How can we properly protect PHI on iOS so that it can still be accessed by those who are allowed to access it, potentially offline, and doesn't restrict the data to being viewable by only one person - preferably without storing logins (as we don't want user credentials stored)

Follow-up: If this isn't something feasible, what would be the best course of action to take to meet most of the needs above?

Edit:Clarification
Authentication takes place originally when pulling down/submitting data and we need to encrypt the data that's pulled down while keeping it accessible to previously authenticated users without storing the key.

Disclaimer:  My company makes a HIPAA-compliant iPod application.  I'm responsible for the compliance...

The iPhone actually meets many HIPAA requirements out of the box.  Once a passcode is set on the device, the contents are encrypted -- which takes care of many HIPAA requirements, notably encryption at rest.

For downloading the data, you must use a TLS or otherwise encrypted connection to make sure data is encrypted in transit.

You have to configure your application to download and push a security policy to a web site in a .mobileconfig file that forces the users to set a passcode on the device to use the application.  If the passcode is set, then the device is encrypted.  So, the .mobileconfig will enforce this.

You also should leverage use of the keychain to store any type of token or credential provided by the user.  To make it simpler, you can have your app require a 4-digit passcode to unlock those credentials from the keychain --rather than have them retype a password on the phone.

If the app does not have a network connection to the server constantly, you can create a sync button.  This will sync relevant data to the local filesystem.  When changes are made, it saves it locally, until the app is told to sync again, in which case it reconciles changes with the master web app database.

Finally, this is not an exhaustive description of iOS HIPAA compliance, I encourage you to consult with a lawyer to draw up your security policies and other documentation, which is required to have under HIPAA.


Best way to authorize and authenticate a user on web API I am doing a hypothetical web just for learn some security tips and the first problem I've found is the login, I've read like 40 articles, a lot of questions here on stackoverflow and I still don't know which method is the best one (this is a non-real case, so we can assume we need a very high security)

most webs I've developed I use a expirable access token that I need to send on every call to the API via query param or via Authorization header, then I store the token on the local storage

I've read some articles that claims that way is unsecure and the best way is with cookies, I've read also that the best way is with sessions

Any hint? I'm a bit confused about which way is the best one to secure first the authentication and then the store of the access token to make the authorization

"Best way" is almost always subjective in questions like these. There are some very good ways, and you should consider them all and how they fit your hypothetical scenario in order to select the "best" one.

That said, one method that I would rank highly would be using mutually authenticated certificates, aka "Client Certificate" authentication.  TLS can require that both the server AND the client use certificates to establish the connection.  In order to connect to your service, the clients would need to prove themselves to a certificate authority and request a signed certificate, which they would send as a part of the TLS handshake process.

You could also require the certificate provider to issue the client certificates with a suitably short lifetime to make sure that the clients are authenticating to the cert provider on a regular basis.

Also note that authenticate and authorize are two very different activities.  Certificates are great for authentication, but you should probably be looking at a different mechanism for authorization.


LFI code execution when directory specified I am working on hackme, which introduce LFI in php code.

<?php
if (isset($_COOKIE["user"])) {
    $file="txt/".$_COOKIE["user"];
    include $file;
}
?>

So I can include any file from the system by just setting cookie user to file location, eg: "../../../etc/passwd".

Is there any way to use this vulnerability to execute my own php code?

I have tried using:

/proc/self/environ
/proc/self/fd/0
/proc/self/fd/1
/proc/self/fd/...

neither was working (no results) and errors was similar to this one:

  include(txt/../../../proc/self/fd/2): failed to open stream: Permission denied

Well, there may be many ways to do something like this.  I agree with the comments regarding doing some research into exactly what an LFI is doing, and looking a bit at RFIs to help understand the implicit differences.

As to your question, the answer would be yes, but strictly theoretical as we have no direct interaction with the application, therefore I do not know if the application is even vulnerable to other vectors that may come into play.

Without giving you the answer, as these types of vulnerable applications are for learning on your own, there are multiple ways to potentially execute PHP via LFI, most involving uploading a file in some way, but that's not nearly always the case.  Some examples: via some sort of stored comments, accessing the page via LFI and having the code execute; via uploading through some sort of file upload functionality and accessing the shell you uploaded via the LFI; via turning your LFI into an RFI (have you tried?); via escaping the command that's causing the file read (your injection point), and running PHP after it, and a plethora of other potentials.

Since you control the cookie and it's reflected directly into the PHP, have you simply tried cleanly closing the statement the cookie gets dumped into, and writing more PHP afterward?  This would be the first thing I would try when a value gets reflected, unmodified, into code in use on the server.

Hopefully this can be an answer 'enough'.  These types of questions are a bit subjective, but this may help.


Encrypting intellectual property on client side Is it possible to effectively protect/encrypt intellectual property that is on the client side?

Assume that I am selling a product (software) to clients, that contains intellectual data, for example malware signatures in the case of an antivirus product. What I do not want, is competitors to get my end-point solution and extract the valuable data for their benefit.

How do companies tackle such a scenario? Or does this problem have a solution at all?

I assume that the basic approach requires encryption of the data while on the disk. Of course the decrypted data (part of them) and the key for decryption are in RAM at some point, which means that access to RAM means access to the data eventually, so for this scenario lets assume that we do not care about the RAM issue and we only care about data at rest.

So assuming that I decide to encrypt my data on the client side. My problem is the handling of the encryption/decryption key:

If the key is in the appliance/code (hardcoded, file, etc) then eventually it will be exposed by reverse engineering. If I have access to the Internet maybe I can create a complex PKI scheme to lets say decrypt the data on Server side and send them back to the client. But maybe this is not a given (you would expect an antivirus to work without Internet connection even with old signatures), or has very expensive performance.

How can someone effectively resolve this?

If your data at any point is in plaintext on user’s machine – you can’t secure it. You can do many things to protect it, but this would only slow down a dedicated attacker: obfuscating source code, encrypting data at rest, rotating encryption keys on server, etc. This is the territory of DRM, and there are many companies that will sell you their solutions.

Every DRM system would sooner or later be broken (if your product is worth it), game piracy shows this pretty well. Also, as you’ve pointed out, any strong defense like server-side crypto would be inconvenient for users (and probably expensive four you). I propose that valuing UX over IP protection would offer a much bigger competitive advantage than having an unusable app with close-to-perfect IP protection.

GitHub is a good example. The source code of the self-hosted enterprise version is encrypted at rest with a pass phrase "This obfuscation is intended to discourage GitHub Enterprise customers from making modifications to the VM. We know this 'encryption' is easily broken.". And despite having a large chunk of source code for github.com available to every enterprise customer, they’re still in business. Offering useful service was better for business than stringently protecting IP.

There are some other ways to protect against IP theft by your competitors. One classical technique is called “Paper Towns”. Since the maps of the same area would look very similar, cartographers started to put fake towns on their maps, and if your fake town shows up in the competitor’s map then you’ve got the proof of IP theft. Even google maps does this. Recently genius.com has shown that the lyrics in google’s search result were scraped from their site by encoding a message in alternating kinds of quotation marks in the lyrics.

You can protect antivirus signatures in an analogous way: by including some signatures of a fake viruses, and periodically scanning these fake viruses with the antiviruses of your competitors.


What encryption and signature systems (don't?) allow for plausible deniability of the OP's key being used? I need to prevent Mallory from blindly matching encryption and signing keys to messages

Hypothetical scenario:

A user creates a public key
An encrypted or signed payload exists.
With only public key, and a signed or encrypted payload, Mallory wants to find out who signed the data.  We want to prevent Mallory from associating an encrypted payload to the public key.

I assume that most modern encryption primitives (GCM, AES, RSA, Blowfish) allow for this type of association, however, it's possible that some protocols (GSM?, SMIME? PGP?) might disclose the signing key in the payload, even if the spec allows its omission.

Question

Can someone either tell me which crypto allows for plausible deniability, or conversely which ones do not?*

*I ask in this way to prevent a too broad close reason, because I'm not sure which is greater

Additional Info:

Mallory has the public key, so CPA attacks might be possible, but the data should be random.
It is acceptable that the original signer, and intended recipient can verify the key.
If Mallory somehow MITMs the connection, and passes her key to the signer, plausible deniability doesn't have to apply.

If it is encrypted, just knowing the public key it may be possible to conceal the key that was used. As the public key will just be encrypting a random key for a symmetric cipher, a large enough key length means it can't be bruteforced. The owner of the private key simply decrypts the key and tries if the data is properly decrypted (eg. an attached hmac). Mallory simply can't test all possible keys.

On the other hand, if the data is signed, by its very definition it must be possible to verify that key A signed data. So Mallory could always determine which of the public keys it has signed that file.
(OTOH if Mallory doesn't have your key or eg. a database with the keys from every suspect, even on schemas that contain "metadata" it typically only provides the fingerprint of the key used, so it's useless)

The simple answer is to encrypt(sign(data)).

Obiously, the metadata -such as sending email account- shouldn't be leaking your identity.

This only achieves plausible deniability for the given scenario of blindly matching keys to messages. Bob would be perfectly able to prove that the message he received was sent by Alice. Usually, the term plausible deniability is used to mean that Alice can even deny that she wrote that. For that you can use a protocol like OTR.


Can a URL that has no links to it be discovered? Say there is a URL example.com/abunchofrandomsymbols and there are no links to it anywhere on the internet. Could it be discovered somehow?

My guess is a browser like Google Chrome could report it to Google. But would Google do something like that?

I understand this question belongs to security through obscurity category and maybe not a good idea, but still, would such URL be discoverable?

If you are asking whether "URLs can be discovered somehow", then the answer is definitely yes. For more information, you can check the links provided by Steffen Ullrich in a comment to your question. Full URLs can be leaked in several ways: they are probably recorded in server logs, they can be sent as a referrer whenever the page loads an asset (image, javascript, external fonts, etc.), they might be recorded by your ISP (unless you always use HTTPS, in that case only the domain can be seen), they can be recorded by malware in case you get infected (infected on your computer or on the website itself), they can be leaked in a lot of different ways by mistake (copy-paste fail, or thinking you are going to browse to a URL and instead the browser/application searches for it sending it as a query, etc.).

And as you said, they can also be recorded by any software you use, often unexpectedly. Your email client might be processing all the content of your emails automatically, for several purposes which might include commercial purposes, and they might be parsing and recording all URLs in the content, for example. The same is true for other (often privacy-invading) software, from a simple text editor to a whole OS. And don't forget the antivirus: it might be trying to record all the URLs it can, to scan them and block them if they are known to be malicious. And all this could be done by your browser too, of course.

As for Google Chrome, does it know what URLs you visit? The answer seems to be yes, but maybe not always and maybe only if you have certain features turned on (which might be on by default anyway): check out for example its privacy policy at https://www.google.com/chrome/privacy/ . Quoting some parts:

  When you can’t connect to a web page, you can get suggestions for alternative pages similar to the one you're trying to reach. In order to offer you suggestions, Chrome sends Google the URL of the page you're trying to reach.
  [...]
  In general, usage statistics do not include web page URLs or personal information, but, if you are signed in to Chrome and syncing your browsing history in your Google Account without a Sync passphrase, then Chrome usage statistics include information about the web pages you visit and your usage of them.
  [...]
  Crash reports contain system information at the time of the crash, and may contain web page URLs or personal information, depending on what was happening at the time the crash report was triggered.
  [...]
  Some versions of Chrome feature Safe Browsing technology that can identify potentially harmful sites and potentially dangerous file types not already known by Google. The full URL of the site or potentially dangerous file might also be sent to Google to help determine whether the site or file is harmful.

This of course does not mean that the URL will certainly be crawled and then included in search results. However you can never be sure of what Google (or other similar companies) is doing with your data, what they plan to do, and what they will do tomorrow. It's a company, with its software and services, with settings/goals/policies that can change very quickly any day.


How to approach 2 tier PKI RSA Root CA with subordinates that should support ECDSA I have a situation for which I am not sure how to approach it. Basicialy I need to find out if it is possible how to issue ECDSA Certificates with a RSA Root Certificate. Is this possible? and how would I go about it?

This is the situation:
Currently there is a single tier PKI with a RSA root. We need a tier 2 PKI with 2 subordinates. The plan is to setup the 2tier PKI next to the single tier and then migrate all the templates. One of the requirements now is however that our PKI should support ECDSA certificates because one of our devices we will start using has the following requirements:

•   Datapath encryption: AES256 Counter Mode
•   Keying messages    encryption: EAS256 GCM Mode
•   Web access: AES256 GCM Mode
•   Digital  Signature: SHA-384, ECDSA-521 for load signature
•   Key generation:    ECC and ECDH P-384 (secp384r1)
•   Web browser supported ciphers:    TLS_ECDHE_ECDSA_WITH_AES256_GCM_SHA384 or          TLS_ECDHE_ECDSA_WITH_AES128_GCM_SHA256

I have seen a post that seems to ask something in the same direction, however the answers that follow are a bit unclear to me.

This is actually not uncommon. Just have a look at google.com when forcing ECDSA ciphers:

$ openssl s_client -connect google.com:443 -servername google.com -cipher 'ECDSA' -showcerts
...
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
-----BEGIN CERTIFICATE-----
MIIHxzCCBq+gAwIBAgIIEW2Lf7xzMtQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
...
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
...
-----END CERTIFICATE-----

openssl x509 -text on the first certificate (*.google.com) shows that it is as expected an ECC certificate, but that it is signed by an RSA key (sha256WithRSAEncryption):

    Issuer: C=US, O=Google Trust Services, CN=Google Internet Authority G3
    ...
    Subject: C=US, ST=California, L=Mountain View, O=Google LLC, CN=*.google.com
    ...
    Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
            Public-Key: (256 bit)
            pub:
                04:94:3c:36:cd:84:17:27:5d:cb:a5:af:ff:b5:4a:
                ...
            ASN1 OID: prime256v1
            NIST CURVE: P-256
Signature Algorithm: sha256WithRSAEncryption
     8a:52:2c:ec:e0:ee:c4:18:33:71:38:10:ea:55:2a:62:68:13:
     ...

The issuer of this certificate is as shown Google Internet Authority G3 and looking at the details of the second certificate provided by the server shows as expected that it has a RSA public key:

    Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
    ...
    Subject: C=US, O=Google Trust Services, CN=Google Internet Authority G3
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:ca:52:4b:ea:1e:ff:ce:24:6b:a8:da:72:18:68:
                ...

Creating an certificate with an ECC public key signed by a CA certificate with a RSA public key is nothing special: just create a CSR for the certificate with an ECC public key and let it sign by the CA. There is no difference in signing an ECC certificate vs. a RSA certificate.


How to know if certificate is self-signed How do I find out if a certificate is self-signed or authorized by CA? Somewhere I read that self-signed subject and issuer will be same, is it correct?

Self-signed certificate will have identical subject and issuer fields, but a) this is not guaranteed, and b) the inverse is not true. Just because the fields have the same value that does not mean the certificate is self-signed.

Here are the outputs from one of our internal root (root-ca.crt) and intermediate certificates (ca.crt):

$ openssl x509 -subject -issuer -noout -in root-ca.crt
subject= /C=DE/ST=Berlin/L=Berlin/O=classmarkets GmbH/CN=classmarkets CA
issuer= /C=DE/ST=Berlin/L=Berlin/O=classmarkets GmbH/CN=classmarkets CA

$ openssl x509 -subject -issuer -noout -in ca.crt
subject= /CN=classmarkets CA/C=DE/L=Berlin/O=classmarkets GmbH/ST=Berlin
issuer= /C=DE/ST=Berlin/L=Berlin/O=classmarkets GmbH/CN=classmarkets CA

You can see that the fields are the same for both certificates, even though ca.crt has been signed by root-ca.crt:

$ openssl x509 -noout -text -in ca.crt | grep -A1 'Key Identifier'
        X509v3 Authority Key Identifier:
            keyid:A2:2D:AF:A0:D2:64:DF:30:F1:72:39:AC:21:AF:45:D6:D4:12:19:94
--
        X509v3 Subject Key Identifier:
            30:B0:6B:B5:56:9A:95:7C:31:4B:B2:65:95:0D:F9:EE:E8:3D:3A:C9

$ openssl x509 -noout -text -in root-ca.crt | grep -A1 'Key Identifier'
        X509v3 Subject Key Identifier:
            A2:2D:AF:A0:D2:64:DF:30:F1:72:39:AC:21:AF:45:D6:D4:12:19:94

Note the absence of the Authority Key Identifier in root-ca.crt.

RFC3280 states in section 4.2.1.1 (emphasis mine):

  The keyIdentifier field of the authorityKeyIdentifier extension MUST
     be included in all certificates generated by conforming CAs to
     facilitate certification path construction.  There is one exception;
     where a CA distributes its public key in the form of a "self-signed"
     certificate, the authority key identifier MAY be omitted.  The
     signature on a self-signed certificate is generated with the private
     key associated with the certificate's subject public key.  (This
     proves that the issuer possesses both the public and private keys.)
     In this case, the subject and authority key identifiers would be
     identical, but only the subject key identifier is needed for
     certification path building.

So it seems to me that the Authority and Subject Key Identifiers are a much better indicator for self-signed certs than the Issuer and Subject fields. For a self-signed certificate the Authority Key Identifier will either be absent or have the same value as the Subject Key Identifier.


Guaranteed Public Key Authenticity besides Physical Meeting and (Possibly Untrustworthy) Root CA's I would like to ask if it was possible to somehow transfer a public key and guarantee it without having to physically meet and verify that the person I met is who they say they are and without having to rely on a third party that may not be trustworthy (because of government mandates or because of the currency of data). I have thought of several ideas such as Convergence by Moxie Marlinspike, but that requires trusting that every notary out their is not evil and I have also thought of China's Quantum Satellite, but that would require a physical and secure exchange (am I right?). Cost is not an issue as I just want to know if it can be done.

The last thing I can think of is the shared secret and I think it may work, but I do not understand how can both computers generate the shared secret and know what the other computer generated, or does it matter (as the Wikipedia entry for Diffie-Hellman seems to indicate with the paint example that both secrets are different colors)?

Basically, I want to know if it is even possible to guarantee that a Man in the Middle Attack is not possible without either physically meeting or trusting a third party. Thanks!

Edit: Well, something I did figure out based off of Mike Ounsworth's answer is that since it isn't realistic for me to meet every person who wants me to verify keys, I could do things like print the key's fingerprint on business cards and post it in as many places as possible as it is a lot less likely that an attacker could modify every copy of the key or fingerprint and a person that really wants to confirm my identity could check multiple sources to do so even if they don't know me. This would be a combination of "meeting in person" and third party distribution that would satisfy me. After all, in order to modify everything in this world, one would need control of the whole world and if that happens, then we all have bigger problems on our hands. (This sounds a lot like the Tor Timing Correlation Attacks which shows we all have problems if this happened).

The fundamental question you're wrestling with here is:

How do I know that the human at the other end of the internet is who they say they are?

As far as I know, there's only two ways to accomplish this:

Pre-share some information out-of-band, usually the hash of your public key, at a physical meeting, a phone call, printed on paper in a sealed envelope, etc.

If you have a common person that you have both already established trust in, then you can extend trust. Ex.: a mutual friend in PGP, or a common root CA in PKI.

If you want to reject both of these and conjure trust out of thin air, then you might be stuck, regardless of the technology you use.

On the note of technologies, let's talk about two:
Diffie-Hellman
DH is a method to establish a shared secret with someone at the other end of the wire in such a way that an attacker can't eavesdrop it. DH has no inhearent mechanism to authenticate that the person you're talking to is in fact who they claim to be. When authentication is required, DH is usually augmented by requiring each person to have a certificate issued by a commonly-trusted root CA.
Quantum Key Distribution
If cost is not a concern, then QKD might be your answer. Instead of sending information encoded in voltage, like we usually do, a ~$1 million USD QKD machine encodes information in the spin of quantum particles. By the laws of quantum physics, this means that any eavesdropping will alter the message and the receiver will know. Like Diffie-Hellman however, this is a way to secure information in transit ... it doesn't do much to prove which human is at the keyboard.


How does a BlackBerry handheld connect to BES? How does a Blackberry device connect to BlackBerry Enterprise Server (BES) for the first time? What are the security mechanisms used to protect against a rogue BlackBerry handheld trying to connect to BES?

This should help you out: http://docs.blackberry.com/en/admin/deliverables/25762/BlackBerry_Enterprise_Solution-Security_Technical_Overview--1315426-0302055542-001-5.0.3-US.pdf

The basic idea is a new device is provisioned on BES with an activation code that is communicated to the user. The user enters the activation code and BES generates a device transport key when it connects. The device transport key takes care of authentication after enrollment.

A rogue device could possibly connect if the activation password is intercepted and the rogue device is connected first. The only problem with the scenario is the administrator would have an indicator that a rogue device is connected when the end user complains that the enrollment did not work.

The BES architecture is well thought out. BES attachment handling has been the achiles heal.

http://btsc.webapps.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB27244

http://btsc.webapps.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB17118