Are there any free, premade penetration testing labs?

Honestly, the best solution I have used is Core Impact, but it doesn't come cheap. Of course there is always BackTrack, which includes most of the tools you'll need and is completely free.

However, I would say that in almost all cases a one stop solution will not fit all situations and its best to have a wide and varied tool set.

I would suggest always having a good intercepting proxy, like OWASP ZAP or WebScarab.

In some cases you'll also find that these tools are just not good enough and you have to create your own tool to exploit a vulnerability.


Should I buy nonsense domains just to make sure my clients don't visit a misspelled domain?

Only you can decide whether or not it's worth it. There are a few situations that you should consider:

How does your typical user visits your site? Are they primarily visiting because you gave them physical business cards or adverts where they have to type your domain manually? Then you should register and redirect all common typo domains to your main domain. Are your users primarily visiting you from online adverts or search engine? Then you probably don't need to worry much about typo domains.
Are you aware of overseas businesses in similar industry that have similar sounding names that might one day expand to your country? Then you might want to consider purchasing their domain name to protect your own trademark.
Are you using a country specific TLD? Are you not on the .com.xx of your country's TLD? Are your main domain on a novelty TLD? Then you might want to consider purchasing the .com version of that domain name, in case you have users that thinks that every website ends with .com, or if they tried to use Ctrl+Enter on the URL bar.
Are there other countries that your business might plan to expand to in the near future? Then buying your name under that country's TLD might be something you might want to consider.
Does your main domain names consist of common, regular words in the language in your primary audience? Is there common, similar sounding/similarly typed words or synonyms that your audience might misremember your name as? Does your name consist of unusual words?

One thing you definitely want to do to set a budget limit on your domain purchases. The number of you would have to have for this kind of typosquatting are endless. There are endless variety of permutations and you cannot purchase every single permutation of typos and similar names unless you have endless budget, which I assume you don't. So you'll need to set priority of what matters to you most. Domain names aren't that expensive, but they do cost quite a bit, and you need to renew them every year or so. If you're a smaller business, holding 500 typo domains are going to eat into a good chunk of your revenue. If you are Google, these expenses are negligible.

How much are you willing to spend to hold an asset that don't actually make you any money, for a situation that probably won't matter much even if it happens. Do you have other ways you could better spend the money? That $100/year you spend on squatting might be better spent on upgrading to a higher tier server or to buy a CDN service to help improve that performance issue that you've been having.


Facebook changed the default email address for every contact.  How do I mitigate the impact and risk?

What are the exact circumstances that cause the default email address to change?

Facebook wants control.

If the email address has changed, how does that affect liability?

Just change it back?

How does one mitigate the risk, and/or undo the changes?

You change it, like you have always been able to do, Facebook even has a support article on the subject.


Can isolated forms be dangerous for my server security?

Your main concern, if you can use these scripts to "write back" to the page, is Cross-Site Scripting (XSS). You should also be aware that just because you don't link to a file, doesn't mean someone won't find it on your site. There are tools (e.g. dirbuster) that can brute-force file and directory names on web servers to find interesting things like admin scripts.

Bottom line: don't put test data on your production server, or, if you absolutely must, at least put the scripts in a directory protected by a password (e.g. htpasswd for Apache).

EDIT: Adnan points out that you want to execute arbitrary PHP code on your server, submitted by users. That's the definition of a horrible security hole. The way that other sites get around it is via heavily sandboxing the PHP installation and blacklisting risky commands, but even then it's not perfect. My suggestion? Don't try to do this if you don't have a lot of experience in PHP, Linux administration, and security.


Security Certificates - Tools to Generate Security Certificates

openssl is a very good command line tool that I have used to create self signed certificates. This will allow you to specify the values for each and every field in the certificate and it is available for both Linux and Windows.

basically you can create a self signed certificate using openssl in just one command

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out mycrt.pem -days 1000

This command will generate a keypair and a certificate with a validity of 1000 days.

You can become your own CA (of course your certificates will not be recognized/validated by browsers) and use this self signed certificate to sign other certificates for your personal use.This process will involve following steps using openssl.

Generation of CSR- Certificate Signing Request
Signing the request (as a CA) by using your self-signed certificate
import the CA certificate in the browser under trusted CAs.

here is a good tutorial on creating your own CA model.


Not really, no.

First, some terms. You mention ARP spoofing; this is not something you can detect at the IP level. ARP is what tells you which MAC address to address your frames to in order to send them to a given IP; ARP spoofing means you think you're sending them to the right IP, but your device addresses them to the attacker at the MAC layer. This can, however, be detected by software that monitors ARP traffic (by paying attention to ARP updates, and noticing when someone sends one that seems to conflict with a previous update).

The defense to a MitM attack on a TLS-based VPN is certificates (others use shared secrets). Someone with a forged certificate has gone well beyond the "done their homework" stage, into the "this is a serious attacker with serious capabilities" stage. Relying on things that aren't designed to stop a MitM in any way and are easily replicable (like an RFC 1918 address, or the list of open ports) is not likely to work. If the bad guy has the capabilities your question implies, they can just forward all packets on to the router unchanged except for those they want to mess with. You can't detect this, except by checking the public key of the VPN certificate against a known-good value, or by detecting the ARP spoofing in the first place.

There are other things an attacker could do; for instance, they could set up a rogue AP connected to the real one. This doesn't involve ARP spoofing, and can't be detected at the IP layer. It's not all that difficult.

Basically: There are ways to do an MitM attack. To prevent that, certificates were invented; the point of a certificate on a VPN is to prevent MitM attacks. You're asking how to avoid an MitM while assuming the thing designed for that exact purpose has been compromised.


Difference between certificates with "extension fields" and "Non Repudiation" usage

The extensions are only some kind of policy meta-data attached to the certificate. Technically, no matter the extensions, a certificate remains the same thing: a file linking a key to an identity. Its information could be used for any purpose: authenticating a server, a client, signing other certificates, signing emails, signing software/driver code, etc.

That's where extensions enters into play: they tell the application which usages are applicable to this certificate, so that when the application encounters the certificate in an unauthorized context it could (or must, depending if the usage is set to critical or not) consider the certificate as invalid and refuse it.

However, this check must be done at the application level. A poorly implemented application may not check these usages properly and accept any certificate at any time.

Also, few supplementary things must be noted:

These extension are only restriction. A certificate with no extension is allowed to be used in any role (no usage limitation), while a certificate containing some extension is restricted to the usage defined by these extensions,
Theses extension are actually divided in two main parts (plus one merely hstorical):

The key usage (like "Non-repudiation" in you example) defines lower-level cryptography usage allowed for this certificate,
The extended key usage provides a higher level usage authorized for this certificate ("TLS Web Server Authentication" and "TLS Web Client Authentication" in your examples).
Some applications also handle what's called Netscape Cert Type, it can be seen as the precursor of the extended key usages and gather usages such as "SSL Server", "SSL Client", etc.

All of these key usages may be associated and used in a complementary way.
Some extension might be flagged as "critical": this flag determine how an application not recognizing / having not implemented a specific extension must handle the certificate. Under such situation, if the "critical" flag is enabled the application must reject the certificate, when this flag is not set the application may still accept the certificate.

Extended key usages names (as well as Netscape cert type) are rather straightforward to understand. Key usages however deeply depend on how the protocol (in case of a network communication) will use the certificates. Commonly found key usages for a SSL/TLS client/server application are the following ones:

Server: Digital Signature, Non Repudiation, Key Encipherment,
Client: Digital Signature, Key Encipherment, Data Encipherment.

So, to answer to your edited questions:

  Does certificate with "Non Repudiation" usage allow to authenticate all clients with/without "TLS Web Client Authentication" usage?

  But "TLS Web Server Authentication" without "Non Repudiation" allows to auth clients only with "TLS Web Client Authentication" usage?

The "Non Repudiation" usage from the server's certificate will be mostly checked by client software, not by the server, and it will have no impact on the way the server will validate client's certificates.

"TLS Web Client Authentication" usage will prevent client's certificates from being used in a server context. It's absence will not block any authentication. However, if a client tries to authenticate using a certificate without this usage but with "TLS Web Server Authentication" instead then the authentication will most likely be refused by the server.


What prevents "money card" (offline smartcard system) from getting duplicated for payment fraud?

I could figure out some informations about the smart card it self.
The chip isn't just holding binary data which every terminal is able to access. The chip contains a micro controller which can get its own firmware set up. So the terminals aren't communicating with the stored data, they just have a API to the microcontroller.

So if you want to copy the data, you have to request the mc to read the data for you. What he ofcourse will deny.

