How does Android L achieve strong encryption with a low entropy passphrase?

Chip-based banking cards typically use a 4-digit PIN. It would take at most a few hours to try them all if the card didn't protect against brute force attempts. The card protects against brute force attempts by bricking itself after 3 consecutive failures. The adversary does not have access to a hash of the PIN (there are physical protections in the card that make it extremely hard to read its memory), but only to a black box that takes 4 digits as inputs and replies “yes” or “no”. The key to security here is that the adversary can only make online attempts, not offline attempts. Each attempt requires computation on the defending device, it is not just a matter of doing the math.

An Android phone or any other computer can do the same thing with its storage encryption key. The key is not derived from the passphrase (or pattern), but stored somewhere and encrypted with the passphrase. Most storage encryption systems have this indirection so that changing the passphrase doesn't require re-encrypting the whole storage, and so that the storage can be effectively wiped by wiping the few bytes that make up encrypted key (the storage encryption key is uniformly random, so unlike a key derived from a passphrase it isn't subject to brute force: the adversary needs to obtain at least the encrypted storage key to gain a foothold).

If the adversary can read the encrypted storage key, then they can make fast brute force attempts on the key on a cluster of PCs. But if the storage key is stored in tamper-resistant storage, then the adversary is unable to read it and can only submit passphrase attempts to the device, so the device can apply policies like “limit the rate of attempts to 3 per minute” or “require a second, longer passphrase after 10 failed attempts”.

The new feature in Android L is upstream support for an encrypted storage key that isn't stored on the flash memory (from which it can be dumped with a bit of soldering or with root access), but instead in some protected memory (which may be accessible to TrustZone secure mode only). Not all phones running Android L have such protected memory however, and even if it's present, there's no guarantee that it's used for the encryption. All Android L changes is providing the requisite code as part of the basic Android image, making it easier for phone vendors to integrate.

Android provides an API to check whether the application keychain storage is in protected memory). I don't know if there's a corresponding API to check the protection of the storage encryption key.


Contact Incapsula's support, they will help you set up a rule that prevent scripts/headless browsers from requesting random URLs. it can be easily done using their system


How did the brute-forcers get my IP address so quickly?

The IPv4 address range isn't that big.

A class A network (/8) has about 16 million hosts, and in theory there is 256 of them. As a result, the internet has about 4,294,966,784 hosts. Of course, this is an approximation.

Many address ranges are actually reserved (e.g. 127.0.0.0/8, 10.0.0.0/8), and others are actually one address that represent a NAT-ed internal network. But just judging from a naive back-of-the-envelope calculation, we can say it's somewhere in that ballpark.

What an attacker can do now is mass-scan one subnet for a particular service, such as SSH. Simply get a number of hosts (e.g. 32 hosts) and divide the target subnet evenly. Scan only for SSH hosts on port 22, and check which hosts reply.

An attacker can then either try to launch a brute force attack themselves, or they can sell that list of active hosts to someone else, who then attempts to attack you.

How long would it take to make such a list? Assuming that the attacker wants to scan a whole class A network (16 million hosts), with 32 hosts to scan, at roughly 100 hosts per second, we get a rough estimate of 90 minutes. Of course, time will vary, depending on the speed or the number of hosts, but it should be in that ballpark.


The official specifications seem to lack of test vectors but there are libraries including some:

Crypto++ Library http://www.cryptopp.com/
Bouncycastle Library http://www.bouncycastle.org/ (in class org.bouncycastle.jce.provider.test.GOST28147Test)

Hope this helps.


Why are packets constantly being sent to international ISPs?

Given the uncommon high ports and that the hostnames look like IP addresses from normal consumers I would suggest that this is peer-to-peer traffic. There are several legal or mostly legal programs which are doing peer-to-peer like Skype, Bittorrent and other file exchange programs. But peer-to-peer techniques are also used by malware like Zeus.

Since it is not known what you deliberitly run on your system one can not decide if these connections are caused by software which you run intentionally or by software which you run unknowingly, i.e. malware.


Need a word-list generator from a few words and numbers

I would recommend to extract the password hash with rar2john, then go with a mask attack with oclhashcat cracking with your GPU to gain some speed. It works well on windows.

simple example with masking:
say you know the password contains the string 'password' but the two numbers that follow are unknown. Then, the masking part of the command will look like this:

command: -a 3 password?d?d
keyspace: password00 - password99


Why do we even use passwords / passphrases next to biometrics?

Passwords and biometrics have distinct characteristics.

Passwords are secret data. Data is abstract: it flows quite freely across networks. Cryptography defines many algorithms which can use secret data to realize various security properties such as confidentiality and authentication. The shortcomings of passwords are due to the fact that they are meant to be memorized by human beings (otherwise we would just call them "keys") and this severely limits their entropy.

Biometrics are measures of the body (in a wide sense) of a human user. Being measures, they are a bit fuzzy: you cannot take a retinal scan and convert it into a sequence of bits, such that you would get the exact same sequence of bits every time. Also, biometrics are not necessarily confidential: e.g. you show your face to the wide World every time you step out of your home, and many face recognition systems can be fooled by holding a printed photo of the user's face.

Biometrics are good at linking the physical body of a user to the computer world, and may be used for authentication on the basis that altering the physical body is hard (although many surgeons make a living out of it). However, this makes sense only locally.

