Is there a way to physically trace stolen hardware? This must have been asked before, but I cannot find any related question.

Is it possible to put into hardware, some kind of "transmitter", so that in the event of it getting stolen, it can be physically traced?

This would be similar to the "find my phone" logic applied to some smartphones, where Google Maps (or whatever) highlights the (approximate) location of the device.

It was suggested to me that it might be done by placing an RFID chip into the hardware.  I looked on Google/Ebay for more information, but each would assume I already know exactly what I need.

Can anyone explain the technology required, and provide examples of any equipment needed please?

RFID chips can only be read at very close distances (a few centimeters to a few meters, depending on type). So unless you suspect that the device is in the same room, an RFID chip won't help you locate it.

To remotely locate a device anywhere in the world, the device needs:

A GPS receiver to get its location
A GSM modem to transmit its location to a server via a cellphone network.

A smartphone already has both, so a software solution is quite straight-forward in this case.

When you want to bug an item which has neither, there are hardware devices available which have both. Usually each of these devices has a cellphone number. You send an SMS to the given number and the device responds with its GPS coordinates. Enter them into Google Maps and you have an address you can report to the police (Do not attempt to recover your property by going there yourself. You are endangering yourself, you might violate the law yourself by overstepping legal boundaries of vigilantism and might give the criminals opportunity to destroy evidence which can then not be used to convict them in a court).

To find such devices in online stores, search for "GPS tracker". A quick search on amazon.com shows gadgets like this, but I have no first-hand experience with these devices, so I can not give a product recommendation.


Do my Windows system binaries contain sensitive information? I have a dataset from a malware detection project that others want to use. Part of that dataset is system binaries that I had retrieved from my PC by searching for *.exe files (to serve as a benign dataset). Is it safe to share these files or can they contain sensitive information about accounts/identity etc.?

Everybody's (me included) reflex answer to such a question will normally be: Huh huh huh (falls off chair). No! How would you think this could even work? Executables are signed nowadays, which prevents them from being modified!

However, if you consider "exe" files in general, not just those from a fresh naked Windows install, the answer must be: Careful!.

Some executables (an increasing number) are specially crafted for you. And yeah, they're signed, doesn't make a difference.

This includes at least some, but more likely most executables you downloaded from one of those modern software-as-a-service or online shop or whatever you call them things. Adobe, Steam, Office360, you name it.
I don't know the technical details about each and every of these, they're just examples that came to my mind as possible candidates. It is however certain, that among other methods, custom-signed executables exist (not just on PC, for example the Nintendo shop definitively works that way).

So, if your Windows system is not just a Windows system, but one that includes custom-signed (or what would one call it? custom-branded?) executables, then you may give out sensitive information.

Also, not all executables are the same version, and not all executables are present on every computer. Unless one also considers file creation dates, it is probably a bit far fetched to say that they provide a unique fingerprint, but this information could certainly be used to more or less identify your system, with a little error margin.

While in theory, there's probably enough combinations of features and versions to identify every atom in every computer, in practice most installs will have mostly the same features, and mostly the same versions. Which amounts to maybe a few dozen million real permutations. But still, if it's a problem that someone might tell that's this-and-that combination points to your specific computer with, say, 85-90% likelihood, then... be aware.
Mind you, it's not so much different with genetic analysis, although of course numbers are much bigger in that case. Folklore tells us that siblings are 50% genetically identical, but in reality, complete strangers are 98% genetically identical. That's because, well, they need these genes in that particular composition to even exist (you will be surprised how much you have in common with, say, a rat or a bunny!). But even if people are mostly identical in almost everything, there's enough in the small, remaining bit to tell quite a lot about someone.


Security in wireless ad hoc sensor network (without physical access) I want to know without taking physical access, what are the methods that can steal the data in a node.

When talking about eavesdropping, how can an attacker sniff the packets? Do they need to listen to that node or listen to channel?
Is there any other way to get nodes data?
What happens when impersonation attacks happen? Can an attacker get all the data of particular node?
How can encryption can be used to secure communication? And is there any way to protect keys? If a hacker gets the key does that mean he gets the all?

Here you are talking of just an ad-Hoc wireless connection with/without internet connectivity is an important aspect which is unclear.
Considering it to be with an Internet Connectivity then the usual WEP key is completely vulnerable.
WPA-2 is preferred alternative.
Also node data can be theft only if specific ports are left open.
So that has nothing much to do with network here; instead iptables or firewall must me secured.
On similar lines even if the key is lost to the hacker that doesn't guarantee he can take all your node data.


Do WebGoat style XSS attacks still work? I am going through the WebGoat exercises, to refresh my knowledge of XSS attacks.

Specifically, I am doing the Stage 1 XSS exercise. This exercise has a form that deliberately does not sanitize input. The solution video shows using the JavaScript alert function to put out a message and the session cookie.

Stage 3 has a built in XSS code snippet, that upon viewing a profile will show the contents of 'document.cookie'.

In any modern browser, all without any add-ons, I cannot get this to execute. I can generate messages using JavaScript alert, but it never prints the contents of document.cookie

The tutorial on this page for get cookies shows that it is possible to print the contents of document.cookie in a JavaScript alert message.

What I would like to know is why I can't do the same in a very simple, deliberately vulnerable to XSS web application. Is there some XSS detection in all modern browsers preventing this? I've tried with he options to disable web security on IE, Firefox and Chrome and it makes no difference.

edit: Things I have tried for both WebGoat 5.4 and WebGoat 6.0.1:

Accessing via Firefox with a new, default profile and no addons
Chrome with the --disable-web-security and/or –disable-xss-auditor
arguments
Accessing via Mantra
Setting the X-XSS-Protection header to 0 in my requests.

Is WebGoat trying to teach about an XSS attack that is no longer a threat?

2nd edit:

Per Martin's answer, I tried setting the header manually as seen in the screenshots below. I modified the lesson title so it is obvious fiddler is correctly intercepting the page.

The cookie is not set as secure3 or httponly, but refuses to be read from any browser via JavaScript, via bookmarklet or Scratchpad. The cookie is set correctly in the browser and is viewable in the browsers cookie dialogs.

What property of this cookie is preventing it from being read?

Setting the X-XSS-Protection: 0 header is the correct solution, but you have to add this header in the response, not in your request.
Steps:

Make sure you have an actual cookie which is not secured with the HTTP-only flag. (You can edit the JSessionID cookie for example)
Use a correct JS command to retrieve the cookie (test it first in console), for example: var a=document.cookie;alert(a) (note: if you have multiple cookies, you will have to split them, I assume you only have the JSESSIONID cookie)
Store the command in the street field, with script tags: var a=document.cookie;alert(a) (Stackoverflow hides the script tags, make sure you add them)
Fire up Fiddler before saving. We will intercept the response and add the X-XSS-Protection:0 header in the response (if you have the developer version, you could probably add it in the source)
Intercept the response, edit the response headers, add the X-XSS-Protection:0 header, hit CTRL+S just to make sure, then hit 'run to completion'.
Et voilà

Update: screenshots for clarification.

Fiddler

*:

Webgoat result


Is it possible to still perform click-jacking with if a website has SSL? There are someways to stop click-jacking on websites without HTTPS, but I have seen that you cannot perform click-jacking on website the does have SSL. Is this true or can you still perform click-jacking?

You should read about what SSL (HTTPS) really is. SSL has no connection to click-jacking, and it is still possible regardless. As dandavis stated in comments, proffesional pages nowadays are custom-scaled to browser resolution, so Click-Jacking is really not often used tactic. Modern websites also use headers to prevent click-jacking by telling browser not to load them in <frame> or <iframe> from other sites.


Pre-Installed Tails OS Flashdrives I ran across a pretty cool looking dongle that has Tails OS pre-installed, with tutorials on how to use the software.

I wanted to ask the community how safe you guys think this kind of technology is? The founders posted a Binary file at the bottom to be "Transparent", but I wanted some input from the tech community.

Here is the Link - https://www.kickstarter.com/projects/blackcard/black-card-online-privacy-simplified

Tails is probably the most secure you can go in terms of choosing an OS but it's still vulnerable and it needs to be used in the proper way I would recommend reading the documentation or instructions on its website. All that Kickstarter is is a pre-installed USB drive with Tails on it which seems stupid since most people already have a USB drive lying around and Tails is open source and free. I would never buy a USB with a pre-installed OS if I was worried about security. Rather make it myself it takes about 5 min.


How can I trust that this is Google? How do I trust that I am typing my password for Google when I'm using a Safari web view in an any iOS app?

How do I trust that I am typing my password for google

You do not.

Apps should allow you to do that through actual Safari browser in another window, where you can see the address bar.


Isn't this the same as using a certification authority? Taken from Wikipedia, here is the pretext to my question:

  A certificate authority (CA) is an organization that stores public
  keys and their owners and every party in a communication trusts this
  organization (and knows its public key). When the user's web browser
  receives the public key from www.bank.example it also receives a
  digital signature of the key (with some more information, in a
  so-called X.509 certificate). The browser already possesses the public
  key of the CA and consequently can verify the signature, trust the
  certificate and the public key in it: since www.bank.example uses a
  public key that the certification authority certifies, a fake
  www.bank.example can only use the same public key. Since the fake
  www.bank.example does not know the corresponding private key, it
  cannot create the signature needed to verify its authenticity.