So the other way is, to physically produce a identical chip containing the same controller with the same firmware running on, made for that chip. because only that chips own mc is able to access its binary data and read it correctly. (What sounds almost impossible to me. Even if not, the amount of money won't be enough for the work this would effort)

Or the other option for doing so is: get the controller seperated from the binary data, without destroying it. and hack the encryption he stored the data with, to be able to write plain data in the chips memory.

Without hacking the encryption we could try to shortcircuit the mc...

Even to short circuit the mc wouldn't work, as the money using terminals will use the API to the controller and are also not accesing the data directly.

And I would bet, you can't short circuit the mc, access the data directly and then set back the undamaged microcontroller, without at least making it invalid by some secruity flags or such kind of stuff.

Also notable is that the terminals in generell are just able to decrease the money amount. Such that are able to increase the money are hold by the bank it self and not given out. So they are probably on a way encrypted, that the chip contains a public key which keeps some information about how the "money decrese" has to be encrypted. What would missmatch in case of a increase.

That was all I figgured out, and I would guess this is enough to be an answer even in some one else eyes.


Why cant I bypass user authentication by copying cookies?

The site is probably protecting against session hijacking by using some kind of heuristic to guess that you are not the same user, e.g.:

IP
Geolocation (of IP)
User agent

All of these are imperfect in the sense that they can be bypassed. Some may also filter out legitimate users. Without knowing how the server is configured you can only guess and ivestigate with trial and error. Try sending the exact same HTTP request from a machine with the same external IP and see what happends.

Other ossibilities is that you picked the wrong cookie, missed some other security feature that needs to be included (e.g. CSRF headers), or that the session simply timed out.


Why does StartTLS block connection to apache

When I do openssl s_client -connect myservername:443 -starttls smtp, other clients are still supported just fine.

Of course, the connection from OpenSSL fails:

$ openssl s_client -connect myservername:443 -starttls smtp
CONNECTED(00000003)
didn't found starttls in server response, try anyway...
140029862278800:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 330 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
zsh: exit 1

because the -starttls smtp instructs openssl to use the STARTTLS command as per the SMTP protocol, and my server is a Web server, that talks HTTP (and HTTPS), not SMTP, and it has no idea what "STARTTLS" may mean.

If connecting from a client and doing this (improper, unsupported) STARTTLS actually freezes your whole server, then you have a big problem (namely, a really easy denial-of-service) that deserves thorough investigation, especially since, to my knowledge and as per my own tests, Apache+OpenSSL does not in general suffer from that kind of bug. In fact, given that Apache forks several sub-process to handle clients, and each process handles several (many) clients in parallel, it would be surprising that a bug in handling incorrect data from one client would really block all clients.


Securing internal REST service call via JavaScipt

You can't, really. Anything sent via javascript can be tampered with. Because of this your SPA will be vulnerable to XSS and MITM attacks. An option would be using session tokens and obfuscation which is such a grotesque solution. Plus this will be an opening for CSRF attacks: CSRF. Otherwise, I recommend having your users login so that there will be some form of authentication.


Identification info that my wireless card sends to the (wifi) network

The only identifying information that the card sends is the MAC address.

However, other parts of your system can send identifying information as well.  For example, the DHCP client may send your computer's name to the DHCP server; if you browse the web, you can be identified through browser fingerprinting.


You have basically created a custom hashing algorithm. If no one knows how your algorithm works and no one knows that it is trivially based on MD5, then it will be extremely difficult, if not impossible, to crack this hash. So, to answer your question directly about the hash, it is likely going to be uncracked without further knowledge.

The only real danger here, and it's not a trivial problem, is that if someone finds out how your algorithm works, then your efforts offer no protection at all.

This is known as "security by obscurity". It is secure as long as the attacker forever remains ignorant. One look at your algorithm and the hashes are equally crackable as MD5.

If you hide your front door, then someone with your keys will not be able to get in... Until they find your front door. It is always better to have better keys and locks.


Storing encrypted information in database vs partition encryption

Better for what? In general, encryption is used to prevent someone from accessing encrypted data.

Database level encryption is more complicated to implement at both administrative and application sides. However it prevents unauthorized staff from accessing the data.

Filesystem level encryption leave your database open to any staff member, who has direct filesystem access. However, it's much easier and faster to deploy and debug application using database encrypted such way.

From the application level, if an intruder is able to gain access to decrypted data level, it's irrelevant, on which level the database is encrypted.

So, database level encryption protects you from fraudulent staff, and partially from external intruders. But if you're looking for the best solution for external intruders, you should concentrate rather on application security, than on database level encryption.


If you encrypt the same thing it is normal, if you encrypt something different it is not normal. In that case you have probably an error in your implementation.

A common error is to translate the encrypted result to string for transport, all non-readable bytes are then changed to "?" by .net.


Limit OpenVPN client certificate to specific VPN with shared CA chain

Using hooks

On each server, configure a client-connect hook:

client-connect /etc/openvpn/hooks/client-connect

In the client-connect script, check if the user common name is in a list of common named dedicated for this server instance:

 #!/usr/bin/python3

from sys import exit
from os improt environ

# Load the list of allowed common-names from file.
# One common name per line.
with open("/etc/openvpn/allowed", "rt") as f:
  allowed = f.read().split("\n")

# Allow if the common name is in the list:
if environ["common_name"] in allowed:
  exit(0)
else:
  exit(1)

You can devise any other scheme for deciding if a user is allowed on a given server (naming convntion, looking it up in a postgres database looking if up in a LDAP, etc.)

Using CCD

Alternatively, this list can be defined without hook through with client-config-dir:

ccd-exclusive
client-config-dir  /etc/openvpn/ccd

You should only need to touch a file for each allowed common name:

# Add a user to this service:
touch /etc/openvpn/ccd/john.doe


SFTP between guest virtual machine and its host

I'm not familiar with VMWare Player, but with VirtualBox, if the network is in "NAT" mode (or, presumably, host-only mode, but I haven't tested it), the source IP address for network connections from the guest to the host is the address of the host's network adapter.  For example, if the host's address is 192.168.0.10, connections from the guest will show up as coming from high-numbered ports on 192.168.0.10.

If you set your hosts.allow file to only permit connections from the VM host's public address, this should provide the security you need.

As an alternative option, VirtualBox supports "shared folders": portions of the host's filesystem that are accessible from the guest.  This requires support software on the guest, though, and an Arch LiveCD may not have it.


Create mod page for an anonymous website

The most simple solution would be to protect the files which are part of your admin interface using the http password authentication capabilities of your webserver (like .htaccess on apache). This will prompt you for a username and password via your browser. You rarely see this solution "in the wild" because it's far uglier than logging in through a web-based form, but it's entirely sufficient for private admin backends where beauty doesn't matter.

A solution with an even higher security standard would be to use TLS authentication with both server and client certificates. It means that the connection to the admin portal is encrypted and that the user-authentication works via a certificate in your web browser. Consult the documentation of your webserver for how to set this up. You won't need to get a server certificate from a 3rd party authority (even though you can get them for free now). Because you are the only user, you can simply add your own certificate as a trusted certificate to your web browser.


I have 2 solutions for this.

1)No. Don't give them the password.
If they need your password to perform migration then they should just ask you to input your password.
Note: If the process is lengthy and you need to input it multiple times check option 2.

2) Don't give them "your" password, but give them the password for the device.
Change the password to something generic before handing the device to them. This way if the process is lengthy the person performing the migration can use it whenever he needs. Also, "YOUR" password stays with you (that's why it's secret) and you can use it again when the new device comes. (I strongly recommend changing the password from time to time).
Tip: Make the password something funny so the guy working on your device smiles when he does it. It doesn't hurt trying to make someone smile.


How do credit cards with chip+pin securely allow recurring transactions?

There is a difference between using your CC on a machine (ATM, PoS) and online.

On a machine you will be identified by the CC number and PIN. If you are using card with a magnetic strip - it can be easily cloned. If you are using chip card, then it's safer, because machines can not read the chip, they can only interact with it and ask it to verify if the pin is correct or not and the chip will answer only "yes" or "no". In essence chip is like a little computer, that is specifically designed to be tamper proof (even on physical level - it's encased in a special epoxy and disassembling it without breaking something is quite difficult).

When shopping online PIN is not used for indentification. Other pieces of information are used to verify that you are who you are, like the numbers on the back of the credit card, your full name, billing address, phone number, email address.


How would one verify that the public key from WhatsApp's servers belongs to the person I expect it to?

Both the QR code and the 60 digit number need to be verified "out of band", for example:

Saying the number out loud in a telephone call
Meeting in person and scanning the QR code directly from the other device


The paper On the Security of the TLS Protocol suggests HTTPS provides availability

No, it doesn't.

Quote of the relevant section of the paper:

  II. Security Goals

  ...

  The primary goal of TLS, defined in its specification, is
  “Cryptographic security” [3]. This goal already refers to the
  Confidentiality corner of the CIA triad. The CIA triad describes the
  most necessary security goals a secure application has to fulfill in
  order to provide data security. The following three enumeration items
  describe the corners of the CIA triad [2].

The paper claims that TLS's first security goal "Cryptographic Security" matches Confidentiality in the CIA triad. The paper doesn't claim that TLS fulfills the other two corner of the triad.

  Does HTTPS provide availability?

No it doesn't.

If we refer to RFC 5246, TLS has four goals:

  2.  Goals

  The goals of the TLS protocol, in order of priority, are as follows:

  Cryptographic security: TLS should be used to establish a secure connection between two parties.
  Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange
  cryptographic parameters without knowledge of one another's code.
  Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as
  necessary. This will also accomplish two sub-goals: preventing the
  need to create a new protocol (and risking the introduction of
  possible new weaknesses) and avoiding the need to implement an entire
  new security library.
  Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the
  TLS protocol has incorporated an optional session caching scheme to
  reduce the number of connections that need to be established from
  scratch. Additionally, care has been taken to reduce network activity.

While the paper didn't make a claim about Integrity, TLS together with the associated x509 certificate actually also fulfills the Integrity criteria, provided that you trust the CA system. Confidentiality in TLS is achieved by cryptographic signing and MAC of each packets transferred in the connection, which prevents data traveling through the connection from being altered without being noticed.

TLS doesn't directly improve Availability, although it can improve availability in some scenarios, such as when used with client certificate, a TLS Terminator can be configured to reject unauthenticated/improperly authenticated connections before proxying it to the real server, which could reduce the impact of abuse on a scarce resource on the real server.