There is a good illustration in a James Bond movie (one with Pierce Brosnan; I don't remember which exactly): at some point, James is faced with a closed door with a fingerprint reader. James is also equipped with a nifty smartphone which includes a scanner; so he scans the reader, to get a copy of the fingerprint of the last person who used it, and then he just puts his phone screen in front of the reader; and lo! the door opens. This is a James Bond movie so it is not utterly realistic, but the main idea is right: a fingerprint reader is good only insofar as "something" makes sure that it really reads a genuine finger attached to its formal owner.

Good fingerprint readers verify the authenticity of the finger through various means, such as measuring temperature and blood pressure (to make sure that the finger is attached to a mammal who is also alive and not too stressed out); another option being to equip the reader with an armed guard, who checks the whole is-a-human thing (the guard may even double as an extra face recognition device). All of this is necessarily local: there must be an inherently immune to attacks system on the premises.

Now try to imagine how you could do fingerprint authentication remotely. The attacker has his own machine and the reader under his hand. The server must now believe that when it receives a pretty fingerprint scan, it really comes from a real reader, which has scanned the finger just now: the attacker could dispense with the reader altogether and just send a synthetic scan obtained from a fingerprint he collected on the target's dustbin the week before. To resist that, there must be a tamper-resistant reader, which also embeds a cryptographic key so that the reader can prove to the server that:

it is a real reader;
the scan it sent was performed at the current date;
whatever data will come along with the scan is bound to it (e.g. the whole communication is through TLS and the reader has verified the server certificate).

If you want to use the typing pattern, the problem is even more apparent: the measuring software must run on the attacker's machine and, as such, cannot be really trustworthy. It becomes a problem of defeating reverse engineering. It might deter some low-tech attackers, but it is hard to know how much security it would bring you. Security which cannot be quantified is almost as bad as no security at all (it can even be worse if it gives a false sense of security).

Local contexts where there is an available honest systems are thus the contexts where biometrics work well as authentication devices. But local contexts are also those where passwords are fine: if there is an honest verifying system, then that system can enforce strict delays; smartcards with PINs are of that kind: the card locks out after three wrong PINs in a row. This allows the safe use of passwords with low entropy (a 4-digit PIN has about 13 bits of entropy...).

Summary: biometrics can bring good user authentication only in situations where passwords already provide adequate security. So there is little economic incentive to deploy biometric devices, especially in a Web context, since this would require expensive devices (nothing purely software; it needs tamper-resistant hardware).

Biometrics are still good at other things, e.g. making the users aware of some heavy security going on. People who have to get their retina scanned to enter a building are more likely to be a bit less careless with, e.g., leaving open windows.


Statistics about webservers and browsers SSLv3.0 support

SSLPulse, a monthly scan of SSL amongst the 200,000 biggest websites, has statistics on SSL 3.0 support: https://www.trustworthyinternet.org/ssl-pulse/

They publish at the beginning of each month, so any day now there should be new data. Already you can see SSL 3.0 support dropped from 98% to 60% from October to November.

(You can use the "Previous" and "Next" buttons at the top right to view the data for each month.)

Coincidentally, Ivan Ristic is also involved in this project.

EDIT: Also see:

https://zmap.io/sslv3/


Is it secure to install RSA SecurID Software Tokens on the same computer that will be used to access the VPN?

No, it's not fine, obviously. One of the benefits of 2-factor authentication using RSA tokens is the fact that even if the attacker installs a keylogger on the victim's workstation or is able to dump memory of the user's processes, that information will not be sufficient to allow the attacker to authenticate with user's credentials, as a one-time password generated on a different device is required for the authentication to succeed.

If the software tokens are running on the same system, then a simple memory scan will reveal the tokencode and allow the attacker to authenticate on the user's behalf. The attacker can additionally copy the provisioned RSA secret and generate the tokens themselves.


Just a guess, but somebody may be looking for machines where a specific piece of software has been installed using git. It could be software that has a vulnerability, that they are seeking to leverage. In other words, a reconnaissance effort.
Interesting that they didn't even bother to spoof the user agent.


Seriously, don't be a Dave and roll your own crypto.

Use a proven KDF such as PBKFD2, bcrypt or scrypt to hash your passwords. See this great answer for more information on how to securely hash passwords.

For your scheme, mypass is essentially no longer your password. mypassxth is. An attacker has no problems just bruteforcing the password with his nice little GPU as you are using MD5. This has NO bearing on an attackers ability to bruteforce your password, and just makes password hashing that much more computationally expensive for your servers.

If you are using a good KDF like bcrypt instead of MD5 for password hashing, this scheme will add a lot of additional load on your servers with very little gain.


What is the difference between EDE and EDE3?

I checked https://www.openssl.org/docs/man1.0.2/man1/enc.html and found the following:

des-ede-cbc        Two key triple DES EDE in CBC mode
des-ede3-ofb       Three key triple DES EDE in OFB mode

So, EDE is two-key triple DES, and EDE3 is three-key triple DES.  See https://crypto.stackexchange.com/questions/63449/what-is-the-keyspace-of-2-key-3des for the differences between two-key triple DES and three-key triple DES.


How could the string \";alert('XSS');// be used for XSS?

In this case the first \ is escaping an escape to provide attacker with a un-escaped double-quote:

var x="\\";alert('XSS');//"

This is assuming the target application has a broken escape routine.


Is it secure to use email to add content to a website?

This is no more or less secure than sending a link in the e-mail that allows responding without having to login.  It is not particularly secure, but it is a supported feature.  There is already a post by E-mail feature provided in WordPress that you may want to look in to.  I'm not 100% sure that it will work for posting comments, but if you do have to write your own stuff, you could base it off the existing mail to post functionality.

Just be aware that e-mail can easily be spoofed and is sent completely unencrypted, so anything you e-mail may be intercepted and anyone could send an e-mail appearing to be from any address unless you use some kind of e-mail signing and verification.


Is WPA-PSK AES safer than WPA-PSK TKIP-AES?

TKIP is vulnerable to an attack similar to the WEP "ChopChop" attack.

TKIP uses MIC for guaranteeing the integrity of an encrypted
frame. If more than two MIC failures are observed
in a 60 second window, both the Access Point (AP)
and client station shut down for 60 seconds. The newer
TKIP attack uses a mechanism similar to the
“chopchop” WEP attack to decode one byte at a
time by using multiple replays and observing the
response over the air. When a MIC failure occurs,
the attacker can observe the response and waits for
60 seconds to avoid MIC countermeasures. Using
the mechanism, the attacker can decode a packet at
the rate of one byte per minute. Small packets like
ARP frames can typically be decoded in about 15
minutes by leveraging this exploit.

TKIP also includes a sequence counter that could
detect if a packet is being sent out of sequence.
However, with the introduction of QoS based on the
WMM standard, the sequence enforcement across
multiple QoS queues was relaxed for performance
reasons. This creates another security flaw. Once
a TKIP frame has been decoded, the attacker can
use the obtained key sequence to further inject
up to 15 additional arbitrary frames using different
QoS queues without triggering a sequence number
violation that would have lead to the injected packet
being dropped.

Summary of TKIP Vulnerabilities

This is not a key recovery attack. TKIP keys
are not compromised and it does not lead to
decryption of all subsequent frames.
The attack affects all TKIP deployments (WPA
and WPA2) regardless of whether they
use Pre-Shared Keys (PSK) or the more
robust enterprise mode with 802.1x
authentication.
The attack can reveal one byte per minute of
a TKIP encrypted packet. Small frames like
ARPs are good candidates for the attack.
If QoS is enabled, the attack can also lead
to injection of up to 15 arbitrary frames for
every decrypted packet. Potential attack
scenarios include ARP decoding followed by
ARP poisoning, DNS manipulation, etc.
WPA and WPA2 networks that use the more
robust AES-CCMP encryption algorithm are
immune to the attack.
The attack is capable of decrypting a TKIP
frame sent from an AP to a station
(not station to AP).


What a programmer should know before their web service's client audit

From what you have said, this would appear to be a common audit issue that would be raised from a compliance based approach to security.

I would expect that the security auditor is looking to identify if your new implementation supports weak SSL cyphers and therefore raise a risk based on this.

If your customer has a PCI/DSS requirement then the audit may look to confirm the following:

  PCI DSS Requirements
  4.1 Use strong cryptography and security
  protocols (for example, SSL/TLS, IPSEC,
  SSH, etc.) to safeguard sensitive
  cardholder data during transmission over
  open, public networks.

For more information, OWASP has a good deal of information on this and advise -

  Only Support Strong Cryptographic Ciphers
  The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected the server must be modified to disable the use of weak ciphers. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes.


Is it possible to have stateless server nonces in HTTP Digest

If the server is stateless, whatever the clients sends to "get authenticated" can be replayed. An attacker only has to eavesdrop on a request by a client, and then can send his own request with the relevant header simply copied. An expiry date prevents the attacker from doing that indefinitely, but even if the attacker can wreck havoc within your server only during one day, this is still unsatisfactory. Possibility of replay attacks is consubstantial to statelessness; it is unavoidable.

And HTTP Digest is not a great protocol anyway. HTTP Digest ensures a security service only in a model where attackers can potentially spy on exchanged data, but not alter it; this is not a very realistic model. In practice, you need something more thorough, like SSL, at which point you can send the password as is (HTTP Basic) and forget about HTTP Digest.


Experience with a recent DDoS attack on Apache

Requests to port 443 were likely faster because you were being DDoSed on port 80.  Apache preforks processes.  To service port 80, Apache needed to spawn a new process.  To service 443, Apache was using an existing process. (I think...  must check later)
DDoS mitigation is still a hard problem.  You need to discern legit traffic from fake traffic, and you need to do it with as little interaction as possible.
If this is a for-profit service, a professional web server admin and/or a DDoS mitigation service would be the way to go.

If you are a web server admin, then digging into the features of the tools e.g., CSF and Apache mod_security can help.  Attackers are focused on trying to look like legit traffic.  I'm an admin myself and this kind of attack is a serious PITA to protect against.  Getting a handle on the signature of the traffic and filtering appropriately can take time.  Fortunately, today, the DDoS tools don't respond quickly, so they'll move on to the next target or just give up for a while.

Note that there is a lot of sorta-legit traffic which looks like DoS attacks.  Badly behaved spiders are the most annoying to me.  People linking graphics into social media can look like a DDoS, with dozens or hundreds of hits per second (from unique IPs) if somebody deep links a graphic on a popular forum.

Be sure when you block somebody with IPTables, don't "reject" their traffic.  Drop it.  It slows things down.

I look forward to reading other responses on this topic.


Why there are some weird requests to my web hosting

I'm not going to say "ignore them entirely", but this is pretty common.

They're automated scans for logins - basically, anyone and their dog/cat/cow/python/rat can scan a site for common login URLs. If the scan finds them, then they'll usually probably try following up with credential stuffing attacks (i.e. using username/password combos that are either known defaults such as admin/admin or come from a data breach).

The best way to prevent those from succeeding is to not use weak username/passwords (using a password manager - nothing else is really practical), and enable two-factor authentication if Plesk allows that.


Is cellphone based (tethered) Wi-Fi hot-spot hackeable?

In theory yes it has its dangers like:

Someone can "Borrow" your connection
Someone can do packet sniffing

All these dangers only apply for users who are connected.
But since your phone doesn't have an IP for the control panel and your control panel is local and does not need access from an IP, no they could not get to your control panel.

All the data sent, received are encrypted and there will be use of a firewall.

Just keep your password safe and you should be fine.


Stack buffer overflow exploit stacking characters?

This is what I've came up with:

63 6D 64       ; "cmd"  <-- 0x19FF28
20             ; \0x14
31 C0          ; XOR EAX, EAX <-- 0x19FF2C
8D 1C E4       ; LEA EBX, [ESP]
88 43 03       ; MOV BYTE PTR DS:[EBX+4], AL
40             ; INC EAX
53             ; PUSH EBX
50             ; PUSH EAX (inc)
E8 74 77 F7 F0 ; CALL 74 77 F7 F0
19 FF 2C       ; jump back to 0x19FF2C

Takes up 23 bytes, however it needs a tweak on address, where it jumps.


What is the need of security token to prevent CSRF attack?

To prevent CSRF the most effective method is to provide a CSRF token along with every request.  This is a token that is generated on the server side and associated with a particular session.  Then whenever that session submits a request, your server side code will check to confirm the correct CSRF token was submitted.  If it was not, a CSRF attack has taken place and the request will be rejected.

Often times these tokens are stored in hidden fields, but if you are using a REST API then I suspect you are making a lot of AJAX calls and this probably isn't the best method.  I would suggest creating a global javascript variable that is initialized with the CSRF token one time and then accessed whenever submitting a request.  If you are using something like jQuery it is fairly easy to include another request parameter in all AJAX calls, so this might be an option as well.  The latter is typically what I do, and it makes for much cleaner code.

Here is a link to OWASP's CSRF prevention cheat sheet.  I would recommend giving it a read.


I think that it is not a good idea as this deployment would defeat the basic idea of SSL/TLS: End-to-end encryption.

In practice, such a deployment can cause the following problems:

Sites, web services etc. that use Certificate Pinning (e.g., via HPKP) would stop working because the browser / client is suddenly seeing a valid but different SSL certificate.
Many smartphone apps do certificate pinning for their web service endpoints because there is only one client which makes public key pinning relatively easy.
Google Chrome and Firefox a predefined list of pinned certificates and hard-codes the Google certificates into the browser. So Google domains would not be accessible from the Chrome browser any more. Here you can find more information on that regarding Firefox.

Everything in the SSL/TLS world is going towards pinning certificates and narrowing the trust relationship between CAs and SSL/TLS-enabled domains. That's why I don't think that what you suggested is a future-proof network design.


What you are essentially trying to do is build a pseudorandom number generator (with salt + Key0 as the seed) and use the output of it as a key stream to construct a stream cipher. Some comments:

Consider that if the first block is all 0, then all subsequent keys can be recovered. This follows from the fact that the first block is XOR-ed with Key1, and Key1 XOR 0 = Key1. If Key1 is known it can be passed to SHA512 to produce Key2 and so forth.
This is not a contrived scenario, even if the first block is not all 0, suppose it is some sort of header data where k bits are known. Those k bits can now be XORed against the first cipher text block to recover k bits of Key1. The search space is now reduced to 2^(512-k).
(Cryptographic) Hash functions in general only provide guarantees that they can't be inverted (given H(m) you can't find m) and are collision resistant (it is hard to find m' != m such that H(m) == H(m'). They say nothing about providing output that is indistinguishable from random, which is required of a cryptographically secure pseudorandom number generator.