I get that certification authorities help thwart man-in-the-middle attacks, but I don't understand the point of spending money to use a certification authority's certificate if browsers just hardcode the CA's public keys to validate it outside of HTTPS communications which seem to be somewhat browser-dependent because...assuming I use RSA encryption with SHA1 and OAEP padding on my server, isn't it just as secure if I:

Generate a secondary private and public key pair
Keep secondary key a secret, write it down somewhere and lock it inside a vault
Always sign my server's primary public key with the secondary private key
Hardcode the secondary public key in my client applications
Use my secondary public key to check if the server is the server they say they are by checking that the public key they issue to me is signed with my secondary private key?

I am thinking of using this model over a TCP socket server where I can specify my own protocol and essentially be my own "browser"...

Essentially, is this all that's behind a CA? That's pretty sad...it honestly feels like a money-grab scam when you can just become your own CA. I mean, if the CA is compromised, browsers need to get patched, keys reissued, etc. If my client application becomes compromised, I don't need to wait while the hole is closed, I can quickly push out a new public/private key pair and send the public key of my pseudo-CA to client applications.

What you're describing is called certificate pinning; essentially, you ignore the whole CA process and just give the user application a certificate to trust. It's actually widely recommended for non-browser applications (e.g., mobile apps) for the exact reason you stated - if you rely on a CA and it goes down, you're in pretty deep trouble, whereas it's relatively easy to fix it quickly with certificate pinning by pushing a new certificate. Or better yet, you can have two certificates in your app, and rotate them if one goes down, then push a new certificate in the next update.

Of course, web browser makers can't amass and verify a collection of everyone's certificates ever, so they choose to trust a few centralized servers that then verify everyone else, and this is mostly successful at keeping users out of trouble. That's why the CA system exists.

I should clarify that you're still trusting a third party - it's just a different third party that doesn't charge you for the privilege. For instance, if we're talking about an iOS app, the app is signed by the App Store. That's what's preventing an attacker from swapping out your hard-coded certificate with another certificate.


How to secure a certificate internally Say I have a certificate which I use to sign the software I ship. This happens in the (daily or more) build on the buildserver (Windows machine). Easiest solution would be to put the certificate file (pfx) on the buildserver and just use it there.

But like this, it could be stolen by either any guy in the company (think .. frustrated leaving guy) or a virus or whatever. This might lead to a disaster.

Currently the certificate is stored in the certificate store as "unexportable", which should be a little more safe. But how safe is this "unexportable" thing really? The server is a VM, so I guess someone could just copy the the whole thing, take it with him and sell it, or use it to sign anything.

Of course anyone with access to the buildserver could use it to sign anything on there, but I guess there isnt really a way to fix that. (And going to the office to signing malware (or whatever) seems much more unlikely than just selling the certificate or something like that, so it is assumed to be way more unlikely)

So my questions are:

How safe is that "unexportable" thing really?
Should it be put on a hardware machine to make it harder to steal/copy the whole thing?
Is there a better/more secure way to handle this?

"Unexportable" means that the dedicated functions from the operating system will refuse to export the private key. However, it is of course there; this is just software, so the private key, when used, necessarily exists at some point in RAM with all its structure. The marking of the key as "non exportable" is a security system only against attackers who do not have administrator rights, and must act within the constraints of the API. Otherwise, export is rather easy. For that matter, a simple whole-system backup would be sufficient to obtain the private key.