How do I check if KPTI is enabled on linux?

Linux kernel logs the KPTI status on boot so, running the following command would print the status on patched kernels. If it prints nothing then, KPTI is disabled.

dmesg -wH | grep 'Kernel/User page tables isolation'

Linux Kernel 4.15rc6 has enabled KPTI(Kernel page-table isolation) and it has been back ported to
Linux Kernel 4.14.11, 4.9.74, 4.4.109, 3.16.52, and 3.2.97.

So, if you are running any of these versions KPTI is in place. Most distros(running any Linux kernel version) will push an update to the Linux kernel within a day or two to fix Meltdown and spectre.

Note: Add the parameter pti=off to the GRUB in order to disable the KPTI. For info: https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter


If I unzip a password-protected zip file, will the person I downloaded it from be notified in anyway?

Unless you open some executable within it or open it with archivator with known vulnerabilities, there is almost no way he can know. You can always airgap it by using VM's or literally disconnecting PC from any network.


If SSL private key is compromised, what can they do?

The attacker can use the private key to either mount an active man in the middle attack or decrypt passively sniffed traffic if RSA key exchange was used. The exact possibilities of an active man in the middle attack depends on the abilities and location of the attacker in the network. Some examples:

If the attacker is inside the local network of the victim he might try to use ARP spoofing or DHCP spoofing to either incorporate the router or the DNS server used by the victim.
At the ISP level the attacker could reroute DNS requests to a DNS server under his own control and this way direct the victim to its own fake system which uses the stolen certificate and key.
Similar attacks could be done if the attacker is near the original server or near the authoritative name server for the domain with the compromised certificate.
An attacker at a different ISP could also bring itself in the path to the original server or the authoritative DNS server by rerouting traffic using BGP spoofing.

For more information see the related questions What can an attacker do with a stolen SSL private key? What should the web admin do? and Can an attacker reuse stolen SSL private key to recreate that domain on his server.


I have to say the usual 'I am not a lawyer' here, and don't know the current law in Germany ( I believe this is changing a lot in recent times, as it is in all countries).

You should probably lock the other guy out and choose a more secure protocol such as WPA2. Not a good idea to let an attacker keep access to your network.

Any lawyers for the copyright holders will be holding you responsible as the packets went through your connection. You can keep a log of the traffic for the intruder on your system. It won't be that much proof, as you could easily spoof a mac address yourself and become your own 'intruder'.

There's really no way to prove your innocence which is what you will be asked to do, since the copyright holders will argue that all they have to prove is that the offending traffic went through your connection. Making it your responsibility to secure your connection properly. You can claim that the manufacturer of the router or your ISP made the protection trivial to break, and that you assumed that since there was a password, you were secure.

You could try some kind of man-in-the-middle attack on the intruder, since you are the man-in-the-middle. This might allow you to decrypt enough traffic to identify him/her, though I doubt it. If the traffic is mostly encrypted, it will be hard to spoof SSL certificates at this stage. This also raises the question that if the traffic is encrypted, how do the copyright holders know what data was in the offending traffic going to your connection.

Beware that a lot of these type of letters by copyright holders are scare-tactics, sometimes not even from the real copyright holders, to extort some money from you to make the problem go away.

Some mac addresses you might not have thought of might also be on your network such as smartphones / tablets / smart-tv / gaming console ... these might be your 'intruder'


Is PGP combined with a regular web-based email service secure?

They key to PGP e-mail security is that it provides full end-to-end encryption. The "path" you describe is actually flawed, and in fact may be overkill depending on your needs.

Hopefully, the below overview will help you see how the multiple layers of security you are suggesting would be applied.

You start with your e-mail.

  [Email]

Your system encrypts the e-mail with PGP.

  [PGP [Email] ]

Your system puts the package into a secure stream addressed to your e-mail provider. (We'll say SSL.)

  [SSL [PGP [Email] ] ] ]

Your system sends that traffic to your trusted VPN gateway.

  [VPN [SSL [PGP [Email] ] ] ]

Once traffic reaches the VPN gateway, the VPN gateway forwards it along to your e-mail provider through the open Internet. However, this is not part of your trusted connection to the VPN gateway.

  [SSL [PGP [Email] ] ]

Your e-mail provider stores the message on their servers. Without intimate knowledge or agreements as to how the provider handles their data storage, you cannot assume that any additional encryption is used.

  [PGP [Email] ]

When the E-mail provider receives your message, they send it along to the recipient's e-mail provider. However, you cannot be sure that their provider's servers require connection security to receive e-mail or that there is any encryption used on their at-rest data.

  [PGP [Email] ]

The recipient contacts their provider's server to check their e-mail. However, you cannot be sure that the recipient's client software is configured to use a secure connection for this.

  [PGP [Email] ]

The recipient finally decrypts the e-mail and reads it.

  [Email]

Strictly for the purpose of ensuring confidentiality of the e-mail message's contents, the VPN is essentially superfluous. In fact, so long as PGP remains unbroken and the keys you are using are trustworthy and un-compromised, every layer of security applied afterward could fail and the e-mail's contents would still remain protected in transit. You could be using an unencrypted connection to your e-mail provider over the clear Internet, from the sketchiest of coffee house hotspots, and your e-mail would still be protected in its travels. That's the point of end-to-end encryption - it's made so that the transfer medium does not need to be trusted, especially because it cannot be trusted.

If you're looking to additionally provide anonymity, then the VPN does have a purpose. However, to be fully effective, this requires that you do not provide any Personally Identifiable Information (PII) to your e-mail & VPN providers (E-mail headers still have to be sent in the clear, and you cannot trust the path between your VPN provider and the recipient. Your e-mail and/or VPN provider may therefore be forced by court order or other coercive measures to reveal your account info & connection logs.) and that you do not do anything over the VPN connection from which your PII can be directly obtained or inferred.

Of course, all this protection also relies upon yours and the recipient's systems being secure. If either system is compromised, all bets are off anyway.

In the end, you should always remember Law #9.


What risks should I be aware of before allowing advertisements being placed on my website?

Yes.  Serving advertising is opening yourself up to attacks from the marketing company, or any of their middleman, etc.
There are two ways you can serve advertisements.  One way is to put the advertisement in an IFRAME.  The second is to include it inline, via SCRIPT SRC=.

An iframed advertisement is safer: it is walled away from the rest of your page by the same-origin policy.  While the ad can still serve unsavory content, display spoofed content, or try to exploit vulnerabilities in the user's browser (in a drive-by download attack), it cannot tamper with the content on the rest of your site or the user's interaction with your site.  However, because the iframe limits what the ad can do (it cannot look at or interact with the containing page; it cannot do expando ads and the like), advertisers generally pay less for these kinds of ads.

An inline (SCRIPT SRC=) advertisement is a greater danger.  If the ad were malicious, it could completely take over your site: it could steal session cookies, plant a keylogger, steal the user's password, disrupt the site's appearance, grab personal information from the user and forward it off-site, spoof user actions, plant unsavory content on your site, etc.  Therefore, if you use this method of including ads on your site, you are placing total trust in the advertising company and everyone they do business with.
Similarly, you can embed a Flash ad in your web page.  This poses similar risks.

Malicious ads have been seen in the wild.  In 2009, the visitors to the New York Times web page were attacked by a malicious ad that was being served on the NYT pages and that showed a fake A/V alert (technical details and more details); the attacker bought coverage for his/her ad by pretending to be a customer of the NY Times.  Apparently, the FoxNews website has also been attacked by a malicious advertisement, as has MySpace, Excite, Expedia, Rhapsody, MayoClinic, Bing, Yahoo, the London Stock Exchange (details), eBay, Doubleclick, MSN, Spotify, Drudge Report, and undoubtedly others.
There have been some studies of the prevalence of malicious ads.  Dasient estimated that three million malicious advertising impressions were served per day in 2010.
In principle, there are technical defenses.  For instance, Yahoo's AdSafe is a restricted subset of Javascript, designed to allow advertisers to build rich media ads (written in Javascript) that can be embedded directly into the page (via SCRIPT SRC), while maintaining security.  However, AdSafe has not caught on, and advertising networks have been reluctant to adopt technical defenses.  Instead, they rely upon their vetting of their clients -- which can be fairly cursory.  There are also some other approaches that might be applicable, including Google Caja, Microsoft's Web Sandbox, and sandboxed iframes, but I'm not familiar with whether they can be readily applied to typical advertising scenarios.
As a result, if you accept ads, you are taking on a security risk.  In many cases this risk is acceptable, particularly if the revenue stream from ads is significant enough.  But I would generally recommend that, if your site is especially security-sensitive, then you should probably avoid putting ads on your pages.


Given two passwords, what is the fastest way to compare the strength of them with john?

There's essentially no way to determine which password is stronger in absolute terms because the strength of passwords depends on the way an attacker is approaching cracking the passwords.  However, it is possible to figure out (for a given wordlist and set of mangling rules) which one would be cracked first by an attacker.

Start by determine what wordlist and rules you want to use.  I would probably use the rockyou.txt wordlist that is well known and combine it with one of the rulesets listed on the openwall wiki.

You can run john in a mode where, rather than cracking passwords, it will just generate the candidate passwords to be tried.  This is called stdout mode.  For example, you can use:

john --wordlist=rockyou.txt --rules=Korelogic --stdout

This will produce a list of all of the candidate passwords, in the order that they would be tried by JtR.  If you have enough disk space, you can just tee this to a file for later analysis.  If you really only care about the two (or so) passwords you're studying, you can just grep for those to get the order they would be tried:

john --wordlist=rockyou.txt --rules=Korelogic --stdout | grep -E -n '^(password1|password2)$'

Thanks to Hector for reminding me of the -n flag to grep.  This will give you the line number for each of the passwords when attempted, showing you (relatively) how far down the generated password list they are -- in other words, how quickly an attacker gets to them.

Alternatively, grep as follows (suggested by dave_thompson_085) to not care about special characters:

john --wordlist=rockyou.txt --rules=Korelogic --stdout | grep -n -x -F -e 'password1' -e 'password2'


Detecting botnets that use HTTP instead of IRC

I know most bots use either IRC or HTTP to communicate with the C&C

As far a I know IRC is not much used any longer in current C&C communication because it is to easy to detect. Current C&C communication tries harder to blend in and uses mostly HTTP, but DNS is also used.

  So if a botnet is using HTTP, how can this be prevented? Just theoretical!

Since the communication is deliberately designed to blend in the normal traffic and sometimes even uses Twitter or common blog sites to exchange information it is very hard to detect. Looking at such a traffic nevertheless often shows small differences to normal browser behavior, like atypical HTTP requests (older User-Agent, special or missing headers...). But that's not guaranteed and malware can even instrument the browser on the system to do the requests and thus will blend in even more.

Another source of information is to look at the history of the target host, because often botnets have a flexible infrastructure where the IP behind a name changes often or where the target host changes often. Thus you might detect it because the traffic goes to unusual hosts or to the same hostnames or IP addresses known from other malware. But again, it's not guaranteed that this C&C communication works like this or rather uses sites where users can generate content (Twitter, Facebook, blogs...) to spread the commands.

Thus it is sometimes possible to detect such a communication when looking at specific requests and sometimes you need to look at the larger traffic pattern from the host (anomaly detection). There is no single technique and there is no guarantee that you'll find it, because like I said the traffic is designed to be indistinguishable from normal traffic.


This seems to be created by someone who is not a cryptographer, I would not trust this scheme to produce "true" random numbers. Additionally, the entropy source still exists in the form of a photograph, and the process can be repeated by an attacker with access to it. Generally with a TRNG, once entropy is extracted, its gone, there is not a copy of it somewhere, it is read into the DRBG and processed irreversibly.
This is best described as an entropy extractor and DRBG, and a giant block of solid green will have essentially no entropy, but this will still output a series of values that pass the NIST randomness tests. The fact that this passes randomness tests is meaningless, so did Dual-EC.
I would be substantially more comfortable if it accepted camera input only, not pictures, and ran something like this:
PRNG = SHA384( SHA512(Camera Input) || (Camera Metadata, time, gps, etc) || (32B System RNG output) )
And took a photo, feeding the PRNG output into a large entropy pool of a DRBG, then spitting out a value for use after enough photos were taken. For a 384B pool, 8 pictures to fill the pool, then each additional picture gives up to 256-bits of output. Of course this is more valuable on a mobile device where a camera can take pictures arbitrarily, a desktop system does not have the same flexibility.
This turns a camera into a whitener for the system RNG, which can be supplied with much better entropy from cryptographic accelerators built into the SOC, but may still be considered suspect. The whitening eliminates the ability for old outputs to predict new outputs, or the other way around, while still making use of the system entropy provided.
Updates:
There were some very interesting comments added to this post, and I figured I should respond to some of the points raised, as they have merit:

From reading the site it intentionally described it in plain English so the content is understandable for a wider audience. Perhaps this gives the impression that it is not created by a cryptographer.

That is not the reason for my initial comment, I prefer an algorithm/scheme design to be readable in both plain English and a pseudocode for comprehension, and a good job was done in the plain tedxt respect. My comment was based on the design itself.

Moving a photo from a standalone camera to an air-gapped computer then erasing it afterwards does not give any attacker a chance to repeat the process.

Erasing data is not always successful, that is common knowledge. Also an attacker can go directly to the airgapped system to get the data if it is still there. Or they can un-gap it with an implant, even in a faraday cage (acoustic and optical transmitters). A RNG that relies on a faraday cage and airgapped systems for security has a huge usability problem.

It's actually just a randomness extractor using a hash function, essentially a TrueRNG ... The entropy in the photograph is used only once.

No, nothing about this makes it true random. It is deterministic by design. The output is determined from the pixels in the photograph.

Reading the site, the critical steps are: carefully taking a quality photo in the first place, and the extra safeguard of removing sequentially repeating pixel colours which is mentioned in step 3 of the mentioned algorithm. Any low entropy sections in the photograph are removed before randomness extraction begins

You are right, I missed the part about non B/W colors. However even if the R value only varies by 1 bit across alternating pixels, that method will not remove the pixels, and the entropy will still be poor.

Your comparison of this design to a deliberately backdoored algorithm by the NSA is nonsensical. Passing randomness tests is not meaningless in itself. It's essentially a smoke test to rule out completely bad input.

Comparing one algorithm to another that passes the same test is not nonsensical. Many pass the tests while being completely broken. Randomness tests are usually used to test the algorithm and make sure the code is working, not the input. Input should be tested before passing to the RNG, and between each functional block. A failure at input should prevent the output from even being generated.

Your counter proposal lacks a coherent definition to be implementable, appears to be quite slow and throws away an enormous amount of entropy to the point that the scheme is unusable. For a start, what is “Camera Input”? ... What is its data format? How is it loaded into the program? ... You don't mention how the user should take pictures.

I was not designing a counter proposal, it was just a basic example of something that would generate 384-bits of output from a single camera input. Something that I would trust more than that in JC. I did not describe any component in detail, or the motivation behind them, just a high level overview. What followed was also a fairly basic example of what to do with it. Slow? I doubt it. Unusable? Not at all. "Camera input" is the information the camera captures, sent directly to application memory without transfer to disk.

Also it's intriguing that you immediately switched to using NSA designed SHA2 hash functions in your recommendation instead of openly designed alternatives by trustworthy cryptographers ... I wonder what the point of using both SHA384 and SHA512 is other than making it slower. Surely you could do only one hash of all the inputs concatenated together.

The SHA2 family is one of the most studied of all hash functions. No it is not designed openly, but it performs well, has a simple implementation, and has withstood decades of analytical attacks on both the compression function and the full hash, notwithstanding the problems that apply to all MD type hash functions, which are not relevant to this type of use. I also like Blake. Keccak is slow.
The point of using 2 different hash functions with 2 different sizes is simple. The first is to compress the entropy of the photo down to a 512-bit value. The second is to diffuse and compress that value with additional data and additional entropy, while using different initial values, and truncating the function to hide the full state by a cryptographically strong amount (128-bits). You could also use HMAC with a key from system entropy, and truncate, instead of using SHA384. Once again it was just an example, but there is logic behind the construction.
And finally

This answer seems to be created by someone who is not a civilian, I would not trust this schemer to produce “true” random numbers.

The implication that I am an intelligence agency plant makes me feel all warm and fuzzy inside. If I say I am not, will you believe me? Am I also correct in assuming that you are one of the program developers/contributors or related in some way? I don't expect an answer to that. I will say that additional edits would not be appropriate for a back-forth discussion on merits of the scheme in question.


Is it ok to append the nonce/iv to the ciphertext when using AES GCM?

Absolutely. There is no risk from appending the nounce/iv to encrypted text.


User Groups (Circles) Inside a Web of Trust

There are two generic points which must be made:

PKI is for authentication, not for authorization. "Certificates", be they X.509 or OpenPGP "key signing" (same concept, different format), are meant to bind identities to public keys; they convey the information "Bob's public key is X". Certificates don't work well to manage authorization-like information such as "Bob is allowed to sign in the name of Company Y".

Revocation is the subject where this distinction is most easily seen. Revocation is asynchronous; it is not efficient as propagating changes quickly. If Bob is fired, you want to revoke his "signing rights" immediately, preferably five minutes before informing Bob himself that he is no longer welcome. You don't want to remove the rights some hours or days after the deed, because there is a lot of harm that a disgruntled Bob could do.
You cannot enforce forgetfulness. In cryptography, power is knowledge: you can sign or decrypt by virtue of knowing the corresponding private key. When a participant has this power, then he somehow "knows" the private key, if only potentially (e.g. the key is in his computer). If he chooses to remember the key forever, well, he can. You cannot make sure that he did not keep a backup somewhere.

To remove signature power from a user, you must make his key obsolete. This means generating a new signature key, and giving it to all the remaining signers (excluding Bob).

Sharing signature keys is not recommended anyway. When a secret is known to more than two persons, it is no longer secret, only somewhat discreet. If you want to allow a group to perform signatures in the name of the group, a robust solution would take the form of a signed, dated, short-lived, authoritative list of "allowed signers". A document which says "On April 30th 2013, Alice, Charlie and Donald are allowed to sign in the name of Group Y"; the document is then signed by a group manager. Verifiers will check the signature on this document to see whether the signer is really part of the current list of allowed signers.

The "group manager" must be an entity who can decide who is part of the group, and who is not. This is inherently centralized, thus at odds with the decentralized model of the Web of Trust.


How Secure is Storing Cryptographic Information into the CPU Register instead of RAM

An answer obviously depends on the kind of CPU you are talking about.

For example, with general-purpose registers on a modern x86 CPU, you have several problems:

CPU registers are mostly 64 bits wide. To store a cryptographic key of decent size, you'd need at least two registers. This is a problem because the number of registers on x86s are very limited (it's even worse with older x86 CPUs)
CPU registers are the main "work area" of a CPU, so you can't store a cryptographic key there for longer periods of time because there is basically no protection/isolation in effect - any register, except some special purpose registers (which, however, are needed for correct functioning of the operating system/task switching etc, and therefore can't be used to store cryptographic keys), can be accessed by anyone who can get the processor to execute a few instructions. This isn't true for memory, which can be protected from access by unauthorized programs.
On operating systems which support multitasking (so, basically every current OS), when a task switch occurs, all the register contents are saved to RAM when a task is preempted and reloaded from RAM when the task is given the CPU again. This happens dozens, if not hundreds of times per second. So your cryptographic keys would end up stored in memory anyway. They might also end up swapped out to disk when a page that stored a currently stopped task was swapped out to disk to make room for another process.

Edit: As your followup comment and my repsonse to it explains, you can work around some of these problems using special purpose registers which are usually unused. However, there are still problems that don't seem to make this worthwile:

Your OS must cooperate - if it happens to use these special-purpose registers for the purpose they were actually designed for, your keys get overwritten, and your data may be trashed without you noticing it.
You're still only protected against cold-boot attacks (assuming no state actually leaves the CPU, which isn't so easy to guarantee due to task preemption) and against low-privilege attacks that can't get access to ring 0. When your kernel gets compromised, your keys can still be easily stolen with just a few simple CPU instructions. It might be even easier to steal them in that case, because you'd know exactly where to look for them. So you're not adding any security except against cold boot and maybe some DMA attacks (when an unprivileged program stores keys in RAM, other unprivileged programs can't read them, either).

I don't know how prevalent cold boot attacks for key extraction actually are in the wild. I'd assume state-sponsored special ops teams, plus your occasional gadget freak might pull them off. But I'd worry much more about compromised OS kernels than about cold boot attacks.


API Design Model - Client Side Encryption

You would need a session level key that could be given to the non-trusted javascript.  Basically a site running the API would need to have the ability to request an individual session for each of the users from their API key and then the user's session would have to use that key.  This allows the trust to be maintained between you and the server hosting content while also allowing the user to perform operations based on the server's key without divulging it.


How will SHA1 deprecation affect internal CA's?

Microsoft has had the logic in place for some time.

By default, any certificate that is a subordinate of a trust anchor from the Microsoft Trusted Root Program will not be trusted after the cut-off date if the subordinate has a SHA1 signature.  Any SHA1 certificate that is a subordinate of a locally installed trust anchor will still be trusted.  This is the case for all applications that use Microsoft's built in CAPI for their certificate processing, which includes Internet Explorer and later versions of Chrome.

Mozilla decided to do their own thing with the Firefox browser (as it doesn't use CAPI) and stopped trusting any SHA1 certificates, regardless of whether the trust anchor is internal or part of the Mozilla Trusted Root Program.

Remember that all trust anchors are trusted because you (or the browser/OS developers) explicitly placed them in the trust anchor store and not because they are digitally signed.  Therefore, whether the trust anchor certificate has a SHA512, SHA1 or MD4 signature makes no difference whatsoever - the signature is not used to imply any trust or security in the certificate.


Hardware Level Write Protection for a CD-R

A CD burner works by firing precise beams of IR or UV laser radiation at a targeted point on the disc surface, where it interacts with a chemical dye. This dye changes optical reflectivity when exposed to such radiation, hence the term "burning". When reading it back, a lower intensity beam (usually at a different electromagnetic wavelength) scans over the disc and interprets the levels of reflectivity as a signal. When appropriately interpreted, this produces a stream of 0s and 1s.

There are two primary ways of encoding such data. The first is simply to assign "reflective" and "non-reflective" as 0 or 1 directly. One downside with this is that it is prone to errors. A speck of dust or a small scratch could corrupt the data, so extensive error detection and correction (e.g. parity) data blocks must be included. An alternative method is to use transitional encoding, which converts the transition of reflective to non-reflective and vice versa as 0 and 1 bits. This helps improve error detection and correction because long runs of reflective or non-reflective responses are simply ignored. Parity is still required, but to a lesser extent.

If the former method is used, it may be possible to etch more non-reflective bits (whether these are determined as 0 or 1, I am unsure). However, in my understanding, this simple version of encoding isn't commonly used.

If the latter method is used, things get more complicated. Causing a reflective bit to become non-reflective would break the transition (i.e. you'd have non-reflective followed by non-reflective) and simply destroy the bit. The parity would then correct the error, assuming there is enough remaining data. Since the read controller is aware of its position on the cylinder, trying to damage a single bit-pair in the hopes of offsetting the data in a way that allowed you to control it wouldn't work, as it would recognise that the bit-pair was destroyed and move on to the next bit pair, rather than shifting the stream by one bit.

The only trick I could see being feasible is to destroy the data to the point where the parity correction results in the wrong data, but this would not allow you to arbitrarily alter data - the results would be bound to a strict set of outcomes, based on the calculation of the parity. As such, it is relatively infeasible to modify the data on the disc in any meaningful way.


What is the risk of using Windows Phone 8.1 now?

Unsupported operating systems can have vulnerabilities that have no patch. Over time, that threat grows. That means that it becomes trivial for an attacker to be able to breach the device. A breach of the device means that all data on it is exposed as well as all the accounts (business, email, personal, banking, etc.).
Yes, there is a chance that the OS does not have a serious flaw, but there is a small set of people in the world who can make that assessment, conclusively. And a CPA is likely not in that set.
Updating from unsupported software is listed as an "essential" item in the NCSC's Cyber Essentials certification. If you don't, you are rolling the dice.
Links:

Australia ACSC: https://www.cyber.gov.au/acsc/view-all-content/guidance/operating-system-hardening
Standards org: https://nvd.nist.gov/800-53/Rev4/control/SA-22
Industry Framework: https://www.tripwire.com/state-of-security/security-data-protection/security-controls/20-critical-security-controls-control-18-application-software-security/
Media/News: https://www.inc.com/joseph-steinberg/why-you-should-not-use-software-that-is-no-longer-.html


Keysigning and digital message signatures: are they the same thing?

Digitally signing some "message" is a generic concept. Digitally signing a PGP key is part of this broader concept, with the "message" being the signed key.
A digital signature proves only that somebody has signed the message. It is up to the specific use case on what it means if a message is signed. I.e. the technology of signing is the same, but the meaning (semantics) can be different for different use cases.
In case of signing a PGP key it means that the signer has somehow verified that the key belongs to the one claimed in the key. Similar in case of signing a X.509 certificate (like used in HTTPS) it means that the certificate authority (the "issuer" of the certificate) has somehow verified that the claimed subject of the key (like a domain name) actually belongs to the owner of the certificate. In case of a digitally signed mail it means that the mail is actually created by the one who signed it.


Safest way to access data from an SQL server

Your question is very confused. I'll assume that English is not your first language and what you are really asking is "should a DBMS be exposed on the internet?"

  he does not want the database password in the code

That's just the start of your problems.

There are things you can do to make the problem less bad than what you are currently proposing, but they still leave a lot to be desired.

Use the credentials provided by the user to authenticate in the DBMS

i.e. the database password is the user's password. This restricts the use of the database to known users (as opposed to making it available to anyone on the internet) and removes the need to embed the database password in the client. But it doesn't solve any of the other problems.

restrict the accounts access to only run stored procedures

Done properly, this would prevent an attacker from reading stuff from the database they shouldn't have access to - e.g. they should only be able to see their orders and not orders from other people. It also allows you to implement your business logic on the serverside (you can't trust logic implemented on the client). You should never store data which has not been vetted for compliance. This also gives some scope for managing the user experience more effectively when things do not proceed along the happy path. However its really hard to implement application logic in procedural SQL.

restrict the access to specific IP addresses

Where only known IP addresses will be accessing a service, this is good practice - it cuts down on the noise, but its not foolproof. And your mention of an IOS app (I presume you are referring to iOS, Apple's mobile device operating system, not IOS, which is Cisco's network device operating system) suggests you won't be able to determine the client address in advance.

...but these are not nearly enough protection!!!

DBMSs are simply not designed to be exposed in a potentially hostile environment. And SQL, using the same channel for data and control, is particularly susceptible to abuse. Nobody has been able to fix these problems on a DBMS - and indeed, nobody is trying any more as the solution is to implement a proper control layer, serverside, on top of the DBMS.


How can I publish data from a private network without adding a bidirectional link to another network

You can use a serial port. By default there are two data lines, one per each direction, plus a ground wire (which is irrelevant here). By disconnecting the appropriate line you can prevent communication in a certain direction.

It's really easy to use it, at the very basic level I think you can run something like echo hello >> /dev/ttyS0 and receive it with cat /dev/ttyS0 at the other side. There is no complicated network stack to work around (which would prevent unidirectional communications as it would treat the lack of response as packet loss) and most languages have easy to use libraries to talk over serial ports.

Here's an example in Python on how to send some JSON over serial:

import serial, json
s = serial.Serial('/dev/ttyUSB0')
data = json.dumps({"status": "OK", "uptime": 60}).encode("utf-8") # make UTF-8 encoded JSON
s.write(data + "\n") # send the JSON over serial with a newline at the end


What web browsers support ECC vs DSA vs RSA for SSL/TLS?

According to GlobalSign, the following browsers support ECC:

Browser                         Minimum Version Required

Apple Safari                    4 (On ECC Compatible OS)
Google Chrome                   1.0 (On ECC Compatible OS)
Microsoft Internet Explorer     7 (On ECC Compatible OS)
Mozilla Firefox                 2.0

Supported operating systems are:

Operating System            Minimum Version Required

Apple OS X                  OS X 10.6
Google Android              4.0
Microsoft Windows           Windows Vista
Red Hat Enterprise Linux    6.5


Why does TLS 1.3 deprecate custom DHE groups?

With  TLS 1.2 the server first needed to tell the client within the ServerKeyExchange message about the parameters of the DHE group it supports. Only then the client could act on these. With TLS 1.3 the client chooses instead from a set of named groups from start. Since the client now chooses the groups instead of the server the key exchange can start immediately (all information are known from start) which cuts a full RTT from the handshake, resulting in better performance.

Of course, in theory one could also still have custom groups this way, only that the client defines these groups this time and not the server. I cannot find any specific information why custom groups where removed but it seemed to happen during some interim meeting in mid 2014 based on this message in the TLS mailing list. I cannot find any information about this on the official meeting in 03/2014 nor on the next one in 07/2014.

But, some information in the paper Indiscreet Logs: Persistent Diffie-Hellman Backdoors
in TLS from 2016 might point into the right direction. This paper discusses deniable backdoors using custom DH groups and in VII. Discussion A. Mitigation Strategies various strategies are discussed to prevent such backdoors, like disabling DHE completely or using only known good (named) DH groups similar to what is done with ECC. If fully removing DHE is not an option then having a fixed set of named DHE parameters looks like the easiest way to handle this problem.


Can Javascript engines that run on the JVM be used to implement the Spectre exploit?

Exploiting Spectre (and Meltdown) requires the ability to time things with reasonably high precision (on a modern CPU, in the tens of nanoseconds range).  Javascript engines that don't do JIT compiling don't provide the precision needed to do this.


ssh-keygen: How to guarantee the uniqueness of serial numbers?

My testing showed that the serial numbers seem to be used to uniquely identify the certificates that are revoked. Therefore, if two certificates are using the same serial numbers, revoking one will cause the other to be "revoked", too, so the other certificate won't be able to authenticate the user.
Therefore, it's true that the serial numbers of certificates should be unique.
I haven't found a way to automatically guarantee the uniqueness of the serial numbers. Therefore, for manual management, a spreadsheet might be needed. When the certificates are generated automatically by some program, the program may simply increment the serial number by 1. The serial number in openssh is implemented as an unsigned 64-bit integer so it should be extremely unlikely to consume all of them.
UPDATE: I wrote an article with more details: SSH: Uniqueness of X509 Certificates Serial Numbers


Ongoing effort to detect MitM attack on TLS?

Certificate transparency is a system that indexes all certificates. Domain owners can watch the certificate transparency logs to see if any certificate has been issued that they did not request. Browsers may check the certificate log, to make sure that every certificate they encounter is added to the log.
So M can create a certificate and:

not add it to the log. B's browser can detect that the certificate has not been added, and is thus likely a fraudulent certificate.
add it to the log. A can detect that a unauthorized certificate has been issued.


Mifare classic can be completely cloned. You can buy cards with changeable UID as well - I just ordered a bunch. The blocks of the card which require non-default keys can be cracked on a PC using cheap hardware. E.g.: Proxmark or Adafruit PN532 / Elechouse PN532 V3, using libnfc and a few other programs. All the tools needed come stock in Kali linux.

I haven't had any luck accessing these blocks which require non-default keys yet, but only because I have not applied serious effort. Desfire EV1 (IIRC) is a post-2008 revision, and these cards are considered secure and are uncloneable p.t.. If you know this to be incorrect, please provide links.

A lot of places use Mifare classic tags for access control and such - more power to that - but I would not use anything less than at least Desfire from NXP (no china knock-offs) for anything involving money.

Google 'mifare classic cloning'.

From reading various sources I estimate it will take max 25-30 minutes to read all data from these cards. For cards which use default keys, it takes less than a second. The Adafruit PN532 (it has a decent antenna) can do it from a distance of 7cm - this range can be increased with custom antennas. Desfire can be read from 3-4 cm. Seems that the more power the card requires to process and communicate, the lower the range of a scanner. Trivia: A single layer of alufoil prevents this... no need for a 'steel wallet'. Just duct tape it over a standard creditcard holder and store that in your wallet.

Edit: any supplementary info from pentesters and engineers would be useful for OP. Please correct any misunderstandings I may have about NFC ;)