Assuming a random oracle model (so point 3 can be disregarded and the output of a hash is treated as true random) and a uniformly random plaintext you would have security of 512 bits. I very much doubt however that this is the case, though it is hard to put an exact number on the security of the scheme. My recommendation is to use a well studied stream cipher seeded with random.


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

BitTorrent uses a method called Chunking, in which files are divided into 64 KB – 2 MB pieces. Each piece is hashed and the hashes (along with the piece size) are stored in the torrent's metadata (the small .torrent file, or the metadata you receive via DHT). That, along with the info_hash, makes BitTorrent quite resistant to intentional tampering (poisoning). SHA-1 is used in the info_hash and to verify the chunks.

The University of Southern California has made study on the subject:

  We discover that BitTorrent is most resistant to content poisoning.

  ...

  Because the index file is distributed outside of the P2P file-sharing
  system, each chunk can be verified with a reliable hash contained in
  the metadata. This verification provides BitTorrent protocol with high
  resistance to content poisoning.


Are salts and password hashing needed for random keys?

You seem to be mixing different use-cases here. One use-case is obtaining an encryption key from a secret. The other is storing login data.

If you need to derive an n bit encryption key for a symmetric cipher as your AES example suggests, the best you can hope for is n bits or entropy. If you have a true random source and use it to generate all n bits independently, that's the maximum possible entropy. Hashing your data at best won't decrease the entropy.

If your input is a user-provided pass-phrase, a key derivation function has to be used to condense the entropy of the arbitrary length string into the number of bits expected by the cipher. A simple hash function can be used as a key derivation function but it won't be very secure. User's pass phrases often have very poor entropy. The goal is to make the evaluation of the key derivation function so expensive that attacking the pass phrase is no more efficient than directly brute-forcing the key bits. In your case, the identity function already provides this property, however.

A different use-case is storing login data in a database. Here, hashing and salting is not used to “make the passwords more secure” but to make it hard to guess the actual password even in the case that the attacker gets hold of the database. If the database contains the passwords in plain text, it doesn't matter how long and random the password is. The attacker can always read it directly.


Are Flash .SWF apps (browser) a security threat?

If 'banners' means simply asking for user permission before executing the plugin, then the answer is yes - on an unpatched vulnerable system. Eg - CVE-2015-5122
Yes. Why not? I can record with your mic, take pictures of you and upload it for blackmail value or use it in a bunch of other nasty ways. Even if you don't care about someone being able to record you or photograph you, think about the possibilities of using this in combination with a flash 0day or even a vulnerability left unpatched by you, the user.
If you consider (1) and (2) security flaws, then this is a possible attack vector. Just apply the same exploitation concepts here. There's no difference.

Java exploitation: As @Anders said, this answer has been moved to that link

tl;dr: Yes. All of these are possible attack vectors, either in combination with SE or through exploitation of unpatched systems or using private exploits.


Since you just echo a GET variable, this is vulnerable to XSS. But that has nothing to do with your use of eval which I take is the main focus of the question. So let's look at that.

If you replace eval(...) with echo ..., you will note that no matter what you pass in, the output will be this:

return ($_GET["$a"]);

This is because you use ' and not ", so $expression does not end up conatining the value of the GET variable. So there is nothing controlled by the user in the expression you are evaluating - It's basically just a constant. That's not dangerous (given that the constant itself doesn't contain dangerous code), but it's not exactly useful either. You might as well just drop the eval.

But still... I would be nervous if I was responsible for this code. It sure looks shaky, and just using eval no matter why is a huge red flag. Plus, who knows what I might have missed in this answer.


Security issues with an append-only log in UNIX

For an authoritative answer, see your instructor.

Here are some possible security issues:

How will we enforce/ensure that the log can only be appended to, and no prior entries can be deleted/removed/modified?
Who/what will have authority to append items to the log?
Who/what will have authority to read the log?
What do we need to do to ensure that confidential information is not stored in the log, or else is adequately protected?
How will this stand up in court, if the logs ever need to be used as evidence in a legal dispute?
What information/events should I log?
How will we secure the information to be logged while it is in transit from the system generating the log to the system storing the log records?
How will we secure the log information on storage?
How will the log records be used?  How can they be used to detect attacks/fraud/anomalies?  What tools/techniques will be used to analyze the logs?

For techniques you can use to address these security issues, you might start by reading the following questions on this site (they should cover a good part of the space, and if there is anything specific missing, you can ask another more specific question separately):

Techniques for ensuring verifiability of event log files
WORM media types
What data should be logged?
Do any cloud storage system offer an append-only mode for buckets, directories, etc.?
How can I secure my log files?
How do I log everything a certain program is doing?
Is it legal to log passwords from failed logins
What's the risk if I accidently type my password into a username field (Windows logon)?
logging requirements for PCI for web applications


I would enable auditd to monitor changes to the files you expect to be backdoored. You will be able to determine which account and process that is responsible for doing these changes.

After installing auditd (not installed pr default on all systems), you can start monitoring changes in files. To do this, simply run the command:

auditctl -w /var/www -p wa

This command will log all file changes to the auditd log file. Usually you will find it in /var/log/audit/, but it is system dependent.

If you are concerned that the attacker might notice this (and maybe remove the rule), you can lock it by running the command:

auditctl -e 2

No further changes can be made to the audit rules until the system is rebooted. Before doing this, be sure that the audit rule above do not generate an insane amount of logs.

Lastly, the audit logs are a bit cryptic. Once you have found that the system is backdoored again, you can search for the audit trail, using the command:

ausearch -f /var/www/backdoored_file.php

I hope this will provide you with the clues on what is going on.
Good luck!

Additional:

To make the audit rules survive reboot, you have to define them in /etc/audit/audit.rules


What happens if someone gets access to my trust folder containing all trusted certificates, and uses one of them for his own client? Can he get access to my server?

The folder will only contain the public parts, i.e. the certificate with the public key. It will contain the private key for the certificate. But this is needed to use the certificate for authentication. Insofar this is not the part to worry about.

  ... if this approach is appropriate considering security standards?

You are essentially manage the trust into the certificates manually. This does not scale well but if you need only care about a few certificates this should not be the problem. Problems exist if the person which decides about the trust does the wrong decisions, but this is comparable to somebody issuing a trusted certificate to a party which should not get one. Similar revocation is cumbersome but this is not really better if you are using your own CA.

The main problem I see is that you don't control the information in the certificate, specifically the expiration time. In theory the client could issue a certificate which will be valid practically forever (i.e. something like valid until 2099). This will not be a problem if you expire the certificates manually anyway after some time (simple deletion) and expect the client to create a new one.

And of course, it is always a problem if you design your own process instead of using established processes since this increases the risk that you fail to notice if you do something dumb. And this can be a problem specifically in the context of security.


Does it matter which key is considered private and which public?

Shouldn't necessarily matter...
In RSA you can use either d (private) or e (public) to encrypt and also decrypt. This doesn't work with all cryptosystems. For example DSA won't allow this.

So technically it wouldn't really matter if you exchanged the values of e and d.

...but does
Performance:
But actually you usually want verification (using e) to be fast. And then accept that signing (using d) is slower.

Usually the public exponent is picked to be some simple and small binary representation. The number 65537 (0b10000000000000001) is regularly picked as the public exponent. And a much, much larger (about the same size as the modulus, so about 2048 bits nowadays) number as the private key.

See also: https://crypto.stackexchange.com/questions/3110/impacts-of-not-using-rsa-exponent-of-65537

Security:
And: You can't really flip this around (large public exponent, small private exponent), because there are published attacks on small private exponents. (Wiki: Wiener's attack)

See also: https://crypto.stackexchange.com/questions/3271/why-should-the-rsa-private-exponent-have-the-same-size-as-the-modulus


XSS vulnerability in a module that doesn't exist

...we get a 404 page

My guess is that this 404 page includes the script given as argument and thus the 404 page itself is vulnerable to XSS.

  How can we resolve this?

Nothing is known about your application so no specific fix can be recommended. But you should look into how you create your 404 pages. Likely you simply include the URL the user tried to access in plain (i.e. not HTML escaped) inside the error message which makes your 404 page a possible attack vector for XSS.