To make key storage robust against local attackers (people who have access to the machine, and are technologically competent), you need a Hardware Security Module. This is an expensive piece of hardware, which will never give away a key which has been entrusted to it; it will actively destroy the keys if it detects a physical breach. Moreover, it will log all private key usages. Someone accessing the HSM physically could still obtain as many signatures as he wants, but they all will be logged and will not have the key itself (so he won't be able to sign afterwards). A cheaper (but somewhat less robust) version would be a smart card.

The usual method for securing access to code signing keys is to have two keys; a "development key" which is used for development, and a "production key" which is used only when an actual product is about to be shipped. Developers' machines are configured to accept the development key as valid, so that developers may work with code signed with the development key, but of course only the production public key is deployed in the user base. The idea is that signing with the production key should be sufficiently rare that you can do that in a non-automated way, under physical scrutiny of the management, and using dedicated hardware (e.g. a smart card which is normally kept in a safe).

(When using special hardware to store a private key, backups can be an issue. You should take care to either keep a safe copy of the key somewhere, or to be able to obtain a new one within a short notice.)


How to secure application VM? This question is derived from my previous question on Isolating Web application where two approaches were recommended.

Apache Chroot Jail
Isolation through Virtualization

My question is if one of the VM on which application is hosted is compromised will the virtualization layer be enough contain the vulnerable web application? Are there any other security measures need to be taken to protect other VMs?

See this question for a sense on how secure VMs really are. How secure are virtual machines really? False sense of security?

A good general rule is to not allow the VMs to communicate with each other through networking. This means proper measure to segregate network access should be enforced.

If you notice a compromise on any of the VMs, immediately nuke the VM and setup again from a known safe point. This should be relatively easy to do with virtualization compared to an actual server.

Besides that, make sure that your hypervisor is kept up-to-date to prevent any known exploits against the hypervisor from allowing a compromise to break out of the VM and affect the host or other VMs.


AES-ECB chosen plaintext attack with long secret I'm having some trouble understanding the methodology for a crypto exercise I'm doing. The goal of the exercise is to recover an encrypted secret string through a chosen key attack on AES in ECB mode.

I have an oracle function that takes a string as input, appends the secret string to it, and returns the AES-ECB-128 encrypted string for it, using a static, randomly-generated key.

oracle("text goes here!!") -> AES.encrypt("text goes here!!somesecretsomesecret", "staticrandomkey!")

I understand how to get the plaintext for the secret phrase using the method described here, and have been successful at recovering 16-byte secret strings.

What I don't understand is, how can that method be applied to secret strings longer than 16 bytes? Unless I'm missing something obvious, it only works for recovering the first block of an appended secret.

I think you already said the solution in your post but let's repoint it.

AES work with block size of 16 bytes (128 bits)
The secret is appended to a text that you choose.
???
Find out the characters of the secret string one by one

If it was not an exercize I would give more details...

EDIT

Once you find the first 16 bytes, all you need to do is :

Exactly the same thing but look at the second block!

The solution...

Get the first secret block

Enter 15 characters and retrieve the first 16 encoded bytes
Then enter 16 characters changing the last one until you get the same result as with 15 characters for the first 16 encoded bytes. That 16th character is the first character of your secret. You can then repeat the process by putting 14 characters and then finding the second secret characters with the same thechnique.

Get the second secret block

You already found the first 16 secret bytes. Now enter 15 characters and find the result for the second block of encoded bytes; bytes 17 to 32. Then enter 32 characters, only changing the last one until you find the 17th secret characters in the secret string. Then repeat to find the 18th and so on byte.


how does iran blocks domains in tls connection but not based on ip recently (last week?) internet in iran has started blocking https websites again.
they did this before but that was, as far as I know, ip based. but it seems that the new blockage in not ip based but domain based.

a test with
curl -vvv https://www.domain.first
curl -vvv https://www.domain.second
shows that curl tried to connect to same IP in both cases but in the first case it gets stuck in hello stage of https.

is tls domain based? for supporting multiple website on same ip?. but does that expose the domain in the initial negotiation? I always thought that tls used IP?
I am not a network pro, so sorry if this is not clear.

What you seem to be seeing is related to Server Name Indication, which is basically the TLS equivalent of HTTP's Host: header.

Per that same wikipedia article:

  Therefore, with clients and servers that implement SNI, a server with a single IP address can serve a group of domain names for which it is impractical to get a common certificate.

Practically, SNI is basically a record sent during the TLS session setup - the High Performance Browser Networking book provides an overview of the handshake, and also provides a specific section on SNI, summarised as:

  The TLS+SNI workflow is identical to Host header advertisement in HTTP, where the client indicates the hostname of the site it is requesting: the same IP address may host many different domains, and both SNI and Host are required to disambiguate between them.

tl;dr: SNI allows an observer to identify the specific domain a TLS request relates to. It can also be used, as was recently reported by FireEye, to obfuscate the 'real' target of a connection - e.g. you can have an SNI to google.com, but a Host: header for youtube, and this (currently) will allow you to browse content from youtube without exposing the fact.


How can an out-of-the-box (Windows) server not be secure? Background: I'm considering switching from shared web hosting to VPS for added security. However - managed VPS's costs much more than unmanaged ones.  So, assuming:

I secured my website against any type of sql injection and the like.
I Keep my password secure .
I set Windows update to automatic.
The web hosts themselves don't 'attack' the computer (because if they
do - there's really not much I can do about it anyway).

Is there anything else I must do to make it safe? (Safe. Not impenetrable.) Am I correct in assuming that most vulnerabilities are of software run on the operating system, and not the operating system (Windows) itself?

And a specific issue: It seems from what I've read - that there is need for closing ports. But why? A port doesn't do anything - it's the applications listening to it which might be vulnerable - but if an application is listening to a port - it supposedly needs to do that, and you can't just close the port.

EDIT

I do realize that security is a continuous effort, and that obviously my own software might contain security flaws. What I'm looking for is an 'aha!' type of answer like - "Ports are not dependent on the software listening to them!"

First off, you say you have secured your website against, "any type of sql injection and the like." What this means, at best, is that you have secured it to a standard that you think is good enough at that point of time, but it may still be insecure.

I'll give you the basic overview:

Microsoft WIndows itself, when written, has many vulnerabilities, both known and unknown
All applications have vulnerabilities
Applications and operating systems are patched over time, but new vulnerabilities
are discovered
Every open port could allow an attack, depending on what vulnerabilities are present in the application listening on that port

The general guidance is that you should:

Install your platform, install the O/S and patch up to date
Remove all unneeded applications
Follow Windows hardening guide
Install only those applications needed and patch up to date
Follow hardening guides for these applications
...etc etc

You cannot secure something. You can only reduce the risk of a successful attack, and even then, this is a continuous process.

Update: rolling up comments

Although the only application you need on there is a web server, Windows out of the box has many applications listening on various ports. These should all be hidden from the outside world unless you have good reason (may be needed to connect remotely etc. in which case you need to secure that application) - and you can do this by disabling the application or blocking the port at the firewall etc.


Manipulating data during a MiTM I'm trying to learn some attack methods by myself and I have hit a wall where I can't find any information. I have successfully performed an ARP MiTM between 2 systems and I am able to sniff the traffic using tcpdump, driftnet, etc.

My question is: How can I actively modify the packets by injecting HTML code into the response (non SSL, of course)

Ettercap has options to inject into an html stream. You could also use proxies.


Password sharing with spouse or mate (bulk-change shared passwords (via cloud service))? I've read on New Scientist magazine that in 80% of all cases when people in a relationship share a place where they live one of the spouses knows the other's password, thus making the question I am addressing in this post a real concern.

On some other site, I've read that on average any given person will have about four passwords which they will tend to use on any given site. Over the years I have personally become part of more or less 40 sites where I am registered (social networks, shopping, mobile phone and Internet subscriptions, banking and bills, Google services, etc...).

Now, suppose someone breaks up (perhaps for good), or goes into a divorce, or any other uncomfortable situation where the other person may be able to enter into your accounts and read stuff without you knowing about it, or even worse, carry out modifications, deletions, password changes (or even account deletions!) (which could happen at just about any moment; and who wants lawyers!!!).

Nasty stuff! So, what I would like to ask, is, is there an online web service somewhere, or perhaps an account manager in the cloud (or on your mobile device with cloud backing), that will allow you to bulk-change all passwords you are using everywhere?

Ideally, you should be able to specify all your accounts, with some tracking system. Once all have been added, and each of the four passwords assigned to each, any time something happens you bulk-modify all passwords in one step (via a master password used to access the cloud service).
What other solution could this problem have. Keeping secrets from the other spouse is impractical and I would even say impossible in most cases, and the same goes for passwords. Is what I am describing possible and has something along these lines already implemented?
Or is there perhaps something even better to handle this problem which I have not thought about?

Thank you for sharing your solutions to this omnipresent and vast-reaching problem.

Services such as LastPass have an auto change password feature.

However, this has to be done per site.

The solution of bulk updating everything is to a problem that should not exist in the first place. i.e. Passwords should not be shared between applications. Each service should have a unique, strong password of its own. Otherwise if one service gets compromised and the password is found, the rest go with it.

The idea of using a password manager is to have a strong but memorable password for the master password, and for each site it protects they have a totally random, unmemorable, strong password (e.g. 20 completely random characters). If you wanted to share account details with a trusted partner, then some password managers have functionality to allow this. The account owner would just have to unshare these accounts in the event of breakup before changing the password.


How were Cryptographic nonces used in the Yahoo! data breach? How does an attacker use Cryptographic nonces to generate access cookies through a script on a server? As what happened to Yahoo! servers.

I wonder if this was a not a mistake in the article.  They call the stolen cryptographic values "nonces," but a nonce is intended to be used only once and I would not expect them to be stored in an account database because, depending on their use, the value would change many times during an authenticated session.

If I had to guess, what they call a nonce is actually a salted hash generated from their password and the script on the Yahoo server was allowing them to authenticate using the hash instead of checking the provided password against the stored hash.

Edit:

After reading this, the "nonce" changes only after changing the password which to me indicates it is either their salted+hashed password or else some type of unique identifier for their account cryptographically generated based on their password and maybe other fields, but I suppose it could be based on other information entirely.

It is hard for me to guess what the script used to mint the cookies intended purpose was.  It could be that it is part of their regular authentication process.  It was available from the internet and so may have been called by the browser during authentication making it easier to find by the attackers.  Maybe the browser called one authentication function to validate the username/pass and was returned the "nonce" which it used to call the function in question to generate the session token.  Whatever it's intended purpose, in this case it allowed the attackers to bypass the traditional authentication process that salts+hashes the client provided input to compare to what is stored in the table, instead allowing the "nonce" value to generate a session token with the authorization granted to the account.  The whole point in storing passwords in a salted+hash form is to prevent someone who successfully stole the account database from being able to use the credentials without a lot of extra work.  With the referenced script on a server this step was basically eliminated and the results were not much different than if the passwords were stored in cleartext.


HTTPS - Can server see details of client side certificate? I am using mitmproxy to intercept HTTPS connections from my client device to a third party server. In order for mitmproxy to intercept SSL requests, I need to install a trusted root certificate on my device.

Is there a way for the server to know that requests have been intercepted? Can the server see the details of the custom root certificate? For example if the name is "mitmproxy", can the server see that?

Is there a way for the server to know that requests have been intercepted?

No, because the communication with the server does not use the custom-installed MITM certificate. That certificate is only used by the client when communicating with the proxy.

[Client] <=========================> [Proxy] <=======================> [Server]
           Connection using fake               Connection using real
           user-installed cert/key             server cert/key

The server only knows that it is communicating with some client. The server has no idea that that client is actually a proxy acting on behalf of another client. The proxy-to-server connection is a perfectly genuine HTTPS connection, using the server's real key and certificate.

The connection between the client and the proxy is where something fishy is going on. The proxy knows that the certificate isn't genuine, but the proxy is controlled by the person orchestrating the MITM attack, so that's perfectly reasonable.


Why store a salt along side the hashed password? Understand the need to protection credentials with hashes that are expensive and to use cryptographically random salts.

What I would like to understand is why you would store the salt along side the hash in the database, does this not defeat the point of having one?

Take a SQL injection vulnerability in which I can dump the data in the User table. If I have access to the Hash as well as the salt does it not make my brute force attempt easier (as apposed to not knowing the salt?).

If storing the salt with the hash - does this not defeat the point of protection against rainbow attacks? (if an attacker has access to the database).

I can see where you're coming from, but the answer is basically "that's not what the salt is for".  If I'm trying to discover a particular user's password, the salt doesn't help much if it's right beside the hash.  However, it's not expected to be useful in that situation - cracking an individual user's password is difficult enough already.

The point of the salt is that it's something to add to each password before hashing such that each password is unique - if two users both have hunter2 as their password, the hashes need to be different.

Say an attacker is fishing through a database (or a whole range of databases) to find everyone whose password is letmein123.  Without a salt, they can do the hash once and search for the hash.

Without a salt if an attacker spots two or more identical hashes in the database, it indicates that this is a weak password (since multiple users have chosen the same one) and can concentrate on cracking this first.

But the salt is a user-specific prefix/suffix that is added to the password before hashing, so (even with a "public" salt) an attacker has to re-calculate the hash for every user - so checking one password against 10000 users isn't any more efficient than checking 10000 passwords against one user, which is the point.


What methods can be used to prevent the browser (IE11 specifically) from storing credentials / autocomplete Going through Pen Test and it was asked of us to disable auto complete in our CC payment fields.

We tried adding autocomplete=off and also tried false on the input filed. A
ny suggestions to override this 'feature' in IE11 and other browser specific extensions?

It is true that most major browsers now ignore the autocomplete value if set in the web application.  However, IE11 only ignores this setting on password fields, it should still honour the autocomplete setting on CC fields.  As Xander suggested, it could be worth checking the input type for your CC payment field.


Chain of causality in Equifax breach (expired certificates disabling IPS capabilities) I am researching the Equifax breach described here:
https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf

Apparently the attack went undetected for a long period of time and the main reason given for this are expired certifiates: Because of expired certificates, the Equifax IPS was unable to inspect encrypted traffic and detect the breach in time.

-- Edit, based on Steffen Ulrich`s response below --

Page 34 of the report gives some more details:

  The expired SSL
  certificate was installed on a traffic monitoring device called an SSL
  Visibility (SSLV) appliance.195 This device allowed Equifax to inspect
  encrypted traffic flowing to and from the ACIS platform by decrypting
  the traffic for analysis prior to sending it through to the ACIS
  servers.196 Both the intrusion detection system and the intrusion
  prevention system were behind this monitoring device.

And further below on the same page:

  The default setting for this device allowed web
  traffic to continue through to the ACIS system, even when the SSL
  certificate was expired. When this occurs, traffic flowing to and from
  the internet is not analyzed by the intrusion detection or prevention
  systems because these security tools cannot analyze encrypted traffic.
  According to documents obtained, the SSL certificate installed on the
  SSLV device monitoring the ACIS domain ai.equifax.com expired on
  January 31, 2016. As a result, Equifax did not have visibility into
  the network traffic in the ACIS environment for nineteen months

-- end of edit --

According to my research it should still be possible to decrypt data, even with an expired certificate. Consider for example this post here:
https://stackoverflow.com/questions/28098470/no-error-encrypting-decrypting-data-with-an-expired-certificate-using-rsacrypt

I am not that familiar with IPS products and respective configuration possibilities, so I am a bit confused: What exactly is the issue with the expired certificate? Is the IPS checking the validitiy and in case the cert. is expired just refuses to decrypt traffic? If so it seems to be, that there should at least be an option to decrypt anyway and issue a warning to the whoever´s running the IPS. Is there such a thing?

Thanks for you insight and cheers

I suspect that the report is kind of misleading in claiming the expired certificate as the problem. A certificate can not be used to decrypt traffic at all but rather the private key matching the certificate is needed. This is at least true for the (obsolete) RSA key exchange which I assume was used here - for inspection with DH key exchange one would need instead need the pre-master secret of each TLS connection and neither certificate nor private key would be usable.

Thus the problem is likely not the expired certificate but instead that the private key installed on the device matched the public key in the expired certificate but not the one from the new certificate. This is likely because the new certificate did not reuse the key from the old certificate but instead a new key pair was created. For successful inspection the new private key matching the new public key in the new certificate had to be installed on the inspection device.


End-to-end encryption with a reverse proxy and an application server Lets say that I have an nginx reverse proxy that proxies the traffic to a Tomcat on the same server. I think the most common way to configure this setup is to enable SSL on nginx and then proxy the unencrypted traffic to Tomcat. So far so good. The traffic starts to grow and I decide to move the tomcat to a different server for performance related reasons. Now the connection between the nginx and the Tomcat is unsecure (http).

How should I prepare for this security concern? Should I tunnel the traffic through an SSH tunnel from nginx server to the Tomcat? My servers could be located in a cloud service so the connection between them is not secure (to my knowledge).

What you want is "Upstream SSL".

This is when you re-encrypt the backend connection with Nginx. You don't need to buy another certificate. You can use self-signed certificates for the backend.

Discussed here: StackOverflow: Nginx load balance with upstream SSL
and here: ServerFault: Configure Nginx as reverse proxy with upstream SSL

Blog here: "SSL Offloading, Encryption and Certificates with NGINX (Archived here.)
They insist on calling this "End-to-End" encryption in their blog. (It maddens me that they do that. If you re-encrypt, then you're no longer end-to-end encrypting.)
(But Citrix is guilty of the same terminology sin with their "NetScaler" loadbalancer. (Archived here.))


OpenSSL, x509: what is the correct way to picture signing authorities? For the purposes of creating a VPN, I can't find a logical explanation of OpenSSL's/x509 scheme. I'm royally confused about these three terms,

Certificate Authorities
Gateway certificates
End-point Certificates.

I've read both Openswan: Building and Integrating Virtual Private Networks, and Building Linux Virtual Private Networks (VPNS). Both of these books in my mind presume an enormous amount of knowledge that the average programmer doesn't have, namely how does OpenSSL's x509 stuff work. I understand the basics of Public Key encryption, sending your public key, having the recipient encrypt their message to you which can only be decrypted with your private key. I've read the other answers here too, so let me specify my areas of confusion.
Should I think of a OpenSSL Certs as,

Certificate Authority → Gateway Certificate → End-point Certificate

Or,

Certificate Authority → Gateway Certificate
Certificate Authority → End-point Certificate

It comes down to this,

Does the self-signed CA sign the Gateway Cert which signs the End-point (client) certs? Or, does the CA sign all of the certs directly? Does the Gateway Cert have any direct relationship to the client-cert, or is that just an element of configuration in the VPN?

In X.509 certificates, there are Certification Authorities and End Entities. A CA is a system/organization which owns a public/private key pair and uses it to issue certificates, that is, sign them. A certificate binds an identity to a public key, and the job of the CA is to assert such bindings. You use the public key of a CA to verify the signature on a certificate. The public key of a CA can, in turn, be bound to the CA name by virtue of them being stored in a certificate, signed by a super-CA. This process is recursive, so you will end up, in practice, with certificate chains beginning with a "ultimate CA" (normally called "root CA" or "trust anchor") that you trust ex nihilo (it is hardcoded in the software or its configuration files), then a number of certificates, each containing the public key used to verify the signature on the next. All the certificates in the chain are necessarily CA certificate, except possibly the last one.

The last certificate in the chain is then called "end-entity" because it designates a system/organization which is not in the business of issuing certificates, but is "something else", for instance a VPN server. Since the end-entity key is not used to sign other certificates, the end-entity certificate necessarily appears last in the chain, hence its name.

In a VPN, there are end-points and gateways. A gateway is a machine which accepts connections from other systems (end-points, and other gateways), and forwards traffic on behalf of the connected system. An end-point does not indulge in forwarding; it sees only its own inbound and outbound traffic. The StrongSwan documentation begins with a rather self-explanatory diagram. End-points are application servers and desktop computers, while gateways are structural elements which route data.

Gateways (and, possibly, some end-points) need private/public key pairs, and the other systems must be able to verify that a given public key is indeed owned by a specific gateway or end-point. This calls for PKI and certificates. All these gateway and private/public key pairs are used to "do VPN", certainly not to issue certificates for other people, so they are all end-entities, as far as X.509 is concerned.

Certification and VPN structure are orthogonal. The certificates are used to assert bindings between names and public keys. There is no need for a CA to be located on a server which is also a router or gateway; there is actually no need for a CA to be online at all. Also, there is no need for a gateway to act as a CA: the gateway is meant to forward network traffic, not to make statements on the identity of other systems. You can conflate both roles and make a gateway also a CA, but this is very artificial, it is not needed in any way, and it will increase confusion.


How to secure a digital ID from being faked? We're trying to create a digital ID to replace UK Passport/driving licences for entry into licensed premises, but need to ensure it cannot be faked (or failing that, the barrier to faking it needs to be very high).

Here are the restraints we need to deal with:

We need to be able to implement it on Android and iOS
Door supervisors don't like to use technology on their side, so mobile to
mobile communication solutions are not possible, and anything that
requires more than a minor effort on their side is likely not an
option either
To show the ID, the users will scan a static QR code around the neck of the door supervisors, which will display the ID on
the user's phone until dismissed.

Assume sufficient authentication is a prerequisite, and that we can make use of users facebook data if necessary.

Traditional IDs use a hologram to prevent forgery, and despite this being relatively easy to fake in many cases, it's considered a sufficient level of security for many physical ID cards. We could use gyroscope and accelerometer data to create something that looks and moves like a hologram, but our fear is this could be faked, either in a web app in the browser or on an app on a rooted iphone/sideloaded onto android.

We've also considered using physical security tokens as a solution, whereby the door staff have a physical security token with the QR code. The user would scan the QR code which tells the app which venue they are at as well as what the ID of the security token is. The app could then speak to the security token digital authentication server and display the matching token code for that ID - which would should match and prevent forgeries. However due to token drift over time would need regular manual synchronisation, and so is not a perfect solution.

Any ideas?

the users will scan a static QR code around the neck of the door supervisors, which will display the ID on the user's phone until dismissed.

If "the user" is the subject of verification then you cannot create a system with any level of accuracy/trust based around this constraint. The subject controls both the identity data and its processing. Even if the door supervisors were technologically literate, they cannot trust information displayed on someone else's device.

Assuming that you have a database of customers and verified ages (or more correctly dates of birth) then the only way I could see this working would be for the customer to direct the door supervisor to the record (e.g. by presenting a QR code) which the door supervisor could resolve on their own device. This still needs a mechanism for tying the record back to the person standing in front of them - the most obvious and least intrusive way to do that would be to present a picture of the customer on the door supervisors device (there are lots of different ways to resolve this last part). But this is going the route of solving an impossible problem by changing the constraints.


How safe is it to use a Linksys WAP54G Access Point? I have a Linksys WAP54G v1 device that I want to use to create a second WiFi network.

The device is configured for WPA2-Personal, AES encryption with a random 64 character paraphrase.  The firmware is version 3.04 (circa 2009).

What is the risk in using an older device with older firmware if the encryption WPA2 is known to be "good"?

Thanks

The Linksys WAP54G has two listed CVE security vulnerabilities that are rated 10/10 in severity.

CVE-2010-1573 and CVE-2010-2261.

The details say that versions 3.04.03 and earlier are vulnerable to both.

In the case of CVE-2010-2261, the presence of hardcoded credentials would allow any attacker able to send and receive web traffic to access dedicated debug web pages that give a root shell.

As for CVE-2010-1573, the presence of hardcoded credentials allow any remote attacker to access the router, escalate privileges, and gain complete control.


How does proxychains avoid DNS leaks? Also directly related, how are the DNS servers queried when using proxychains? Assume I'm using Tor for proxychains.

If I uncomment the DNS part of proxychains.conf, my requests supposedly get sent straight to the Tor network. If this is the case, how is DNS resolving done? At what point? Does uncommenting that line in the conf file avoid the querying of my ISP's DNS server, and if so then how?

Many thanks.

Part of this boils down to how proxychains works in general. In order to proxy traffic from arbitrary programs (that may or may not have proxy support), proxychains uses the LD_PRELOAD environment variable to load itself as a shared library into the program that is being called. Since it is "pre"-loaded, the functions exposed by the proxychains library take precedence over others, e.g. libc. This allows it to hook certain network related functions.

For example, when the program calls connect() on a TCP socket, proxychains has replaced the real connect() function with its own, one that instead knows how to shove the traffic through your configured proxies.

The same applies for DNS, although it is a slightly special case. The application will make a call to gethostbyname() (obsolete) or getaddrinfo() to perform DNS resolution. If the proxy_dns option is not specified in the configuration file, proxychains will call the unaltered libc function, resolving DNS normally through your system. If the proxy_dns option is present, it will instead redirect both functions ultimately to a modified version of gethostbyname() that is fairly more complicated.

This modified version actually doesn't do any DNS resolution at all. Instead, it creates a fake IP address in the reserved 224.x.x.x or 225.x.x.x range, and maps your requested hostname to it in a table (e.g. 224.1.2.3 --> www.example.com). This will come in handy later.

The application then makes a connection to the fake address returned above (224.1.2.3). Proxychain's hooked connect will then set up a connection to the configured proxy. It will then look up the fake IP address in the DNS table to retrieve the original hostname that you were requesting (proxychains says: `224.1.2.3? That was "www.example.com"). Depending on the type of proxy in use, it will request a connection to the original hostname through the proxy. The proxy performs the DNS requests on your behalf since it is the one making a connection to the real destination.