Is autocomplete="off" bad for username input fields?

autocomplete off is for sensitive information, for example credit card numbers. The exception is the input type password, because modern browsers do not store input for that type, and disabling autocomplete messes with password managers, thus decreasing security.

Usernames are not sensitive information, although there are still good reasons not to broadcast all your users usernames - eg via username enumeration - if you can avoid it (easier bruteforcing or phishing).

But in the case of autocomplete, an attacker cannot harvest all or even a large amount of usernames, but only usernames where they have physical access to the computer or if an XSS vulnerability exists.

The only negative effect may be privacy violations via leaked usernames or email addresses (if they are used in stead of usernames). But if a user is concerned about privacy on a shared computer, they should use private browsing.

Because of this, it is very difficult to argue that there is even a slight security benefit for autocomplete off for usernames. There is however a real usability impact, so I would recommend against it.


Open challenges in Identity management for Internet of things

It might be wise to see how other vendors are currently handling this problem.

For example, if you take a look at Amazon's IoT button's technical specs you'll see two things that directly relate to your question.

First, they use device serial numbers in the form of

"serialNumber": "GXXXXXXXXXXXXXXXXX"

Where each X is a mixture of letters and numbers and the G listed above is simply the letter G which happens to be the first character of the serial numbers for this product. This is quite a large amount of address space for numbering devices and the numbers themselves are fairly straightforward. Assuming they don't use the letters "o" due to confusion with the number zero (the letters are all capitalized so I and L might be in use) this is roughly 35^17 unique serial numbers give or take a few numbers they may or may not use it's an insanely huge number, more than 25 digits long. For most vendors this serial number, or it's equivalent, is programmed into the hardware and it is probably very easy to do when they are created.

Then, in the case of Amazon IoT, they have a system to allow customers to create their own PKI X.509 certificates or simply download unique PKI X.509 certificates created by Amazon on demand to their devices.

If you look more closely at the size of X.509 keys and their relative keyspace (which could also be effectively expanded by using certificate options) you'll see that size of keyspace for Billions of devices is not a problem at all.

The bigger problem is getting unique certificates onto the devices and managing them. This can be a lot of work if not done at a factory.

Per the device changing networks, I have to connect the device to each 802.11 wireless network I use manually. Then it uses MQTT to call home

Per the device changing ownership, in the case of Amazon's IoT you could simply transfer the device with it's existing serial number to a new owner and have them generate new certificates.

There are several other commercial IoT ecosystems which do things in their own way but generally, and as far as your question is concerned, this is how it works and size isn't really a problem for the scale you mentioned.

Important Note: Not all vendors allow customers to use their own PKI and this can create another problem where there are multiple copies of public-private key pairs. Likewise, some vendors simply aren't concerning themselves with security at all at this time.

Useful references:

http://docs.aws.amazon.com/iot/latest/developerguide/iot-gs.html

https://aws.amazon.com/iotbutton/faq/

https://en.wikipedia.org/wiki/X.509

https://www.ietf.org/rfc/rfc5280.txt


Nmap uses different scanning methods depending on whether it's running as root or not.

The error you see is normal. Try adding -Pn and you will probably get identical results to the scan you ran as a regular user.


Bitlocker on a laptop without carrying around recovery key

What kind of attack are you trying to protect yourself from?

Assuming your only concern is that the data on your lost/stolen laptop will not be readable, then it is OK to carry the recovery key with you. Generally people are very good at securing their wallets, it should be "safe" to keep it on a piece of paper in your wallet.

If you're concerned about being directly threatened to divulge the key then it's obviously a much bigger risk to be carrying the recovery key around.

From a usability perspective though, I would not want to go through the pain of entering the key repeatedly (you mention it's 25% of the time!) Your best move is to solve whatever problem is hanging your laptop on shutdown.


How can end-users detect malicious attempts at SSL spoofing when the network already has an authorized SSL proxy?

How can someone be expected to browse securely in this environment?

You can't really. If there's an official MITM proxy and it's not your network, just don't do anything you don't want the network admins to be able to see. Use your own personal connection to connect to sites with personal accounts.

  With all certificates being signed by the proxy, how can I validate
  that the website isn't additionally being spoofed by some other
  third-party?

I think it's fair to assume that the proxy itself, when it makes the connection to the actual website, does check the validity of the certificate against a list of CAs it was configured with (probably that of the OS it's running on).

  I'm worried that there might come a time where Firefox is also
  configured to ignore these spoofed certificates. How can I prevent my
  browsers (Firefox, et. al.) from accepting these certificates?

The trend has always been to increase the awareness about invalid certificates in Firefox.

In Firefox, you can disable certain CAs by going into Options -> Advanced -> Encryption -> View Certificates -> Authorities. Then, use "Edit trust" (or delete a CA cert). You're likely to find the CA cert installed within this institution. You can also review the exceptions in the "Servers" tab, if any.

  Why do browsers allow this function? It would seem almost more
  sensible to completely disable HTTPS than to allow such a false sense
  of security as this. Is this not a major security issue - that the
  browser accepts seemingly-legitimate certificates even though they are
  not the ones provided by the websites?

