Firstly, what does it mean "A proxy is something that acts on your behalf"? Can anyone give a more detail explanation about proxy? I read a number of papers but still bit confused

The client connects to the proxy, either explicitly (configured as proxy in browser) or implicitly (transparent proxy). The proxy then looks at what the client wants (i.e. access web site) and executes this. This means the client does not get the web site by itself but it instructs the proxy to get the web site and then gets the data from the proxy.

  Secondly, how can application proxy know if the incoming data is safe or not?

They don't really "know" fully if the incoming data are secure. But they can check if the application protocol is valid, can check the payload for malware  signatures, extract suspicious payload and execute it inside a sandbox etc. This way they can detect at least part of the unsafe content.

  Thirdly, how does a proxy function if i am going to send packets to external network

If you don't send the data to the proxy but directly to some external network than the proxy must be somehow in the path. This is usually on a firewall where packet filter rules redirect your traffic to the proxy for analysis.


Is there a reason to disable root login, if SSH connections are restricted to a single IPv4 address?


What port state to expect from Nmap when scanning ports that are open only to specific IP addresses

It really depends on the firewall configuration, but almost every one will give back the default Port Closed message. If the default firewall behavior is to drop the package, it will be dropped. If is to send a RST package, you will receive a RST.

I am not aware of any firewall that responds with a Port is open, but not for you message.


The blinding mechanism blinds a random value. The amount is in the signature, eg the bank uses a key X for a 100$ bill, a key Y for a 200$ bill, a key Z for 300$ bill.
Thus the bank can know the amount by checking which key is used to sign.

Its important that a static value (static for all "bills") is used in the message, else the same coin can be double-spent multiple times by simply spending blinded coins. By using a random static value same for all coins, ensuring coins that is depoisted is really properly unblinded, and one random value that ensures each coin is unique.

Its important that the bank signs ANY coin, but only accepts depoist of coins having a unique static value + random value. This adds a risk for the customer: If the customer does blind a non-coin message and ask bank to sign it for lets say 100$, then those 100$ will be "burnt". Theres no way for the bank to verify if a blinded coin is valid in its unblided state. Same if the customer blinds a already spent coin and withdraws it again, since the same coin can be blinded in unlimited number of variants, and since bank will accept ANY coin for withdrawal, the bank can use the same coin to withdraw 100$ multiple times, but also important that the bank checks that the coin is unblinded Before accepting it for depoist, to preserve the double spend protection.
This means you can withdraw 100$ multiple times with the same coin, but can only depoist the coin once, which means you will "burn" Money in this process too.

To faciliate Exchange, eg you pay a 100$ bill for a 80$ merchandise, you should get 20$ back. For this to work, theres 2 solutions:
The retailer prepares a couple of unminted coins and ask bank to sign for (withdrawing Money from retailer's account), and then gives to customer. However, this requires the customer to trust the retailer, because if the retailer does not intentionally blind the coins, or blinds the coins badly (for example, with a bad random value), then the customer can be traced by the bank.

This can be solved by the customer minting "unminted coin materials" - eg valid but blinded coins which are unsigned, that the customer gives to the retailer. The retailer sends the coin to the bank which signs for them. The retailer gives back those blinded, but signed, coins to the customer, which unblinds then, and depoists them to the bank.

if the retailer and customer does not trust each other, and does not trust the bank either, its possible for the retailer to create a blinded message, which the retailer gives to customer. Customer blinds the coin (again), and then sends to bank for withdrawal. Upon receiving signed coin from bank, the customer unblinds the coin (now the coin is only blinded once), then customer gives coin to retailer, which unblinds the final value, and sends to bank for depoist. Not the retailer and not the customer, can be traced.
This regardless of if retailer or customer omits a blinding step in a attempt to trace the customer or retailer. Both must agree on a traceable transaction for it to occur.

Same is repeated for Exchange, eg customer blinds coins, gives to retailer, blinds a second time, sends double-blinded coin to bank, bank signs, retailer unblinds, customer unblinds, customer sends to bank for depoist.


Is there any benefit to keep sending UN/PW to the server over Session ID ( i.e., Stateless vs Stateful)

Resending your username and password is a much greater security risk and has no benefits over session ids (or some variation of access tokens) that I can see.

Losing a password has greater impact

Here's why: If your session id is hijacked, your attacker will have access to your session, which is bad enough. But if he gets your username and password, he can impersonate you to the service for as long as he wants (because usually passwords don't expire, unlike sessions), he can reset your password and lock you out of the service etc. Also, since a lot of people reuse passwords on other sites, getting your password might also compromise your accounts on countless other sites. He can't do any of that if he only has the session id. So it's better to expose the short-lived, localized session id to risk than the long-lived username and password.

Ideally, the password would never be transmitted over the network at all (there are schemes which avoid sending the password, and most browsers and web servers are capable of using the simpler ones (google digest authentication, for example), but unfortunately, developing this technology has been neglected in favor of implementing server-side login systems using nice-looking login screens, which require transmission of the password.)

Session hijacking is (should be...) hard

Stealing a session id isn't so easy. Guessing session ids is very difficult (trillions of times more difficult than guessing the average password) if the application generating them is doing it right. Session ids should be created as long random strings using a crypto-strength random number generator; and since most sessions are only valid for a few hours at most, there isn't much time to make a lot of guesses. Passing session ids as GET parameters in the URL is a problem, yes, but this should be done only to degrade gracefully when the user's browser doesn't accept cookies. Most session ids are passed using cookies which live in the header of an http request.

Federated authentication and authorization

Finally, resending the username and password is often simply impossible, since they might not be available. If you use federated authentication an authorization systems such as OpenID/OAuth, you don't have access to the user's credentials; you just get an access or id token (or both), which are a kind of notarized letter to prove that you are who you say you are and should be given access to a certain resource. Again, the access tokens are only valid for a few minutes up to an hour, and only for a specific resource, so even if an access token was stolen, the damage someone could do with it would be limited.

With OAuth, you can request a special kind of token called a renewal token which you can use to get a new access token without the need to have the user log in again when the old access token expires. So this comes close to your question about resending the login credentials, because if the renewal token is stolen, the attacker gets almost indefinite access to the service the token is meant for. But note that even when a renewal token (which is typically kept out of the reach of user agents by a server) is stolen, this doesn't compromise the user's password and all the other sites he uses his account for.

Restful APIs

Unlike websites that allow a user to sign in, APIs are often stateless. So the client must authenticate with every request he makes to the API. This can be done by sending the username and password every time you make a request, but many APIs solve this by having a client first get an access token using his credentials, an then use the access token to access the API. OAuth is a perfect example for this. So again, the password is only sent once per "session" to get an access token.


Your thought is good, if you want to run automated analysis. Make sure you have set everything up according to the instructions provided. Since you want to start looking into malware analysis, set up two virtual boxes. One running on linux and one on windows, so you can use Limon to analyze both Linux and Windows malwares. Apart from the working environment, make sure you read some stuff about malwares (Malware analyst's cookbook or something similar) and develop some reverse engineering skills. Both the understanding of them and their "hardcore" analysis will come pretty handy if you consider taking it to the next level. Start by disassembling some simple programs (hello word), learn some tools like ollydbg, ida pro(if you find a license), radare2 and step up to manual unpacking and real malwares. Automated tools usually do the job, but being able to question their results and find more... Man that's priceless ;)


For DHE_RSA_.. Cipher Suites what is RSA used for?

In a cipher suite like "TLS_DHE_RSA_WITH_AES_256_CBC_MD5" RSA is used for authentication, while AES (256 bit) in CBC mode is used for encryption.

Authentication is needed since Diffie-Hellman is vulnerable to Man-in-the-Middle attacks. An attacker could easily exchange the Diffie-Hellmann paramater and would therefore be able to intercept the communication later. So signed Diffie-Hellman parameter ensure, that a Man-in-the-Middle attack would be detected. There is a variant of Diffie-Hellman key exchange called anonymous Diffie-Hellman (DH_anon) which doesn't use authentication.

The server signs the Diffie-Hellman parameter (via RSA) from which the so called pre-master secret is derived. From the pre-master secret the master secret is later calculated, from which in turn the symmetric 256 bit AES key is generated. Remember that the Diffie-Hellman parameter being exchanged are public, so they are not encrypted with RSA. They just get signed.

I took most of this from here which is a nice summary of the whole topic. Unfortunately it's only in German, but maybe the figures still help you. You can find more detailed information in RFC 5246.


Apache, DocumentRoot and path traversal - /manual/ query

Apache itself should not serve files outside of its DocumentRoot.
However, in your example, the directory traversal is done as a GET parameter to the ssi.html file. A script have access to the filesystem with the same permissions as the user running the web server (nobody or www-data is common).

I find it strange that the manual for for SSI should contain a vulnearbility. I cannot find any details about this file being vulnerable pr default for any versions of apache.

It is possible that someone has planted a backdoor (knowingly or not) in this file. Does your url actually respond with the passwd file, and have you inspected this file to see if there have been any modifications to it?

1) Deleting (or removing the configuration for) this should remove the associated vulnerability.

2) This should not create a major problem. There are other ways to harden an apache server. In this context, running it in a chroot jail would make sense.


Can you suggest PHP code for this purpose?

In order of preference.

1. PECL Libsodium

If you haven't heard of libsodium, go learn about it right now. I very strongly recommend that you use libsodium if possible.