Specifically in your case, if you were to run:

$ proxychains curl https://example.com

The Tor SOCKS5 server will receive a request from proxychains such as:

Hello server! Connect me to www.example.com:443

The Tor SOCKS5 server will then handle everything; performing DNS resolution and sending your packets over the Tor network.

TL;DR: When the proxy_dns setting is enabled, no real DNS requests are made (or needed) from your end.

Source: Read the source code at https://github.com/haad/proxychains/


Can we drop XP from HTTPS support? If not, when? XP support was dropped by MS on April 8 2014, almost two years ago, but there are still many people who use XP for internet surfing.

Also, there are still many sites like Google or Facebook who offer SSLv3 and similar stuff to support XP.  However, if we would drop XP we would have a much better security. We could use:

ECC
SHA2 certs (well yeah, XPSP3 fixed theat one, but too many XP users still have SP2)
TLSv1.2
AES
HSTS
HPKP
SNI, probably one of the most important aspects of shared HTTPS hosting.

We have a pretty similar situation with older Android (<4.0) but unlike for XP we have actual numbers of the active androids in the Internet by Google and their number is just 3.2%, where we could almost ignore them.

And the most significant point is that everyone who really wants to be on this old system can use Firefox which offers all the nice Security features, and still does XP and most old Android versions (Froyo is an exception).

