How important is encrypting traffic that never leaves a data center?

I think it depends upon your company's security goals and risk assessment. Are you happy to own the risk? In a worst case scenario where your data gets snooped upon or stolen, what will be the impact on your business? How important is your data?

Take these factors into consideration during planning.


The first check I would do in this circumstance is to see why the browser thinks the certificate is untrusted.
Most likely case (as it's every site you're friend is using) is that the certificates presented in the browser are being issued by an untrusted Certificate Authority.
If you click the error message, it should be possible to see who the issuing CA is.  For example on the cert below the issuer is Comodo

That should give you a good clue as to what's going on.  If it comes up as an known anti-virus provider then it's possible as @vilican says, that it's just misconfigured software and not something malicious.
Once you've checked that, assuming you've not resolved it, my next stop would be proxy settings for the browser and/or the operating system. If there's a proxy set here, unset it, see if that affects the problem.
Assuming you get through those two without a resolution, the next step would be considering the possibility that the router/firewall on the network is intercepting SSL traffic.  You could check that by adding a new machine to the network (that you know doesn't have the issue) and see if you start getting SSL certificate warnings.  If that turns out to be the issue, you'd need to speak to whoever has the access to configure the router. Again it may be a security feature doing this and not actually malicious...


Patent free symmetric-only key exchange protocols?

Key exchange protocols break up into two major categories.   Server-Based key Establishment and server-less key establishment (I think I'm going to buy that book.). Within these two categories you'll find protocols that use symmetric or asymmetric ciphers or both.   There are lage number of Key exchange protocols documented on Security Protocol Open Repository(SPORE),  which is a very cool resource.

A good choice for server-based key Establishment is the Needham-Schroeder Symmetric Protocol which can be performed entirely with AES and is used in Kerberos.

For server-less key establishment you should look at Lowe modified BAN concrete Andrew Secure RPC.  It is old,  however I do not believe this protocol has been compromised.

You should use SSL/TLS whenever possible,  but it will require more than 1kb of memory.


What is the difference between Federated Login and Single Sign On?

Single Sign-on (SSO) allows users to access multiple services with a single login.

The term is actually a little ambiguous. Sometimes it's used to mean that (1) the user only has to provide credentials a single time per session, and then gains access to multiple services without having to sign in again during that session. But sometimes it's used to mean (2) merely that the same credentials are used for multiple services; the user might have to login multiple times, but it's always the same credentials. So beware, all SSO's are not the same in that regard. Many people (me included) only consider the first case to be "true" SSO.

Federated Identity (FID) refers to where the user stores their credentials. Alternatively, FID can be viewed as a way to connect Identity Management systems together. In FID, a user's credentials are always stored with the "home" organization (the "identity provider"). When the user logs into a service, instead of providing credentials to the service provider, the service provider trusts the identity provider to validate the credentials. So the user never provides credentials directly to anybody but the identity provider.

FID and SSO are different, but are very often used together. Most FID systems provide some kind of SSO. And many SSO systems are implemented under-the-hood as FID. But they don't have to be done that way; FID and SSO can be completely separate too.


Are personas used in information security? (like in UX)

Yes, in a way.

When one designs a Threat Model, one thinks about the current system, the potential goals of a "Threat Actor" (attacker or a careless user), and the currently available tools, techniques, and procedures to exploit vulnerabilities.

For instance, I work with one client that outlines all this in detailed documents and sets priorities in relation to the risk priorities of the system and business. The focus is on threats not the attackers themselves, though.

That said, there is a huge benefit to using the UX style of personas in a more traditional way to deal with the "careless user" problem. In many cases, better UX would prevent many of the user-generated security problems we face daily.


file piece ("chunk") hashing is actually an essential, core feature of BitTorrent (the downloaded pieces are immediately and automatically verified), and a part of the BT protocol - the .torrent file contains the hashes needed for verification. So, unless the .torrent file is altered by an attacker (which is a very different issue), the integrity of the files is verified while they are downloaded, automatically (and invalid parts are silently discarded).

So: if you trust the source of your .torrent file (which is always questionable for a plain HTTP connection, plus see the Mint incident with hacked site), the subsequent download is indeed the same as the source claims.

Even so, if you want to verify the integrity later,

the signature hash for an ISO is the same regardless of download method - see e.g. http://cdimage.ubuntu.com/releases/15.10/release/SHA256SUMS and http://cdimage.ubuntu.com/releases/15.10/release/SHA256SUMS.gpg for the 15.10 release hashes and signatures.

See also: Is Torrent safe for sharing legitimate files (file verification)? Does it use SHA1 or SHA256?


Need a test vector for the putty ssh-2 file mac validation


Let's say we're exploiting buffer overflow in some foo function. Consider the following stack after overflowing the buffer, stopping at ret instruction in foo function:

   ....
------------------------
"system" fn address         <-- stack pointer
------------------------
4 bytes of garbage
------------------------
"bin/sh" address
------------------------
   ...

After that, when we execute ret instruction, we'll jump right to the system function. Then, stack will look like this:

   ....
------------------------
4 bytes of garbage          <-- stack pointer
------------------------
"bin/sh" address
------------------------
   ...

so, now we are in system function. Those 4 bytes of garbage are now the return address for system function, and the values below return address are system function arguments – in our case it's single *char argument that points to "/bin/sh" string.


Can I find out what encryption is used by my Android Bluetooth keyboard?

Your specific keyboard uses two-level E0 for encryption and P-192 for key exchange.

Bluetooth always uses encryption. However, the different versions use different encryption protocols:

So, what cryptography does each version use? For Bluetooth BR/EDR:

Prior to 2.1, versions do not use any key exchange. Keys are pre-shared, usually using a very weak PIN. They are often vulnerable to brute force as a result of the small keyspace. The cipher is E0, which is fairly weak and can be broken with a known plaintext attack given enough data.
From 2.1 to 4.0, key exchange is performed with ECC, specifically the NIST P-192 curve. This provides approximately 96 bits of classical security which isn't great, but isn't practical to break yet. Although it uses the rather weak E0 cipher, it uses so-called two-level E0, which is a more secure construction that uses the cipher twice. No practical attacks are known against it the way it is used in Bluetooth, but attacks only get better, not worse, so the cipher should be considered weak.
Since 4.1, key exchange is performed using a much stronger ECC curve, P-256, which gives approximately 128 bits of classical security. The cipher used, AES, is also superior to E0. These versions of Bluetooth are generally immune to passive attacks. Active MITM attacks may be possible if out-of-band authentication is not used and a weak PIN is used for authentication instead.

Bluetooth Low Energy (LE) is a little different and was only supported since 4.0. Prior to version 4.2, Bluetooth LE does not use any key exchange mechanism, making it vulnerable to passive attacks. This is a severe regression and can only be mitigated by using BR/EDR instead of LE, or by ensuring only LE version 4.2 or newer (which re-introduced P-256 for key exchange) is used.

According to a quick web search, the Celicious Tri BK01 Bluetooth keyboard uses version 3.0, which means it is using P-192 for key exchange and two-level E0 for encryption. No practical cryptographic attacks are known that can be used against this keyboard, but weaknesses in E0's design and the only barely adequate security of P-192 mean that advances in cryptanalysis in the near future may render it vulnerable. Do not use it in situations where long-term security is required.

Now, your real question shouldn't be what kind of encryption is being used, but how secure it is for entering passwords or other sensitive information. Excluding EMSEC (TEMPEST-type) issues, timing attacks may be possible. Each time you press a key, the keyboard immediately transmits it wirelessly. Although the key press may be encrypted, the fact that a key has been pressed and the exact time it was pressed (and released) is not hidden. It is possible to deduce potential passwords simply by viewing timing patterns, as certain sequences of key presses occur with different timing patterns than others. This problem becomes bigger the more often you enter your password. If your adversary may be collecting both the encrypted data as well as the precise timing intervals of the transmissions, your password may be revealed if entered enough times.

Related:

Difference between Secure Simple Pairing and Secure Connections in Bluetooth?
What can an attacker do with Bluetooth and how should it be mitigated?
Difference between Bluetooth LE Secure Connections security mode 1 and level 3 and 4?


Are there stories of any individuals being affected by Heartbleed?

No so much of a story.
I found that my little web server I was running was not secure from #heartbleed.
I used the following test 'http://filippo.io/Heartbleed/#secure.jermsmit.com'
After discovering this I logged into my host and issued an apt-get update && apt-get upgrade -y --- once completed all worked just fine.

So much for my little story.


I have only heard of two types of teams:

Blue team - The defenders of a network
Red team - Attackers of a network
Tiger team - Same as red team, however is a older term of the attacking/opposition side of an engagement
White team - The team that establishes the rules of engagement and are usually the employees of the organization. The white team does not conduct any testing.

CISSP study guide has the following explanation of the different teams:

  White team  A neutral team of employees acting as observers, referees, and judges between > a red team of mock attackers (offenders) and a blue team of actual defenders of their
  enterprise’s use of information systems. The white team establishes rules of engagement
  (ROE) and performance metrics for security tests. The white team is also responsible for
  deriving lessons-learned, conducting the post engagement assessment, and communicating
  results to management. Occasionally, the white team also performs incident response
  activities and addresses bot attacks on an emergency basis.


Why are salted hashes more secure for password storage?

It typically works like this:
Say your password is "baseball". I could simply store it raw, but anyone who gets my database gets the password. So instead I do an SHA1 hash on it, and get this:
$ echo -n baseball | sha1sum
a2c901c8c6dea98958c219f6f2d038c44dc5d362

Theoretically it's impossible to reverse a SHA1 hash. But go do a google search on that exact string, and you will have no trouble recovering the original password.
Plus, if two users in the database have the same password, then they'll have the same SHA1 hash. And if one of them has a password hint that says try "baseball" -- well now I know what both users' passwords are.
So before we hash it, we prepend a unique string. Not a secret, just something unique. How about WquZ012C. So now we're hashing the string WquZ012Cbaseball. That hashes to this:

c5e635ec235a51e89f6ed7d4857afe58663d54f5

Googling that string turns up nothing (except perhaps this page), so now we're on to something. And if person2 also uses "baseball" as his password, we use a different salt and get a different hash.
Of course, in order to test out your password, you have to know what the salt is. So we have to store that somewhere. Most implementations just tack it right on there with the hash, usually with some delimiter. Try this if you have openssl installed:
[tylerl ~]$ openssl passwd -1
Password: baseball
Verifying - Password: baseball
$1$oaagVya9$NMvf1IyubxEYvrZTRSLgk0

This gives us a hash using the standard crypt library. So our hash is $1$oaagVya9$NMvf1IyubxEYvrZTRSLgk0: it's actually 3 sections separated by $. I'll replace the delimiter with a space to make it more visually clear:
$1$oaagVya9$NMvf1IyubxEYvrZTRSLgk0
 1 oaagVya9 NMvf1IyubxEYvrZTRSLgk0

1 means "algorithm number 1" which is a little complicated, but uses MD5. There are plenty others which are much better, but this is our example.
oaagVya9 is our salt. Plunked down right there in with our hash.
NMvf1IyubxEYvrZTRSLgk0 is the actual MD5 sum, base64-encoded.

If I run the process again, I get a completely different hash with a different salt. In this example, there are about 1014 ways to store this one password. All of these are for the password "baseball":
$1$9XsNo9.P$kTPuyvrHqsJJuCci3zLwL.
$1$nLEOCtx6$uSnz6PF8q3YuUhB3rLTC3/
$1$/jZJXTF3$OqDuk8T/cEIGpeKWfsamf.
$1$2lC.Cb/U$KR0jkhpeb1sz.UIqvfYOR.

But, if I deliberately specify the salt I want to check, I'll get back my expected result:
[tylerl ~]$ openssl passwd -1 -salt oaagVya9
Password: baseball
Verifying - Password: baseball
$1$oaagVya9$NMvf1IyubxEYvrZTRSLgk0

And that's the test I run to check to see if the password is correct. Find the stored hash for the user, find the saved salt, re-run that same hash using saved salt, check to see if the result matches the original hash.
Implementing This Yourself
To be clear, this post is not an implementation guide. Don't simply salt your MD5 and call it good. That's not enough in today's risk climate. You'll instead want to run an iterative process which runs the hash function thousands of times. This has been explained elsewhere many times over, so I won't go over the "why" here.
There are several well-established and trusted options for doing this:

crypt: The function I used above is an older variation on the unix crypt password hashing mechanism built-in to all Unix/Linux operating systems. The original (DES-based) version is horribly insecure; don't even consider it. The one I showed (MD5-based) is better, but still shouldn't be used today. Later variations, including the SHA-256 and SHA-512 variations should be reasonable. All recent variants implement multiple rounds of hashes.

bcrypt: The blowfish version of the crypt functional call mentioned above. Capitalizes on the fact that blowfish has a very expensive key setup process, and takes a "cost" parameter which increases the key setup time accordingly.

PBKDF2: ("Password-based Key Derivation Function version 2") Created to produce strong cryptographic keys from simple passwords, this is the only function listed here that actually has an RFC. Runs a configurable number of rounds, with each round it hashes the password plus the previous round's result. The first round uses a salt. It's worth noting that its original intended purpose is creating strong keys, not storing passwords, but the overlap in goals makes this a well-trusted solution here as well. If you had no libraries available and were forced to implement something from scratch, this is the easiest and best-documented option. Though, obviously, using a well-vetted library is always best.

scrypt: A recently-introduced system designed specifically to be difficult to implement on dedicated hardware. In addition to requiring multiple rounds of a hashing function, scrypt also has a very large working memory state, so as to increase the RAM requirement for implementations. While very new and mostly unproven, it looks at least as secure as the others, and possibly the most secure of them all.


what is the value of using a VPN browser extension incremental to the value of IP hiding

Your VPN provider (Windscribe) seems to be using this as marketing garbage, and in reality, the browser extension provides little protection when used in combination with the standard desktop client since your connection is already using the VPN.

The browser extension simply combines a VPN (that's only utilized within the browser and not system-wide) and an ad/tracker-blocker. When you enable it, it creates a VPN tunnel, and if the desktop client is already on, then it tunnels through the system VPN connection, creating a 'double-hop' connection since it's going to one VPN server, then to another VPN server, and then to its final destination on the web.

As for its tracker blocking capabilities, they're pretty much useless. The moment you sign in to any website, you give away your identity. There's also browser fingerprinting, which can track you even when you switch to 'incognito mode'. In reality, this browser extension does next to nothing to make you anonymous.

If you want a robust solution for anonymity online, use Tor Browser with Tor disabled and your VPN active. As long as you don't voluntarily give up your identity, you won't be able to be tracked when using Tor Browser


What's the purpose of the lock and unlock feature in password managers?

"Locking" the database (in KeePass, "Lock" just plain closes the database) means that the decryption key for the database and any decrypted passwords from the database are no longer accessible in memory.  Without that protection, something like KeeFarce can be used to extract that information:

  KeeFarce allows for the extraction of KeePass 2.x password database
  information from memory. The cleartext information, including
  usernames, passwords, notes and url's are dumped into a CSV file in
  %AppData%

Something like that could be run by someone who got malicious code running on your machine.  One of the first things an attacker will do, once they get code running on your machine, is to look for credentials that it can use to extend their access to other systems.  This fits that bill.


AES CBC padding when the message length is a multiple of the block size

Padding is a way to encrypt messages of a size that the block cipher would not be able to decrypt otherwise; it is a convention between whoever encrypts and whoever decrypts. If your input messages always have a length which can be processed with your encryption mode (e.g. your messages always have a length multiple of 16) then you do not have to add padding -- as long as during decryption, you do not try to look for a padding when there is none. If some of your messages require padding, then you will have to add some sort of padding systematically, otherwise decryption will be ambiguous.

Padding does not add security. Badly implemented padding management can leak information (padding oracles) so you have to be careful with your implementation -- preferably by not doing it yourself.

(Of course, you would be better served with an encryption mode which does not need any padding and includes the much needed but much overlooked integrity check; that would mean GCM or EAX, not CBC.)


There are several flaws:

First, I don't see why you would want to "reinforce the use of existing lib (Bcrypt mainly)".
Either you use a solid password hashing algorithm (BCrypt is good) or you don't. If you don't, you should not attempt to 'reinforce' it, but switch to a solid algorithm instead.

Second: Your code is, as you say, Javascript. Javascript implies client side hashing. Client side hashing is mood, there are several answers here on security.SE that explain why this is the case. (If you only choose to use Javascript for demo purposes, ignore this point.)

Third: Your 'fixed salt' is typically known as a 'pepper'. A pepper can add security in some very specific cases. A pepper works by being a secret. As a result, a pepper has no benefit whatsoever if used for client side hashing.

Fourth: SHA256 is a general purpose hash. It is designed to be fast. Fast is exactly what you do not want for password hashing.

Fifth: Your final comparison operator is vulnerable to timing attacks.

But is all comes down to the first point: pick a solid password hashing algorithm (BCrypt) and don't attempt to improve upon it.


Risk associate with nonce and hash found in url

As long as the domain name corresponds to the expected one and that there is no blatant XSS included in the URL, the risk will most likely not depend on the URL itself but how it is handled by the remote site.

The nonce and hash as requested in your question are common in registration email and, as long as they are properly generated, do not present any security risk.


The "Kaminsky bug" (CVE-2008-1447) affects "BIND 8 and 9 before 9.5.0-P1, 9.4.2-P1, and 9.3.5-P1".


Since the first two packets are SYN+ACK, they look like a response to a connection attempt: the server on 98.126.43.174 might be a totally honest and genuine Web server, who received a connection request (a SYN packet) on port 80, which, from the point of view of that server, was coming from your IP (and port 339). It is possible that the server 98.126.43.174 is currently under a SYN flood attack and the attacker selects random IP and ports for each of its malicious SYN packets; in that case, your IP was randomly selected as purported source for one of the SYN packets.

As for the firewall, some simply block basic SYN packets, i.e. the first packet in the TCP three-way handshake. These firewalls rely on your OS to drop all others since your OS never received the initial packet to start with. This would explain why these packets reach your machine: the firewall lets them pass because it knows that the packets will be either legitimate (follow-up on a SYN packet you sent) or harmless (if you did not send a SYN packet).

As for the UDP packets, they might be responses to previous requests. Some software use a lot of UDP with randomly selected ports, Skype being the usual suspect.


Forgot your password: "New password must have a minimum of 4 characters different from the previous password"

It is mathematically possbile do what they are doing securely to store passwords in a manner that would enable that feature but would not have the old password stored in plaintext. But just because it is mathematically possible, does not mean that it is likely.

Homomorphic encryption

At Eurocrypt 2004 Michael Freedman, Kobbi Nissim, and Benny Pinkas presented a paper that explicitly addressed how to efficiently find the intersection of two sets without revealing the contents of either set (other than the intersection) to anyone who didn't have it before. It is also possible to find an estimate of the size of the intersection without even revealing (much about) the intersection itself.

Now that was in 2004 (and was based on previously work). So there have been improvements since then in this and related algorithms. So there are known techniques for finding out how many characters are common to two sets without revealing the contents of either set. (In the case you are asking about, it is only one set, the old password, that needs to be concealed as the system is given the full new password.)

Bloom filters

If we are talking about overlap of sequences of four characters (instead of just characters in both passwords), then a reasonably secure way of doing this is with a Bloom Filter. A Bloom Filter is a special sort of hash table. Each four character substring of the original password could be added to the Bloom filter when that password given to the service and then all four character substrings of the new password can be looked up in the Bloom filter.

Note that Bloom filters are designed for when there are lots of members of the set and are probabilistic. They can give false positives.

The obvious answer is sadly correct

I would be astounded if the site in question is using homomorphic encryption or even Bloom filters. They are almost certainly doing it a manner in which the operators of the site (and anyone who breaches them) have access to the plaintext passwords.


This sounds like a good task for Shamir's Secret Sharing, as Stephen pointed out in comments. One example of off-the-shelf software that can do this is Crypto++ (relevant docs: http://www.cryptopp.com/docs/ref/class_secret_sharing.html).


The theory is that traffic to the DMZ must be inbound. In that case, should something bad happen to the the DMZ host, the attack is contained within the DMZ.

This means that the connections from your LAN must be initiated in the LAN, which usually means some kind of push (to the DMZ) or pull (from the DMZ) operations. This is doable for mail but sometimes impracticable for other services.

In that case the DMZ is often seen as a "thin layer" which is in theory more robust (because it is lighter) and therefore potentially less prone to vulnerabilities (and hacks).

This is particularly true when you get the actual data from a mammoth service which should not be accessed directly. This extra layer also allows you to "break the protocol" (as you mentioned), which means that an attack which would have succeeded on the target host will not be doable on the exposed one (because of the architectural change which stops the payload on the first layer (which is not vulnerable to that attack)).


What's the difference between using HSTS and doing a 301 redirection?

Let's look at the scenario with a 301 redirect first. The victim sends a request to http://example.com (as pointed out in comments, this could because of SSLStrip or because the user just entered example.com in the URL bar and browsers default to HTTP). If there is no MitM attack they get a 301 response back, and is redirected to https://example.com. But if there is a MitM, the attacker can just choose not to send the 301, but instead serve a (possibly modified) copy of the site over HTTP.

The weak point here is that an initial HTTP connection (without TLS) is made, and the attacker can modify that traffic. However, if you had used HSTS the browser would know (assuming that the victim had visited the site previously) that the page should always be served over HTTPS - no HTTP request would ever have been sent, and the browser would just send a request to https://example.com. The attacker cannot MitM the TLS connection, so the attack is prevented.

(The fact that browsers cache 301 responses makes this a bit more complicated in practise. For more info on that, see bonsaiviking's great answer or this question. The short story is that the 301 being cached might help a bit, but not take you all the way that HSTS does.)


Why does Chromes XSS filter block injection into HTML element, but not into attribute?

Because there is no vulnerability resulting from the HTML code in the second case (you would need to close the tags first, eg '"><script>alert(1)</script>; this would be caught by the auditor).

You may have JavaScript code which further processes your HTML code and thus introduces an XSS vulnerability in the second case as well (eg via script gadgets), but that is not what the XSS Auditor monitors:

  The XSS Auditor runs during the HTML parsing phase and attempts to find reflections from the request to the response body. It does not attempt to mitigate Stored or DOM-based XSS attacks.

The JavaScript interpreter will be run after the HTML parser, so any vulnerabilities introduced by JavaScript will not be caught by the XSS auditor.


Solution for password spraying on my app

You need to correlate the failed logins on the server to some characteristic the attacker has. Typically, this can be the IP, but there may be other options depending on how your app is built and what data it collects.

This means you need to keep track of failed logins across all users for some window of time.

Once you identify an IP that is failing to log in across many accounts, you have some difficult options regarding how to respond. You could block the IP, which could lock out all legitimate users using that IP, or before lockout, check to see if the IP has been used by other legitimate users (i.e. determine if the IP is likely legitimate or not).

IP blocking is crude and error-prone. It is just as easy for attackers to rotate through IPs as it is to rotate through usernames. You also risk the chance of locking out your legitimate users.

You could also tackle the problem on a different layer altogether. You could implement 2FA, which protects the users and means that you don't need to protect user passwords through log analysis. Or you could make the decision that users who are vulnerable to password spraying need education or better password guidance rather than trying to protect them against themselves.

The problem here isn't that your app is vulnerable to password spraying, it's that the passwords are easy to guess.


which places are used to store the the encryption key?

Other Places are:

TPM
CPU Register (implementation: Tresor)
HSM
Security Tokens
many other Hardware based storages


While the alert is alarming, based on the information provided, it does not appear to be of concern.

When IE restarted, it attempted to reopen the page it was last on, which was apple.com. res://ieframe.dll/... is how IE reloads the last page it was on. Malware Bytes caught this dll loading and alerted on it.


Do client certificates provide protection against MITM?

A man-in-the-middle attack is when an attacker inserts himself between client and server, and impersonates the client when talking to the server, and impersonates the server when talking to the client. "Impersonation" makes sense only insofar as there is an expected peer identity; you cannot impersonate an anonymous client.

From the point of view of the server, if the client shows a certificate and uses his private key as part of a CertificateVerify message (as described in the SSL/TLS standard, section 7.4.8), and the server validates the client certificate with regards to a set of trust anchors which does not include an hostile or incompetent root CA, then the server has a guarantee that it is talking to the right client (the one identified by the client certificate). The guarantee holds for all subsequent data within the connection (it does NOT extend to data exchanged prior to the handshake where the client showed a certificate, in case that handshake was a "renegotiation").

This means that a client certificate indeed protects against the specific scenario of a rogue CA injected in the client trust store. In that scenario, the "attacker" succeeded in making the client trust a specific root CA that is attacker-controlled, allowing the attacker to run a MitM attack by creating on-the-fly a fake certificate for the target server (this is exactly what happens with some "SSL content filtering" proxies that are deployed in some organizations). Such MitM breaks client certificate authentication, because what the client signs as part of a CertificateVerify message is a hash computed over a lot of data, including the server certificate -- in the MitM scenario, the client does not see the "right" certificate and thus computes a wrong signature, which the server detects.

From the point of view of the client, if a client certificate was requested by the server and shown by the client, then the client knows that the true server will detect any MitM. The client will not detect the MitM itself; and if there is an ongoing MitM attack, then the client is really talking to the attacker, and the attacker will not tell the client "by the way, you are currently being attacked".

In that sense, a client certificate prevents a true MitM (aka "two-sided impersonation") but does not protect against simpler frauds (one-sided impersonation, i.e. fake servers).

Bottom line: In the presence of SSL with mutual client-server authentication (both send a certificate to the other), a successful MitM requires the attacker to plant rogue CA in both the client and the server. However, if the attacker can plant a rogue CA in the client only, the client is still in a rather bad situation (even though a complete MitM is thwarted).


First of all you would not normally expect kernel memory to be mapped in a GPU. Even if you did modern GPU's generally don't have much in the way of support for sharing memory between processes.

There have certainly been research papers on speculative execution inside of a GPU - Speculative Execution on GPU: An Exploratory Study; Liu, Eisenbeis, Gaudiot - but I don't believe it is actively done at a hardware level by any existing devices.

So whilst theoretically there is nothing to stop you building a GPU/OS setup that may allow it I doubt this is possible on any existing products.


No. Your connection to Facebook is not at risk when you use a VPN. That's because the communication between you and Facebook is SSL-encrypted and therefore the content cannot be read or modified by anyone in between, neither your ISP nor your VPN provider.

They can conclude that you use Facebook but not read or control what you do on Facebook.


Is there a trusted independent firewall review company?

To your initial question, the only thing I've seen that purports to really do this is the Gartner Magic Quadrant. However, given the overall complexity of firewall solutions, it's hard to make an apples to apples comparison in my opinion. Often they are used for their basic layer 3 and layer 4 filtering capabilities, and as such are treated like commodity devices like a switch. In this case the most important thing is simply finding a reputable vendor that can handle the scale you operate at for the cheapest price you can find.

I am making the assumption you're talking about hardware appliances, but in general this would go for any firewall solution. It's really tough to get a real answer on a firewall, since there are so many variables. There's how much bandwidth it can push, how many connections per second it can handle, the rule chain processing, application level stuff, etc. There often are IDS features bundled into firewalls, but again testing is needed to use these at scale.

Like with any technology, scaling is always a concern. However, unlike AV a firewall generally has a key point in the infrastructure and so if it runs slowly it causes real business impact immediately. There are so many features available in various firewalls, it's also very hard to do an apples to apples comparison. I've done some pretty large scale firewall implementations and testing with aggregate bandwidth in the 100s of Gbps. The way we performed it was testing several vendors using simulated traffic similar to our production traffic. We found that in our case some vendors just could not handle our traffic patterns, despite them being "rated" for our environment.


Does embedding images in PDF retain metadata?

Yes, EXIF data may be saved, depending on how your PDF tools work.

As an example, you can take a JPEG with EXIF data, put it into LibreOffice Writer, then save that document as a PDF with "Lossless Compression" enabled and "Reduce Image DPI" disabled. If you then extract images from that PDF (there are many tools for this, I used an online one for speed) the JPEG EXIF data will still be there.

If you enable lossy JPEG compression, at least in LibreOffice's PDF export dialogue, it appears that the JPEG is recompressed to a new file with EXIF data stripped.

It is not difficult to remove EXIF data from images in Windows, and you should be able to talk them through the process. For each image, right click it, go to properties, go to the details tab, click the "Remove Properties and Personal Information" link at the bottom, select "Remove the following properties from this file", click the Select All button, then click OK.


The answers I've gotten have been good, but I wanted to provide a bit more depth, going specifically in to why the system exists at all, which should explain a bit more about what it's good for.

Disclaimer: While I now work for Google, I knew nothing about this project at the time this answer was written. Everything reported here was gathered from public sources. This post is my own opinions and observations and commentary, and does not represent the opinions, views, or intentions of Google.
Though it's worth pointing out that I've been using this and tinkering with it for quite some time now, and as someone who has dealt a lot with social engineering and account takeovers, I am disproportionately impressed with what has been accomplished here.

Why something new was needed
Think about this: Google deployed two-factor authentication a long time ago. This is a company that cares deeply about security, and theirs has been top notch. And while they were already using the best technology available, the additional security that U2F delivers above traditional 2-factor is so significant that it was worth the company's time and money to design, develop, deploy, and support a replacement system that they don't even themselves sell. Yes, it's a very socially-conscious move of them to go down this road, but it's not only about the community. Google also did it because they, themselves, need the security that U2F alone provides. A lot of people trust Google with their most precious information, and some in dangerous political environments even trust Google with their lives. Google needs the security to be able to deliver on that trust.
It comes down to phishing. Phishing is a big deal. It's extremely common and super effective. For attacks against hardened targets, phishing and similar attacks are really an attacker's best bet, and they know it. And more importantly:
Our phishing protection is laughable. We have two-factor auth, but the implementations offer little defense. Common systems such as SecurID, Google Authenticator, email, phone, and SMS loops -- all of these systems offer no protection at all against time-of-use phishing attacks. A one-time-password is still a password, and it can be disclosed to an attacker.
And this isn't just theoretical. We've seen these attacks actually carried out. Attackers do, in fact, capture second-factor responses sent to phishing sites and immediately play them on the real login page. This actually happens, right now.
So say you're Google. You've deployed the best protections available and you can see that they're not sufficient. What do you do? Nobody else is solving this problem for you; you've got to figure it out.
The solution is easy; Adoption is the real issue
Creating a second-factor solution that can't be phished is surprisingly simple. All you have to do is involve the browser. In the case of U2F, the device creates a public/private key pair for each site and burns the site's identity into the "Key Handle" that the site is supposed to use to request authentication. Then, that site identity is verified by the browser each time before any authentication is attempted. The site identity can even be tied to a specific TLS public key. And since it's a challenge-response protocol, replay is not possible either. And if the server accidentally leaks your "Key Handle" in a database breach, it still doesn't affect your security or reveal your identity. Employing this device effectively eliminates phishing as a possibility, which is a big deal to a security-sensitive organization.
Neither the crypto nor its application is new. Both are well-understood and trusted. The technology was never the difficulty, the difficulty is adoption. But Google is one of only a small number of players in a position to overcome the barriers that typically hold solutions like this back. Since Google makes the most popular browser, they can make sure that it's compatible by default. Since they make the most popular mobile OS, they can make sure that it works as well. And since they run the most popular email service, they can make sure that this technology has a relevant use case.
More Open than Necessary
Of course Google could have leveraged that position to give themselves a competitive advantage in the market, but they didn't. And that's pretty cool. Everyone needs this level of protection, including Yahoo and Microsoft with their competing email offerings. What's cool is that it was designed so that even competitors can safely make it their own. Nothing about the technology is tied to Google -- even the hardware is completely usage-agnostic.
The system was designed with the assumption that you wouldn't use it just for Google. A key feature of the protocol is that at no point does the token ever identify itself. In fact the specifications state that this design was chosen to prevent the possibility of creating a "supercookie" that could be used to track you between colluding services.
So you can get a single token and safely use it not only on Gmail, but also on any other service that supports U2F. This gives you a lot more reason to put down the money for one. And since Yubico published reference implementations of the server software in PHP, Java, and Python, getting authentication up and running on your own server is safely within the reach of even small shops.


Ripple20 is a group of vulnerabilities (19 of them), each one with its own considerations.
To identify the vulnerabilities you need some response from the devices, which can be obtained from a scanner like nmap, but since Wireshark is a passive tool, it may not help by itself to identify the vulnerable devices.
More information of each one of the 19 vulns can be obtained from the company that disclosed the vulns.


Just like PDFs, websites, and other complex formats which need to be parsed, there could be parsing bugs. At best, such bugs trigger a warning or crash the program, and at worst (but not uncommonly) they are able to run code on your machine.

Because it has a serious impact, these bugs are taken seriously and solved by the maker as soon as possible (for popular and supported projects at least). Having such a bug, which is widely applicable in case you want to hack someone, is quite valuable. If you use such an exploit on someone, you are basically giving something away which could be worth tens or hundreds of thousands of euros.

The risk of such a website having such an exploit and using it on you, and you having an unpatched instance, is probably negligible.

It's more likely that they send you a file that is called something like music.mp3.exe which Windows sees as an executable .exe format and runs. Or some other bug that it not a bug in your mp3 player itself.


Im unsure if this is the "correct" approach, but I would change the permissions of the file to owned by root but also owned by another group which only has read access. Making sure your upstart user is in this shared group.

# groupadd upstart
# usermod -G upstart the_user
# chown root:upstart the_file.conf
# chmod 740 the_file.conf

The above adds a new group "upstart" at which point user "the_user" is added. The file ownership is changed to user "root" group "upstart" and permissions set to "root" read, write, execute; and group "upstart" read.


What is "web of trust" in PGP and S-MIME?

You trust A and A tells you that K is the key of B. Therefore, you believe that K is the key of B. Of course, this can be extended to indirect chains. For example if you trust the judgement of A, you can specify that you also trust anyone that A trusts.

PGP users sometimes also have key signing events. The idea is that you show up and prove your credentials to other people at the event who will then sign your key. This now means that whoever trusts someone at the event that signed your key, can check the signature of your key made at the event and thus verify that the key they found online actually is your key.

These trust relationships form a network and this is your "Web of Trust".


According to the Windows Internals 5th Edition book, the 5-bit ASLR bias for heaps is "multiplied by 64KB to generate the final base address, starting at 0, giving a possible range of 0x00000000 to 0x001F0000 for the initial heap".

As such, the initial heap for IE on Windows 7 will always be between 0x00000000 and 0x001F0000, with 32 possible locations. By filling the heap with 320MB of data (0x14000000 bytes), the attacker can almost certainly guarantee that the 0x12121212 address is filled:

Low address case (heap is created at 0x00000000): We fill all addresses from 0x00000000 to 0x14000000, so 0x12121212 is filled.
High address case (heap is created at 0x001F0000): We fill all addresses from 0x001F0000 to 0x141F0000, so 0x12121212 is filled.

This is mitigated in 64-bit Windows 8 and later when the application is compiled with the /HIGHENTROPYVA flag: the size of the ASLR bias for the heap is 24-bit which results in 16,777,216 possible locations for the heap over a memory address space of 1TB.

You can find more information about ASLR in the BlackHat 2012 talk "Exploit Mitigation Improvements in Windows 8.


Is it possible for OWASP ZAP to pass-through some requests without intercepting them, as if there were no proxy?

Yup we have an FAQ for that: https://www.zaproxy.org/faq/what-options-exist-for-selective-proxying/

Options include:

Via a Browser Add-on/Extension
Via Global Excludes
Via a PAC (Proxy Auto-Config) File
Set “No Proxy For” in Your Browser


Can I Retrieve Email Addresses from BCC?

You can't. You simply won't have any information about the Bcc header when you receive the mail, so you there's nothing to "unmask".

The way Bcc is designed is specified in RFC 2822, under section 3.6.3. To quote the specification:

  The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
  addresses of recipients of the message whose addresses are not to be
  revealed to other recipients of the message.  There are three ways in
  which the "Bcc:" field is used.  In the first case, when a message
  containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
  removed even though all of the recipients (including those specified
  in the "Bcc:" field) are sent a copy of the message.  In the second
  case, recipients specified in the "To:" and "Cc:" lines each are sent
  a copy of the message with the "Bcc:" line removed as above, but the
  recipients on the "Bcc:" line get a separate copy of the message
  containing a "Bcc:" line.  (When there are multiple recipient
  addresses in the "Bcc:" field, some implementations actually send a
  separate copy of the message to each recipient with a "Bcc:"
  containing only the address of that particular recipient.) Finally,
  since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
  sent without any addresses indicating to the recipients that blind
  copies were sent to someone.  Which method to use with "Bcc:" fields
  is implementation dependent, but refer to the "Security
  Considerations" section of this document for a discussion of each.

  When a message is a reply to another message, the mailboxes of the
  authors of the original message (the mailboxes in the "From:" field)
  or mailboxes specified in the "Reply-To:" field (if it exists) MAY
  appear in the "To:" field of the reply since these would normally be
  the primary recipients of the reply.  If a reply is sent to a message
  that has destination fields, it is often desirable to send a copy of
  the reply to all of the recipients of the message, in addition to the
  author.  When such a reply is formed, addresses in the "To:" and "Cc:"
  fields of the original message MAY appear in the "Cc:" field of the
  reply, since these are normally secondary recipients of the reply.  If
  a "Bcc:" field is present in the original message, addresses in that
  field MAY appear in the "Bcc:" field of the reply, but SHOULD NOT
  appear in the "To:" or "Cc:" fields.

  Note: Some mail applications have automatic reply commands that
  include the destination addresses of the original message in the
  destination addresses of the reply.  How those reply commands behave
  is implementation dependent and is beyond the scope of this document.
  In particular, whether or not to include the original destination
  addresses when the original message had a "Reply-To:" field is not
  addressed here.

In practice the case where To and Cc recipients receive no Bcc line, but each Bcc'ed address receives a Bcc line containing only their email address, is most common. This provides no indication of a Bcc to the To and Cc recipients, and indicates to the Bcc'ed recipients that they were sent the email via the use of Bcc without revealing other Bcc recipients.


There are a number of reasons not to use SSL, none of which being a good reason in itself, but cumulatively they can explain a lot of things.

The main reason not to use SSL is an effect of the strongest force in the Universe, i.e. laziness. However easy setting up SSL is, not setting it up will still be easier. This alone explains why so many sites still use HTTP only, not HTTPS. A great many sites can get away with it, and not being attacked, because there just are not enough attackers around to attack every site, by a long shot (and attackers are no less lazy than everybody else).

Among other reasons, one can cite the following:

Hosting several HTTPS Web sites with distinct names on the same IP address has long been difficult, especially when the various sites don't know each other (either the server uses a certificate with all the names, but this can result in apparent and unfortunate associations, or the server relies on SNI, which does not work with Internet Explorer on WinXP).
SSL prevents some types of caching, in particular the transparent proxying that some ISP are quite fond of. This implies extra bandwidth requirements for the server (hard data on the increase is difficult to come by, and depends on the site type; for instance, a Web-mail interface like Gmail would be unlikely to benefit from heavy caching anyway, contrary to a picture-heavy site).
In (much) older days, HTTPS Web sites were not indexed as thoroughly as non-SSL sites, resulting in a widespread idea that you get better indexing by shunning SSL (that one has been wrong for quite some time now, but old ideas are hard to eradicate).
Some people still have the feeling that SSL implies a heavy computational cost (that one isn't correct either, but still common).
As an ironic twist, some people fear that using SSL would project the impression that they do care about security, thus increasing the reputation backlash if (when) they get hacked. The idea being that if you never claim or let it believe that you ever gave any attention to the concept of security, then maybe people will be more indulgent when they discover how much indeed you disregard it.


When to implement authentication and authorization?

You should let the client know about this too, you can provide them with 2 options, the first being the client will see A&A in the early stages and another seeing A&A in the later stages. This is sort of like giving the client a heads up & keeping them in the loop.

Equally important, depending on the client's needs, if the client wants fast results and implementation of security 'now' is not a factor, then he will go for the 2nd option.

I highly recommend implementing A&A at the start of the project, hence every other change & update you push from then on will be with respect to A&A being implemented, prevent hiccups & future errors popping up! Hope this helps.


Can you decrypt a TLS stream byte by byte?

Data in TLS is sent in TLS records, which can carry between 0 to 16KB of payload.

If you stop processing the received data at a TLS record boundary, there is no security problem I can see. The processed data was securely transmitted.

If you wish to stop processing data in the middle of a TLS record, you have a problem. You must verify the MAC for the whole record (and in CBC cipher suites also the padding), so you have to process the entire record. But if you don't verify the MAC, yes, you can decrypt a partial TLS record. Of course, because encryption is malleable, this is extremely insecure. The data in that record could have been easily changed by an attacker.


Am I correct in thinking that if I only visit sites that are on the onion network, I don't go through an exit node and therefore not at risk of the attacks/compromises that are associated to exit nodes?

Yes that's correct. If you are connecting to a hidden service, you're not leaving the Tor network. In theory, the hidden service itself is also not traceable and looks like a regular relay to all intermediate nodes. Since theoretically nobody knows where the hidden service is located, the usual attacks through observing exit nodes don't apply.

  I use a VPN all the time now on everything that I can get it on so that's the only IP address that would be seen but is it really necessary to use a VPN if you don't leave the onion network?

If you don't use a VPN, your ISP or network administrator will know that you are using Tor (but not what you are doing). So use a VPN if you find it desirable to hide your Tor usage from others. Connecting to Tor directly also facilitates traffic correlation attacks. Also, in case of a DNS leak attack, e.g. through the Tor browser, the VPN might give you an extra layer of protection as you'd only resolve addresses through the VPN tunnel and not give away your real IP address.


Is it safe to encrypt twice with AES, with any mode?

As long as you don't mess anything up in the implementation, the security should be at least as good as the least secure encryption. An example of such a mis-implementation (suggested by the comment) would be if you accidentally encrypted twice with AES-CTR mode using the same key and same IV (this is a mis-implementation since the IV must never be repeated with the same key). Such a mis-implementation and repeated application would result in the "double encryption" just returning the plain text.

You might expect much more security (for example if you use two different keys), but this is not always the case due to attacks like the "meet-in-the-middle" attack.

For example, the encryption algorithm "2DES" is two applications of DES with different keys, but there is a meet-in-the-middle attack on 2DES. This is is why people used 3DES, but nobody used 2DES.


Addressing availability element of CIA triad using technical controls

"Only available to certain users" is not a measure of "availability". That's "confidentiality".

Making sure that information is available to users who need it is a measure of "availability". Redundancy, backups, load balancing, parallelism are technical controls that address availability.

Access control and encryption do not affect availability but affect confidentiality.


How does Facebook avoid crawling over their site?

Other than the user's privacy settings, Facebook doesn't inhibit spiders. My scans show they are not even using a Web Application Firewall to block requests. The load to scrub every HTTP request of the most popular website would be massive undertaking.  The problem is that your scanner isn't equipped to interact with a mostly JavaScript client communicating to a REST backend.  Netsparker is also unable to detect DOM Based XSS,  which is more common on facebook.


How does 32 bit Meterpreter migrate into 64 bit process?

The migration works as follows:

Client sends a request to the server to generate a new payload with
specific architecture of the target process.
Server generated the payload and sends it to the client.
Client injects received payload into the target process, e.g. explorer.exe
Client calls ExitThread() to close the old connection without terminating the process.
New payload successfully connects to the server and awaits new commands.


It is unclear from your question when you are talking about the MySQL client and when you are talking about the server. While MySQL can accomodate encrypted passwords in the client (using mysql-config-editor) IMHO a better solution is to use an encrypted home dir (or sub-dir) mounted at login time, not least because it provides a means for storing other secrets.

If we're talking about local databases, then you can rely on the SO_PEERCRED for authentication, if we're talking about remote databases then using an ssh tunnel (with a keypair - possibly held on an encrypted home dir) and SO_PEERCRED might be more appropriate.


PKCS#7 is an old standard from RSA Labs, published later on as an "informational RFC". Then, a new versions was produced, as an "Internet standard", i.e. with the seal of approval from the powers-that-be at IETF; a new name was invented for that: CMS. Newer versions were subsequently defined: RFC 3369, RFC 3852, RFC 5652. You can consider CMS and PKCS#7 to both designate the same standard, which has several versions.

CMS (PKCS#7) is a format for applying encryption, signatures and/or integrity checks on arbitrary binary messages (which can be large). It can be nested. It is the basis for some protocols such as time stamping. It is also frequently (ab)used as a container for X.509 certificates: the SignedData type includes a field for a set of signatures (and that set can be empty), and also a field to store arbitrary X.509 certificates which are considered as "potentially useful" for whoever processes the object.

CMS is nominally backward compatible: there are version fields at various places, and a library which understands a version of CMS should be able to process messages from older versions; moreover, such a library should also produce messages which are compatible with other versions, inasmuch as it is feasible given the message contents. See section 5.1 for an example: the "version" fields are set to the minimal values which still make sense given what else is in the structure.

S/MIME is a protocol for doing "secure emails". S/MIME uses CMS for the cryptographic parts; what S/MIME adds over CMS is the following:

Rules for encoding CMS objects (which are binary) into something which can travel unscathed in emails (which are text-based). These rules build on MIME, so basically Base64 with some headers.
Canonicalization rules for signed but not encrypted emails, with "detached signatures". When an email is just signed, and the recipient might not be S/MIME-aware, it is convenient to send the signature as a CMS SignedData object which does not contain the email data itself; the signature is joined to the email as an attachment. It is then important to define exactly how the email contents are to be encoded into a sequence of bytes for the purpose of signature verification (a single mis-encoded bit would imply verification failure).
Restrictions and usage practices on the actual CMS objects: how much nesting is allowed, what types may appear...
Some extra attributes so that a sender may publish, in his signed messages, what kinds of cryptographic algorithms it supports and similar metadata.

In a way, we can think of S/MIME as the glue between CMS and emails.

OpenSSL is a library which implements some protocols, including some versions of PKCS#7 and CMS and S/MIME. The library also comes with command-line tools which expose, as a command-line interface, some functionalities of the library. The tools won't support anything that the library does not implement (the contrary would be surprising, to say the least), but the converse is not true: the library may implement features to which the command-line tools give no easy access, or no access at all.

Generally speaking, the command-line tools are not very "serious". They are convenient for some manual operations or a few scripts, but for robust applications you should use the library directly (it is a C library, but bindings exist for many programming languages).

Among the command line tools are the subcommands pkcs7, cms and smime. Confusingly, the cms command is meant to be used for S/MIME, and supports S/MIME, and turns out to be usable as a "generic" CMS support tool only as a byproduct. The OpenSSL developers created the new command cms in order to support recent versions of S/MIME (and CMS) because they felt that they could not update the smime command without breaking interface compatibility: third-party scripts using openssl smime would have become invalid, if the parameters for that command has been adjusted to account for newer S/MIME versions. So they just created a new command, called cms.

Theoretically, you should use openssl cms for everything related to S/MIME; but since that command gives access to the OpenSSL support code for the "new" versions of S/MIME and CMS, it necessarily allows you to produce S/MIME messages which are perfectly valid but use features that older implementations of S/MIME might not support. This is summarily described in the man page. Extensive tests with other S/MIME implementations (e.g. Thunderbird, Outlook...) are needed to know exactly what you can do with S/MIME without making your emails unreadable by other people.


Can data be forensically retrieved off an encrypted hard drive?

All current disk encryption methods strength relies on the key secrecy.

While your key remains a secret (and it needs to be strong enough to remain one), then the content of your disk at rest remains a secret. I say "disk at rest" because when the computer is running, ie. you already unlocked the drive yourself, then your file-system is accessible and also the secret key could be retrieved from your computer RAM.
When, since you mentioned this situation in your question, the key is known by the attacker, then the disk encryption does not bring any value anymore. If your file-system keeps the data of deleted files on the disk, then this data will still be recoverable.

The encryption mechanism and the file-system are two different layers, the encryption goal is to protect unauthorized access attempts to the file-system, but once this obstacle is removed then the file-system becomes freely accessible and keeps the same properties as in unencrypted disks (there might possibly be however some subtleties coming with the abstraction brought by this supplementary encryption layer and making data retrieval more difficult, but I would not rely on such side-effect to bring any real security).

So, if the question here is "Should I wipe highly sensitive files in case I am forced to reveal my encryption key", the answer is that this makes sense. Apart from such case, secure file deletion will not bring any value against attacker ignoring your secret key.


Pros/cons of using a private DNS vs. a public DNS

DNS is a very broad topic, even when you narrow it to have a security focus, however I will attempt to address this in a way that will make most sense to you.  If you are looking for a very high level introduction to DNS, I would suggest this.  For a little bit more detail, check this out.

First of all, you may want to be aware that Private DNS vs. Public DNS can be construed to mean multiple things.  The first thing that I thought of was split-horizon DNS, where you use the same DNS name for internal and external, but provide different information depending on the source of the DNS request.  There are other options, however, such as choosing to use completely different names internally and externally (such as example.com publicly and example.local privately).  I have seen both implemented in corporations, however having completely separate internal and external DNS servers and namespaces is preferred from a security point of view.

You would typically want to keep your RFC1918 addresses only in your private DNS, as well as your private addresses which are Internet-accessible.  This is less important with IPv4, but with IPv6, having Internet-accessible IP addresses is much more widespread (although not necessary).

Essentially, it boils down to the fact that you would want a private DNS infrastructure in order to serve employees, so that they would not need to memorize the IPs (or VIPs) of every service.  You would not want these DNS entries available to the Internet because it could be used for enumeration or discovery (see section 2.6), among many other reasons.  The security of a system is said to boil down to some basic concepts, and you must keep in mind that, if you release certain information, if it allows anybody to compromise the CIA triad.

There is also the option of an extranet DNS infrastructure, which would be for partner companies, or companies that you do business with on a regular basis.

Finally, public DNS is provided as a service to your customers, again, so that they will be able to contact whatever it is you are providing.  A couple of security concepts to keep in mind with DNS include:

DNS Open Resolvers and Amplification attacks
DNS Cache Poisoning Attacks
Zone transfers from rogue DNS servers

There are many, many more types of attack when discussing DNS, but I feel like the previous few are a good starting point.  If you are interested in DNS security, I would also point you to this write-up, and also DNSSEC.


SSL cipher suite: what does "export" mean?

"Export" means ciphersuites that were designed to be sufficiently weak they could legally be exported from the US back in the 1990s when there were much stricter legal limits on exporting encryption from the US (and some other countries, but Netscape was in the US). See Which SSL/TLS ciphers can be considered secure? for a summary, various sections of TLSv1 for the gory details, and TLSv1.1 for a vestige. TLSv1.2 deleted it altogether except for a reserved alert code.

The difference between EXP-EDH-RSA-DES-CBC-SHA and EDH-RSA-DES-CBC-SHA is that the first uses export-limited ephemeral Diffie-Hellman key exchange with RSA authentication (EDH-RSA) and 40-bit DES in CBC mode symmetric encryption with HMAC-SHA1 integrity (DES-CBC-SHA); the second uses export-limited RSA key exchange and authentication (RSA) (which possibly/usually uses a temporary RSA key for key exchange) and the same symmetric encryption and integrity.

The similarities are that both use a special variant key-derivation function, and both should not be or have been used for any security purpose after about 2002.


The point at which you can exchange the data makes it a "non-air-gapped interface".

The definition of an air-gap as per RFC 4049 is:

  An interface between two systems at which [..] they are not
        connected physically [..]

Normally, when dealing with highly sensitive data, you don't save it on an end-device.
There are Product Data Management solutions with comprehensive permission management that will run on a seperate server and store your files encrypted.

Any given user will never get access to the actual files but only to specific functions that can be applied to that file. In this way, you can ensure that some users can only view partial data whereas other users, if necessary, can commit write changes to the PDM solution that will then be applied to the actual file if found legitimate.

That said, data confidentiality is a very complex topic that does not have a perfect solution.
If you cannot guarantee the legitimacy of an access, there is no way.

If a user cannot copy the data, he/she will pull out his/her smartphone and make a photo. Once you hand the data to anyone who is not 100% trustworthy, mark it as "considered to be gone".


hide dhcp/ip request, traffic under lan router

Okay. I cleaned up your post to what i think it is you're asking for which is how to connect to a network without getting the router generating logs about my activity.

You can manually set your IP address of your machine to 192.168.1.199. Since your machine is the client, it must send a Discover request for an IP address to the router if it wants one. If you set it statically, the DHCP process never kicks in.

Additionally, you can manually set your DNS to something external like 8.8.8.8 (google's public/free DNS servers) but that will not let you resolve any internal client devices.

If you don't want someone knowing that you've connected to their LAN, your best bet in a scenario like this would be changing your MAC address randomly whenever you want to connect and using a Static IP. Most routers will store information on MAC addresses in order to assist in routing information correctly between clients.


Certificates in general
Certificates are complicated, I don't blame you. By far, the most common use-case for certificates is for TLS websites where you need to submit a Certificate Signing Request (CSR) to a publicly-trusted CA in order to obtain a certificate that browsers will accept. In that case you revoke your certificate by contacting the CA who originally issued it. This does not apply to you.

Certificates in Android / Google Play
My understanding of the Android / Play Store code signing model is that you generate a private "app signing" key using the wizard in Android Studio. This key is then used by Android Studio to sign your APK files, and in order to upload your app to the Play Store, you need to also upload your public key and associate it with your Play Developer Account. From here there are two models: A) that key is publicly-visible an your Play Developer account and end-users's devices verify that the app has been signed by that key, or B) the key generated by Android Studio is used as the "upload key", and Google generates a second "signing key" in your cloud account to re-sign your APK with. Option B is probably more secure since compromise of your laptop does not mean compromise of the signing key (assuming malicious uploads to the Play Store can be rolled back).

In your case someone else has access to your private key, so they can write any software they want and publish it with a cryptographic signature linked to your Play Developer Account (bad news for you).

What to do?
It doesn't seem like Google has a model for "revoking" app signing keys, but you can remove a key from your Play Developer account if you contact support. Google has a help article Manage your app signing keys, and at the bottom is:

Lost or compromised private keys
If you're enrolled in Google Play App Signing, you can reset your upload key if:

You lost your private key, or
Your private key has been compromised

Note: Resetting your upload key will not affect the app signing key that Google Play uses to re-sign APKs before delivering to users.
Reset your upload key

Step 1: Generate a new private key and upload certificate

Step 2: Contact our support team

Since you need to contact the Google Support team anyway as part of this process, I would just contact them right away for advice.


@trustme lpmxp625.com is a malware link so lets first start by finding out how i came to that conclusion.

If we do a Google search for that link* (The star indicates a link listed below) we find the first 100 results coming back as people asking how to remove lpmxp625 from their PCs which brings up red flags in my mind. Now we go to VirusTotal.com lets run a scan on the link**. After scanning the link 4 out of 50 antivirus engines comes back as saying its malicious with BitDefender leading the way. BitDefender has 98% detection from most tests***. We will continue on doing more tests with Sucuri which is a website scanner but it comes back with even more bad news for that domain****. We can scan with more scanners and tools but they all come back with bad news.

I personally use hosts-file.net for blocking malware/ad blocking i find it to be highly reliable for blocking malware and ads. I also use other lists as well. Most of these list are composed by volunteers who actively try to find malware so that other users don't get infected.

https://encrypted.google.com/search?num=100&site=&source=hp&q=lpmxp625.com&oq=lpmxp625.com&gs_l=hp.3...2108.12684.0.13417.6.6.0.0.0.0.121.396.5j1.6.0....0...1c.1j2.51.hp..6.0.0.0.G1fjtGRXyNg

https://www.virustotal.com/en/url/a8c9a4ae305969b7305b85d378eaf45dc147d9b43a12e88c5fe76d2b7cf56d76/analysis/

https://encrypted.google.com/search?num=100&q=bitdefender+wins&oq=bitdefender+wins&gs_l=serp.3...19756.34772.0.35011.14.10.4.0.0.0.73.642.10.10.0....0...1c.1.51.serp..1.13.603.1zCnWd1mqWA

http://sitecheck.sucuri.net/results/lpmxp625.com

Hope that helps.


How to detect use of personal NAS devices from corporate machines?

As a low-effort, low-yield approach; could you simply put out a note reminding people not to use personal NAS for business backups?

Knowing the risks of being caught with unauthorised material will surely deter at least some people whilst a more formalised technical solution is found?


Is there any reason why PHP files require write permissions?

I'm wondering whether to make most of these files readable/executable

PHP files do not need to be executable. That could be worse than having the write permission.

Furthermore, in the specific directories mentioned (e.g., var generated vendor pub/static pub/media app/etc) write permissions are probably required (at least for some file types). I have not tested it in depth, but generally it will break my Magento site if I don't give the permissions recommended (or a variation of them as I will mention next).

Recently I have been experimenting with an alternative permission scheme that I believe improves security. I asked a question about it here:

https://magento.stackexchange.com/questions/297324/linux-file-permissions-on-webroot-for-magento-2-when-755-and-644-are-not-good-en

The question comes from reading "You can have your cake and eat it too" at https://serverfault.com/a/357109. When I asked the question, I had not tried that scheme with Magento. I have tried it now and it works very well.

The other thing to be sure you have done is modify docroot to improve security. After doing this you should not have any executable files in the DocumentRoot of your Magento site. You can check from the command line like this:

find pub/ -type f -executable


Use XSS vulnerability in iframe to compromise parent?

Iframes have a special tag called "sandbox" that sets how to treat the content of the iframe.  Using that tag, you can granularly set permissions to allow an iframe to interact with the parent.  Normally iframes are pretty restrictive as to how they can affect a parent when loaded from a different domain, but if you see things like: allow-same-origin, allow-scripts, allow-top-navigation, etc then there may be case specific ways to exploit it.

[edit] Most cases of iframe XSS attacks do not actually involve injecting arbitrary code into the parent website.  Instead they are typically one of the following:

You take control of the child website, and replace it with something like a fake login form to make people think that they are loging into the parent website to access the content, when you are really phishing their credentials.
You distribute a "useful" service that other programmers embed in their sites that you actually use to phish private information.  Then you pray on people's trust of these other websites to get them to give you something useful.  For example: a tax bracket calculator that asks for your name, address, and SSN.
Instead of parent.com, you make an evil twin website called parents.com that contains parent.com inside of an iframe so that it behaves just like the real site, but your version of the website is collecting the end user's private information.

So, the most likely way for you to be able to exploit this scenario would be if you could replace the form with something that looks like a login form for parent.com and post not to parent.com, but to something that you actually control to steal user credentials.


Your solution should work well enough and I believe it is the best one possible currently without destroying the USB flash drive. The problem is that the old container may leave remnants for the same reasons, why it is insecure to change the password. Namely wear-leveling.

If these remnants include the header, the attacker may be able to retrieve some files, that were not overwritten. If you are really really serious about having the data 100% secure, you should put the new container on a new flash-stick and properly destroy the old one with the container with weak password.

Alternatively, as ThoriumBR mentioned, you may decrease the chance of the remnants surviving by writing random data to the flash drive (for example making largest possible empty VeraCrypt volume and also choosing the secure deletition). This does not guarantee the data will be destroyed properly, but it increases the chance somewhat. Repeated writing to the flash memory will however lower its life-expectancy, so the flash drive will be more likely to fail.


What is the nature of this SQL injection attack?

I'm no MySQL Guru but this SQLi attack appears to just gather information about you schemas. I have attempted to improve the formatting and converted the hex encoded ascii like 0x217e21 to its text equivalent. I don't understand all of this SQL but there are no updates, no deletes, no inserts, no stored procedure or batch calls. So I can see no way this would modify your server or you database.

If the attacker prepended a known name into this query they could then establish if the middle part of the query evaluated to true (they would get the student record returned) or false (no student record returned).

It appears that the attacker is trying to determine if any of your column names contain the pattern '%cc%', I would guess they are attempting to see if you store credit card database in your DB. They could then modify this script to find out in which table this information is stored and then modify it once more to select from this table. Tools like SQLMap allow this to be done quickly and painlessly.

SELECT * FROM students WHERE name = '' and
(select 1  from(
 select count(*),
 concat((
    select(
      select(
        select  concat('!~!',d.schema_name,'!~!')
        from information_schema.schemata as d
        join information_schema.tables as t on
            t.table_schema = d.schema_name
        join information_schema. columns as c on
            c.table_schema = d.schema_name and
            c.table_name = t.table_name
        where not c. table_schema in('information_schema','mysql') and
        c. column_name like '%cc%' and
        not t. table_name in('access', 'phpbb_users')
        group by t. table_name  limit 2,1
      )
    )
    from information_schema. tables  limit 0,1),
    floor(rand(0)*2))x
from information_schema.tables  group by x
)a)
and '1'='1'


In mobile, can "Early Media" be sent from the phone?

I don't believe that this is possible, as a standard/recommendation, due to the separation of signaling from media circuits.  The process of answering a call is separated from the interconnection of the circuits, and the latter is only possible/feasible after the call-status of acknowledgement of an answered call is returned.

The ringing heard on the caller side isn't necessarily indicative of the call-progress as it can and is often first provided by the originating network (you've heard double ringing before?), and the custom ringtones/messages are from a in-network peripheral that the called device is unattached from other than by account configuration stored separately from the physical device.

However, as a customization, this is not really a challenge for a non-standard device to capture the audio from the microphone of the pre-ringing device and send it back through the network as MMS (SMS-core extension) content.


Can I tell that both VPNs are used by using those traceroute info ?

Just based on the traceroute this is not possible. You need at least to know what the endpoints of your VPN connections should be and check if these are shown in the traceroute.

If the router VPN is used these endpoint IP are the VPN entry (router) and exit (somewhere on the internet). If the laptop VPN is used the VPN entry is the local computer and the VPN exit is somewhere on the internet. If both VPN are used together it will exactly look like if laptop VPN is used only since the underlying carrier for the laptop VPN (i.e. the router VPN) is not visible from within the laptop VPN but only from outside.

  If both VPNs are used, shouldn't I get more hops used in the 2nd traceroute ?

No, you should get the hops until the VPN entry (i.e. local laptop or router) and from the VPN exit (somewhere on the internet). Thus it depends on where exactly entry and exit are.

  Is there a more reliable way to test if both VPN are used ?

You cannot see this way if the VPN are stacked. A packet capture on all the entry or exit points of the VPN would be more reliable.

  Are the "VPN passthrough" settings in my DD-WRT router involved in my questions ?

Probably not. This should not be relevant for OpenVPN connections.


Sending order details in hidden input fields?

Looking at the details you have provided.Logic attacks can be conducted using burpsuite or any other proxy.The order amount can be changed to any arbitrary value.

P.s:- insufficient details about server side processing and checks.


Does chaos theory have any practical application in computer security?

Chaos is not sufficient. A cryptographically secure PRNG must produce unpredictable output: it should not be sufficient, for someone observing a long stream of values produced by the PRNG, but not knowing its internal state, to predict the next bit with a success probability substantially distinct from 0.5 (i.e. predictions should not work better than luck). In the case of f(x) = 2x2 - 1, it suffices to observe one output value to compute the internal state (if f(x) = y then x = ±sqrt((y+1)/2) and thus predict future behaviour of the generator. This would make for an extremely weak PRNG.

A secure PRNG produces output which is indistinguishable from randomness; as such, it looks chaotic. Being chaotic is necessary for a secure PRNG, but nowhere near sufficient, as the example above shows.

Chaos theory fascinates some people because it deals with chaotic behaviour emerging out of "normal" physical functions, which is surprising because "mundane" physics have accustomed us to expect tame, linear behaviour of physical quantities (thermodynamics being the prime example of that). However, computer security works on computer which already live in a discrete, thus non-linear world (it is all zeros and ones). In computers, chaotic behaviour is the norm; for cryptography, we must go much beyond that.

Chaos theory would be relevant if you had to build a PRNG without using a computer, but instead relying on a few tools from macroscopic physics. In that case, chaos would be all you would have to work with. Chaos theory is the right tool to explain why a lottery machine is a good RNG. But this does not apply to computers in which complete accuracy is the norm: you cannot measure a physical quantity with more than a dozen digits or precision, and the value you get is always approximate to some degree, as if the World kept the extra precision up its metaphorical sleeve; but you can get a thousand bits exactly, and there is nothing more in a computer.


How to sign and encrypt mails using firefox

I believe you misunderstood the Firefox function.

Firefox itself is not a mail client, therefore it doesn' provide you with ability to encrypt and/or sign your emails; use Mozzila Thunderbird with Enigmail and OpenPGP plugins if you're looking for this kind of functionallity.
Here's nice how to: https://securityinabox.org/en/thunderbird_main

The Security Devices function is used for the purpose when you wan't to use different password and certificate manager than the default Firefox one, I believe for example KeePass or something like that.


How to treat non-optional bad security questions?

"Security questions" are just an alternative password which is not used often, but which, presumably, will not be forgotten by the user. Since it is a password-equivalent information, treat it as such: use true, high-entropy passwords as answers to security questions. Of course, since you will not enter these often, you should write them down on a paper, stored in a safe place (they are meant to be used as a backup for the "true" password; you do not need them often).

(Note: most systems will handle responses to security questions in a case-insensitive way, which decreases the "entropy" of that password -- hence, make it even more random. 15 random letters would be enough.)


Searching a tool to perform SSL/TLS handshakes and store data

You can write yourself a script which uses openssl
openssl s_client -showcerts -connect ipv4:443 </dev/null
to connect to each ip you and grep all the required information.
The server certificate is the first certificate returned, and will be PEM formatted. The CA certificate is the final certificate returned, and is also PEM formatted.The output will also have the cipher and protocol used for handshake
For ipv6 use ncat. ncat -6 --ssl -v ipv6 443 and grep all the inforamtion.
If you want to enumerate all the ciphers that ip supports, you can use testssl.sh.I'm not sure whether ipv6 is supported.
As SNI is initiated by the client, you should already have the servername of that ip to get the SNI from the server. this question might help you

If you dont want to script your way through,check out Tenable Nessus(trial version available) or OpenVAS(opensource).Before you intiate a scan, chose only plugins related to information gathering, as some plugins actually attack the target and also simply consumes more time.


How strong is a simple XOR encryption with random IV?

I'd like to implement some kind of simple (yet as strong as possible) encryption > for my client-server application network traffic. Data to be encrypted can be both textual, and binary.

You're implementing a modified Vigenère cipher. That might be a problem in that any sufficiently large sequence of repetitive data (with binary zeroes being the most evident), or structured data (e.g. JSON) as pointed out by Polynomial, will reveal the key length and the algorithm that you're using, and trivially allow a decryption of a couple keylengths' worth of information.

Several cryptanalytic approach exist that can be adapted to your case. A simple distribution test will reveal that it's worthwhile to run an attack.

Apart from that, you have a standing vulnerability in the key distribution: either you have a key (or a finite set of keys) hardwired in both client and server, or you need to provide for secure key exchange.

  using certificates and big libs like OpenSSL is just overkill for my project.

Please do not take this wrong, but you're approaching this the wrong way. I agree that implementing OpenSSL would be orders of magnitude harder than going Vigenère (or Vernam/OTP which is the next logical step). But you needn't do that - you only need to use an existing library. After that you'll be safe and sound and will actually enjoy not simply more security, which may be superfluous to you, but greater simplicity of code and greater maintainability.

Depending on the setup, you could perhaps do this by simply dropping a SSL proxy such as Stunnel in front of your plain HTTP service:

                       |
HTTP service --- PROXY | === SSL channel === SSL client (browser)
                       |

and be able to both test your system in HTTP and supply your clients securely in HTTPS.

Other Web servers (both Apache and Nginx) as well as load balancers allow for SSLifying server-side services.


What stops a malicious DNS subdomain provider from impersonating my website?

Yes, the DDNS provider could issue a wildcard certificate. It could also send your visitors to another IP address, because the provider has control over the DNS entries of your subdomain. (Without a complicated MitM setup)

Given the constraints (no own domain name), you have to trust your DDNS provider to not spy on your visitors.

However, all new official certificates have to be documented in a certificate transparency log (rfc6962) to be trusted by Chrome and Safari (Firefox sadly does not offer this feature as of today). By checking these logs, you can find out if someone (e.g. your provider) has issued a certificate for your domain (or a wildcard certificate that includes your domain). You can check these logs at crt.sh.

To sum up, you can't prevent it, only detect it.


Why mobile applications share device characteristics with third parties?

The more information third parties have about a consumer the more accurately they can profile what causes a consumer to make decisions. Simply knowing what app's are on a mobile device can reveal a lot of demographic information about the user (think dating apps, news apps, religious apps, type of games purchased, etc). Likewise the type of hardware you are using can also imply economic information (using a $1200.00 phone vs. the most popular free phone given away with two-year plans). This type of information is worth a lot of money to a variety of organizations as it can help them persuade the consumer to do things (buy things, vote on things, change the way they view a political topic, etc.) What you are asking about is a HUGE subject and the data is used in millions or ways but the following to URLs would be a good place to get some background information on it.

http://www.cbsnews.com/news/the-data-brokers-selling-your-personal-information/

https://www.privacyrights.org/content/data-brokers-and-your-privacy

BTW: a popular book which covers this information and probably provides a much more in-depth answer to your question is

Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World
by Bruce Schneier
ISBN-13: 978-0393352177
ISBN-10: 039335217X


Why does sslstrip+ fail to intercept the traffic from websites like facebook and gmail?

That's because Facebook, GMail and other websites  are able to inform the browser that it is supposed (or not) to be secured with SSL thanks to HTTP Strict Transport Security (HSTS). This fixes the key problem with previous SSL implementations and what made SSLstrip possible.


Prevent external hard disk drive from infection

Your external HDD can get infected in at least 3 ways:

Executable files stored on the ext. HDD can get infected, meaning that what they do when executed is changed.
Your ext. HDD can be made to boot a mini OS which then goes on to boot your normal OS. The infection for this can happen at any time though policies of your operating system can prevent unprivileged of doing the according changes. At least on Linux you should be fine as long as you don't give the malware root rights. Actually harming you, however, can only happen this way if your ext. HDD is connected while you boot your computer.
The firmware of your ext. HDD can be changed in such a way that it makes malware stored on it persistent. Then even overwriting your entire HDD doesn't get rid of the malware. This includes of course formatting existing partitions, deleting them, creating a new partition table, etc. Exploiting this requires vulnerability of your ext. HDD's firmware.

None of these ways of attack can be prevented by simply partitioning your ext. HDD into 4 partitions.

However, the first one can be partially prevented by partitioning your ext. HDD into 4 encrypted partitions and only decrypting the ones you're planning to use. If for example you only need access to the backups partition, only decrypt this one. Malware then can't infect your executable files stored on a different partition. If you want to transfer files from or to a computer which might have malware on it, only decrypt the file transfer partition. Make sure to never execute files from there.

Exploiting the second way of attack can as I already said be foiled by simply having your ext. HDD disconnected when you boot. If this is too inconvenient for you, maybe disabling booting from USB is a better option for you as this also renders this way of attack impractical. Make sure, though to not only change your boot order to put HDD first. Disable booting from USB all together in your BIOS settings. Otherwise malware which also uses the 3rd way of attack can trick your computer into booting from the ext. HDD anyways, however, it's very unlikely that this happens. I've never heard of a malware doing this.

The only ways the 3rd way of attack can be prevented is through OS policies or having an ext. HDD which makes in nearly infeasible to change its firmware. However, if you connect your HDD to a different computers, it might have different OS policies. And if that computer has a a malware with systems rights running, OS policies are useless.


Modern encryption schemes are trying to achieve ciphertext indistinguishability (AES and others). It means that you cannot distinguish a ciphertext from a random sequence of bytes (no more than with probability of 50%).

This said, if your disk was encrypted, and if you consider that your opponents cannot break the cipher algorithm that you were using (at least not before the data in your disk will becomes obsolete), you can leave your disk as it is.

But, you definitely need to erase (and shred), all the key information (key slots) from any places where it might have been stored (because a physical access may lead to the recovery of it if a flaw is discovered).

Whatever, my personal advice is:

  Shredding does not take so much work (start it on a Friday afternoon and get your disks back on Monday morning clean and ready to be used). Just do not try optimize security, it is just wrong.


How much of a visible deterrent is IT security?

There are a number of different control types, to name a few there are Deterrent, Preventative, Detective, Corrective, and Compensating controls. The idea being that each type of control will specialize in providing a different type of security.

In the case of your padlock, that would fall under a deterrent control, since it is something intended to be noticeable and keep people away. Other examples would be a sign that warns people of a guard dog, visible security cameras, etc. Basically anything that can delay or deter an attack.

Preventative controls are in place to stop something from happening, so again the lock would fall into this category as well.

The best practice is to layer security across many different control types (and vendors) to mitigate the chances of an attack being successful. However, there is no such thing as risk elimination, just that you can reduce them down to acceptable risk as much as possible.

The main point is that the security should cause an attacker more trouble that the data inside is worth, ie. not worth the effort. Although im sure that there are probably people out there that would enjoy a challenge purely for the sake of it rather than the potential data that they could get to.

In the case of IT Security, placing warning signs on login to say that a user will be prosecuted would be classed as a deterrent.

If you saw two bikes, one with a big and heavy lock, and one with a small old-looking lock, and you wanted to steal a bike, which one would you choose?

Further Explanation

To explain this further we can break Deterrence controls into sub-categories:

Technical
Physical
Administrative

I'll explain each one individually below.

Techical

Technical controls that would deter a would be attacker are quite limited, in the case that the purpose of all deterrent controls is simply to try and stop someone from attempting to attack. For technical controls we can use warning signs on login pages, a proxy server that redirects to warn users a certain site is restricted, etc. It doesn't go any further than this though

Physical

Physical controls are anything that would make it look difficult to attack. Things like a high fence, visible cameras, floodlights, etc. would all be classed as physical deterrence controls. Signs that state that areas are off limits, would be another.

Administrative

Administrative controls contain policies, guidelines and standards. For example, a strict security policy that states severe consequences for violation would fall under this category. Training for awareness would also be an example here.

In summary, anything that makes a target look more difficult without actually implementing anything to stop them are classed as deterrence controls. There is usually some overlap, especially with preventative controls, because things like a locked door, or a high fence can fall under both categories.

If you want some further reading on the other types of access controls here is a short blog from a CISSP study guide that explains them quite well: http://cisspstudy.blogspot.com/2007/05/types-of-access-control.html