Security is so fun!
The correct answer is #1 because it is the only scenario that doesn't have an immediate impact on the security of assets on your organization. #1 doesn't do anything!

2) can compromise the physical security of your building or office, w/e

3) is the direct disclosure of sensitive data, the very definition of an internal security breach

4) can significantly disrupt operations, depending on what the server is used for and may create blacked out periods where you do not know what happened

5) can result in untrusted or outright malicious software installations or introduce additional weaknesses


Downloading a new SSL pinned certificate insecure?

Assuming the source of the new certificate is the one you're pinning, and the pinning certificate hasn't been revoked, you're probably OK. At some level, you have to trust the system (EDIT: I mean you have to trust that public key crypto works in general, not that the PKI/CA system in particular is trustworthy), and you're already doing everything you reasonably can to verify the server.

Now, with that said, standard practice is to pin only the public key information (which means you can do things like re-issue the same certificate with a new expiration date, without breaking your pinning) and to pin both the key of your current certificate, and a backup key. The backup key is for if you need to rotate or revoke your current certificate, rather than just re-issuing it. The backup key pair can be created in advance, and then you throw the only copy of the backup private key in a vault or something until you need it.

Between the ability to re-issue certificates so long as you don't change the public key, and having a backup key if you do need to change keys, you should have a large window between when you need to rotate/revoke a key, and when the pinning breaks. During this window, you can release an app update that turns the old backup into the primary key, adds a new backup, and removes the no-longer-trusted primary entirely. If necessary, your app can including a version check function that reminds users to upgrade from the store when the keys change.


How can you securely generate keys on AWS?

This "low entropy" mantra is a dud. See this answer for details. The executive summary is: some software, in particular /dev/random, may report a "low entropy" and block for reasons which make no practical sense. The idea of entropy being "exhausted" comes from a mathematical model which has only tenuous links with reality, and may (theoretically) provide any security gain only when the randomness is used for "information theoretically secure" algorithms. Usual algorithms such as RSA or AES are not of these class.

So what you need to do is the following:

OpenSSL should normally use /dev/urandom, avoiding the problem. If the problem occurs, it will manifest itself as a "blocking" behaviour (key generation takes an abnormal amount of time, with no CPU used).
If the problem occurs, "refill" /dev/random with fresh pseudo-randomness, which is good enough. Something like: dd if=/dev/urandom of=/dev/random bs=1024 count=64

There is, however, another issue which is not so easy to deal with. Cloud systems are virtual machines, which may run concurrently with other virtual machines on the same hardware. When two execution threads run on two cores of the same CPU, even if they relate to distinct virtual machines, they share the level-1 cache and may potentially spy on each other. The technique involves doing memory accesses in an array which uses the same cache lines as the target code, and reconstructing the target secrets by noticing when some array elements have been evicted from cache.

Working prototypes have been demonstrated in lab conditions. Whether they may be applied in a practical setup depends on a lot of parameters, and is currently unknown. However, it is plausible. The conclusion is that if you do something serious with keys, then you should strive to run on your own hardware, or at least obtain some guarantee from the cloud provider that your virtual machines will not share the same hardware servers as virtual machines from other customers.


Q: Need help understanding hacked site that only impacts AT&T LTE users

Is the page server over https? If not it could be AT&T intercepting and injecting ads. See https://www.pcworld.com/article/2976298/websites/att-wi-fi-hotspot-caught-injecting-ads-into-web-pages.html where they are doing it on WiFi hotspots for http and https

As for the scenario were a hacker did this, a number of hackers try and restrict the set of people who see the malicious content to extend the time they are un-detected for. Targeting specific mobile carriers seems like it would not be worth the effort unless the attacker has a grudge against AT&T.


Metasploit x86/unicode_upper failed with "An encoding exception occurred"

A workaround for it is to leave off the encoder selector -e x86/unicode_upper. Thus, the msfvenom will try some encoders up they find some that work with the corresponding bad characters.


In client side certificate authentication why, if, do we need to share the certificate

Do you exchange the pfx, with the private key as well as the certificate?

Only the client certificate is provided to the server. And the client proves to the server that it has access to the private key by signing some data which are at least in part provided by the server. This is actually very similar to how it works with the server certificate.

  If I had a certificate signed by a trusted CA why not just send that one and the server would just need to validate it? is the case that the exchanges certificates are ad-hoc ones and they just need to validate it's issued by them?

"Trusted CA" is what the server considers as trusted for the authentication of the client. This often does not mean that the certificate was issued by a publicly trusted CA as is preinstalled in the systems but by a private CA which the server considers as trusted for the purpose of client authentication.

  Is this exchange where the Certificate Signing Request can be used?

A certificate signing request (CSR) is used when applying for a certificate. In case of a private CA trusted by the server you need to send your CSR to this private CA which then issues a certificate based on the CSR. Note that using a CSR is not mandatory. Instead it might be that you just get issued a personalized smartcard with a certificate (and the matching key) already on it without creating a CSR.


Is malware or screen capture possible with iMac as external display?

You are correct in that there are risks with the Thunderbolt to Thunderbolt connectivity when connecting two devices.

The DMA type of attack you mention is a distinct and very real attack vector.
https://en.wikipedia.org/wiki/DMA_attack

However Tramell Hudson's talk on Thunderstrike is probably the best description of the security issue you are asking about.
https://trmm.net/Thunderstrike