So let's get to the point:

In light of all that, is it already "safe" to drop XP support (and old Android along with it) from HTTPS sites to give better security? Especially seeing that browser vendors are going to mark even more vulnerabilities out day by day.  Should we wait, and if yes, until when?

Depends entirely on specific sites. I suspect that a lot of sites with known audiences have already started dropping support for XP specific fixes - sites dedicated to OSX software, for example, probably get negligible XP using traffic. They may well have decided that they would rather have better security than worry about the few users who use XP.

On the other hand, sites like Facebook probably still see quite a lot of XP users, especially from countries where upgrading computers is prohibitively expensive. Dropping all support would instantly lose those users, which Facebook might not consider worthwhile.

It essentially comes down to a business decision though, rather than a security decision. If your business feels it is worth supporting these users, it will keep doing so. If not, it may drop the support.

For your own site, it's entirely safe to drop XP compatibility features. You might lose some users, but there isn't anything to stop you.


how block all subdomains for a particular domain I want to block all traffic to and from my network to a particular domain. Apparently, this is not possible in Windows, with either a HOSTS file or using firewall rules: the HOSTS file requires every sub-domain to be listed separately, there is no wildcard feature to just cover all of them (why?); and the Windows firewall rules work by IP address, not domain name.

My home office router/firewall is consumer-grade and gives a feature that's supposed to block traffic for certain "keywords"... but it doesn't work at all for https connections because it can't "see" the entire address. Which I think is ridiculous, because it can see the domain name, which is what I want to block.

Anyway - I can't seem to get a straight answer from searching because there's so much noise around this question - if I take a step up in router quality, get a commercial one, will I start to see more useful network management features, like being able to block a domain and all its sub-domains? Can I also prevent machines on the network from taking an end-run around these rules by resolving IP addresses by other means?

There are a few options for a home office:

upgrade the router to one with the desired features (high monetary cost)
run your own DNS server internally (high labour cost)
upgrade your existing router to DD-WRT/OpenWRT or alternate firmware (moderate labour cost)
offload the issue to a 3rd party, like a DNS provider, such as OpenDNS (small labour cost to configure your router, free for home use)

Can you prevent direct IP connection? That's another problem entirely. Short answer is 'no'. Long answer is 'yes', but then you are looking at more equipment, technology, and configurations/costs. None of the options here are reasonable for home use.


How to block access from a single computer, other than blocking the IP? Here is the scenario:

I have an application, whose one feature/part is to generate voice calls.
I have also provided a (working) demo to generate calls from the website, by inputting your number (without login). To avoid misuse, I have added a CAPTCHA and IP limit.

But there is a user, who manually enters a phone number and keeps on generating calls. They keep on changing their IP, so CAPTCHA and IP limit, both don't work. And it costs me money, as they mostly generate international calls. Blocking international calls, is also not an option, as I provide international service too.

Is there any way to prevent this, without removing the free demo?

I was thinking of doing this using MAC address, or something similar, which blocks a particular computer but I know there will still be loophole due to MAC address spoofing.

How can I solve this? I am using PHP.

A couple of ideas:

First, the obvious:

Change your public ip to other. So migrate the service and notify it to legitimate demo users.

Anyway this is not a definitive method, maybe other (or the same "evil" user) can scan and find you again.

Second one:

Use port knocking. This is a good solution to open services to internet you don't want to be abused. But the problem maybe could be "difficult" to open the port for some users. Not sure if you have a customer db which is supossed to use your free demo service. If you have it, maybe you can notify to all how to do it.

A little example. Let's suposse your service is using port port 12345 and you already have configured port knocking. Anybody scanning your public ip will have a "filtered" response on that port. You can set a combination of ports in order to open it only for the ip "knocking". Let's suppose the combination of ports to open it is 5555, 3432 and 10678.

You can send the instructions to your customers to open it using nmap doing:

for x in 5555 3432 10678; do nmap -Pn --host_timeout 201 --scan-delay 0.5 --max-retries 0 -p $x <yourPublicIp>; done

As I said maybe is too complicated for some customers. It depends of the kind of your customers. If they are IT staff they will have no problems.


Correct CRL and OSCP URIs along certificate chain Merely because of private interest and usage in my own network, I'm creating a certificate chain (Root CA → Intermediate CA → Server cert) using openssl. I'd like the certificate chain to be traceable and also being able to revoke certificates.

At the moment, I am not sure, which CRL distribution Points (crlDistributionPoints in openssl config speech) and OSCP URIs (authorityInfoAccess = OCSP;URI: ... and authorityInfoAccess = OCSP;caIssuers: ...) are the correct ones to set when creating a certificate. Examining the certificates of some public websites, it seems to me, that the following is the way to go. So, would you please check whether I'm right?

Root CA certificate:

CRL: Root CA CRL or none at all
OCSP URI: OCSP URI of Root CA or none at all
CA Issuer: URI of Root CA certificate or none at all

Intermediate CA certificate:

CRL: Root CA CRL
OCSP URI: OCSP URI of Root CA
CA Issuer: URI of Root CA

Server certificate:

CRL: Intermediate CA CRL
OCSP URI: OCSP URI of Intermediate CA*)
CA Issuer: URI of Intermediate CA

*) It seems, one OCSP responder could handle OSCP requests for the Root and the intermediate CA. If so, I could also use the Root CA's OSCP URI, right?

So, every certificates data have to point "one level up", to the location, where its own validity can be checked. Is that correct?

Thank you in advance!

All of these fields have no meaning for the root certificate, as it is already known by the application, and the only way to revoke it is to modify the application. There is no CA more trusted than the root CA to certify that the root is trusted, or that it should no longer be trusted (i.e. revoked).

All of those fields are optional, and the baseline requirements, which define what is required of publicly trusted Certificate Authorities, only require the CRL distribution points for intermediate CA certificates.

CRL distribution points

For CRL distribution points, if you only specify an uri, it is considered to point to a CRL signed by the same issuer, that will contain a reference to this certificate if it is revoked. It is not necessary that all certificates issued by a certificate authority have the same CRL distribution point, and you could segment these so that the CRLs do not grow too much (for example, every 1000 certificates issued, you change the CRL distribution point, and the CRL at that URL will only contain references to those 1000 certificates).

You can however also specify a crlIssuer field in addition to the URL in the CRL distribution point, to specify that the CRL will be signed by a different CA. So you could also point to the same CRL in the leaf certificate and intermediate certificate, and specify in the leaf certificate that the crlIssuer is the root certificate, though that would require you to use the root certificate to revoke a leaf...

OCSP URIs

For OCSP URIs, it should point to an OCSP server that can provide an OCSP response for the certificate. Similarly to CRLs, you need not use the same server for all certificates issued by a given CA and could segment it, though this is far less common as the OCSP answer does not grow with the number of certificates issued by the CA. You can also point to the same URL as that used by other certificates. An identifier for the certificate for which OCSP is checked is provided in the OCSP query, so that server can answer with the correct answer even if it handles multiples CAs.

CA Issuers