These instructions should get you started with installing libsodium and the PECL extension on your computer. The rest of that e-book should give you an understanding of how to use specific components, and contains plenty of example code. If you need a starting point for PHP cryptography to point non-experts to, libsodium is the best available today.

For secret-key authenticated encryption, refer to this chapter of the e-book.

2. paragonie/halite

(Disclaimer: I wrote Halite.)

All the power of libsodium, and an interface that looks like:

use \ParagonIE\Halite\Symmetric\Crypto as Symmetric;

$key = KeyFactory::loadEncryptionKey('/path/to/key/file');
$ciphertext = Symmetric::encrypt($plaintext, $key);

Check it out: paragonie/halite.

3. defuse/php-encryption

Defuse Security published an encryption* library on Github at defuse/php-encryption.

By encryption, I actually mean authenticated encryption:

Version 1:

AES-128-CBC with PKCS#7 padding and a random IV
HMAC-SHA-256 (verified in constant-time)
Uses HKDF-SHA256 to split your key into an encryption key and an authentication key

Version 2:

AES-256-CTR with a random nonce (CTR mode doesn't need padding)
HMAC-SHA-256 (verified in constant-time)
Uses HKDF-SHA256 to split your key into an encryption key and an authentication key; now with a random HKDF salt to mitigate the impact of birthday collisions in the random CTR after encrypting 2^64 blocks

Disclaimer: I'm one of the coauthors of this library, although most of my contributions won't land until the version 2 rewrite, which includes version tagging and a streaming interface for encrypting/decrypting files safely.

4. zend/zend-crypt

I recommend this one last because I have not personally audited it, but it is part of the Zend Framework and a lot of PHP security experts attest to its quality. Go ahead and use it if you're already using the Zend Framework.

Update: Since I originally wrote this answer, I did discover an issue in Zend\Crypt\PublicKey\Rsa (ZF2015-10 a.k.a. CVE-2015-7503). However, their symmetric-key encryption implementation appears to be secure.


How is HTTPS protected against MITM attacks by other countries?

Certificate Transparency
The Certificate Transparency standard requires that when a certificate is issued, it should also be submitted to one or more Certificate Logs. These are simple network services that maintain cryptographically assured, publicly auditable, append-only records of certificates. Once a certificate has been added to a Certificate Log, an independent monitor can check the log to ensure that no fraudulent certificate has been issued. These days browsers require all certificates to have a Signed Certificate Timestamp (SCT) either in a TLS extension or through OCSP stapling, which is used to establish that the certificate has been added to a Certificate Log. Most browsers require the certificate to be present in more than one log (Chrome requires at least two, for example). If the SCT is missing, the certificate is rejected. This ensures that whenever any root/intermediate CA starts issuing fraudulent certificates, the monitors will notice and raise a red flag. Then either the CA revokes the certificates, or browsers stop trusting that particular CA.
In the past, HTTP Public Key Pinning was used. This involved the browser saving the public key(s) of a site the first time it was visited, and if the keys suddenly changed, the browser would refuse to connect. Dynamic pinning, which allows any site to be pinned at the first visit, has now been deprecated. However, static pinning, in which browsers ship with hardcoded public keys for popular domains like google.com and facebook.com, is still used. This can also be used to detect MITMs with fraudulently issued certificates, if the MITM targets any of these popular domains.


Does Heartbleed mean new certificates for every SSL server?

It means much more than just new certificates (or rather, new key pairs) for every affected server. It also means:

Patching affected systems to OpenSSL 1.0.1g
Revocation of the old keypairs that were just superseded
Changing all passwords
Invalidating all session keys and cookies
Evaluating the actual content handled by the vulnerable servers that could have been leaked, and reacting accordingly.
Evaluating any other information that could have been revealed, like memory addresses and security measures

Summarized from heartbleed.com (emphasis mine):

  What is leaked primary key material and how to recover?

  These are the crown jewels, the encryption keys themselves. Leaked
  secret keys allows the attacker to decrypt any past and future traffic
  to the protected services and to impersonate the service at will. Any
  protection given by the encryption and the signatures in the X.509
  certificates can be bypassed. Recovery from this leak requires
  patching the vulnerability, revocation of the compromised keys and
  reissuing and redistributing new keys. Even doing all this will still
  leave any traffic intercepted by the attacker in the past still
  vulnerable to decryption. All this has to be done by the owners of the
  services.

  What is leaked secondary key material and how to recover?

  These are for example the user credentials (user names and
  passwords) used in the vulnerable services. Recovery from this leaks
  requires owners of the service first to restore trust to the service
  according to steps described above. After this users can start
  changing their passwords and possible encryption keys according to the
  instructions from the owners of the services that have been
  compromised. All session keys and session cookies should be invalided
  and considered compromised.

  What is leaked protected content and how to recover?

  This is the actual content handled by the vulnerable services. It
  may be personal or financial details, private communication such as
  emails or instant messages, documents or anything seen worth
  protecting by encryption. Only owners of the services will be able to
  estimate the likelihood what has been leaked and they should notify
  their users accordingly. Most important thing is to restore trust to
  the primary and secondary key material as described above. Only this
  enables safe use of the compromised services in the future.

  What is leaked collateral and how to recover?

  Leaked collateral are other details that have been exposed to the
  attacker in the leaked memory content. These may contain technical
  details such as memory addresses and security measures such as
  canaries used to protect against overflow attacks. These have only
  contemporary value and will lose their value to the attacker when
  OpenSSL has been upgraded to a fixed version.


I am an IT security professional, currently working as an IT Auditor and am very familiar with the SOC 2 attestations.To answer your question, it helps to first give a little of background into the SOC 2 program.

Th SOC 2 certification is the brainchild of the AICPA and it is based on Trust Service Principles. Each Trust Principle has a defined set of control criteria that outlines what characteristics the system as your management defines must meet. As to the specific controls used to meet each control criteria, that is a decision of your company's senior management.

  Are there any specific steps one must follow to achieve SOC 2 compliance?

This question is ultimately misguided. The SOC 2 is concerned around the controls that your management has defined governing the services
it provides to a client. As such, rather than asking what checklist I can use to ensure I pass, think about which of the Trust Principles are important to the customers of your company. Most likely they will be reviewing the audit results before deciding whether or not to do business with your firm. If controls attested to by the service auditor are of no value to the end customer, having a SOC 2 certification means nothing for that particular customer

At a high level, the service auditor will be looking to see that the the controls contained in the description given by the senior management of your company are suitably designed and operating effectively to meet the control objectives for each of the Trust Principles. Representative questions the service auditor may ask are listed below:

Are procedures and policies necessary to meet the Trust Principles (as applicable based on service provided) communicated to relevant users?
Is the system as defined protected against unauthorized access (Security Principle)
Is confidential data as defined with the customer protected as agreed upon? (Confidentiality principle)

Ultimately, you are much better served, by focusing on customer needs rather than a generic "check the box" approach.


BeEF has 4 ways to keep user browser hooked -

Create popup under the browser to keep BeEF js code executing,
Prevent closing tab with BeEF code running by asking confirmation
Open new pages in foreground iframes
Capture all link clicks and load new pages through ajax, without reloading page.

Details are here: BeEF Persistence


I'm assuming you're using HMAC or authenticated encryption so that the messages are immune to modification and so you can cleanly detect a failed decryption.

The hub has a list of connected devices, and for each connected device, the active key to use in messages to it, and a list of additional keys to try to use to decrypt messages.
The hub decides on a new key, and for each connected device, adds it to the end of the list of additional keys. (Easy improvement by making a minor change here: you could instead create a new separate key for each device. You don't need to share keys between devices.)
Whenever there are a nonzero amount of additional keys for a device, the hub periodically sends a message (encrypted with that device's active key) containing a request to switch to a new key (the last key in the additional keys list).
Whenever the hub receives a message from a connected device, it will try to decrypt it with the active key and then each of the additional keys until decryption succeeds. If decryption succeeds with one of the additional keys, then replace the active key with that key, and then remove that key and all keys before it from the additional keys list.

Each device only needs to remember a single active key at a time.

This should mean things continue to work even in the scenario where the hub cycles between keys A->B->C, and a device doesn't confirm the switch to key B until after the hub has announced key C.


Some people ran into big trouble for what was done with their exit node. Others got away with it. It really depends on the jurisdiction, but also the context, and in particular the willingness of either law enforcement agencies or the privacy-defending organisations to turn a specific case into a story that will elicit emotional response from the general public and thus help in pursuing a political agenda.

So basically it depends. A lot.


What is ASN.1 usage in SSL protocl and What's the risk of using it?

It is ASN.1. ASN.1 is a generic syntax for describing structured data types, coupled with some encoding rules which tell how such data values are to be encoded as sequence of bytes, and decoded back. X.509 certificates are specified to use ASN.1 with the "DER" encoding rules.

ASN.1 is quite complex, and quite more complex than it should be, because of a long history of committee-driven development. In particular, it includes a lot of distinct character string types for no apparent reasons, and its types to encode dates are remarkably inefficient and hard to handle (and one of them is subject to Y2K issues, currently scheduled for 2050). Faced with this complexity, developers often found attractive the idea of doing specialized decoding "just for certificates", in order to avoid the daunting task of implementing a generic and systematic decoder (in particular, it is possible but inconvenient to implement a full-featured generic ASN.1 decoder in languages such as C which lack automatic memory management, e.g. garbage collectors).

Doing specialized code "by hand", to avoid the overhead of a systematic approach, means that the developer will need to think a lot more about possible issues when presented with "abnormal" data. This is a fertile ground for vulnerabilities (developers are only human, after all) and this is precisely what happened in OpenSSL.

(Other libraries may be impacted as well. I am using OpenSSL as an example because it is very widespread, and also because it is written in C, making consequences of buffer overflows and use-after-free bugs much more dangerous, up to and including arbitrary code execution. In libraries in more controlled languages, which check array boundaries and use a GC, will get less dire effects: a buffer overflow triggers an exception, which is inconvenient but less so than a remote shell for an attacker.)


How can Google search change the location in a URL tooltip?

If you look at the page source, there is a JavaScript function rwt() executed on onmousedown event.

Information Security Stack Exchange

It rewrites the href for the link you click on (you can even see the change if you click and hold the button).

Information Security Stack Exchange

So technically it's changing the contents of the page on user action. Browsers display the tooltip according to current value.

Any party can do that with JavaScript.

Turn off JavaScript in your browser and Google will provide the results on a page where all destination links are real.


Share or not share public key for servers?

One potentially significant advantage of not using the same private key for both the lobby and the game servers is that, even if one or more of the game server keys is compromised, the lobby server key (whose public half is bundled with the client, making it hard to change) is still safe.
Presumably, the game servers present a significantly larger (and more frequently changing) attack surface than a dedicated lobby server, so it makes sense to design your system to be able to recover from an attack on the game servers, while making the lobby server as hard to compromise as possible.
Your third alternative also shares this advantage, since only the login server needs to know the private half of the bundled key.  Indeed, depending what else besides authentication the "lobby" server is doing, separating the critical authentication functions onto a dedicated server may be a good idea.
Also, your third alternative guarantees that clients will not be able to bypass the lobby/login server even if they somehow manage to acquire a copy of the game server public keys (e.g. from another, compromised, client).  (The client could still bypass the login server if they somehow acquired another client's symmetric key, but since those keys are tied to client IDs, your servers should be able to detect it.)  Depending on your use case, this may or may not be an advantage, but at least it shouldn't hurt.

BTW, I feel like I really should amend this old answer to note that there's a more secure (and practical) option than any of those described above:

Don't bundle any of the game or lobby server public keys in the client.  Instead, bundle the public half of a "root" digital signature key, while keeping the private half somewhere safe (i.e. not on any publicly accessible servers).

Use the private root key to sign the public keys of your game and lobby servers.

When a client connects to a server, the server first presents (over an insecure channel) a "certificate" containing its signed public key.  The client first verifies the signature using its bundled public root key, and then establishes a secure channel to the server using the verified public key.

You will also need some mechanism of revoking compromised server keys.  The simplest way is to attach an expiration timestamp to the public server key before signing it, and have the client refuse to use an expired key.  Of course, this means that you'll have to change (or at least re-sign) the server keys at regular intervals before they expire, which is something you'll want to automate.
You can also include in your protocol an option for e.g. the auth/lobby server to send the client a list of revoked server keys that the client should not trust even if they otherwise look valid.  This will at least allow quick revocation of game server keys, without having to wait for them to expire.  This can be useful e.g. if some game servers are run by third parties who cannot easily receive automated key updates, making it inconvenient to use a very short expiration time for their keys.
Of course, another option could be to give such third-party game server operators their own "branch" signing key, itself signed by the root key, so that they can generate and sign their own server keys.  Of course, the client then needs to be able to follow such chains of signed keys all the way up to the bundled root key.  And the branch keys need to carry some (signed) metadata indicating which servers they're valid for, so that the third party can't e.g. just generate and sign their own lobby/auth server keys.
The nice thing, though, is that you don't really have to implement any of those features yourself, since they're all part of the public key infrastructure model used in TLS (and DTLS), which is the protocol that e.g. your web browser uses to connect securely to Stack Exchange (and to any other HTTPS website).  While TLS is a very complex protocol (party due to historical accumulation of features) that you really don't want to implement yourself, there are plenty of TLS libraries that you can use.  Nowadays, it's more than likely that your language runtime even has one bundled in.  (If it can fetch data from an https:// URL, it does, or uses one bundled with your OS.)
Of course, you'll still need to learn how to configure your TLS library to suit your needs (e.g. to only trust your own root certificate and to disable any legacy features you don't want) and how to generate and sign TLS keys, which can be a non-trivial task in itself.  But it's certainly a lot easier than implementing a secure communications protocol all by yourself from scratch.


Is there a way to give out secure tickets wihout storing them?

This sounds like the perfect use of an HMAC. You create a secure random secret S. Then the ticket for each page will be ID + HMAC(S, ID). When you get a ticket you extract the ID, redo the HMAC and then compare your result with that in the ticket.

While this is likely be simpler and faster than an encryption solution, it will only work if you don't mind ID being in clear-text in the ticket.


How to invalidate a session on browser closure?

Session (in)validation is usually a server concept: a session is "valid" as long as the server considers it to be valid, i.e. grants access to whatever data and functionalities are defined to be session-based.

What is usually done is:

The server has a session timeout. If nothing is heard from the client for some time, then the session disappears.
An explicit "logout" button is provided, when users want to trigger an early session end.

From your question, I suppose that you would like the browser "closure" to act like a logout button. If you can capture a closure event, then that's good. Otherwise, you can use a short timeout (e.g. two minutes) and have some Javascript running in the background of the page to do some regular hidden "keep-alive" activity with the server (e.g. every 90 seconds) as long as the corresponding tab/window is open.

Either way, it is up to the server to enforce a timeout. You cannot reliably handle it client-side only, if only because the client can disappear abruptly without any trace (user's laptop battery is empty, user is roaming in a car/train and goes out of range of a station, user's machine or browser crashes, user is evil and kills his browser just to annoy you... possibilities are endless).


Understanding how clients handle incomplete certificate chains

Some certificates use the AIA (Authority Information Access) field to specify a URL from which the next certificate up in the chain can be downloaded.

For example, if you view the certificate for security.stackexchange.com, you'll see that the certificate for *.stackexchange.com is issued by Let's Encrypt, so the next certificate in the chain above the certificate for *.stackexchange.com is the certificate for Let's Encrypt Authority X3.  Sure enough, if you look in the AIA field of the certificate for *.stackexchange.com, you'll see a URL (http://cert.int-x3.letsencrypt.org/) from where the certificate for Let's Encrypt Authority X3 can be downloaded.

However, I'm not sure all browsers will read the AIA information and fetch any missing intermediate certificates from the URLs specified in the AIA.  So, for greatest reliability, it's probably best to bundle all of the certificates in the chain (including all of the intermediate certificates along with the terminating certificate for your site) in one .crt file.

For more information on AIA, see https://discussions.qualys.com/thread/12098.


Where should we maintain external (subcontractors) usernames and passwords?

I am not a network architect, but a red teamer. The networks that have been the hardest from a password management and segregation perspective have been that of administrators needing a user account and an administrator account. So if they are external, they would use their user account with two factor authentication to access the vpn for the environment they need. After accessing the VPN via two factor auth, they would need to access the password vault to "check out" their administrative credentials. Lieberman seems to be a decent option. I would also require two factor authentication to the password vault with a different soft/hard token. After the admins check out their password and then are done with them, have the passwords change, I know Lieberman does this errrr lol. This will HELP mitigate the possibility of the credentials being obtained from memory, cache, secrets, etc.

I think the segregation of domains is good, make sure to check the trust relationship between them. The different domains should not have any established trusts (regardless of what anyone says), otherwise what is the point of a different domain? Here is a link to the Lieberman website that give an in-depth description on how they try and mitigate attack on credentials: https://liebsoft.com/products/enterprise_random_password_manager/

As to the option of using LDAP and Kerberos on the internet...please...do not do that... I don't have enough points to respond to the comment directly. I read through the documentation that was provided: first of all it does not seem to offer the ability to use 2 factor authentication, which is horrible in itself but even more so when you are asking for a solution used primarily by administrators. Also, I just looked and it offers the administrative console for user and authentication management on the internet, with a simple admin username and password. This would leave it susceptible to brute force all day...keys to the kingdom. Some may say you don't have to put them on the internet, however it looks like most "MarkLogic" servers are from a simple shodan search. It looks sketchy at best.

I can say from experience that 2 factor authentication creates a huge headache and disturbance for hackers during their operations. Especially when its coupled with good password management of administrative credentials, i.e. the creds change frequently, are different from the user credentials, and another barrier of 2 factor auth is required to even access them.

ALSO!!!!! Do not let the soft token be requested and automatically approved by the user that is requesting them, AKA a self service portal for soft tokens. That needs to be a manual validation process. I do not believe this is a complete solution, however a good start. Hope this perspective helps at any rate.


How good are Angular Route Guards from a security standpoint?

Any client side restriction can be circumvented by an attacker. No client side restrictions should be relied upon to protect private data. These facts apply to all systems, and the fact that you are using Angular 8 doesn't change anything.

In practice what this means is that your server should not return any data that the logged in user should not access. If you were thinking of returning all data and having Angular guards decide whether or not to display it based upon the user's permission, then that is definitely the wrong approach. That sort of approach can be circumvented by an attacker of almost any skill level, because simply opening the developer tools on your browser and viewing network requests will allow anyone to view all the data.

Rather, the use of guards is simply for a nice UX. Without guards, what happens if the front-end allows a user to navigate to a page they aren't supposed to access? Presumably the user will receive some sort of "Access Denied" error and be very confused. However, if the Angular guards enforce the same set of privileges that the server does, then the user will never be able to visit a page they aren't supposed to visit, and therefore won't get confused by error messages.  Note that your menu has to enforce the same rules.  If your Angular guards would stop a user from going to a sensitive page but there is still a link to it on your menu anyway, then the user will be equally confused when they try to navigate to a secure page and the guards stop them.

Of course this only applies for legitimate users. An attacker of any skill level may find ways to hit your restricted server endpoints directly, so of course your server needs to check permissions too and return an appropriate "Access Denied" message.

  tl/dr: Server side guards are about data protection.  Client-side guards are about providing a smoother user experience.


How long should a hash be to be absolutely secure?

exactly one message maps to a given hash

This is not possible due to the pigeonhole principle. As long as the input message to the hash function can be larger than the hash itself, it is guaranteed that some messages collide with each other and map to the same hash. This is normal and is not a problem for the security of hashes by itself.

You only need to ensure that the hash function is so large that intentionally finding such collisions (a collision attack) is computationally infeasible. A hash digest of n bits has a collision resistance of n / 2 bits. To achieve 128-bit security against a collision attack, it's thus necessary to have a hash digest of 256 bits. This is, of course, assuming the hash is cryptographically secure (like SHA-256) in order to avoid there being attacks that take a shortcut and can find collisions more easily than by brute force.


Securing implicit tokens (Example: Moltin)

Your point makes sense.

The OAuth2.0 RFC (section 1.3.2) explains this :

  Implicit grants improve the responsiveness and efficiency of some
  clients (such as a client implemented as an in-browser application),
  since it reduces the number of round trips required to obtain an
  access token.

But the industry best practice has changed. The OAuth 2.0 Security Best Current Practice document recommends against using the Implicit flow entirely:

  [...]clients SHOULD NOT use the implicit    grant (response type
  "token") or any other response type issuing    access tokens in the
  authorization response, such as "token id_token"    and "code token
  id_token", unless the issued access tokens are    sender-constrained
  and access token injection in the authorization    response is
  prevented.


The bottom line: You are screwed.  If you are concerned that one of the developers deliberately hid a backdoor in that codebase, you have no realistic hope of telling whether a backdoor is present.  Life sucks.

Comment: Some folks here are suggesting you can check for a backdoor by reviewing the code, or using static analysis tools, or somesuch.  Don't believe it.  They are fooling themselves if they think that this is likely to detect a deliberately hidden backdoor.  In my opinion, those answers are overly optimistic and are likely to give you a false sense of security.  (I know I'm going to make myself unpopular by saying this and dissing other commentators, but I feel a responsibility to give you my honest, frank advice.)

Advice and mitigations: As for what you should do, I think you need to tell us more about the function of that piece of software, how it relates to your business, and what are the consequences if it does have a backdoor.  Here are some generic mitigations you could consider, which might or might not be relevant to you, depending upon the circumstances:

Risk transfer. Require the supplier to provide a warranty that the code is free of backdoors, with major financial penalty clauses if any are found.  (Note that, if a backdoor is present, the chances are finding it are pretty low, so the penalties if one is found have to be increased proportionally to the inverse of the probability of detecting it.)
Isolation. You could try to isolate the effect of a backdoor, so that it can only affect the functioning of this piece of software and has limited opportunity to attack other systems of yours.  You could run it in a virtual machine, firewall it off from your networks, etc.  You could potentially also firewall it off from the network, to make it harder for a bad guy to activate the backdoor.
Monitoring. In some cases, it may be possible to perform external monitoring to detect illicit activity.  For instance, in a slot-machine joint, you could monitor the amount of money taken in, the amount paid out, and statistically, those two should bear a strong relationship; if you see pay-outs that exceed the expected amount by over five standard deviations, that might be a good reason to get concerned.  As another example, at a bank, you may be able to use double-entry book-keeping and track some aggregate metrics, such as the rate of consumer complaints and how often consumers dispute charges.  These kinds of monitoring techniques are highly specific to your particular business, but can potentially be effective at detecting shenanigans.

Keep in mind that none of these are likely to provide a really good defense against deliberate backdoors, and they may or may not be applicable in any particular situation, but if you're lucky, they might be better than nothing.


Basically you cannot have such a guarantee. Your applet runs on the client machine, i.e. the attacker's machine. He can inspect the applet code as he wishes, and there is nothing which the applet can hide from the attacker since that's his computer. That the applet is compiled is no big hindrance; reverse engineering works in general, and for Java code in particular it works very well.

(A lot of people in the media industry -- movies, music... -- would be very interested if someone could come out with a solution to your problem. Right now they are still waiting.)

To ensure that only your code runs on the client machine, you have to make sure that the client machine is a closed environment, where the machine owner himself cannot insert arbitrary code of his own. That's the model of game consoles and iPhones (until jailbreak occurs, of course). You cannot have that on PC.


Is this attack vector possible?

I would say it is possible because there is no 100% secure software. In this specific case you are using Evince which is using the poppler PDF library which had several security problems in the past and there is the chance that there are some unknown vulnerabilities either in evince or in poppler or the libc library etc. And while you probably did this as an unprivileged user there were privilege escalation attacks in the past in Linux and there will be probably more in the future. And once the attacker has access to the kernel space there is not much which will protect against full permanent system compromise, which might also include your downloads, downloaded keys for verification of downloads etc.

But a VM would not have fully protected you too because there were bugs in the past in XEN, VirtualBox, KVM/QEMU etc, i.e. every virtualization software.

  How can I scan my linux machine for spyware?

While I think that this attack is possible in theory I very much doubt that it can be easily done. Which means that this attack could only be done by a very knowledgeable attacker who will probably also be able to bypass any spyware scans, because such scans only employ some heuristics and can be tricked.

If you feel that your system is compromised in such a deep way you must be very paranoid. But if you deal with secrets some government or criminal organisations are very much interested in this paranoia might be justified. In this situation your only choice would probably be to throw away your existing system and get a new one. But remember, that the new system might also be compromised already by the vendor or gets compromised during delivery or that that data you restore from backup might already be compromised from earlier infection or that your router might be infected etc.

There is no such thing as 100% security and you have to find out for yourself how valuable your data or systems might be and how probable it is for you to be a victim of very targeted and expensive attacks. And if you just opened the typical PDF malware which uses bugs in Acrobat Reader then you are probably safe because it is highly unlikely that these attacks work against Evince too.

  I had all last updates and installed and my linux was everytime updated.

While it helps to have the latest updates you should understand that updates are often done because security problems where found. And often these security issues are used in exploits before the update gets released, i.e. often the update is only done because some new exploits where found in the wild which used previously unknown bugs. Thus having the updates only fixes against the problems which are already known and fixed and not against the unknown or unfixed problems.


Is it safer to ssh as a privileged user than to ssh and sudo?

It is a matter of risk assessment.

On the one hand you have a speculative article where you base ephemeral information on some vague timings.

On the other hand you have the capacity to connect to ssh as a user (ideally using ssh keys), then to do a sudo (possibly without password, it depends on your specific case). You are in a highly standard environment, with best practices in place.
Even if you ssh with a password, then type a password for sudo - you are in the realms of the best practices above.

Email compromission via timing attacks is IMHO not realistic (what you get is, best case, some lengths of "stuff". With luck and specific environments you may correlate this length to passwords).


Take a look at this explanation of the Diffie Helmann key exchange. The central point is that due to some clever mathematics, both parties are able to compute the secret key, while being certain that no one else could have done the same.

If you spend a couple of minutes looking into the mathematics, it should become clearer why this is possible.


OAuth can be used in many different ways.  If an OAuth tokens is being issued to your web application using your secret key (making your web application into the 'client'),  then no one should access this token,  rather the role of your web service is to perform actions on behalf of other clients and your application must have access control in place.

Alternatively,  OAuth is also used to authenticate browsers.  So if a browser is going through a 3-legged OAuth flow, and then provides your application access to a 3rd party web resource.  Then essentially the browser owns this token,  and is letting your web service utilize this OAuth token.  The client is trusting your web service to keep this OAuth token a secret.


What you are asking for is a random oracle, a hypothetical ideal hash that cannot create collisions unless the input is larger than the output. Such a hash does not exist in reality, and the best you can get is current cryptographic hashes that make intentionally finding collisions harder. The larger the hash's output, the lower the chance of an unintentional collision. A strong hash like SHA-256 is unlikely to ever collide, even if you were intentionally generating billions of IDs a second.

The chance of a collision is 1 - e-b(b - 1) / 2n, where n is the number of distinct IDs in your set and b is the number of bits in the hash digest. This website explains more about hash collision risks.

If all you want to do is generate a unique pseudorandom ID given a fixed-sized input, you could use a block cipher. The input is the input ID, and the output is the unique, pseudorandom ID. This can be described as H = Ek(ID), and is similar to a block cipher in counter mode. As long as the input and output need only be as large as the block size, there will be no collisions. Note that, unlike a hash, this is reversible and knowledge of the key can be used calculate the original ID.

The block size of the cipher is what determines the input and output sizes. For example, a 64-bit block cipher requires a 64-bit ID as an input, and will output a 64-bit value that can be used in place of your hash. Every distinct 64-bit input will map to a distinct and pseudorandom 64-bit output. The input can be smaller than the block size if it is padded with a constant value, but the output must be used as-is. If input or output is truncated, there will be the risk of running into collisions.

Using a block cipher may not be practical if you are converting usernames into IDs, because a 64-bit block size (for example) can accept at maximum an 8 character username, assuming ASCII. If the input needs to be of variable size, I would urge you to use a hash function. The chance of collisions for a strong ≥160-bit hash is vanishingly small. This is what hashes are designed for.


Encryption and Hash algorithms explanation

Encryption describes a method to encrypt and decrypt data. In other words, you can get the original data back, if you know the key.
Encryption can further be divided into symmetric encryption and asymmetric encryption. With symmetric encryption, the same key is used for both encryption and decryption. With asymmetric encryption, two separate keys are used (public and private keys), one for encryption and the other for decryption.

Hashing describes a method to compute some output, based on your data. In contrast to encryption, the output from a hashing algorithm cannot be transformed back into the input. However, since the same input always results in the same output and there is no (feasible) method to predict the outcome of a cryptographic hashing algorithm, you can use a hash to, for example, create a key from a password (although it is quite a bit more complicated that that, with many pitfalls).


Is it possible to restrict email accounts within one computer?

I'm afraid not. You might be able to solve your problem with something called "two factor authentication" though.

This is an option you can enable in Gmail where you will need to have your mobile phone with you whenever you log onto your mail. It is very easy to set up and highly recommended.

If this won't fix your issue, edit your question to add some detail about the specific worry you have, and we may be able to make a different suggestion.


Does google store all the IPs since you opened the account?

From Google's Privacy Policy:

  When you use Google services, we may collect and process information about your actual location. We use various technologies to determine location, including IP address, GPS, and other sensors that may, for example, provide Google with information on nearby devices, Wi-Fi access points and cell towers.

Unfortunately, this policy is vague regarding the retention time. As noted in this paper, Google's policies regarding the anonymization often describe the "expected effects, rather than the process itself."

However, you can see some of the logged IP and location information:

At the bottom of the Gmail page, you can find a link next to the text "Currently being used in x other locations." This link will show some, but not all of your history.

If desired, it is possible enable more detailed location tracking on your account history settings page.


How to secure communication between server application and client mobile application through HSM

I don't understand the advantage of using certificates here. I think one solution for your problem is to deliver your mobile app with the public key of your server. The client and server can then establish a session key as follows:

Client encrypts a random nonce with the server's public key.
The server can decrypt this nonce wih its private key.
Client and server can now derive a session key from the nonce.

Don't forget to use something like a MAC to ensure integrity of the ciphertexts. Without it an attacker could manipulate the ciphertext which could be decrypted to plausible plaintext.


How to explain to a non IT person whether the Internet can be "shut down"?

There are both technical and legal/political barriers to "shutting down the Internet."

The most important concept is that no one owns or controls the Internet.  It is made up of many providers, some global, some local, all interconnected.  The impetus that led to the modern Internet was to design a network that would survive a nuclear attack.  If a part was destroyed, traffic would automatically be rerouted around it.  So there's no one "choke point" that could be shut down. All of the major carriers (and most of the smaller ones) would have to be stopped in order to stop the Internet.

All the providers of the Internet (at least in the US) are private companies, which limits the government's ability to control them. It's difficult to imagine how companies like ATT, Verizon, Google, and Microsoft could be told to stop operating.

Many of these companies also provide telephone service as well as private networking.  Those services and the Internet use the same links and equipment, so shutting down one would shut down the other.  The economic consequences would be tremendous and there would be overwhelming political pressure to keep operating.  Short of a complete overhaul of the American political system, I can't imagine that happening.

I think Trump's comment would be technically, legally, and politically impossible to carry out.  What that may say about his knowledge and abilities as potential president I'll leave to other forums.


Encrypted is certainly better than plain text.

Storing a password in the app, however, still has some issues in my mind. By doing so, you are essentially allowing anyone with control of your computer (the "hacker" in your question) to access your FTP server without credentials.  At that point, they really don't need to decrypt your passwords at all... They can just log in and compromise the files on the server without ever knowing the password.

My recommendation is always to use a password manager that supports 2 factor authentication.  Store your passwords there instead of within various apps written by various persons using varying levels of encryption.

Or use keys as @shadur pointed out in comments above... Protected with a pass phrase.


How does a person request gmail.com from my server?

Its by spoofing the Host: header inside the HTTP request. I however don't know WHY an attacker would want to think your server is gmail's. Propably they want to target servers that does have some sort of catch-all vhost and they just use gmail.com because they know no real server will reply on that, instead of randoming up a hostname like dlgjdlgdlgdjlgj.com , because they are trying to get the engine log, which is only available on the vhost bound to the physical machine, not any virtual hosts.

You can try it yourself:

telnet [your server ip] 80

GET / HTTP/1.1
Host: gmail.com
[include 2 newlines]

and then watch your logs.


CIA are the aspects of a system that information security strives to protect.  Authentication and authorization (important and distinct concepts) are security controls that are used to protect the system with regard to the CIA properties.  For example, authenticating a user and checking that they are authorized to access the data ensures the confidentiality of that data.  Authenticating and then authorizing for modification is helping to ensure integrity of the data.


Why use one URL for all "pages" on my site?

If these were propositions made in the context of information security, then they all would be examples of security through obscurity. From the Wikipedia article linked:

In security engineering, security through obscurity is the use of secrecy of design or implementation to provide security. Security through obscurity is discouraged and not recommended by standards bodies. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that if the flaws are not known, then attackers will be unlikely to find them. A system may use security through obscurity as a defense in depth measure; while all known security vulnerabilities would be mitigated through other measures, public disclosure of products and versions in use makes them early targets for newly discovered vulnerabilities in those products and versions. An attacker's first step is usually information gathering; this step is delayed by security through obscurity. The technique stands in contrast with security by design and open security, although many real-world projects include elements of all strategies.
Security through obscurity has never achieved engineering acceptance as an approach to securing a system, as it contradicts the principle of simplicity. The National Institute of Standards and Technology (NIST) in the United States specifically recommends against this practice: "System security should not depend on the secrecy of the implementation or its components."

Generally speaking, it is a very poor approach to reasoning about a system's security. I do not see any security benefits that might be yielded by employing just one single endpoint, nor would omitting file extensions enhance the security of your web service. There may or may not exist benefits of omission in the realm of search engine optimization (SEO), and I think that may have been what was meant originally. I see even less SEO benefits for the one-page website, however, as pointed out by @Fiasco Labs. I don't market myself as an SEO guru (consult your local Digital Point forums).
The idea of using just a single endpoint may have spawned from today's increasingly common practice of delegating logic and routing to the client side while only serving out one page with static dependencies, and otherwise just performing session-authenticated database/long-term state operations in response to user interaction (see Meteor). Might the recommendation of omitting ".php" also have just been spawned from one person's distaste for that language in particular? I was not there.


My site was hacked and the attacker got data from the config file

Your question can not be answered with the given information.

From what we know you might not even been hacked at all. You might start with telling us more about those queries and what do you mean by directly into the database. Remote access from other IP address or a query you can't find in your scripts? Those query might be from Laravel or a plugin.

Anyway it's impossible to tell how you got hacked without knowing your logs, PHP scripts and whatever is on this server. Even with root access it might not be possible to tell if the attacked cleaned up or your logging is not covering the attack vector.

First step would be to find the time of the attack and check log files at this time. If you can't find anything check the complete log. If you find something you don't understand google it or ask a question.

If you sure you got hacked, you might want to involve your hoster. They supposed to know there server and might have access to logs and tools you don't know about.


Is setting up my own VPN more secure than buying from third party vendors?

In general setting up your own will be less secure because:

there are more ways for your identity to leak out when you are hosting your own service. For example, if you use a dedicated server you might need to register a domain name.
you lose the anonymity of many, many users utilizing the third party VPN service. (If you are one of a few users of your self-hosted VPN, it will be easier to identify you.)
you may not have the expertise to understand the latest security issues related to your hardware, host, network and software stack


SSL verification of host name of https server

Yes, I believe you were wrong to expect that the certificate name validation process would do any name resolution, reverse resolution, or other mapping for you.  The matching that takes place is pretty much a literal thing performed at the application layer (sorry, bad label.  I mean the SSL library code called by the application when I say "application layer"; in OSI this would probably be Session or Presentation layer, but it's all part of the application executable).

I don't believe you'll find a java library handler to add in the name mapping you're looking for, because the SSL/TLS protocol really is about matching the literal names (and then making sure the cryptographic and certification authority aspects are in place).

I believe you can use the subjectAltName tag to generate a certificate which will validly match multiple names, but that's sort of the opposite approach from what you're looking at.


Why is Linux considered more secure than Windows?

Linux isn't really more secure than Windows. It's really more a matter of scope than anything. No matter what malware, exploits, and bad users exist EVERYWHERE. One being more secure than the other is nothing more than anecdotal evidence.

Malware exists for *nix, Mac, Windows, Android, iOS, Symbian, Xbox(yes), hard drives, and bios.

No operating system is more secure than any other, the difference is in the number of attacks and scope of attacks. As a point you should look at the number of viruses for Linux and for Windows. You'll see a trend in that Windows has FAR more viruses for it than Linux does and that's purely because it's more lucrative to hack for Windows since you have a greater chance of getting the thing you want. For all we know there might be a critical flaw in Linux that would open the world to pain if discovered. It hasn't been yet, but it could be there.

Really however OS security comes down to usage, habits, behaviour, and users just as much as it does software, hardware, security, and passwords. Your computer can be safe in an infected network as long as you do the following:

Constantly ask yourself "How do I keep MY computer safe?"

Really all you can ever do is work to keep your computer safe. That includes most notably safe computing habits. You could run for years without anti virus* and never get a virus as long as you're safe and you keep your computer safe. I'd still run an anti virus though since you could be safe all you want and make a single mistake.

After all those big data breaches you often hear about aren't usually on computers, but servers running special software, and it's the software itself that gets attacked and exploited to extract the data. What this means is that your computer is as safe as you make it. They didn't make theirs very safe.

Of course even if you make that software as secure as possible, it's all meaningless if someone manages to steal your credentials. In most data breaches an administrator gets phished, and their credentials are used to log in and steal the data. Here you can see that it didn't matter that the computer was safe since the user was attacked.

This really shows that there are two parts to security: The security of others (never trusted) and the security of yourself (only as good as you make it). To that end we all just try to make sure that the security of ourselves is as good as it can be. Herd immunity doesn't really apply to computer, so we have to keep them safe through our habits, usage, software we put on there, and making sure not to let in anything bad.

  The world's most secure computer is turned off, not connected to anything, buried six feet underground, and destroyed.

Notes:
*: Note the same as no security!


I'm not sure this is a standard term. A quick search reveals that many different people use the term to mean many different things. The common element is that the process takes one password and modifies it.

Some uses are to make a weak password stronger, others are to enable you to use the same password everywhere but to have the mangler make it unique for each site.

So, I don't think there is a standard use, or even a standard use case, let alone a common definition.


To build a rainbow table, how to decide size of chain and number of lines?

The choice of chain size,t, effects the storage size and look up time. At the and you have to calculate the 1000000 chain element.

4000 chains of size 250; 8000 storage size of the hash result, sorting 4000 elements, lookup time at most 250 chain time and 250*log_2(4000) search time.
1000 chains of size 1000; 2000 storage size of the hash result, sorting 1000 elements;  lookup time at most 1000 chain time and 1000*log_2(1000) search time.
400 chains of size 2500; 800 storage size of the hash result, sorting 400 elements; lookup time at most 2500 chain time and 2500*log_2(400) search time.

Use can use this site to calculate the parameters.


If your public key expires, it can't be used to encrypt.  When you generate your private/public keys, you should generate a revocation certificate so you can immediately revoke if needed...if you have no expiry time and no revocation certificate they can last forever.

As for how it works, quoting from https://www.gnupg.org/gph/en/manual/c235.html :

  A key's expiration time is associated with the key's self-signature.
  The expiration time is updated by deleting the old self-signature and
  adding a new self-signature. Since correspondents will not have
  deleted the old self-signature, they will see an additional
  self-signature on the key when they update their copy of your key. The
  latest self-signature takes precedence, however, so all correspondents
  will unambiguously know the expiration times of your keys.


All known vulnerabilities in existing software almost certainly have patches and upgrades issued within hours of disclosure. The vulnerabilities can be fixed by updating to the newest versions available.

To update, issue these commands.

apt-get update && apt-get upgrade && apt-get dist-upgrade

This would automatically upgrade your softwares to the newest versions available.


Among the many reasons why I would not even think about doing what you're contemplating, these would be my Top-3:

Security:
I would never put any file that modifies a system's configuration file in a publicly accessible area. The reason is simple: the publicly accessible area is most vulnerable. If the file gets modded by someone (friend or foe), the modification could cause havoc to both your file system, as well as your server and/or system configuration.
Integrity:
PHP can (and probably will) mess up file locking. As a result, race-conditions might destroy your vhosts.conf file and break your server configuration.
Recovery:
Changes to vhost.conf need a server restart for the changes to be acknowledged by the server. You will need to think how you're going to handle that restart via PHP... and what happens when something goes wrong.  If your server crashes and takes down the PHP engine while it's at it (remember Murphy's law), how are you going to automatically recover from that? PHP won't be of any help in that case.


How does mail email services decrypt an encrypted mail without having the sender's Public Key?

When you send from ProtonMail to Gmail you have 2 options: send a normal email or send an encrypted email.

If you send a normal email it's not encrypted, and Gmail can read and display it.

If you send an encrypted email to Gmail, you set a password for that particular message and ProtonMail will send a link to the Gmail recipient.

This link will take the recipient to a page on ProtonMail where they are asked for a password and then the message is decrypted locally, in the recipients web browser, and displayed to them.


OWASP ESAPI PHP implementation for XSS attacks

your best bet for this would be probably to look at the other OWASP ESAPI implementations to see how they've handled it, which should at least give you the approaches to look at, even if you then need to translate that over to PHP.

In terms of information you could look at this post about the Java ESAPI implementation which is, AFAIK, the most mature one about.  There's another post here which also looks at XSS and ESAPI.


Are these weird emails spam without content?

Empty emails could mean several things:

The sender is attempting to maintain or grow a database of
emails that are legitimate spammable addresses.  Any address that
doesn't respond with a no-such-user error is implicitly valid - even
with a margin of error for the volume of email addresses being
collected.
There is malicious content in the email, which is
stripped from the email by a spam filter - but this means that the
spam filter you use is OK with sending you an empty email.
Spammers make mistakes too - remember how terrible you feel after you forget to include attachments.


Resource consumption attacks against algorithms

This attack is known as Hash DoS, or more generally as Algorithmic Complexity Attack.

There are several ways to implement lookup tables:

Balanced trees
The relevant operations have logarithmic performance, regardless of the data. These are naturally immune to this attack, but they're slower.
Hashtables
If the hashes are well distributed, the relevant operations are O(1) and really fast, but if they're badly distributed they become O(n).

There are two common strategies to avoid Hash DoS: You can switch to trees, or you can use keyed hashes.

For keyed hashes the server chooses a random secret key. Depending on the situation this key can be per-process, per-table, per-request,... Longer lifetimes can allow adaptive attacks over multiple requests, but I'm not sure how big a problem that is in practice.

Then it uses a keyed hash to determine the bucket, instead of an unkeyed hashfunction. If the keyed hash is good, this prevents the attacker from producing collisions quickly. Earlier keyed hashes often suffered from key independent collisions, and thus didn't prevent the attack once these were found. Currently SipHash is gaining popularity, since it's fast, but still cryptographically secure.

My recommendation is using SipHash and to avoid key reuse across requests where possible.

Breaking Murmur: Hash-flooding DoS Reloaded (On Martin Boßlet's blog)
SipHash/Attacks

  Attacks
  Jointly with Martin Boßlet, we demonstrated weaknesses in MurmurHash (used in Ruby, Java, etc.), CityHash (used in Google), and in Python's hash. Some of the technologies affected have switched to SipHash. See this oCERT advisory, and the following resources:

  Slides of the presentation "Hash-flooding DoS reloaded: attacks and defenses" at Application Security Forum Western Switzerland 2012 (Aumasson, Boßlet)

Hash DoS against BTRFS
Many programming languages are currently upgrading their standard libraries to avoid Hash DoS. These attacks hit dynamically typed languages very hard, since they typically use hashtables almost everywhere (member names to values etc.)

Some big projects upgrading their hashtables:

Ruby, JRuby - SipHash
Perl - SipHash
Haskell - SipHash,
.net - Custom, probably inspired by SipHash but seems much weaker
Redis - SipHash


Foolproof way to hide your IP when browsing

"Foolproof" does not necessarily means "NSA-proof" or whatever. A foolproof security system is meant to be a system usable by non-technical users and lowering as much as possible the risk of a misconfiguration impacting the security. Browser's, for instance, involve a lot of "foolproof" security technology against phishing sites, etc..

In case of communication tunneling and anonymity, a reference on the domain is Tails, a linux distribution preconfigured in a way that all outgoing traffic should go either through Tor network, or be blocked (cf. the DNS leaks mentioned by @schroeder and how Tails address them). Tails can be used as a physical media to boot your PC (more secure), or in a virtual machine (more practical).


How do I test for SQL injection vulnerabilities on a site with input fields?

There are a number of ways of testing an application for vulnerabilities such as SQL Injection.   The tests break down into three different methodologies:

Blind Injection:

MySQL example:

http://localhost/test.php?id=sleep(30)

If this SQL statement is interpreted by the database then it will take 30 seconds for the page to load.

Error Messages:

http://localhost/test.php?id='"

If error reporting is enabled and this request is vulnerable to sql injection then the following error will be produced:

  You have an error in your SQL syntax; check the manual that
  corresponds to your MySQL server version for the right syntax to use
  near '"' at line 5

Tautology Based Injection:

http://localhost/test.php?username=' or 1=1 /*&password=1

In this case supplying a Tautology,  or a statement that is always true provides a predictable result.  In this case the predictable result would be logging in the attacker with the first user in the database,  which is commonly the administrator.

There are tools that automate the use of the methods above to detect SQL Injection in a web application.  There are free and open source tools such as Wapiti and Skipfish that do this.   Sitewatch provides a free service that is a lot better than these open source tools.  I can say that because I am a developer for Sitewatch.


Cufon or Prototype as an attack vector for Blackhole exploit kit?

As JavaScript runs on the client side, you can't use it to write to the server's filesystem unless the filesystem/server is already compromised. In other words, the attacker already included, for example, a PHP script that will respond to the JavaScript commands and execute them on the server side.

Your first step now is to scan the server for any such dynamic files. Note that there are also other tools such as http://nodejs.org/ and many many others that the attacker might install to conduct additional attacks.

Having done the above, and cleaning up the Cufon font file, I guess you'll be pretty secure.

Final recommendation. Use this awesome security scanner: http://sitecheck.sucuri.net/scanner/

Cheers!


CVE-2019-0903 detected by just one anti-virus service

It seems like a false-positive; from marc.info clamav:

  Our system updated today:

May 25 09:24:20 daily.cld updated (version: 25460, sigs: 1581004, f-level:
63, builder: raynman)

  (Time is BST - i.e. UTC+1)

  After that we saw a large number of viruses found - all detected as
  Win.Exploit.CVE_2019_0903-6966169-0

  This seems to be including mails without any attachments.


folder and file permission shared host advice

Remember .php is executing in the PHP application stack on the server. It may have access to do more than just a user browsing the web site.

These are my suggestions (not a complete list) for PHP on Apache with limited server access. Hopefully this will get you started in the right direction...

Sanitise Database Calls

When reading and writing to a database sanitise your input especially if you are requiring input from a user. Also be wary about building SQL statements on the fly with user supplied input. Allowing a ‘ or a “  or any number of other character in input could allow a user to inject their own commands to say query the user table. If possible, restrict user input a-z,A-Z,0-9 as this is generally safe.

Here is good stuff that you should know about if you are going to write PHP for your web site.

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Apache .htaccess files

Also, you can apply some good lock downs to your .htaccess file to prevent unwanted or miss use of you web site files.

http://httpd.apache.org/docs/2.2/howto/htaccess.html

You should limit file permissions to .htaccess were possible by setting something like 644 (rw-r--r--). But for an additional layer also put the following in your .htaccess file for the root of your website.

# Prevent access to .htaccess from web.
<Files .htaccess>
  Order Allow,Deny
  Deny from all
</Files>

Limit Permissions

Limit permissions to what you really need. For example if you don't need execute on php.ini don't grant it (it should probably be set to 600). If you are unsure, start with a low permission level and work your way up. It won't take long to try and you will save yourself the headache latter.

Also be careful with execute on image files and files that obviously should not be executed. If someone can use images embedded in your pages to execute code they will if you let them.

If you require access to write a directory like uploads then block access to files that are not required. For example if you have a PDF or image upload directory .php files probably would not be required, so block it.

<FilesMatch "\.(htaccess|ini|sh|php)$">
  Order Allow,Deny
  Deny from all
</FilesMatch>

Better yet, block any files types except the files you need.

Order Allow,Deny
Deny from all

<FilesMatch "\.(jpg|gif)$">
  Order Deny,Allow
  Allow from all
</FilesMatch>

Disable Directory Browsing

If not required disable it. Giving people access to see what files you have may give them information to attack you better. You could disable it via a .htaccess file in the specifc directory or at the root of your site by using something like this.

# Disable directory browsing
Options All -Indexes

Third-party Scripts and Applications

If you use third-party scripts, includes or applications in your website make sure they are from a reputable source and keep them up-to-date. Join mailing lists if required to make sure you know when a new release comes out. A lot of automated attacks against web application using PHP and other scripting languages use well known vulnerabilities that have been previously fixed.


Cleanware. What does it do and are there security risks involved?

Sure, we have all the possible cases here:

Legitimate software that really try to clean your system without infecting you with malware or any other purpose.
Malware disguised as cleaning software what try to steal information from you or just trojanize your computer to be part of a botnet or other similar "evil" purpose.
"Grey" software that really clean your sytem but in addition have a "side effect". Usually this kind of software is not "real bad malware"... sometimes they only are what we can call "light malware" trying to steal non-sensitive info like banking data, they only steal statistics or general info and that kind of things (anyway is a violation of your privacy).

In my opinion if a computer needs a clean, it depends of the grade of the problem. Sometimes the best choice is to format and reinstall an entire clean system. If is a little problem sometimes there are tools that work very well but you must be pretty sure about that software and its procedence (sometimes is the hardest part).


custom Origin header to bypass CORS protection against CSRF

It does not matter what Origin header you set in the response from the server to the browser as you do in your example with server-side PHP code.
The browser does not care about this header.

Relevant for CORS is only the Origin header sent by the browser to the server. If you would be able to fake this from inside the browser you could bypass the protection. But, Origin is one of the headers which can not be changed within XHR or similar requests so such a bypass should not be possible.


Pros and cons of installing security updates automatically?

If you look at CIS Controls (formerly known as TOP20 Critical Security Controls), and particularly the number #3, you will find:
Deploy automated software update tools in order to ensure that the operating systems are running the most recent security updates provided by the software vendor.

So I would recommend it, especially in the case of "low admin attention".

You have well identified the risks, the biggest one being operational issues (update requiring a reboot, update stopping some services, etc.).

Regarding the risk of spoofed update repository, today most update systems rely on TLS authentication and/or package signature, limiting this risk. This risk is usually lower anyway than running a system with an unpatched critical vulnerability.

At the end of the day, you should also consider the risk exposure of the system (internet exposure, etc.) in your decision matrix.


Use Roboo: http://www.ecl-labs.org/2011/03/17/roboo-http-mitigator.html

Demoed at Blackhat in 2011. Very effective and easy to get up and running. I would recommend over any use of CAPTCHA

"Roboo uses advanced non-interactive HTTP challenge/response mechanisms to detect and subsequently mitigate HTTP robots, by verifying the existence of HTTP, HTML, DOM, Javascript and Flash stacks at the client side.

Such deep level of verification weeds out the larger percentage of HTTP robots which do not use real browsers or implement full browser stacks, resulting in the mitigation of various web threats:

HTTP Denial of Service tools - e.g. Low Orbit Ion Cannon
Vulnerability Scanning - e.g. Acunetix Web Vulnerability Scanner, Metasploit Pro, Nessus
Web exploits
Automatic comment posters/comment spam as a replacement of conventional CAPTCHA methods
Spiders, Crawlers and other robotic evil"

Also good measure against DDOS: http://www.rakkhis.com/2011/03/ddos-protection-strategies.html


Is Linux's 'W' command a security breach?

w, by itself, isn't what lets you do this; it doesn't have any sort of elevated privileges, and everything it can do is something you could already do yourself. The actual thing that lets you see other users' processes is that process info is stored in the /proc/ directory, and all users have access to the /proc/[pid] directories that store individual process info.

If the question is instead "isn't /proc being world-readable a security hole," the answer is "a security hole according to what threat model?" Security holes are when someone can do something that they shouldn't be able to do. Many Unix-based systems (this behavior predates Linux) don't consider things like command line options and who's running each process to be sensitive information; making this world-readable was an intentional decision that it was not something that needed to be restricted. This behavior might be good or bad depending on your needs, but the point is that unless it's a problem on your system it's by definition not a security hole.

If you often enter passwords on a command line (that presumably you don't want other users to see), or if you don't want users to see what other users are doing, then this is a security issue, because then it lets people do something they shouldn't be able to do. On Linux, being Linux, you can modify this behavior and restrict /proc. If, like the designers of most of these systems, you don't see an issue with people seeing what programs others are executing, then this isn't a hole. Traditionally, that's not an issue, so most systems allow this access.

(For hidden files: They aren't actually a security feature at all; the reason they exist is convenience. Anyone who can list files in a directory can list all files, including hidden ones).


Do fake wp-login pages help prevent webapp attacks?

Using non-standard paths for your WordPress login and admin pages would stop automated brute-force attacks scanning for every example.com/wp-login.php, but the practice you describe is just messing around with the attackers and doesn't really do any good nor harm.

Best way to stop the bots is to use strong passwords and Fail2Ban.

A fake wp-login & wp-admin could be used as a honeypot for learning more about the ongoing attacks, though. I like to collect the attempted login credentials to know which leaks are currently popular. I also let the credentials "work" randomly to collect the malware they are trying to install. Of course it doesn't work, because it just looks and acts like WordPress without being one. However, by reverse engineering the malware I'm able to learn how it's trying to hide, which gives me an advantage when cleaning infected sites for customers.


the new Nokia 3310 recommended for privacy and security?

I don't know much about the Nokia. But I do know mobile networks and 2G is no way near as 'secure' as the later networks. Mainly due to a lack of suitable authentication at various stages of the communications channel.

If you are solely concerned with the phone OS, then I would argue possibly as it 'may' have a lower attack surface than the iOS due to lower functionality, but the iOS has a lot more attention from the community and may allow vulnerabilities to be easier to discover? But it's worth considering the pro and cons


List of NSA spyware - remote bios exploits

It is possible to at least initiate, if not install BIOS updates from a Windows application.  Example being the Dell BIOS update utilities, which are provided in a .exe.  Heuristics say that if you can install an update from a .exe, there shouldn't be much, if anything, stopping you from installing malicious BIOS.  More so, if you can run an application, maybe you can cause the software to run by exploiting a software bug, such as a buffer overflow, to initiate the installation of your payload, which in this case would be the malicious BIOS installer.

Oh, so I guess to answer your question, if the attacker exploits a vulnerability (documented, or undocumented) then there is no defence.


cryptsetup luksHeaderBackup file smaller than Payload Offset?

The payload start is rounded up for alignment purposes. How much can be controlled by providing the --align-payload option to luksFormat.


HTTP Headers: Document Policy vs. Permissions-Policy/Feature-Policy

Document-Poicy is for more performance/best-practice options. Permissions-Policy is for handling "powerful" features that you don't want third-parties or new devs using.


How attackers extract data from cipher text using brute force?

Entropy of the properly decrypted file is lower than the entropy of the improperly decoded file.

For example, properly decoded JPG file contains header information which may contain string ABCDEF which is low entropy. Also decoded email will contain header with strings (7 bit data is also low entropy).

Entropy can be measured by compressing result. Only header would be sufficient. So compressed header should be smaller than the result, which means the brute-force was successful, otherwise, the compressed result is bigger than original, which means bruteforce was unsuccessful.

Improperly decrypted file is completely random stream of bytes. Compression of it makes it bigger, but if it's correctly decrypted, should be smaller.

To make brute force faster, one can devise some quick entropy level check, however it's not feasible as of now. Currently the minimum encryption standard is AES-128 which is not bruteforcable, and AES-256 is going mainstream which has number of possibilities close to the number of atoms is observable universe. Something like some magnitudes lower than that, but very close.


What benefit is there to adding a password to your SSH key?

Adding a password to your SSH key means that the private key will be stored encrypted on your local machine. That private key is a rather sensitive secret since knowing that key grants access to all servers on which you registered the corresponding public key (in your .ssh/authorized_keys file).

Secrets in local files can be plundered by attackers in various occasions:

Your laptop is stolen.
Your harddisk breaks down (it happens) and you discard it, and the attacker retrieves it from your dumpster, repairs it (e.g. the broken part was the electronic board, and the attacker simply replaces it), and reads your files.
You make a backup of your files on some external device (USB drive, tape...) and the attacker steals it.
Some malware on your machine takes a peek at your files and uploads your private keys to a server in Uzbekistan.
Through some unfortunate configuration mishap, you make your files available to the world at large (e.g. with disk sharing, or with a local Web server which was not correctly setup).
A vulnerability in your Web browser temporarily allows evil-minded Javascript to read and upload some arbitrary files, e.g. your SSH private keys.

This list is not exhaustive. In all these occasions, password-based encryption of your SSH private key will make the life harder for the attacker. Note that your files are likely to contain other sensitive information as well, so SSH private key encryption is not sufficient to reach the beatitude of absolute security; however, it helps.

Of course, there is nothing completely free. If you use a password to protect the on-disk storage of your private key, then you will have to type that password on a regular basis. As usual, security and convenience are two sides of a trade-off.


Role Based Access Control + Data Ownership based permissions

This is a very good question, and it has been identified as one of the problems with RBAC. There is been a line of research on parameterized roles (the pdf can be found online), and more recently, the idea of relationship-based access control has emerged (see work of P. Fong et al, for instance this one). I'm not sure how much has been implemented though.


Use token for Windows Server 2008 AD RMS

You would use the token to authenticate the user to the machine.  RMS uses a client certificate granted by the windows authenticated user to access the RMS protected document.


Is it possible to prevent man-in-the-middle attacks in token-based authenticated online games without packets encryption?

Following to Steffen Ullrich comment I've decided to use HMAC with timestamps and nonces for additional replay attacks protection. This approach should be enough to protect the data against unwanted modifications.


What FDE (with hardware encrypted drives) for OS X works?

FWIW PGPDisk works ok on Mac OSX in my experience, had it running on a MacBook Pro with Leopard without any major issues (although I wasn't doing much in the way of heavy development with it, so hard to guage the performance hit)


My app is asking for card details, but does not stores them. Do I need PCI compliance?

Any merchant accepting payments, regardless of the method, needs to be PCI compliant. To accommodate the various methods of accepting payment (outsource, redirect, iframe, POS, etc.) the PCI council has developed different self assessment questionnaires (SAQ). The SAQ forms are essentially a paired down list of requirements from the full PCI DSS. The requirements included in each of the SAQ forms are those that are most applicable to the way you accept payments.

Based on the method of processing you implement you will need to select the proper SAQ form, make sure you meet all the requirements list, and then complete the SAQ and Attestation of Compliance.


How to learn penetration testing at home?

Free options are few, but there are tons of videos and tutorials on specific attack vectors or products/tools. They will NOT make you a Penetration Tester, but they are free learning resources.

Some decent options to start you off:

MetaSploit Unleashed: Learn an exploitation framework
SecurityTube: various videos covering a multitude of topics
NMap: The standard network enumeration tool
Web Application Hacker's Handbook: It's not free, but it is the bible on Web App Security

For practice, there are a number of resources:

Metasploitable VM (and other purposely vulnerable VMs)
DVWA
Mutillidae
WebGoat
Vulnhub
hack.me

Do some searching on this site for other people offering opinions on free learning resources. But, the only way to learn is to get your hands dirty.

Keep working at it, and keep asking questions!


Simply hashing the BCrypt digest with SHA-256 will trivially expose encryption keys if your password database is compromised. Using the PBKDF2 of the password itself for encryption keys prevents this.

Of course, there are drawbacks. With the described scheme, the server can perform cryptographic operations with the user's key at any time, which may be desirable or necessary. When the PBKDF2 of the user's password is used, the server can't regenerate this key without the user providing his/her password.


What extra security does a 2-step website login process with a PIN provide?

I find it hard to see what security benefits this could provide. In multifactor authentication, the point is to use different factors — i.e., "something you know", "something you have", "something you are". Just repeating the same factor twice seems a bit pointless.

But let me speculate some about what the purpose could be.

1. Stop keyloggers

Only dumb malware tries to get passwords by blindly logging key strokes. Requiring the use of a drop down menu may protect against some malware, but in the end trying to hide user input when the computer is already infected is a loosing game. See this question for a related discussion. In the end, I think the benefits are small here.

2. Increase entropy

If you add a six digit PIN to the password, you get 106 times as many combinations to brute force or almost 20 extra bits of entropy, right? (Or 103 times or 10 bits if you only count the three digits entered.) Yeah, but why not just require a longer password?

Perhaps you want to split it in two to make one part (the PIN) truly random and thereby give protection to users who pick weak passwords. But what does this protect against? For online attacks, you should already have rate limiting in place to deal with this. For offline attacks, you would need to hash the PIN together with the password to get any benefits. But since you can log in providing only three out of six digits they don't seem to be doing this (unless they keep 20 hashes for all possible digit combinations).

3. Limit the effect of stolen passwords

Let's say your password gets stolen (say in a phishing attack). If the attack is only performed once, the attacker will only get half of the PIN. She will therefore not be able to easily log in if she is asked for other digits than the ones she got.

I don't see this as a big benefit. Just repeat the attack a couple of times, or attempt to login multiple times (or from different IP's) until you are prompted for the digits you have.

Drawbacks

It makes users more likely to write the PIN (and perhaps the password while they are at it) down on a post it or an email.
You can not log in using only a password manager. Why make it harder for people who use safe methods to manage their passwords?

Conclusion

I can't see any security benefits that would motivate having the user memorise an extra PIN and go through the hassle of picking numbers from drop down menus. To me this smells of security theater. But perhaps I am missing something.

Edit: Yes, I did miss something. See supercat's answer. It's a very good point, but I'm not sure I would think it is worth it anyway.


How much of a security problem is PHP's proc_open() on a shared host

It's correct that proc_open can be dangerous, if and only if there is user input going through it.

For affecting other users/websites on the server, it's a low risk nowadays since cagefs is being used, and the kernel's security is updated on the servers. So don't worry about other users: it's the hosting company's job.


SQL injection prevention by replacing ' with ''

No, that is not safe at all.

Replacing single-quotes with double-quotes or vice versa will only keep you safe from one type of injection. Also, what if the end user has a legitimate need to enter a single-quote mark?

As was pointed out in the comments, you should use Prepared Statements.

Below is an example, taken from the Microsoft documentation.

However, the technique is not unique to Microsoft. Every serious database supports prepared statements.

SqlCommand command = new SqlCommand(null, connection);

// Create and prepare an SQL statement.
command.CommandText =
    "INSERT INTO Region (RegionID, RegionDescription) " +
    "VALUES (@id, @desc)";
SqlParameter idParam = new SqlParameter("@id", SqlDbType.Int, 0);
SqlParameter descParam =
        new SqlParameter("@desc", SqlDbType.Text, 100);
idParam.Value = 20;
descParam.Value = "First Region";
command.Parameters.Add(idParam);
command.Parameters.Add(descParam);

// Call Prepare after setting the Commandtext and Parameters.
command.Prepare();
command.ExecuteNonQuery();


How to minimize vulnerability to UI state interference attacks

The core of the attack is to monitor another application's memory usage, spot a pattern that means "this application just opened a password-request window", and pop up the attacker's clone of that window in front of the real window.

For windowed operating systems (Windows, MacOSX, desktop Linux), one solution is focus stealing protection: prevent a non-foreground application from placing a window in front of the foreground window.  Some Linux window managers (eg. KDE) have focus-stealing protection.  Windows and MacOSX only prevent accidental stealing; intentional focus stealing is not prevented.


How to detect port scan on SIEM within LAN or same Network?

Every connection within your LAN must go through a router or switch. Some routers allow access control lists, which can block/allow connections to specific ports and services. Each host may also implement internal firewall rules to only broadcast a service to specific hosts, this however, means more management and operational overhead. Another option is to have a NIDS monitor for these sort of things. (Here is how to do it in snort)

Remember that a port scan is not the only way to find out which services does the infected machine access, by just listening to the open connections for a period of time, the virus/trojan/malware can gather which machines within your network are accessed and on which ports, not a 100% sure approach but helpful nonetheless.