At this time, unlike BadUSB ( https://srlabs.de/badusb/  ) we don't currently know of a specific tool taking advantage of this issue but given the complete lack of security controls and the similarities to known vulnerabilities in FireWire and USB we do expect exploits to be developed which will take advantage of the Thunderboldt protocol.

As for the ++DP on the Thinkpad Laptop I believe that actually means it supports Dual displays but regardless of the configuration since the Laptop is communicating using the Thunderboldt protocol it will be subject to attacks as they arise.

Additional Relevant link: http://www.extremetech.com/mobile/197005-new-apple-malware-is-undetectable-unstoppable-and-can-infect-any-thunderbolt-equipped-device

Hope this helps.


I have the CEH certification.

First, please read the official FAQ.

The CEH is pretty basic and covers pre-made tools for hacking and penetration testing, which means that you could pass the exam without a lot of pre-knowledge of anything. That said, you will have a much easier time (and you would be a much more effective CEH) if you did understand the basics of TCP, DNS, and operating systems.

Info Security is a wide area of study and you will never stop learning. Start somewhere and keep pushing in areas that interest you.


What is this QR code authentication scheme called?

The QR code is not relevant here. QR is just a way to encode some arbitrary date in a way which a computer (or a smartphone) can decode based on a photo of the printed code.

What you suggest is, in fact, basic password authentication. Although you call the password a "PIN", it still is a password: something that fits in the brain of the human user, and the user enters it when needed.

Indeed, let's see the point of view of the attacker who has stolen the phone, and wants to gain access to the webapp. Through some reverse engineering, he obtains the stored K'. Then, for every possible password (PIN), the attacker can compute the corresponding K, just like the phone would do. That "K" is just an encoding of the password. There is no way for the attacker to know which potential K is the right one without talking to the server; the attacker is then in the position of an online dictionary attack. In that sense, this scenario is not really different from a simpler basic authentication in which the webapp just sends the password to the server.

However, if we look at the details, there are two points where your suggestion slightly changes the security model:

Since the password is encoded with the stored value K', the attacker must know that K' to enact his attack. That is, the attacker cannot do it without first stealing the phone (at least if the encoding is done properly -- there are many ways to botch usage of encryption). This may enhance security when compared with a basic "show the password" authentication. One might even claim that the whole system is two-factor authentication in that the attacker must obtain both the PIN ("something you own") and the phone ("something you have") to perform the attack. However, since smartphones are quite complex computers, they suffer from the same issues with malware and keyloggers, and since the PIN code is typed on the phone itself, the two factors are not as isolated from each other as we would wish.
The authentication value (the K) is sent as a "QR code": in the proposed system, K must be, at some point, known to both the mobile app and the server, so there must be some communication. A QR code is a communication channel which goes through the phone camera, suitable for situations where a more common network socket is inapplicable. This K is the important value; knowing K grants access to the server. But you encode it as a QR code, meaning that the K will be printed on a screen or on paper at some point, and be quite visible. This is weak against shoulder surfers. We usually don't like it when secret values are made so visible.

This can be enhanced. Instead of the QR code, use normal network. We could call it device pairing (and that name is a reasonable answer to your specific question, i.e. the terminology for this pattern). Namely:

User has an account on a Webapp, on which he usually authenticates with a password.
User launches the mobile app for the first time. The mobile app talks to the server and asks for the user's password.
With the user's password, the app authenticates with the server, and registers on the server an app instance specific authentication token: some random value is generated (on the app or on the server, it does not really matter) and "stored" in some way on the phone.
For each subsequent connection, the server will accept the connection from the user only if it "combines" both the phone-stored value (that the server remembers as being associated with that specific user) and the user-specific PIN code.

There are many ways to do this "combination"; some are cryptographically good, others are not. In the case you describe, the combination works that way: what the phone stores is not the authentication token K itself, but a transformed value K' which is an encryption of K with the PIN code; the "combination" is then decryption of K' with the PIN code as key. If the "encryption" is a single invocation of a good block cipher, this may work. As with all things crypto, implementation is a matter of delicacy.

The QR code, here, would just be a way to convey the authentication token from the server to the phone. It seems redundant and useless: this value K is a secret, it won't be shown to just anybody, only to the right, duly authenticated user. So that does not avoid an initial authentication with the normal webapp password. The only scenario I see where it makes sense is when the user logs on the webapp with his computer (the computer has a nice keyboard, making password entry easy), and wants to pair his phone with his account without actually making any network call between the phone and the server. This seems a bit weird, though: to obtain the app, the phone must have been connected to the Internet, and it will have to be connected to actually talk to the server.


Can Zap scan a web app launched as a JAVA applet?

Per: https://java.com/en/download/help/proxy_setup.xml
For a Java Applet the proxy details can be set via the Java Control Panel.

Configure Proxies through the Java Control Panel

In the Java Control Panel, under the General tab, click on Network Settings.
Select the Use Browser Settings checkbox.
Click OK to save your changes.

Network Settings for the Java Control Panel
Close all browser windows. Restart the browser and try to load the applet.
If the applet still does not load and you see the same connection error,
try to configure your web browser's proxy settings.

So yes you should be able to configure either Java or your Browser to use ZAP in order to capture and manipulate the traffic from a Java Applet.


Using a VPN but Akamai Technologies still registers where my computer is?

The issue was due to DNS leakage.

To fix the problem I needed to find my VPN's DNS server. After that I had to set my network adapter to query DNS from that server.

The problem was fixed, akamai technologies no longer server up web addresses.


Can hackers access Firefoxs login storage through the internet?

The answer, according to me would be yes in cases such as:

Website is able to execute code on your machine and exploit a vulnerability. In general if an attacker can execute code on your machine it doesn't remain your (secure) machine anymore.
You are fooled into entering password on the wrong website using the browser password store.
Finally, vulnerabilities in the browsers password store mechanism itself will lead to access of stored credentials. Refer to:

https://www.bleepingcomputer.com/news/security/firefox-master-password-system-has-been-poorly-secured-for-the-past-9-years/

https://www.threatcare.com/password-manager-vulnerability/

Hope this helps.


No, the intended difference is that MAC says the security officer has given me access to, for example, the SDE compartment. Within it, there are files I can set (DAC) acls on, but no matter what access I assign you, the MAC will stop you from reading those files unless you also have been cleared for access to SDE.

Discretionary access is under my control
Mandatory access is under senior management control
MAC always trumps DAC


Is it possible to use more than one certificate on the same server at the same time?

Yes, you can have more than one trusted certificate path on a single server.

Regarding your concern, please note that certification path does not refer to certifying the server certificate, but its public key, therefore certification path might consist of one self-signed certificate only.

Speaking of server providing two self-signed certificates is equivalent to speaking of server providing two certification paths.


How do I investigate where personal information in a fraudulent email was leaked from?

This could be related to almost anything, personal information are sold just like any other "things" on the darkweb and even on the "web" by relatively legal entities, Databrokers are selling personal information just like any other stuff.

In addition to this as @anon said OSINT tools might be used to gather information about persons, and there are lot of such tools (Shodan, Recon-ng, Foca, Maltego ...).

An other way also is the previous data breaches defined as:

  "A data breach is a security incident in which sensitive,
  protected or confidential data is copied, transmitted, viewed, stolen
  or used by an individual unauthorized to do so."

You can check if you are victim of a previously known data breach using your email at Have I been pwned.

Hope it helped


Exclude file names from mod_security patterns

As Mark Hillick said, we'd have to see the mod_security audit logs to answer this. The logs will show just which OWASP rules are being matched. You could then read the documentation for the rule(s) here. Or you could post a couple of examples of the logs here, showing the specific matches. Then we could better help sort this out with you.


Token Exchange at a REST API Gateway to federate authentication while maintaining detailed authorization (think ABAC) within the API?

I believe the way you describe the problem, keeping the 2 security perimeter and configurations decoupled, is a perfect fit for Token Exchange scenario. Some time has passed since your original post and IdP and API Management solutions have started implementing this functionality (https://www.keycloak.org/docs/latest/securing_apps/#_token-exchange) so I believe you are not the only one requiring this specific pattern.
To answer to your other doubt around stateless token and revocation, you might know already that token revocation is actually a standard (https://tools.ietf.org/html/rfc7009) but that can be implemented only for refresh tokens and by reference token. For by value token this is clearly not possible, but the workaround is obviously to keep the TTL low.


OpenSSL brute-force attacking and file size

it depends, but - generally - no. AES is a block cipher, so you're breaknig a thing by 256 bit blocks in your case. And 100KB is more than enough to guess a type of "what's inside", by MIME, for example, after that a task is a way more simplier


Dealing with the dangers of self-hosting a webserver?

Sounds like you've done a good job doing taking care of the usual suspects.

How good is your web development skills? In my work experience, misconfigured web servers are the most common threat vector for a breach. Having it be only static is a good move. Have you disabled all the default pages? Is the webserver up to date? Have you run any vulnerability scans against it (at least run ZAP, it's free). Opening up an inbound port into your network with a server on it is, let's say riskier, as you now have a footprint on the internet for scanners to find. Granted, your home router is also getting scanned and attacked on the regular.

If this is on your own home network, and someone breaches it, you are in a really bad spot. Have you considered hosting it on AWS or etc? That at least segments it away from your home systems with critical information on them. I am not saying don't do this, as some might, but I highly suggest network segmentation for it, though, away from the rest of your home network.


You are touching a sore point...

Historically, computers were mainframes where a lot of distinct users launched sessions and process on the same physical machine. Unix-like systems (e.g. Linux), but also VMS and its relatives (and this family includes all Windows of the NT line, hence 2000, XP, Vista, 7, 8...), have been structured in order to support the mainframe model.

Thus, the hardware provides privilege levels. A central piece of the operating system is the kernel which runs at the highest privilege level (yes, I know there are subtleties with regards to virtualization) and manages the privilege levels. Applications run at a lower level and are forcibly prevented by the kernel from reading or writing each other's memory. Applications obtain RAM by pages (typically 4 or 8 kB) from the kernel. An application which tries to access a page belonging to another application is blocked by the kernel, and severely punished ("segmentation fault", "general protection fault"...).

When an application no longer needs a page (in particular when the application exits), the kernel takes control of the page and may give it to another process. Modern operating systems "blank" pages before giving them back, where "blanking" means "filling with zeros". This prevents leaking data from one process to another. Note that Windows 95/98/Millenium did not blank pages, and leaks could occur... but these operating system were meant for a single user per machine.

Of course, there are ways to escape the wrath of the kernel: a few doorways are available to applications which have "enough privilege" (not the same kind of privileges than above). On a Linux system, this is ptrace(). The kernel allows one process to read and write the memory of the other, through ptrace(), provided that both processes run under the same user ID, or that the process which does the ptrace() is a "root" process. Similar functionality exists in Windows.

The bottom-line is that passwords in RAM are no safer than what the operating system allows. By definition, by storing some confidential data in the memory of a process, you are trusting the operating system for not giving it away to third parties. The OS is your friend, because if the OS is an enemy then you have utterly lost.

Now comes the fun part. Since the OS enforces a separation of process, many people have tried to find ways to pierce these defenses. And they found a few interesting things...

The "RAM" which the applications see is not necessarily true "memory". The kernel is a master of illusions, and gives pages that do not necessarily exist. The illusion is maintained by swapping RAM contents with a dedicated space on the disk, where free space is present in larger quantities; this is called virtual memory. Applications need not be aware of it, because the kernel will bring back the pages when needed (but, of course, disk is much slower than RAM). An unfortunate consequence is that some data, purportedly held in RAM, makes it to a physical medium where it will stay until overwritten. In particular, it will stay there if the power is cut. This allows for attacks where the bad guy grabs the machine and runs away with it, to inspect the data later on. Or leakage can occur when a machine is decommissioned and sold on eBay, and the sysadmin forgot to wipe out the disk contents.

Linux provides a system called mlock() which prevents the kernel from sending some specific pages to the swap space. Since locking pages in RAM can deplete available RAM resources for other process, you need some privileges (root again) to use this function.

An aggravating circumstance is that it is not necessarily easy to keep track of where your password is really in RAM. As a programmer, you access RAM through the abstraction provided by the programming language. In particular, programming languages which use Garbage Collection may transparently copy objects in RAM (because it really helps for many GC algorithms). Most programming languages are thus impacted (e.g. Java, C#/.NET, Javascript, PHP,... the list is almost endless).
Hibernation brings back the same issues, with a vengeance. By nature, hibernation must write the whole RAM to the disk -- this may include pages which were mlocked, and even the contents of the CPU registers. To avoid leaks through hibernation, you have to resort to drastic measures like encrypting the whole disk -- this naturally implies typing the unlock password whenever you awake the machine.
The mainframe model assumes that it can run several process which are hostile to each other, and yet maintain perfect peace and isolation. Modern hardware makes that very difficult. When two process run on the same CPU, they share some resources, including cache memory; memory accesses are much faster in the cache than elsewhere, but cache size is very limited. This has been exploited to recover cryptographic keys used by one process, from another. Variants have been developed which use other cache-like resources, e.g. branch prediction in a CPU. While research on that subject concentrates on cryptographic keys, which are high-value secrets, it could really apply to just any data.

On a similar note, video cards can do Direct Memory Access. Whether DMA cannot be abused to read or write memory from other process depends on how well undocumented hardware, closed-source drivers and kernels collaborate to enforce the appropriate access controls. I would not bet my last shirt on it...

Conclusion: yes, when you store a password in RAM, you are trusting the OS for keeping that confidential. Yes, the task is hard, even nigh impossible on modern systems. If some data is highly confidential, you really should not use the mainframe model, and not allow potentially hostile entities to run their code on your machine.

(Which, by the way, means that hosted virtual machines and cloud computing cannot be ultimately safe. If you are serious about security, use dedicated hardware.)


TLS replay attack - requirements of the serverHello nonce

Within SSL/TLS, the nonces are used for generating symmetric keys, and as part of the signatures and checks during the handshake. For all those usages, the nonces are simply concatenated (with some other data) and hashed. Assuming that the hash functions behave like "random oracles" (the mythical perfect hash function), then unique nonces are sufficient.

However, SSL/TLS up to (and including) TLS 1.1 uses MD5 and SHA-1 as hash function, for which weaknesses have been demonstrated. They are not random oracles. I am not aware of any result about turning these weaknesses into attacks on SSL/TLS itself; however, better be safe than sorry: use unpredictable nonces. This will not harm, and both client and servers must already have access to a cryptographically secure source of alea, hence unpredictable nonces should not be a too heavy requirement.


Incident Reporting or Notification Policy domain?

You're describing a procedures (i.e. "how do do X"), not a policy ("Do X").  As such the name of the procedure doesn't really matter.  What matters is that it references and is supported by one or more higher level policies.

An information security policy should cover far more than what you've described; I would be very hesitant to title your procedure "Information Security Policy" - that would be like labelling the keyboard "My computer".  The example is intentionally overstated, but if your company were audited and the auditors found your one-pager as the only document labelled "Information Security Policy", then you would have implicitly authorized all actions not covered by that policy.  (I don't know if your company is subject to audits. You've included a pci tag which leads me to believe that it is a possibility).

Generally the information security policy includes incident response policy.  Procedures are written to implement the policies.


Are commercial VPNs useful for privacy, or do they just add another party to be worried about?

Commercial VPN don't add a party to worry about but replace a party. If you worry that your ISP or the public hotspot you use might sniff or even modify the traffic, then you can use a VPN - in which case you have to worry that the VPN provider is doing such stuff instead.

It is thus mainly a question of who you trust more. If you already know that your ISP is sniffing data or even injecting ads into the traffic then it might be easy to trust the VPN provider more. But if both claim that they will protect your privacy and you have no real arguments to believe one more than the other then it is hard to tell what you should more be worried about.


How to be PCI compliant with Shopkeep (and others)?

Well, the first thing you'd do is put the iPad in "Guided Access" (single app mode) so that the only app that can be used is whatever point of sale software you've got on there.

Next, put it on an isolated network segment that doesn't have external access and is properly secured, and you can actually have a pretty secure setup.  At least as secure as typical point-of-sale systems, which are quite frequently lower-spec PCs running Windows.

Finally, there are a lot of MDM (mobile device management) systems and iOS configuration management systems out there to lock them down further.  As mentioned previously, many point of sale systems are actually Windows PCs.  If you can lock those down to make them PCI-compliant, why wouldn't you be able to do the same with a device running a different operating system?


Exploit Development on windows environments

Once the stack is properly overwritten you will see that ESP (stack pointer) has the address where the payload (reverse shell) starts.

As this address changes after each reboot, it cannot be used in the exploit code. Since the address is stored in ESP, all we need to do is find a JMP ESP or PUSH ESP in order for the program logic to jump to our shell code.

Using Mona within Immunity debugger:

First search for all DLL's that are used by the program, this can be done by typing:

!mona modules

This should give a list with DLL's. Now carefully search for a DLL where DEP and ASLR is not enabled. Additionally, make sure the address does not contain any bad character such as null bytes, carriage return and line breaks.

Once that is found, double click the DLL and search for the commands:

JMP ESP

or

PUSH ESP
RETN

In case no results are found, click "C" in the menu bar and search for the opcode "\xFF\xE4" (this is JMP ESP) by typing:

!mona find -s “\xFF\xE4" -m [dll file]

If the PUSH ESP is found, this memory location should be used in order to jump to the shell code.

So what you see in those exploits are memory locations where JMP ESP is performed.


In practice, what software can support is uniformResourceIdentifier. The extension then contains a URI which points to the CRL. http:// and ldap:// URL are rather common; https:// URL for CRL download raise interesting issues since the server certificate must then also be validated (so, in practice, it does not work well, or at all).

In situations where machines have a "natural" LDAP server to talk with (e.g. Windows systems in an Active Directory forest), a directoryName can conceivably be handled automatically, by looking at what exists in the LDAP server under that name. I have not seen it working in the wild, though.

For the other name types, well, some make little sense (e.g. dNSName) or would imply human intervention (rfc822Name). The root of the issue is that GeneralName is a really generic structure which is used in many places, and there is no guarantee that any specific GeneralName value makes sense when employed in a specific context, e.g. as part of a CRL distribution point.

If you are writing a generic validator and you just handle http:// URI for CRL download, then you will have already done better than most (most implementations of X.509 do not check revocation at all !). If you also support ldap:// URI, then the term "luxury" could apply. Realistically, the only reasonable thing you can do with the other name types is to totally ignore them.

That's for CRL download but CRL distribution points have another use, which is segmentation. This is what happens when the CRL Distribution Points extension is critical. In that case, you must match the distribution point name with the Issuing Distribution Point extension in the CRL (regardless of how you obtained said CRL). Segmentation is a way for CA to issue smaller CRL, which cover only a subset of the certificates they issued. To know whether you are using the right CRL, you must match the names between the certificate and the CRL. For that, handling the other name types could be necessary. However, this is not about interpreting these names, but just equality tests.


Passwords are not encrypted inside a POST request.

If any encryption is done it is either at the transport layer (i.e. HTTPS instead of HTTP) and/or there is some application specific client side encryption done. In your case it seems to be the latter and you have to look at the applications code (i.e. the Javascript executed by the client) on how exactly this is done with this specific application.


Where do magic constants for signature algorithms come from?


What architecture could be suitable for a secure environment?

In short yes.

The 2.5 kernels the linked paper talks of are built into the processor and motherboard firmware. Specifically newer Intel processors on UEFI based boards.

There are endless devices that will happily run linux on far simpler boards. Most ARM based setups will have notably less between the OS and the hardware. A Raspberry Pi is an easy to point to example - although there is still a layer of firmware on the chip. There are also entirely open sourced boards like the beagle board. And then you have the option to simply go for older hardware.

However as @schroeder points out in the comments why would fewer layers translate to better security? If you don't trust the hardware manufacturer then how do you know that there isn't an additional hypervisor hidden deep within the chip? - especially seeing as most modern x86 processors have huge numbers of transistors which are never or extremely rarely used in normal operation.

If your security requirements drop to not trusting Intel/AMD then this is one of the simpler aspects you need to consider.


I have my website in wordpress and it got hacked how to secure it?

There are many ways to secure your Wordpress website.

First of all, you need to always keep an up-to-date version of wordpress. Very often, the Wordpress team produces a minor release that aims to fix several bugs and vulnerabilities.

It's probably how the attacker hit your website.

Now, if you search in Google, you'll find some interesting blog posts. I won't copy/paste here all the tips, but here are some good ones:

10 Ways To Secure Your WordPress Install
11 Ways To Secure Your WordPress Blog

You can also consider using this plugin :

Secure WordPress Plugin


Is it possible to "hack" a mobile phone just because it's WIFI is enabled?

AFAIK, it is a common demo in security conferences. While one of the conferencers starts speaking, another one starts a WiFi dump tool to identify phones with an open WiFi. Then he offers them to connect on his network by trying to provide an expected SSID => fine he has immediately done a MITM. As smartphones often carry many apps that try to sync as soon as a network is available, it is likely that attacker will soon get valuable informations on the sytems and applications. Assuming that the attacker is a specialist in pentesting (common for security conferences), the risk that he can find a vulnerable system or app is... rather high if the Wifi was opened - read the owner of the phone is probably not very cautious about his device security.

Then he just tries to get various informations to prove that a hack was possible in a short time and shows the results, with a real impact on people who were hacked, which is the goal of the demo.

Now for the questions:

is it possible is Wifi is closed: no
is it possible on any smartphone with an open Wifi: probably not, because you still need talkative and vulnerable apps
what is the risk on your smartphone? Just count the installed applications that can automatically sync data, and try to evaluate how much you can trust their developper


Tamper Protected VS. Tamper Proof for write-protected memories

About tampering

Dan Kaminsky from "The Motherfucking Professionals" held a great talk at Blackhat 2011 regarding tamper-evident, tamper-resistant and tamper-proof devices. One of the key points he made was that there is no such things as a tamper-proof device! Anything can be tampered with, and it's up to whomever it may concern to see how far one would go to check for tampering.

He explains the meaning of those three words:

Tamper-Evident: A tamper-evident device does not stop you from accessing something, but it makes it evident that you did. A good example for tamper-evident devices are those G-force stickers used on packages. They don't stop someone from handling a package roughly, but it will be evident (by the broken glass) that it was handled roughly.
Tamper-Resistant: I assume that this is the closest to "tamper-protected" in your original question. A tamper-resistant device will actively attempt to prevent you from tampering with something. So it's a bit of a middle-ground between a lock and a seal.
Tamper-Proof: A device that claims to be tamper-proof is a device that is impossible to tamper with. It's effectively as real as a lock that claims to be pick-proof. As I already mentioned in the comments, nothing is tamper-proof.

From this list, you can see that tamper-protected is a stronger claim than tamper-evident, and tamper-resistant is a stronger claim than tamper-resistant.

About Memory

Neither ROM nor other write-protected memory is tamper-resistant or even tamper-evident, at least not by default. While these devices are designed to not be writable, they are not designed to be unique. That means, I can take one ROM chip out of a device, and insert a different ROM chip (of the same model) with my own data, and I have tampered with the device. If my soldering was on point, it will not be evident at all that this has happened. As such, any regular ROM fails at being tamper-evident at all.

Are there ways to make it tamper-evident?

Yes, there are. You could, for example, put a cryptographic signature over the contents of the ROM and a unique serial number. That means that without the knowledge of the private key being used, I will not be able to modify the content of the ROM without the signature check failing (which would make it evident that I tampered with the ROM).

This could be circumvented by replacing the public key that does the verification with my own public key, that I used to sign the tampered ROM contents with. But then it again remains evident that the ROM was modified. It depends on who does the checking, and how thoroughly they do.

You could also attempt some physical tamper-resistance. A simple example would be a solid epoxy blob over the chip. Yes, it will not stop a dedicated attacker, but it makes it harder to tamper with the thing, so it fits our definition for tamper-resistance (and you will now realize that we never specified how well something has to resist).

All in all, any tamper-resistant or tamper-evident device or measure can be defeated by a skilled and dedicated attacker.


Interviews with staff members about privacy and security policies relevant to their positions

I don't know URAC, it appears to do with HIPPA based on cursory googling, though I would assume the context of what is trying to be achieved is the same as other sectors (for me finance).

I would say there are three categories that are important:

General Knowledge:

This would be everyone's responsibility. A common reference to this is your information security policy used organization wide, internet control polices, and user training around phishing/social engineering attacks. You can even lump best practices here.

Role Specific knowledge:

These are polices specific around your job and responsibilities. If you work with PII or medical records (IE you're a DBA) do you know the practices for access into the system, what level encryption or hashing is used, what the difference between PII and public information is.

Sector/Government Compliance Policy:

An example of this (for the finance sector) is the ABA, which is company wide training around laws and regulation to provide a check and balances policy. This is usually required by either a group or a government.


Does TOTP make sense for verification codes?

You probably could, but it doesn't make much sense. Email and even SMS can take long enough to reach people - even people who are explicitly checking for the message - that you'd need to check the last few minutes of codes, which broadens the range of allowable values and slightly increases the risk of an attacker guessing/brute-forcing the code. Meanwhile, the whole point of TOTP - that the generator and the verifier don't need to have any communication channel and only need two common pieces of info (the key and the clock) - is moot here.
Instead, just generate a short code using a cryptographically secure (pseudo)random number generator and send it to the recipient, plus store it (possibly in hashed form) briefly. You can use a database, or just store it in RAM or a cache if that won't pose problems due to load balancing, etc. That way there's only one valid value, you can revoke it immediately any time you want to (e.g. once it's used, once it's expired, or if you detect multiple failed attempts), and there's no persistent secret (the TOTP key) that can be stolen by an attacker to enable generating all future codes too. You can also easily make changes to your codes - change their character set, their length, the way they're generated, etc - any time it feels important.

As a side note, if your site/service has any highly sensitive data - payment info, sensitive PII, etc. - please do not use anything SMS-based as a sole authentication factor. SMS is not very secure, and also mobile phone operators are notoriously bad at verifying your identity before re-issuing your SIM card (or otherwise transferring your number) so possession of a given phone number is not strong proof of identity. Even US government guidelines (which are in many cases behind the times) say you need to offer alternatives to SMS and explain to users that choosing SMS for authentication (assuming you offer it at all) is taking a risk. SMS is acceptable - though still not ideal - as a second factor for authentication, most commonly in combination with a memorized identifier (password/PIN).


Generally the probability comes down to the size of the range.  So for, say, a 4 character password, the password space the number of available characters raised to the power of the number of places in the password.

For example, a bank pin - 4 digits, 10 characters (0-9) - 1000 possible passwords, making the probability 1/10000.

Now your problem is harder, since your range is not all available passwords, you have removed some of the highly guessable passwords.  What you're going to have to do is figure out how many potential passwords are eliminated by each rule, and make sure you account for rules overlapping... for example 12345678 is both a sequence AND all characters. Then take the total password space, subtract the passwords that are forbidden by each rule, making sure not to count a given type of password twice.

I'm not sure what you mean by "it cannot have the word "johnbook" " perhaps I'm being way too literal - obviously "johnbook" is just one password.  Do you mean it can't have that particular word, or it can't have any known common name or short word combination?  For example, is "bethdesk" also forbidden?  What is the size of the dictionary being checked and all are all word combinations long and short forbidden?  You should be able to use combinatorics to figure this out, but you need the algorithm or rules of password checking to know how much this limits the size of the password space.

Also, virtually any word combination is also going to be an "all character" sequence - so have you basically eliminated that, or is the system checking for obvious substitutions - like "passw0rd"?


Could a Chromecast be compromised from its default open network?

An attacker could connect to the open network, but there is nothing but the Chromecast itself they could reach there since nothing else is connected. If the TV is turned on, they could potentially cast to the TV and play whatever they wanted on it. This could be used for some less than fun pranks I guess.
As for your points #1 and #2, these are theoretically possible. Any device can be hacked. But it is not on the level I would expect from an opportunistic attacker who happends to stumble upon an open network. Unless you are a high value target, I would not be worried.
So should you factory reset the Chromecast? Yeah, if nothing else to make sure no one else but you has access to it. You could change your wifi password as well. But should you buy a new Chromecast? No. The cost benefit calculation on that one is not good. Theoretically, your TV could have been compromised through the HDMI connection of the Chromecast but you wouldn't throw your TV out because of this, would you?


Why is it dangerous for a company to allow employees to connect their own devices to the internet?

... allow employees to connect their own devices to the internet?
  ... bring their own device and connect it to the network.

There is a difference between these two phrases and this difference is the important one. It is not really a problem to let users connect to the internet per se with their own devices.

The main problem is if users connect their devices to the companies internal network, because then they might infect the network with malware or cause the leak of sensitive data through there private devices.

Another problem is that any traffic will be associated with the company, which includes clients send spam, spreading malware or downloading or distributing illegal files etc. Thus the company might be held liable for any damages.


CLI API that requires plaintext user details

If you can't change the API, then you need to either store the password or ask for it from the user every time you need to make an API call.

Assuming that asking isn't practical, store the password encrypted.  No, it won't stop a serious attacker, but it's better than nothing: storing the password in plaintext won't even stop a script kiddie.


Giving a PFX cert to a 3rd party email service for DKIM?

DKIM does not work with certificates, it works with plain RSA keys. The private key is used for signing and the public key for validating the signature. To make this possible the public key must be accessible using DNS, i.e. it is stored in a specific DNS TXT record.

While you could in theory use the key pair associated with an existing certificate there is no need to do this and it is probably much better to create a new key pair so that the key for an existing certificate does not get compromised at all. Since only the plain public key is stored in DNS there is also no need to create a certificate with this key and let a CA sign it.


You want to investigate a Hardware Security Module. This offloads the keys (and the crypto processing) to a hardened device from which the keys cannot be extracted.

The best known ones are from Thales and Safenet, and they offer versions that are local PCI boards, locally attached (via USB) and network-attached.

If you only have one or two keys, you can also use a USB token, which is a small, low-end HSM in a form-factor similar to a thumb-drive. Another alternative is a smart-card or CAC, which is the chip from a token in a PVC card that is the same size as a drivers license or passport card, or like a very chubby credit card.

In any of these cases, you would install a driver and engine (both are software constructs) to access the device. From here, you would not have access to the key, and would instead access it via the PKCS#11 API interface or the Windows CryptoAPI, which would wrap the request to have the encryption/decryption on your behalf in hardware.

I would also recommend to have three of these devices, of the same type. When you gen and import the keys, do it on all of them, and then test-encrypt the same string with each and compare the output. If it does not match, beware. The first one is for online use. The second is for near-line backup (if it were pocket-sized, in your safe or in your secretary's locking filecabinet) . The last one is your DR/BC copy, and that should stay with your lawyer, with written instructions about when and to whom it can be released. Put simply, over a long enough time, these devices can fail, but are statistically unlikely to all fail together.


A secure phone line is conceptually possible; this is not really different from, e.g., a secure communication between a Web browser and a HTTPS server (there are technical subtleties about lost packets and whether they should be tolerated, but that is not the issue here). However, the movie-secure phone is not secure, and that's a structural problem.

The problem lies in the question: "is your connection secure ?". If you need to ask to the other guy whether the line is secure, then the line is not secure. That's as simple as that. A "bad guy" could hijack the line and, when you ask whether the connection is secure, the bad guy could simply respond "yes it is !", counterfeiting the voice of the intended recipient (and, in the other direction, he could "replace" the question by an innocent sentence).

In a secure phone line, the caller and the receiver shall be authenticated to each other, which can be done with various cryptographic tools (e.g. digital signatures, or, more simply, a shared secret). Variants of the same tools also establish a session-specific shared secret which can be used to symmetrically encrypt the data. Bottom-line is that once people begin to actually talk, the line should already be secure and both participants shall have ways to know it (e.g. they are using special phones which refuse to communicate if security is not achieved). Otherwise, there is no security.

On a more practical point of view, if I were to implement a phone-like secure system between two entities, I would investigate using VoIP over a VPN. This would require some delving into the details of the VoIP protocol, so I would do that with an open protocol (i.e. Ekiga, not Skype).


There are a few resources such as CIS. IF you want to by up to military standards, I would check out the STIGs (Security Technical Implementation Guides). They have STIGs for SQL Server, and you can check out the general DB reqs.

From your post, it is not clear if you are working in a web environment, but you probably want to know about SQL injection, etc. I'd start at OWASP. They have some general information on SQL injection, some secure guidelines, and some testing guidelines.

In terms for finding current exploits, you can search through CVEs.

If you provide us with some additional detail, we can provide some more resources. You may just want to check amazon for books on the subject that fit your style and focus.


What software commonly generates RSA keys with public exponent 0x23 (35)?

Versions of OpenSSH up to 5.3 AFAICT then they switched to F4=65537. I don't recall seeing an explanation for why they used 35, but I haven't read every line of everything.


Considerations for securing a computer on an open LAN?

If others can read foreign packets in the network, they could intercept your SSL traffic (it's also possible to manipulate the trust store), besides many other things (also attacking your services).
I would recommend you to consider this network as insecure and to use a VPN with good encryption in unsafe networks (so in your office network too).


Citations for Least Privilege network services?

Not sure which kind of reference you're looking for, but The Principle of Least Privilege was first enunciated by Saltzer and Schroeder in their 1974 paper "The Protection of Information in Computer Systems":

  Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide "firewalls," the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of "need-to-know" is an example of this principle.

(Saltzer, Jerome H. (1974). "Protection and the control of information sharing in multics". Communications of the ACM 17 (7): 389. doi:10.1145/361011.361067. ISSN 0001-0782.)

The full paper can be read here.

That should be a valid enough reference.


FIDO U2F use over multiple devices for the same service

Nothing is stored in the Desktop in the case of USB Security Key Based FIDO U2F (Yubikey, PlugUp, HyperFIDO, IDKey, Neowave) implementation. There are other implementation (e.g. Entersekt) which are tied to the client computer.


Is there any point to connecting to a VPN server while on the local network?

Only if you distrust the other users of your home network. I mean, kids these days, one minute you're teaching them to ride a bicycle, the next they're poisoning your ARP cache and sniffing your traffic.


This is a very interesting question, I've come across this when a client was designing a fire-code-compliant office space. The client's work was related to the defence industry and the office space had two rooms with highly classified contents.

Now, of course, if you're a 3-letter government agency, you can disregard whatever laws you want, but let's assume that we want to follow the legal procedure.

The laws are clear when it comes to building code and fire safety (in all countries it's pretty much the same, but I'll quote the one from the United States). The National Fire Protection Association Life Safety Code 101 says

  Locks, if provided, shall not require the use of a key, a tool, or
  special knowledge or effort for operation from the egress side.

So to comply with the laws, the client built the rooms on the side of the hallway, making them impossible to use in the path of egress, then installed a big red button that would mechanically open the door from the inside. Behind the door there's a turnstile gate (though a very different model) that would only allow egress but not entry.

The idea is simple. If your room provides a step on the egress path, then by law it must be opened in the direction of the egress path. So it all comes down to thinking about security when designing the building.

I've found this image online and I added the red arrows and text to illustrate the point (those aren't really exits and fire exits)

So, Should magnetic locks automatically release in the event of a fire alarm? The answer is, it depends.


Risks of explicitly trusting SSL certificate vs relying on certificate chain for validation?

What are the risks of not relying on the certificate chain for SSL certificate validation and instead manually importing the certificate as trusted?

One is related to the fact the chain of validation typically includes a CRL and/or OCSP service to query for invalidated, but otherwise legitimate, certs.
In other words, a cert may be technically valid, but have been invalidated because its private key was compromised - CRL and OCSP are standardised ways of dealing with revocation, which is not generally the case of manual certificate management.

I would also tend to think this is a waste of resources: why expend additional effort on meeting a need that has a better, and more to the point, standardised, solution?

Especially at any scale, surely this is also inefficient: versus the one root (or e.g. 5 root + intermediate CAs) you might want to trust, you would need to distribute X end-entity certificates, and additionally, would be bound to the issuing CA's lifecycle for certs in terms of needing to re-distribute new certificates.

  What additional risks, if any, are there for not keeping the list of trusted root CAs updated?

As mentioned, revocation is one area that springs to mind: absent an effective revocation mechanism, a trusted CA merely indicates that something was, at some point, trusted. It has no clear significance for whether this same 'something' is now trusted.

Without maintaining your trusted roots, I would tend to think you are rendering much of the purpose of x509 moot: trust is a transitive property, and any assumptions to the contrary have tended to be exploited for malicious purposes.


Can't get handshake through de-authentication when penetration testing WiFi

In general, de-auth packets are are part of normal AP to wireless client communications, so the AP can't just change channel on each de-auth packet.

Try to send a limited number of de-auth packets, if you're close enough to the AP, a packet or two will do the job nicely.

Edit:
From comments feedback, the problem was because of using scripts to automate several de-authentications, and it was solved by sending packets manually.


I've read up some on how different images can be malicious and was wondering if this is possible with these icons.

Theoretically. But the instructions you quote are for replacing the displayed icon with the one in the SVG, which is harmless. At most you can mark the Gimp with a Calculator icon and mess with people that way; hardly a "vulnerability" if you ask me.

My desktop manager does not interpret Javascript in the SVG, which could (and has been) a vulnerability, nor does it attempt to open the referring schemas (which could be used for clickverting campaigns or even DDoS, if one succeeded in distributing bazillions of forged SVGs and induce people to adopt them).

The reason why VirusTotal did not classify your SVG as harmful is because it isn't:

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   [...other namespaces...]
   width="64px" height="64px" id="svg3765" version="1.1"
   inkscape:version="0.48.4 r9939" sodipodi:docname="gimp.svg">
  <defs id="defs3767" />
  <sodipodi:namedview id="base" [...sodipodi properties...] />
  <metadata id="metadata3770">[...metadata in RDF format...]</metadata>
  <g id="layer1"
     inkscape:label="Layer 1" inkscape:groupmode="layer">
    <rect id="rect3773"
       style="fill:#00222b;fill-opacity:1;stroke:#00ccff;stroke-width:3;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
       width="61" height="61"
       x="1.5" y="1.5" />
    <g id="text4283"
       style="font-size:144px;font-style:normal;font-weight:bold;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#00ccff;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Myriad Pro Bold Italic">
      <path id="path3064"
         d="m [...graphic path...]"
         style="font-size:61px;font-variant:normal;font-stretch:normal;fill:#00ccff;font-family:Myriad Pro;-inkscape-font-specification:Myriad Pro Bold Italic" />
      <path id="path3066"
         d="m [...graphic path...]"
         style="font-size:61px;font-variant:normal;font-stretch:normal;fill:#00ccff;font-family:Myriad Pro;-inkscape-font-specification:Myriad Pro Bold Italic" />
    </g>
  </g>
</svg>


Why are larger block sizes more desirable?

Block size increases the combinatorics - there are many more different blocks.

3DES and Blowfish always work on 64 bit blocks, regardless of key size. AES always works on 128 bit blocks, regardless of key size. We now know 64 bit blocks are insecure if you send a lot of data.

For more, read the site and the paper for sweet32.


How can be detected connection throttling in response to portscan detection?

Logically you cannot know at which point the server will block you until you actually reach the threshold and be blocked. This is not something that the server will advertise.

If you have a spare IP, you can increase the number of packets per second until you are blocked, at which point you know what threshold not to cross with your other IP.

Good firewalls are likely to use more complex heuristics, depending not only on the number of packets but also the target ports. Chances are that you can work out the actual firewall heuristics by burning a few IP, but you cannot guess it a priori.


Infected Drupal 6 website page with a php shell

Your server itself (not Drupal) was compromised by a local Linux (root) exploit. Although Drupal may have aided in getting the exploit onto your machine, your machine was exploited with CVE-2013-2094, the "semtex.c exploit"

$ md5 fileshare.ro_trolled
MD5 (fileshare.ro_trolled) = ff1e9d1fc459dd83333fd94dbe36229a

$ strings fileshare.ro_trolled | grep -i @fu
sd@fucksheep.org 2010

Cleaning Drupal will do nothing for you, me expanding on what the exploit does would be reinventing the wheel, you can read about what the exploit does (has since been ported to perf) here

My suggestion is starting from scratch with a clean install. The only mechanism to ensure nothing else is backdoored (top, netstat, etc) would be to have been running Tripwire or something similar, where you can go back and compare checksums to trusted sources.


Why should web applications use multiple gatekeepers?

While I personally disagree to the use of the term "gatekeepers" in this sense, I believe they are referring to the various defense components/modules that make-up a defense in depth stratergy for the same.

An example of this would be, while a web.config file cannot be read via HTTP in plaintext, any user logged into the system via a remote desktop solution (SSH, rDesktop, VNC, TeamViewer,PowerShell, etc) would be able to read it clearly. In such a case, not only wil you have to configure IIS Web Permissions to block access but you will have to be configure NTFS (File System) permissions to specify which users may read/write/execute that particular file.

Therefore, I believe they are saying that a serial combination of these "gatekeepers" will help you in developing an effective authorization stratergy.