If present, CA issuers must point to a url that contains the certificate that issued the certificate, though that url can contain multiple certificates encoded as a certs-only CMS message. I'm not aware of that possibility being used very often though.

References

This is all documented in RFC5280 (section 4.2.1.13 for CRL distribution points, and section 4.2.2.1 for Authority Information Access, including OCSP and CA issuers).


Using an e-mail service anonymously What are the options, to use an e-mail service anonymously without exposing yourself (your private info, name etc.) ?

Bitmessage is a decentralized, encrypted, peer-to-peer, trustless communications protocol that can be used by one person to send encrypted messages to another person, or to multiple subscribers.

so using this you can use bitmessage email service anonymously

and here is the guide to use it
guide to setup bitmessage


Do I need microcode update if I update Kernel? There is a CPU vulnerability Microarchitectural Fill Buffer Data Sampling.
I use a Linux OS and I think  to fix Microarchitectural Fill Buffer Data Sampling you need to update intel microcode or update kernel to a fixed one https://security-tracker.debian.org/tracker/CVE-2018-12130

I updated kernel to a kernel where Microarchitectural Fill Buffer Data Sampling is fixed. After that I run spectre-meltdown-checker and I get STATUS: VULNERABLE to all 4 types of MFBDS. Why ?

 CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  NO  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  YES
> STATUS:  VULNERABLE  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)

Yes, you need both.  The Linux-side changes make use of the microcode-side changes to mitigate these vunlerabilities, both are needed for it to work.

Note that you also need to disable hyperthreading if you are really serious about mitigating this.