You're misunderstanding whose responsibility it is to ensure trust. Browsers are just there to use a list of trusted anchors. Whilst they often come with a default list, it's up to the machine's administrator (and/or the user) to check for the list of CAs they want to trust. (There's a slight exception to this with EV certificates, although it's not without its own set of problems.)

If you have a doubt regarding which CA is being use, click on the lock icon or blue/green bar (depending on the browser), you should be able to see the security details. Compare it with what you see using a machine you trust on a network you trust.

If you don't trust which CA certs are installed on the machine, don't use it. More generally, this boils down to this: don't use a machine you don't trust.


Is really TLS backward compatible independent of the version?

Those two posts are saying different things. If the server is configured to not support lower versions, it won't.

The second quote assumes that the server has not been configured to limit supported versions.


The initialization vector in WEP is a 24-bit random value that is used to seed the RC4 algorithm.

RC4 is a stream cipher. This means that for each bit of plaintext, it produces one bit of keystream and xors the two, to generate the ciphertext. The keystream is simply a stream of random numbers, generated from the RC4 algorithm.

In the most basic operation of a stream cipher, the algorithm is seeded with a key, such that the same key will always produce the same stream of random numbers. Since both the client and server know the key, they can produce the same keysteam. This allows the client to xor the plaintext with the keystream to produce the ciphertext, and the server to xor the ciphertext with the keystream to produce the plaintext again.

The problem with this is that a key is only a few tens of bits long, but the plaintext may be gigabytes. After a large number of bits have been produced by RC4, the random numbers become predictable, and may even loop back round to the start. This is obviously undesirable, because a known plaintext attack would be able to compute the keystream (c1 xor c2 = k) and use it to decrypt new messages.

In order to solve this problem, an IV was introduced to complement the seed. The IV is a random 24-bit value that changed periodically, in an attempt to prevent re-use of the keystream. Unfortunately, 24 bits is quite small, and the IV often wasn't generated in an unpredictable way, allowing attackers to guess future IVs and use them to deduce the key.

Further attacks involved actively injecting packets into the network, tricking the access point into issuing lots of new IVs, which allowed attackers to crack WEP in minutes or seconds.

Further reading:

Fluhrer, Mantin and Shamir attack
WEP Flaws
How WEP cracking works (PDF)


Excluding a hash collision (possible but unlikely/difficult) and someone altering your "secure" copy of the hash, I think you got it. You should, of course, run the hashes when the VM is shut down.


How secure is a password app that stores both the password and two factor secret in one place?

Yes, there is a slight security gain from having two-factor authentication (2FA) enabled on a site even when you store the 2FA generation/reset code in your password manager. In a scenario where the attacker can monitor your keystrokes or the credentials you're sending to the website but not download your password database, they would not be able to logon to your account with 2FA enabled because they wouldn't be able to determine your seed/reset code. It's not a common scenario, but a script kiddy might get keylogger software while not having the technical skill to find and steal your password database. A man-in-the-middle attack would also collect your credentials without having access to your password database.

A better solution would be to keep your 2FA generation/reset codes in a separate password database, locked with a password kept in your primary one and stored in a separate location. Then even someone with your password database and your master key will be unable to access your accounts protected with 2FA, and you'll be able to recover your accounts if your cell phone (or other 2FA device) is lost.


Is it best practice to setup a VPN for remote users to use even if there are no services hosted internally?

Despite not having services for users, some other potential justifications for a VPN would be:

Network and admin teams access to L2/L3 devices like switches and routers
RDP access to workstations

Besides those, if you're not actually hosting any services on an internal network for users to VPN in for, then no there is no reason to have a VPN. In fact, doing so would simply result in +1 more port (1194 for OpenVPN for example) being open on your perimeter, and therefore to the public. This would, albeit mostly negligible, increase the attack surface of your company, but with nothing to gain, because you'd have an extra port just sitting open.

EDIT 1:

If you are talking about accessing outside resources like other corporate networks or simply browsing the internet, doing so over a VPN offers several benefits in terms of security and privacy. As user vidarlo pointed out, the benefits in this case would reduce the chance of MiTM attacks, and also provide traffic inspection for roaming devices. To add to that, you would also have better privacy since your actual public ip would be replaced with one from the VPN provider, thereby shrouding your true public ip to the sites you visit.


Is there a risk with making my Device ID public?

The risk is privacy (the reason why Android created the advertiser ID instead) - your test device is now forever attributed to you and/or your company.

Imagine a competitor getting your app, reading the code, and seeing this ID. Then they create an app that includes code looking for this device ID, hoping you will download and use the app (and you would because they are a competitor).

Now your competitor can uniquely identify your device and gain access to whatever you enable access to and attribute it to you. What might they discover? What insights into your next apps might they glean?

In the end, all it is an ID. But the danger is positive attribution.


Is TextKey SMS 2 factor authentication secure against cell phone cloning?

I am the CEO of TextPower and wanted to address your question directly.  Thanks for taking the time to put together a thoughtful query.

I think that you have to step back and look at the bigger picture here. TextPower's 2FA product TextKey works on the basis that you have to have physical possession of the phone, including the SIM card in it to authenticate properly. If you physically possess more than one phone, you can use any one of them, but only the one that is registered with TextPower can be used to authenticate using the TextKey 2FA. If you have a phone with a replaceable SIM card (standard GSM phones such as those found on AT&T or T-Mobile) you can move that SIM card around to multiple devices that have replaceable SIM cards. That is because you are in physical possession of the SIM card that carries the UDID that the phone uses to communicate with the network. Note that the phone number DOES NOT appear in the SIM card. Only the UDID identifies the physical phone. The UDID is a really long unique number and is what the carrier sees when a call or SMS goes through their system - they don't "see" the phone number.

So, could you clone a SIM from a phone and then use it? In theory, yes but in practice that is extremely difficult to do and highly impractical (and improbable) from a hacking standpoint.  Why?  Because to clone a SIM you would have to steal someone's phone, remove the SIM card and then have access to a burner that could make a SIM card.  You'd have to have a supply of blank SIM cards.  By the time you got that done, the owner would probably report the phone as stolen and their carrier would invalidate the UDID rendering your stolen SIM card as useless except for providing a marvelous way for the police to track and arrest you. (The number of criminals arrested in this manner is now relatively large.) The owner of the stolen phone/SIM Card could also stop you by simply un-registering their phone with TextPower.

Furthermore you might think that you could steal someone's SIM card, clone it and then replace it in the original device without the owner's knowledge.  Unfortunately what happens in that case is that besides all the problems listed in the above paragraph, you will have created a couple of other problems. (Of course you first have to manage to steal the device, clone the SIM card AND replace it without the owner's knowledge - no easy task - but we'll let that go for now.)  The additional problem which you've created in this situation is that if the original device that you managed to steal and return was powered up when you powered up your device with the stolen/cloned SIM card, it would fail network registration because of the duplicate UDID (yes, carriers watch this stuff - very closely).  If your stolen device was powered up first then the real owner of the SIM card could not register their device. They would likely report this quickly to their carrier who would discover the duplicate UDID and then invalidate it.

Is TextKey absolutely un-hackable?  We certainly wouldn't say that.  Like any authentication scheme, there are theoretical ways to break it. In practice however, the ways to break it are way out of the range of anyone with less than huge resources and the
willingness to use significant thievery and take considerable risk.  That's why, while we don't promote TextKey as being "un-hackable" we do think that it is more secure than other 2FA methods, particularly those that use a mobile-terminated SMS where a code is sent to the phone, thus opening the authentication process to a MITM/MITB browser attack on the website in question.

I hope that this answers your question clearly.  I am happy to address any more detailed questions or concerns you may have and do sincerely appreciate your interest.


Is this code JavaScript vulnerable to DOM based XSS?

Yes, it is vulnerable if document.theform.reference[id].value can be a value controlled by another user.

If this value was set to javascript:alert('xss') by an attacker then the line

window.location.href = url;

would cause the script to be executed in the context of the current domain for whichever user is currently using the site.


It seems hard to measure or define just how comprehensive the list of manufacturers or products are - you would need to somehow measure it against an even more comprehensive list

For naming, they have produced a Naming Specification detailing how the process works:
https://csrc.nist.gov/publications/detail/nistir/7695/final

For currency, again you would need compare against some other source of data but you could spot check specific items.  It is updated very frequently - there is a consistent pattern of a large number of updates going back many years, which you can see here:
https://nvd.nist.gov/products/cpe/statistics


Textbook uses terminology like Double/Single Bastion Inline/T to describe firewall architectures. Are these terms used in professional environments?