I should add, Intel published details on how to "maybe-perhaps" mitigate it partially using some code sequences, and those work even without the Microcode changes.  At least one of the BSDs deployed these, but Linux did not (and there are no plans to, either. Apparently, they don't mitigate things nearly enough to be worth the hassle).


How can I verify the identity of a US | UK -based person and prevent *fake identities* from being accepted? Given that it's possible to fake ID cards and fake social security numbers are created, I need to ensure that all users of my site are US or UK based citizens, and don't have more than one account.

A few examples where one human may have more than one identity would be

Getting married (name changes, SSN stays the same)
Dual citizenship (how do I normalize accounts where a user is active in both countries)
Hackers (the bad ones) that exploit flaws in creating fake IDs and assume the identity of a fictional, or dead persona, or even steal the ID of another user.
Previously hacked identities, not yet discovered to be stolen

Question

Is it possible to outsource the verification of these tasks with a high level of certainty?
What level of theft/duplication I must accept

An interesting question and I don't think there's one good answer to it.  I'd say you could address this by a combination of measures.  essentially no one measure can stop the fraud but using a combination you should be able to reduce the incidence of fraud to a potentially acceptable level

Request proof of identity and address.  The standard for this in the UK is scanned  recent physical documents.  Of course these are forgeable but that's a first step
Verification of the address.  Send a physical letter with a one-time code to the address and require that that is entered into the application.  This provides some level of proof that the identity claimed is resident at that address.
Credit check the identity at the claimed address, and reject low or no scoring results.  This check provides some proof that the person at the address, has been resident there for a period of time.  Also will provide indicators of fraud.  Also if someone hasn't used an identity for a while (e.g. name change on marriage) this would show on the credit check.
That leaves you with scenarios like family members at the same address.  I'd say that checking that either needs an in-person check or perhaps using a phone call to catch out the person (i.e. if you phone and ask for the putative customer, when they know nothing about the application that's a fair indication there's a problem :) )
If you really want high level assurance and the profile of your customers is such that they would accept this kind of checking (I'm thinking something like high-end private banking), you could have an in-person meeting and as @david-houde mentions above gather a biometric identifier that can be compared against future registrations.


Metasploit Framework: Remove Vulnerabilities from Database? Is it possible to remove the vulnerabilities in Metasploit Frameworks's database that I have imported from Nexpose and Nessus? I want to remove the vulnerabilities from the database while keeping the services in the database.

I have tried using the command msf > hosts -d 192.168.68.129 -c vulns or msf > hosts -c vulns -r 192.168.68.129. Both of these commands results in the entire host being deleted from the database, not the vulnerabilities.

There is no direct way to delete vuln objects from within msfconsole. The best way would be to drop into irb and delete them from there.

msf exploit(ms08_067_netapi) > irb
[*] Starting IRB shell...

Loaded ~/.irbrc
>> framework.db.vulns
=> #<ActiveRecord::Associations::CollectionProxy [#<Mdm::Vuln id: 59, host_id: 320, service_id: nil, created_at: "2016-12-30 17:22:01", name: "MS08-067 Microsoft Server Service Relative Path St...", updated_at: "2016-12-30 17:22:01", info: "Exploited by exploit/windows/smb/ms08_067_netapi t...", exploited_at: "2016-12-30 17:22:01", vuln_detail_count: 0, vuln_attempt_count: 1, origin_id: nil, origin_type: nil>]>
>> framework.db.vulns.map(&:destroy)
=> [#<Mdm::Vuln id: 59, host_id: 320, service_id: nil, created_at: "2016-12-30 17:22:01", name: "MS08-067 Microsoft Server Service Relative Path St...", updated_at: "2016-12-30 17:22:01", info: "Exploited by exploit/windows/smb/ms08_067_netapi t...", exploited_at: "2016-12-30 17:22:01", vuln_detail_count: 0, vuln_attempt_count: 1, origin_id: nil, origin_type: nil>]
>> framework.db.vulns
=> #<ActiveRecord::Associations::CollectionProxy []>

Doing it this way will also remove all the associations with hosts, so you won't have dangling references in the join table like you would if you just deleted them in psql.


What's the best way to test if an RFID blocking wallet is effective? I was recently gifted a wallet that alleges to block RFID signals.  As I am sure you fine folks at Information Security are aware, this is to protect the information stored on my contactless bank card and company ID.  It seems to work some of the time...  I can't swipe into my office if my ID is in the wallet, but my bus pass will still scan.  It's suspect!

I would like a scientific and repeatable way to test the efficacy of RFID blocking abilities of my wallet.  I am looking for something beyond just testing the card at my business or on the bus, as this has been inconsistent.  I am not opposed to purchasing something, but I don't know where to look nor what is sufficient.

An RFID reader system consists of an antenna connected to the proper "reader", i.e. hardware and software to process the signal received from the antenna, and then to the computer.

A simple way to test RFID blocking would be to find the frequency used by your RFID tag, buy an appropriate RFID reader and antenna, put one card at a time into your wallet, move the wallet near the antenna and check if something pops out on the reader.

For a more scientific approach, you should measure the distances at which the cards within the wallet are scanned, and compare them with the distances at which the cards outside the wallet (or better, within a non-shielded wallet having the same thickness of the shielded one) are scanned. If the two distances are almost equal, there might be something wrong with the wallet shielding.

Note that different RFID tags may use different frequencies, so you may need two different reader/antenna pairs, one for the office ID, and the other for the bus pass. In fact, the most likely reason for which the bus pass is scanned, but the office ID is not, is that they use different frequencies, and that your wallet only shields one of the two frequencies.


What else can be done for better security against keylogging softwares? I've been hearing about keyloggers for the past two years, but never took them seriously. Now, as I've started net banking and managing social networking accounts, I'm very much concerned about safety.

After doing a bit of research, I came across these solutions:

Install good antivirus software.
In addition to an antivirus, use other malware detectors such Malwarebytes Anti-malware and Hitman-pro, as a single program might not be able to remove all malware.
Install Key Scrambler.
Use an on-screen keyboard at public places to prevent keylogging from hardware keyloggers.

Still, I don't feel 100% safe as there is always some risk involved, so please suggest what else can I do for better security or is what I'm doing enough?

This question is not duplicate as I want to cross-check the security I've taken and also to find out loop holes in it

Besides what you've done already to protect yourself you have a few additional options.

Use two factor authentication for your accounts.
Don't use public computers.
Use a live distro that you know is safe (you can sometimes reboot public machines and usb boot)

Adding these into your routine should make you pretty darned secure.


Why refresh CSRF token per form request? In many tutorials and guides I see that a CSRF token should be refreshed per request. My question is why do I have to do this? Isn't a single CSRF token per session much easier than generating one per request and keeping track of the ones requested?

Generating the token on a per-request basis doesn't seem to improve security beyond what a per-session token would already do. The only argument seems to be XSS protection, but this doesn't apply as when you have a XSS vulnerability the script could read out new tokens anyway.

What are the benefits of generating new tokens per request?

For the reasons already discussed, it is not necessary to generate a new token per request. It brings almost zero security advantage, and it costs you in terms of usability: with only one token valid at once, the user will not be able to navigate the webapp normally. For example if they hit the 'back' button and submit the form with new values, the submission will fail, and likely greet them with some hostile error message. If they try to open a resource in a second tab, they'll find the session randomly breaks in one or both tabs. It is usually not worth maiming your application's usability to satisfy this pointless requirement.

There is one place where it is worth issuing a new CSRF token, though: on principal-change inside a session. That is, primarily, at login. This is to prevent a session fixation attack leading to a CSRF attack possibility.

For example: attacker accesses the site and generates a new session. They take the session ID and inject it into a victim's browser (eg via writing cookie from a vulnerable neighbour domain, or using another vulnerability like jsessionid URLs), and also inject the CSRF token into a form in the victim's browser. They wait for the victim to log in with that form, and then use another form post to get the victim to perform an action with the still-live CSRF token.

To prevent this, invalidate the CSRF token and issue a new one in the places (like login) that you're already doing the same to the session ID to prevent session fixation attacks.


Are JWT's the way to go in my situation? I am working on a personal project for learning reasons, and have come to the point of authenticating and authorizing users. I would like to keep the project as stateless as possible, to make sure it can run on either 1 or 100 machines without much effort.

Here is my current plan of action for my users on this microservice architecture:

A user goes to an MVC application that serves a game. They are not logged in, so are redirected to a login page.
Upon successful login, the MVC app sets a JWT in the user's cookies. The JWT only contains the user id and their claims (user, admin, etc). The JWT logic is managed by IdentityServer4.
The user is logged in to the MVC app and can play a game. The user posts whatever move they want to make, and the ID of the game they are playing.
The MVC app uses the user id and claim in the JWT to retrieve the game being played from a Redis cache. The move the user posted is processed. The resulting game state is stored in Redis.
User receives the current game state from the server. Repeat from step 3.

My question: are JWT's a good use case for the above scenario? Or are there any downsides I may have missed?

JWTs are meant for when your login process is separated from your application, possibly even offered by another company. OpenID Connect is a single-sign on solution that uses JWTs.

However, in your situation, everything seems to be under your control. It currently runs on one server, but even if it needs to scale to 100 servers all those servers would have the same role and you would still control them.

I would advice using sessions. Sessions are well supported by all frameworks. They are easy to reason about, unlike JWTs which can fail in unexpected ways. Sessions are also easy to scale to 100 servers, so that is not an advantage unique to JWTs.


What is it common to only say "username or password is incorrect" in case of login errors? When logging in to a site with wrong user/password credentials, the displayed error is most generally a generic "username or password is incorrect". Looking into some PHP code that handles such login I found a MYSQL request constrained on both the user id and the password hash, making it indeed impossible to determine which of the strings was wrong if the request returns nothing.

Is there some security principle that explains why sites don't rather search for the username, and then match the password, and also why they don't make error messages more specific ("Username not known", "Incorrect password")?

Because you would be giving the attacker information.

If you say "The username is incorrect" or "The password is incorrect" then the attacker knows that one is correct. So, for example, once they guess a username, they can now focus on guessing the password. Rather than 2 unknowns, you have reduced it to just 1 unknown.

Also, for a site where the username is your email, you can determine if people have an account there. If I go to a site and insert your email address and it says "The username is incorrect", then you don't have an account. If it says "The password is incorrect" then I know you have an account there. Now imagine the site is some form of pornography site and you can start to see why this could be a bad approach in terms of what you are revealing to an attacker.


Extra secure layer to cURL calls I'm trying to figure out how to add an extra security layer to my WebApp cURL calls going to my API Engine.

I have a WebApp that sends data to an API engine I made.

My API will have access to the filesystem and therefore has to be quite secure so that there is no way someone can execute a script on the server.

The idea I had to further secure it si to have a salt on the WebApp and the same one on the API engine, the WebApp will send the cURL with an hashed timestamp and the real timestamp, plus any other request, example:

<?php

$hash = "1h2k3jklh";
$tstamp = time();
$hashed_tmstamp = md5($tstamp . $hash);

$data_to_send = [
    'time' => $tstamp,
    'auth' => $hashed_tmstamp,
    'foo'  => "bar"
];

On the API side I will check if auth is equal to the sent timestamp hashed with the API hash (which is the same as the WebApp one).

This way if the auth is copied and send with a new request will always fail as timestamp updates. I made a little graphical example to better understand.

There is a point, if "the man in the middle" can copy the auth can also copy time and can send requests always with the same time and auth.

So I'm wondering how to solve this part as on the API side I don't have a DB to check against "already used hash".

I'm in doubt I'm probably trying to reinvent the wheel and for sure this kind of stuff has already been checked/handled.

The only point is that I do want the "standard way" but I'm trying to add extra security so that a possible hacker does not know what's on the other side.

Any advice? Also, any better idea?

I would go the exact opposite way. Put the code on github, let people fork it, send pull requests, change the code. It evolves. If you made a critical mistake, someone will notice and inform you.

And use TLS. There's a great community behind it, there are bugs, but they are so obscure most of the time that we mere mortals don't need to be worried. Misconfiguration, programming errors, logic errors and code injections are way more prevalent and exploitable than TLS bugs.

If you want to implement replay protection, use an increasing nonce. This way the server will only need to save one value - the last used nonce, and the client will have to increment it before every request. It does not need to increment by one, it can be incremented by any value. In some API's I use, the nonce is the Epoch (plus milliseconds).

Quoting Antoine de Saint Exupéry:

  It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.

API's are meant to be simple. Don't add any mechanism if you don't need to. Adding components increases complexity, reduces performance, and it's one more thing you need to update from time to time. Keeping only essential parts reduces this burden.


What are the vulnerabilities of using a 256 bit encrypted PDF file over email? I often send confidential documents to others using encrypted PDF files (i.e. files with a user password, and typically with an owner password as well) to prevent both accidental forwards and snooping.  These are typically generated by LibreOffice's export PDF function. I understand that the PDF format for Acrobat 9.0 and higher uses an AES 256 cipher, and I assume that recent versions of LibreOffice generate the same, though I can't find details on this.

What are the possible vulnerabilities in such a method?  Particularly when using a public email service such as Gmail (where one assumes that the plaintext contents of all emails are already with the government, and god knows who else), and sending the files as attachments.

Since it is protected by a user password, it is vulnerable to brute force/dictionary attacks unless you choose a really long and complex password. It does not matter whether your are using AES 128 or 256 if your password is the weakest link. Someone who intercepted your email may try to brute force the password to read your PDF file.

If you want your document to be more secure, Adobe supports the use of PKI based encryption and digital signatures to mitigate the issue of using weak passwords. However, this requires the use of certificates.  While encrypting, the publisher’s computer randomly generates a symmetric key (up to AES256), and encrypts that key to each recipient’s asymmetric public key to include in the document with the symmetric key encrypted content.  In return, the recipient computer uses their own private key to decrypt the symmetric key, and then decrypt the document.

The randomly generated key should have a much higher entropy than your password to mitigate brute force attempts.


Client's Personally Identifiable Information (PII) in the Cloud Is it safe to put a client's personally identifiable information on Microsoft's Office-365, or another Cloud provider storage?

Cloud services such as Office 365 can be far safer than using your own or a suppliers data centre facilities.

So yes, you can of course put client data on cloud services. But will they be happy? Hmm. And will you be meeting their regulatory requirements?

Well only you/they can answer that.

Look for security certifications related to the regulatory environment your client has to work in. Get buy in from the Information Owners by carefully explaining the benefits, risks and mitigations. Look for other similar organisations that may have followed the same journey. Check with relevant government agencies on their views.

BTW, Office 365 is particularly good at this. Their certifications are second to none and they have world class security processes. Microsoft really understand government and enterprise security requirements.


Should I worry about GitHub using IP addresses that are described as having an unknown host? Today, I got a message while doing a git push, saying

  Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts.

It seems as if it's consistent with what GitHub uses, based on What IP addresses does GitHub use that I should whitelist? though I haven't tried looking up how CIDR notation works.

However, if I try looking up 192.30.253.112 at http://ip-lookup.net/index.php , the "Host" information just has a literal question mark. It's only if I open up the "IP owner info (Whois)" section that I see it's associated with GitHub.

Is this unusual behaviour I should worry about from a security perspective?

No, you should not be worried, but you should be checking GitHub's server fingerprint rather then relying on IP addresses.

With git command you do it only on first (ever) connection. If the public key (corresponding to the fingerprint) is in known_hosts file, subsequent connections to github.com cause only warning if the domain got resolved to a new IP address.
It is equivalent of using ssh command with CheckHostIP=no option.

You should be cautious (and check with a trusted source) if a new fingerprint was displayed on your screen for confirmation.

Regarding ip-lookup.net results:

ip-lookup.net figures out what DNS name is associated with an IP address using a reverse DNS.

In case of 192.30.253.112 it queries the address 112.253.30.192.in-addr.arpa which does not have a corresponding forward DNS record.

It seems like a misconfiguration or not strictly enforced-one on GitHub side, however the verification mechanism would not be viable in this scenario.

In case of Git (SSH) client connecting to github.com domain, if you assumed a compromised DNS server redirecting to a rogue IP, the verification of the destination address using reverse DNS lookup would be susceptible to the same attack (compromised DNS server would confirm the address to belong to github.com owner with reverse DNS).

Regardless of IP ownership verification, checking the server fingerprint assures no server impersonation or MitM attack is taking place.


Disable insecure/dangerous PHP functions Typically my job description limits me to code-review of web applications. More recently I've been asked to assist with some server-side PHP optimization where, although I am familiar with it, I lack experience.

I have come across a configuration setting called:

disable_functions

Are there any implications I should be aware of by utilizing this setting (other than the obvious function x() will be disabled and any application that uses function x() will then not work)?

If it is something I should be taking advantage of, I can come up with a list of many functions which could be dangerous, however some may be necessary regardless. Does anyone have a list, or have some suggestions to add as far as which functions should be disabled and why in case I miss/overlook some?

Any insight would be appreciated as although I know plenty of unsafe functions, my server configuration experience is lacking.

EDIT: To clear up any question as to whether this is on or off topic, I was asked to assist with OPTIMIZING the PHP enviroment for increased SECURITY, but I'm asking specifically about the aforementioned configuration setting. :)

There are a number of things that must be understood here:

List of dangerous PHP functions is located here: http://php.net/manual . Seriously, almost any PHP function can be dangerous given the right context. strlen and like are probably safe, but any function that talks to outside world can brings surprises if the rest of the code is not safe.
If you want to secure the site, the security should be throughout the code, just disabling some function here and there is not going to work, only going to blind you and lead to sloppy coding.
There are capabilities in PHP that can assist you in writing more secure code, however they won't make secure code from insecure one. Look for open_basedir and allow_url_fopen as an example.
You can use disable_functions to prohibit some actions that you consider dangerous, however only certain classes of actions can be inhibited this way. For example, you can disable exec,shell_exec,popen,passthru,proc_open,system,pcntl_exec and this probably will prevent running external programs from your code - but most of the things done by these programs can be done by PHP means too. And trying to avoid things like "writing a file" probably won't work - you should do it via OS permissions, not via PHP. So, define what exactly do you want to prohibit first and then see if it's possible - while keeping in mind it may be impossible.
Read security chapter in the PHP manual. Read some PHP security books. Security is not done by just setting security=On in php.ini, unfortunately.


Tails like OS for Smartphones In Jacob Applebaum's latest talk at the 30c3 conference, he advised all journalists to use Tails or similar OS for their laptops.

Does anyone know of a similar OS or functionality for Smartphones?

I know some businesses who have journalists who will be frequently travelling to Sochi, Russia, for the Winter Olympics. They had incidents where journalists was held at border control and cell phones were confiscated.

In your specific case, there's a different answer: never carry sensitive data through a border.

Border agents almost always have enormously wide legal powers to search devices on their own, and are very happy to utilise them when asked to by intelligence agencies.

In fact, if you expect to be subject to a targeted attack by an intelligence agency, I would go further and advise you to not even carry an empty smartphone through a border, because of the risk that it is taken away, compromised, and returned to you.


someone claims to have created such a malware, can he be true? These are not my lines they are by someone else on the internet. I also want to know is that malware that unique? How will it work in GPU and is there a way to sandbox such application?

"HERE GOES THE MALWARE........

  1 More than 80% part runs only on GPU.......

so its useless to run that under sandbox

  2 Around 90% of the virus is always in GPU memory......

To make the matter worse, you won't be able to debug that piece of code.....it does not use CUDA.....

  3 The malware mutates in runtime, and that too, on GPU itself......CPU is not involved...

signature matching won't work....

  4 The malware does not run as a process......

  5 The malware rearranges its pieces in runtime......and becomes a full blown malware from an innocent piece of code.....

  6 Different pieces of malware execute at totally different corners of system.......API Interception is not going to help.......not even at kernel level
  SpyShelter will fail

  7 The malware uses MCR techniques......your security suite gonna raise a hell lot of false positives..... "

and how can we access GPU memory?

Malware can run mostly on GPUs to evade the detection by traditional approaches. One such proof-of-concept is provided in "GPU-assisted Malware". The authors demonstrate how to use General purpose computing on GPUs (GPGPU) to develop a malware which is self-unpacking and with run-time polymorphism.


Can change management for PCI compliance be accomplished via simple emails? Item 6.4.5 of PCI DSS requires the following:

  6.4.5 Change control procedures for the implementation of security patches and software modifications. Procedures must include the following:

  6.4.5.1 Documentation of impact. 6.4.5.2 Documented change approval
  by authorized parties.

  6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system.

  6.4.5.4 Back-out procedures.

We could use full-blown ITIL-compatible software for this. But it seems overkill for a small company (less than 10 employees). We would like to satisfy that requirement in the simplest possible manner.

For example, suppose all these items are managed via a simple email. Whenever a change is necessary, a request for change (RfC) should be sent to a specific email address with all the necessary information (justification, back-out procedures etc). Someone in the role of change manager would manage that email box and approve or reject all incoming RfCs and take the necessary actions, such as notify the sysadmin or schedule the change.

Is it acceptable in terms of PCI compliance?

We used email for change management for a while, and as long as we had a record of it, our auditor was satisfied. However, email is seriously lacking in features and not well-suited to the task.  It's difficult to track, and hanging onto a string of emails and then providing them at audit time is a nightmare.

However, it's easier with other forms of software designed for tracking tickets. You can find decent, free CRM or helpdesk ticket software that can be used to track change tickets just as easily as a full blown ITIL package, but with less features.  The critical components are that you can track what is changing, who authorized the change, and the steps taken. This can be achieved through ticketing software that has the following features:

Allows you to record basic incident/call details
Allows you to assign tickets to people or groups
Allows you to enter notes
Allows easy reporting, or at least access to the database so you can write your own reports.
Bonus if it allows you to attach files and does so in a secure way.  This allows you to attach code review documents, threat models, or other artifacts associated with the change.
Bonus if it has workflow modules to to allow for approval processes (although those can be defined and just done manually)

The more detailed and specific the tracking/logs, the better.


Should I backup a GPG key used for Authentication? Regarding backups (escrows) of GPG (OpenPGP compliant) keys, I seem to understand that (E)ncryption keys need to be backed up, to prevent data loss, and that (S)igning keys should not be backed up, because it is crucial that the owner is absolutely certain that they are the only one who can use the signing key at any moment.
Is there a good protocol regarding backing up (A)uthentication keys? I could imagine no backups because only you want to be able to authenticate yourself, but on the other hand if you lose your authentication key and you need to ssh into a VPS with it, you're out of luck (but with a server at home you could just wait to get physical access to replace the public ssh key).
So does it depend on your situation? I'm asking this question because I am using a Master (C) key with separate Encryption, Signing, and Authentication subkeys. I could conceive of making a Master (CA) key, and then put two public authentication keys on your VPS-- one tied to your (CA) Master key and the other to your (A) Subkey-- so in case you lose your (A) subkey, you can dig up your basement, get your (CA) Master key, and ssh into the VPS to remove the old (A) Subkey public key and add a new (A) Subkey public key.
Thanks in advance.

In general, you should back up data you think is valuable and don't want to lose, especially data that you cannot easily recreate.  Whether that applies in this case, since you can create a new signing key (assuming you have a revocation certificate for the old one) is up to you.  There is no single right answer for this case.
Note that backups need not be done insecurely.  I use Tarsnap for backups, which is a service that implements client-side encryption and deduplication, so all the server sees is just chunks of encrypted data.  Therefore, I feel comfortable backing up things like secret keys since only I can get at the data.


HTTPS green bar loads then goes away I have properly configured SSL, and it loads pages when you put HTTPS. My problem is that when the page is loading. The bar will turn green, once the page is fully loaded. The green bar goes away. The URL stays as HTTPS. I have checked all items on the page for any NON-HTTPS items and I couldn't find any.

The site URL is: www.jlucina.com.

Why does the bar turn green then go away after the page fully loads?

UPDATE: It seems to work on Chrome for the most part. If I continue shopping and add another item it breaks. So weird.

I have confirmed that it is a mixed content issue because I used a plugin that disables all images on the site and it stays green when I do that. I can't find which image is causing the issue.

The problem is that you sometimes refer to https resources by https://jlucina.com; for example one image is located at: https://jlucina.com/sites/default/files/pin.png

Now your web site is setup that https://jlucina.com 301 redirects to http://www.jlucina.com, so despite the https in the source the resource is sent unencrypted over the network, so you get the partially encrypted warning in firefox.  So if you try going to https://jlucina.com/sites/default/files/pin.png you end up at http://www.jlucina.com/sites/default/files/pin.png which is your mystery unencrypted media resource.

You can use curl to see the http response headers:

$ curl -I https://jlucina.com/sites/default/files/pin.png
HTTP/1.1 301 Moved Permanently
Date: Thu, 23 Aug 2012 10:15:05 GMT
Server: Apache
Location: http://www.jlucina.com/sites/default/files/pin.png
Cache-Control: max-age=1209600
Expires: Thu, 06 Sep 2012 10:15:05 GMT
Connection: close
Content-Type: text/html; charset=iso-8859-1

I got to the bottom of this by using a tool like firefox's web console, seeing what's sent over the network on port 80 (facebook.png, twitter.png, pin.png) and then going back to the page, seeing how/where they were referenced and eventually figuring out https://jlucina.com differed from other https links and used curl to check the headers of the request.


What is the application of SHA384withRSAEncryption? I am trying to understand the application of SHA384withRSAEncryption. SHA-384 is a message digest algorithm and RSA is used for public key cryptography (secure communication).

RSA involves a public private key pair, so there are 2 ends of communication. One who encrypts the message using the public key and the other one decrypting it.

What is the use of both SHA384 and RSA Encryption together?

Now, how is SHA384withRSAEncryption used for storing data in a Database securely?

Is there an application of SHA384withRSAEncryption in "Data in Rest" Applications?

Thanks.

This corresponds to an RSA PKCS#1 signature with SHA384 hash. This means that the data is hashed using SHA384, and that hash is signed with the RSA private key from a PKCS#1 certificate.

In terms of securing data in a database, this would be pretty unusual. However, it could be used to ensure that data entered into the database was generated by the owner of the RSA private key. In the case of an attacker that has access to the database and nothing else, this prevents them from forging records.

The same sort of idea fits in with long term data storage. It proves that the data was not tampered with after being signed.