There are many textbooks that invent their own terminology; as long as you can understand the terms used in the context of the book, that's OK. For example, your "single bastion inline" is called "Internet screening firewall" elsewhere, and your "Single bastion T" could be called "Internet Firewall with a Single DMZ"
(When I use a word, it means just what I choose it to mean—neither more nor less.")
That being said, there are a number of standard terms.
A host-based or host resident firewall is most of the times a bit of packet filtering by the OS. At best unreliable: we've had examples where a server's "host-based firewall" was completely opened by the upgrade of a software package.
A screening router is a  router that filters the IP traffic. Rules should be kept simple. In general (but not always) it is stateless filtering. (https://dullaart.website/acl/index.html for some more info on that).
A screening host is a host that screens/filters the network traffic. You could say that a firewall is a screening host. Some will also say that a proxy is a screening host (though at a higher level of the OSI-stack).
A bastion host is a host through which all traffic must go. Many describe firewalls as bastion hosts, though some use the bastion host only for a host like a web server or proxy. A bastion host is always at least dual-homed: it has an input and an output. Although that may be virtual too.
A multi homed host is a host that has a network adapter in different networks. Like, for example, your bastion hosts.
The T in the architectures is for the optical likeness, but you may have guessed that. When I learned about firewalls (long ago), your "double bastion in line" was called "Dual firewall with a T-DMZ" Inline is also a term that describes how hosts are connected.


What are RealVNC 5.0 Authentication Protocol Security Limitations?

Having a long password doesn't mean it's secure - the VNC client might still have vulnerabilities, such as the authentication bypass bug in versions 4.0 to 4.2.2. However, a limit of 255 characters is certainly better than a limit of 8 characters, since you can at least rule out a brute force.


Why don't we reward users who choose strong passwords?

We don't know how to measure the strength of a password, by looking at the password. Of course, there are many tools that purport to be "password strength meters" and give you a nice green colour. However, they are all baloney and do not give you the "true" strength; instead, what the password strength meter tells you is: "assuming the attacker is a chimpanzee, then your password is good".

So while a "red" value from the meter is an interesting information (it tells you: "your password is so poor that even a chimpanzee could break it"), concentrating on getting a "green" result will not get you far. It will, in all generality, make you immune to chimpanzee hackers.

In fact, password strength meters, and even more your proposed badge system, are toxic: they encourage users to find "witty" passwords that go out of the couple of "password rules" embedded in the password meter system. This trains users into trying to reach password security through wit and cunning, the exact opposite of what they should do. Password strength comes from randomness. Randomness cannot be measured from the output.

What could work is a password generator, that uses randomness to suggest a password to users when they choose it. Then they may get the badge if they elect to use that password. If they make another choice, in the privacy of their mind (where randomness is hard to obtain, unfortunately), then they don't get the badge.


See How can files be deleted in a HIPAA-compliant way?

For OS X, the system includes a way to wipe all free space in the Disk Utility program, but that does not take care of slack space (the space between the end of a file and the end of its block). BCWipe can take care of slack space.

HFS+ reserves chains of filesystem space before writes in order to speed up writing. Space may be reserved and then later freed, resulting in free space containing data after a wipe.

Cache files, preloads and memory paged to disk may also result in unexpected disclosures. If you really feel it's still worth approaching, How to wipe file slack on OS X has some tips.


Strange POST requests to server's IP address. Is this security issue?

The short answer is no, this is not a security issue. That is said with the caveat that you are okay with the load these requests are putting on your server, and you are correct that every single one is being handled with the same error.

Things you should still do:

double check your stack to make sure that there are no known vulnerabilities that look like what's happening
hit your server with the requests that you're getting a make sure there's no information leaking out.
check that there might not be a timing attack happening.


Why we store session id instead of user id inside cookies?

That would be a very bad idea because a malicious user could change the id they are sending.

If for example the admin has the id 1, and a user the id 101, that user could simply change their id in the cookie to 1, and thus gain admin privileges.

For the same reason, you would not want to send any other relevant data in cookies, as you cannot trust this data (unless it's signed and thus cannot be altered, eg using jwt).

You could of course generate random user ids. But even if we assume that these are unguessable, this would be problematic. It would essentially be the same as if you were sending the password in a cookie. If an id leaks even once, an attacker would gain permanent access as it is unrevokable. Session ids on the other hand expire after a while or can be revoked.


Why do some EV certificates show the full address of the organization, but others only show the state or city?

According to the CABForum, which produces the guidelines for EV certificates, the street number and postal codes are optional in the EV certificate contents:

  Address of Place of Business (EVG 9.2.7) – This field must contain the
  address of the physical location for the Subject. City, state and
  country information are required. Street number and postal codes are
  optional.


The reason DBAN or such erasure software, wont beat the investigators, is that when they find out a drive is erased (zero:ed), this will count as destruction of evidence, which is punishable.

Thus, its enough that the investigators prove that the drive has been intentionally erased. It depends on country, but in most countries that employ the "forbidden fruit" scheme, do also make it illegal to destroy evidence, even "own" evidence.
In countries that employ a "free evidence usage" policy in court, does normally make it legal for the suspect to erase his own evidence (its up to the police to catch the evidence before it gets erased), to balance everything out, but in those countries, erased disk is same as someone putting a letter in the fireplace, eg something that usually don't make it out to the headlines.

And they can find out if a device is used after it has been taken out of fresh packaging, as there is a log in the disk, normally called SMART, that will log different charactericts of the disk, as power on hours and other similiar metadata, thus a investigator can see roughtly how much a disk has been used, which means a investigator can see if a disk is just zeroes because its unpacked but not yet used, and a disk that is zeroes because it has been intentionally erased.

And even if that log is erased via firmware commands (may not always be possible), its possible for a investigator to look at the wear of the flash chip where SMART data is stored, and see that the content of the flash chip is altered, as a unused disk will have a zero SMART table with a zero wear.

Thus, a encryption means that the investigator is stuck, as its the same as hiding evidence, which isn't illegal. In the real life world, hiding evidence could be taking that murder knife and putting under the floor planks. Even if the investigators wont find it, they cant convict you. However, if you put that knife in the fireplace, the investigators can use the burnt out knife as evidence that you did destroy evidence, and thus you will get punishment anyways.

Forgetting a password don't count as destroying evidence.

So actually, erasing the disk by encrypting it with a random password, is safer, than erasing it with DBAN, when it comes to legal issues. Same with DBANing a disk, and NOT do a final zeroization. But a completely random disk can also be taken as destroyed evidence, why it can be a good idea to put a real truecrypt boot loader or boot loader from some other encryption software, to give a plausible reason to why data is random, when you have erased it.


It is very risky to make non-standard use of encryption functions. All sorts of subtle problems tend to creep in; problems with existing tools being just some of them.

Presumably, this design was chosen to ensure both confidentiality and authenticity. A better solution would be to have two key pairs: one belonging to the originator of the data, the other to the receiver. Each would share their public key and keep their private key secret. When creating data the originator would encrypt with the receiver's public key and then sign the encrypted data with their own private key. The receiver would first verify the signature and then decrypt.

This solution will provide both confidentiality and authenticity while working just fine with existing tools and expectations.


Best hash for indexing and searching encrypted data

So first warning first:

  If data is secure, it cannot be searched against, only checked
  against.

Now regarding searching: There is no good way to search encrypted or hashed fields, it will ALWAYS eat up CPU. There is a reason for this: Your data is in a one way street. It gets retrieved into memory, checked against, the in memory version destroyed, and the entry minus the data you can't send gets sent. This is for security purposes as well as attack proofing purposes. So then it begs the question "How do I search against it?" Literally an entry at a time. Because each hash or encryption should be unique and never repeatable unless checked against with the initial value, you have to retrieve every encrypted object, go through them until you get a match, and then return the id or pkey of that entry. Is this long, drawn out, annoying, and secure? Yes. Can this be done faster or better? Not really.

More Warnings:

NEVER STORE A RAINBOW TABLE! Those are easily cracked vulnerabilities(Don't believe me?)

NEVER STORE SALTS IN THE DATABASE! If the data as a whole gets stolen, this encryption is now worthless

If the data needs to be *truly secure**, hash it through a one way hashing algorithm(like bcrypt)

IF you MUST search against encrypted data, use a separate decryption program to decrypt the data, do the search, and send it back again in a compiled, standalone binary app. This way if the public facing server has an unwelcome visitor, they can't get that data at all, the key is still secure, and your data is safe.


How to block users from downloading an attachment of a timed WordPress -post before article goes live?

Your solution:

  Options -Indexes

It blocks the directory listing of files. The only way a user could find the attachment is if exact name of the attachment is known. This could be attacked using the following ways:

The Attacker uses a Directory exploring script or tool like Directory Buster. These tools contains dictionaries of millions of words, which are then bruteforced at rapid speed. If the attachment name matches with the word it will be displayed.
A pattern could be formed about the name of the attachment if the user observes the name of previous attachments, hence creating a custom wordlist to bruteforce.

On a scale of 1-10, how easy my current solution is to hack? Is it possible to make this solution relatively safe

Ans) It depends on the complexity of the names of the attachment.

Is there another safer solution for this? could a plugin be developed to transfer the file from a safe place when article gets released

Ans) Yes, a plugin can be developed, using cron jobs and wordpress development.

Can ANY solution where the attachment is on the server/inside WordPress -uploads be a safe solution?

Ans) This solution works , you just need to make your attachment file names a little complex. Means that avoid dictionary words, use special Symbols (" £ $ % ^ & * ( )<>?:@~}{) etc.

Is there a third party solution for this? Like service that could release documents at specific time

Ans) I don't think there is any, and there is no need to waste money on such services, as described above, if you follow this. hopefully it will work for you.


SAT (Satisfiability) it is security risk?

The symbolic execution technique, as used in KLEE, is just a way to ask a SAT-solver to validate/invalidate possible runs in the software without executing it for real. It allows to focus on feasible paths only.

So, this will not be a security threat if you can run a SAT-solver and validate/invalidate the paths of your software. I will just mean that you will be able to explore all its execution paths for sure (exhaustively).

It also means that the internal of your software can be fully explored, which might be a problem if you want to hide something (a patented algorithm, a cryptographic key, ...). In such case, people tends to use specific obfuscation techniques (usually specific opaque predicates to defeat SAT-solvers) to render the exploration of all the executable paths more difficult.

Hope this help you to better understand the whole thing.


No,

While I don't know the settings you use to disable, using:

DYNAMICBASE:NO

Should disable ASLR on your executable
You can easily check it with process explorer / PE-studio and more.