Meltdown and Spectre Attacks Canonical question regarding the 2018 Jan. disclosed Meltdown and Spectre Attacks. Other identical or significantly similar questions should be closed as a duplicate of this one.

Main concerns

What is speculative execution and what does it do?
What is the difference between Meltdown and Spectre?

How does Meltdown work?
How does Spectre work?

How do I protect myself?
Is the KPTI/KAISER patch sufficient to protect my computer?
The patch is claimed to induce a loss of performance; is it true? How much does this mean?
Can/should I disable the new patch if I'm worried about performance losses? What are the risks?
Which platforms and CPUs are vulnerable?
I'm running a virtual machine/containers; to what extent am I vulnerable?
Can I detect a Meltdown/Spectre attack on my computer?
Are these attacks remote code execution vulnerabilities?
Do I need to patch my software/website?
Can I be affected while visiting a website?
Can you explain this with an image?

References:

Meltdown research paper
Spectre research paper
CERT Notice
CERT Meltdown and Spectre Side-Channel Vulnerability Guidance

This answer is an attempt at addressing simply the main concerns. The details here might not be exemplary accurate, or complete. I'll try to link to more detailed explanations when possible.

What is speculative execution and what does it do?

Speculative execution is a feature of modern processors that comes as an optimisation. To allow for the parallel treatment of instructions into the processor pipeline, instructions can be processed ahead of time by using techniques such as branch prediction, value prediction or memory prefetch. Instructions can then be executed out-of-order.

This is a way to gain time by predicting correctly what happens next, instead of keeping the processor idle.  When the prediction fails, the instructions are rolled back.

What is the difference between Meltdown and Spectre?

Meltdown exploits are globally easier to implement than Spectre.

Meltdown takes advantage of memory reads in out-of-order instructions, Spectre acts on the branch prediction mechanism.

Spectre allows for cross/intra process memory disclosure, Meltdown allows disclosure of kernel memory to the user-space processes (normally not accessible).

Meltdown has a known software mitigation.

Both rely on a cache side-channel attack, which is a measure of timing differences when accessing certain blocks of memory to deduce the information otherwise unknown.

How does Meltdown work?

In a nutshell, Meltdown works by asking the processor to load memory the user-space program should not have access to. Memory is read in an out-of-order fashion and put into cache. Using a side-channel attack (execution time measurement) on the cache, it is possible to infer the value of that memory location.

How does Spectre work?

Spectre works on a different level and does not allow access to kernel-space data from user-space. In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result (if -> true), that results in asking for an out-of-bound memory access that the victim process would not normally have requested, resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way, memory belonging to the victim process is leaked to the malicious process.

How do I protect myself?

Update your operating system and/or hypervisor.

The main operating system distributors already release patches to implement the KPTI/KAISER behaviour. This is a means to reduce the attack surface by removing the user memory mapping of the kernel that are not strictly necessary for the processor to function.

Microcode (firmware) updates are likely to be release at some point.

Are the KPTI/KAISER patch sufficient to protect my computer?

No. And it only covers Meltdown.

The problem lies in the architecture design of the processors. To solve the problems completely (or even partially in the case of Spectre), at least a firmware update will be necessary. It is also possible that processors will have to be replaced by more recent models without this design flaw.

The patch is claimed to induce a loss of performance, is it true? How much does this mean?

Yes, but the loss incurred is dependent of the software workflow. Claims are it could range from 5% to 30% loss, depending on how system call reliant your software is. Benchmarks with high kernel-to-user space transitions, such as databases, have been reported to be the most affected.

This is still undergoing investigations, preliminary reports have been made (see links).
However, since impacts vary by application, you should test the performance impact in your environment rather than relying on generic benchmarks.

Preliminary results (independent??):

Phoronix 1
Phoronix 2
RedHat

Official announcements:

Microsoft announcement
Intel announcement
Apple

Can I/Should I disable the new patch if I worry about performance losses? What are the risks?

No. You can, but it's definitely not recommended.

First of all, if you're managing data from others, you would make your clients vulnerable to data theft.

Then, the performance losses still have to be properly evaluated and are highly dependent on your specific workflow. It's not a straight down 30% in performances.

Should you disable KPTI, you run the risk of having your confidential data leaked.

Which platforms and which CPU are vulnerable?

Most of the Intel CPU are vulnerable to both attacks. AMD CPU seems to be only affected by Spectre. Some ARM Cortex processors are affected, while all other ARM processors are not. PowerPC processors in the POWER 7, POWER 8, and POWER 9 families are affected, and others may be.

(see links for details).

I am running a Virtual Machine/Containers, to what extent am I vulnerable?

As per Steffen Ullrich's answer

Meltdown attacks do not cross VMs, only leaks kernel memory to local processes.
Spectre can work across VMs.

Also, from Steffen again, Meltdown and Spectre works with containers, as containers relies on the host kernel.

Can I detect Meltdown/Spectre attack on my computer?

It's very difficult, if even possible to.

Meltdown and Spectre both uses a designed property of the CPU that is triggered by innocuous programs all the time, making malicious programs difficult to tell apart from benign programs.

Are these attacks a remote code execution vulnerability?

No they aren't.

To be able to apply this attack, the attacker need to be able to execute code on the target host. Note however that if these are combined with other attack vectors, for example file upload or cross-site-scripting exploits, then there is a possibility of executing them remotely.

Do I need to patch my software/website?

In an ideal world, no.

In reality, some browser vendors already have implemented decrease in time accuracy measurements to mitigate the side-channel attacks. The KPTI should already provide a fair enough fix for programs using native system calls.

Can I be affected while visiting a website?

Yes, there's already a proof of concept of a Javascript exploit for Spectre (only).

Can you explain this with an image?

No, but Randall Munroe can:

[Source XKCD : https://xkcd.com/1938/]


Security code review For an application that is hosted by a legacy server version which cannot be patched,  could a periodic security centric application code review prevent potential exploitable vulnerabilities to the application? Can an application security code review replace non patchable servers?
Let's say codes related to sensitive data in an application.
A code review cannot replace patching or address all exploits but it could mitigate some risks that is caused by poor coding practices.  If a legacy server is non patchable,  wouldn't a security centric code review address at least some exploits that stem from poor coding practices?

No

Security code review is a good idea, but it does not protect against unpatched software. For example, if your server uses Nginx, it could have been vulnerable in the past to CVE-2013-2028. It doesn't matter what application code is present, because the vulnerability is in the web server itself. The best way to fix this vulnerability is to patch the server. There may be other ways to mitigate the vulnerability, but patching is almost always the best solution.


Two-factor port-knocking via SMS (TXT) It seems to me that a useful alternative or supplement to traditional port-knocking, fwknop, etc, for a system requiring only occasional access, would be to:

Set up a one-time pad of keys, and a pre-shared key.
Store a copy of that pad and that pre-shared key on the server to be protected, and keep another copy of each to hand.
Keep all copies of those keys as private as practicable (this should go without saying!).
Arrange for the server to be able to receive SMS (text) messages from a whitelist of telephone numbers, discarding all others.
Rate-limit incoming SMSes from each whitelisted number by adding a progressively larger delay before processing.
Have the server process the SMSes accordingly:

If decrypting the contents of the SMS with the current key from the one-time pad yields a message in a specified format, containing a port number, a protocol, and the pre-shared key, then:

Delete the current key from the one-time pad, and make the next key the current key.
Send a reply SMS, "OK"; and
Permit a new inbound connection to the server to be made on that port under that protocol until either such a connection has been made or a pre-configured timeout (e.g. 5 minutes) has elapsed.

Else:

Do nothing.

I have two questions:

Does such a system yet exist, preferably in a FOSS form?
Other than, perhaps, unsuitability for use-cases requiring large quantities of inbound connections, what are the flaws in such a system?

I'm not aware of anything exactly like what you're looking for.  Some close misses:

SMSterm provides a terminal-over-SMS, but with 'minimal authentication'.  Free, but looks comatose (last updated 2002, no home page)
Ales-U provides commands over SMTP with some mumbling about 'secure method'. Not free, and swinging a big Patent stick, not the most attractive mating behavior.

I haven't played with either, BTW, that's just a little Google and the like.

I will suggest the following thoughts as regards your question #2:

Think SMTP.  Any SMS-space solution going to servers is probably going to involve an SMS-to-SMTP gateway, and a solution designed for SMTP will probably work for you as well.

Size matters.  SMS messages are short, so if you're signing or encrypting your commands, it's going to take several messages to get them to the server.  The server will need to reconstruct the entire message.  This is a disadvantage.

Swimming upstream.  Most SMS security-related messages go server-to-client, not client-to-server.  In essence, that's because it's harder for someone to intercept messages sent to your phone than it is for them to forge messages from your phone.  So the key-based encryption you suggest is necessary, but see my previous point about the problems it causes.  And you'll find less solutions because everyone else is swimming the other way.

Port knocking is rare.  If you're looking for a solution that does port knocking, you're fishing for a pretty rare species.  If you look for a solution that permits authenticated remote commands, you might have better luck.

Less chatter is better.  One advantage of your scheme is that it doesn't require back-and-forth, it's a one-way request that is then followed up on with a wider bandwidth connection.

Authentication is the key.  Once you have a way to send authenticated commands to a server and have them validated and acted upon, the question of what transport you use becomes an add-on.  Solve that problem first, and then you can tack it onto whatever transport (SMS, SMTP, HTTP POST, ICMP ping, Avian carrier) you want to.

Public keys are better.  If you're going to try to send authenticated messages, don't screw around with "a one-time pad of keys, and a pre-shared key".  Just use certificates to encrypt and authenticate.  One-time pads are great except when they're not practical, which is usually.

HTH!


Is it possible to spy on Tor browser within local network? Imagine yourself connecting your personal device to your workplace wi-fi network.

Can managers, network administrators, or some other person/potential attacker see my browser's activity if I'm using Tor browser or run all my traffic through the Tor network?

This answer is based on the assumption that the adversary is able to monitor the traffic to/from your device, but has not compromised your device.

In that case, the adversary may be able to see that you are using Tor, because they'll see connections from your device to nodes on the Tor network.  But, that person won't be able to determine which sites on the Tor network you or visiting, and won't be able to see the information that you are exchanging with those sites.

See https://www.csoonline.com/article/3287653/what-is-the-tor-browser-how-it-works-and-how-it-can-help-you-protect-your-identity-online.html for more info.


Top banks using TLS 1.0 Am I vulnerable if my bank uses TLS 1.0? Is it easy for somebody to do a MITM attack? Should I just access their online banking at home where I assume it is safer to do so?

If your bank uses TLS 1.0 with an SSLv3 decoding function, it is vulnerable to a MitM attack using the POODLE vulnerability.

If they are vulnerable, you are no safer accessing online banking from any particular location, the vulnerability is in the bank's TLS implementation.

You can check Poodle Scan to see if their server is vulnerable.


Difference between private key exposure and tampering in mutual authentication Consider a remote and local system doing mutual authentication either by TLS through server/client certificates or similarly wireguard.
What are the differences when the private keys (in particular the one for the remote system/server) are
a) exposed in clear to an attacker
or
b) the attacker can actively change those
Note that both sides might not know the other ones public key in advance. E.g. the attacker has the ability to tamper with the creation of the server keys and sends a valid but evil public key to the client.

The most obvious difference between them is that in Scenario A, the attacker can carry out Man in the Middle attacks with very little chances of getting caught, since the key pairs remain unchanged and there is almost nothing out of the normal for either parties to notice.
In Scenario B, the attacker changes the key pair. Although, in some cases, the attacker can still carry out a successful Man in the Middle attack, this has a significantly higher chance of getting caught since any of the parties can notice the sudden change of the public/private keys if they have already communicated in the past with uncompromised keys (specially if the client implements something like public key/certificate pinning).


What can an attacker do if he knew my database credentials? If an attacker knows my database username and password, what can he possibly do if he doesn't have access to my server? Let's say my database is using Microsoft SQL Server. Is there a way he can use those credentials to manipulate my database?

Assuming that

You're 100% sure that your database server only accepts local connections.
You're 100% sure that the attacker doesn't have access to the local environment from which connections are allowed.
You're 100% sure that the application that uses the database is otherwise secure.
You're 100% sure that those credentials aren't used for anything else directly or indirectly related to the system.

Then, there's no problem in them being exposed.

Of course, as you can see, those are very big assumptions. If you're willing to take the bet, then go ahead and allow the credentials to be exposed. If not (I wouldn't), then work as best as you can on your security, and keep those credentials secret.


What is the importance of fuzzing? I’ve heard a lot about fuzzing website parameters with programs like OWASP-zap but what is the importance of it? A simple active scan finds vulnerabilities in a website such as XSS. So why do we need the fuzzer?

If someone could shed some light on this that would be amazing! I’m new to website hacking.

Fuzzing is not a technique to find known vulnerabilities. That is the job of an active security scanner like you said. Instead, a fuzzer is designed to assist with finding new bugs that are not yet known. They do this by constructing random or pseudorandom input and feeding it to the target. Good fuzzers will be format-aware and will feed it input that appears slightly corrupt, but is otherwise valid. When this is done for long enough, new and unknown bugs will often start to surface. These bugs can be analyzed and sometimes even turned into a working exploit.


Is there a risk with making my Device ID public? When making a mobile app with ads, I am required to register my test phones as test devices by providing the Device ID.  These Device IDs are unique to an individual phone.  Is there any risk with publishing my app with the Device ID?  Or should I remove my Device ID before publishing?

Is there a risk with making my phone's Device ID public?  If so, what is it?

Added Details:

Google's AdMob requires you to add your test device ID to your code, in order to prevent false advertisement. They suggest this code be removed before publication, but so not say why. It is an inconvenience to remove it, and prevents testing on the live build. Several sources say it does not need to be removed, but Google's documentation says it does. I am trying to determine why they want this code removed. My best guess is that it may be a security risk to publicize your devices unique identifier.

The risk is privacy (the reason why Android created the advertiser ID instead) - your test device is now forever attributed to you and/or your company.

Imagine a competitor getting your app, reading the code, and seeing this ID. Then they create an app that includes code looking for this device ID, hoping you will download and use the app (and you would because they are a competitor).

Now your competitor can uniquely identify your device and gain access to whatever you enable access to and attribute it to you. What might they discover? What insights into your next apps might they glean?

In the end, all it is an ID. But the danger is positive attribution.


What are the risks from letting users share their own calendars? I've worked for a variety of technologies companies.  In working for startups I've noticed a wide variety of opinions about whether sharing calendars is a security risk.  I can imagine that it would be bad if someone learned that sales was having a meeting with Company X.  But the risk would be manageable by the individual users and the same info is available through other means.

The downsides of hiding calendars are easy for me to "imagine".  Hiding calendar information prevents somebody from sharing it with their spouse or other person that is considered trustable.  For me, the biggest inconvenience is that I can't see all of my calendars in one place.  It also means I have to go into multiple accounts to be able to update calendar events instead of doing it from one place.

Are there other expected risks from calendar sharing?
Are the risks from calendar sharing widely considered to be serious enough to cause the inconvenience that is inevitable?

But the risk would be manageable by the individual users ...

"Would be" is very different from "will be". Users are also capable of choosing strong and unique passwords but they rarely do because it is inconvenient. Similarly it is likely that users will not properly take care of the risks with sharing calendars because it is too much effort.

  ... and the same info is available through other means.

It is very different if some competitor has fast access to lots of sensitive information about the activity of a company in one place instead of taking the time to dig through lots of information and correlate these. And, if the information is also easily available through other means then you might be doing something wrong. Restricting access to calendars is not the only thing one should do to protect such information.

  Hiding calendar information prevents somebody from sharing it with their spouse or other person that is considered trustable.

Hiding calendar information is different from hiding full calendars. It is possible to forward select entries to others. Some systems also allow to share just information about busy vs. free without sharing the details of the events.

  Are the risks from calendar sharing widely considered to be serious enough to cause the inconvenience that is inevitable?

Yes. At least in larger companies it is common that full access is restricted to anybody working in the company and maybe even limit access inside the company.


How could SSL certificate affect the symmetric key length? This article in GoDaddy support knowledge base says

  All of our SSL certificates support high-grade 256-bit encryption

How would they not support it?

The SSL certificate contains keys for asymmetric encryption and is there to

prove that the server is exactly what it claims and
allow the server and the client choose the same symmetric encryption key which is then used for the rest of the connection

It looks like nothing prevents the client and the server from negotiating some MagicAES with 10240-bit key (or 90th level DES with 4096-bit key) and use it for the life of the connection.

How would the SSL certificate internals limit the symmetric key length?

It is, to put it bluntly, a steaming pile of bullshit.

The SSL certificate has no bearing on which SSL or TLS cipher suites are negotiated. The two parts of the protocol are separate.


Removable FireWire port blocks There are other questions here enquiring about disabling FireWire ports reversibly via software or irreversibly via hardware (e.g. epoxy/desoldering).

I would like to know if there are any reversible hardware protection methods available; for instance, something similar to these USB port (b)locks: 1 2.

At a cleared defense contractor we actually looked at building these and it is not that hard of an issue. Not foolproof, but fairly reasonable. It was a cyber-security research program and it did not get funding, but I always thought it would be a great commercial idea. At the time (a couple of years ago), to my knowledge, no one was doing this for firewire. Not many for USB, but it looks like the USB market has changed.


What is the best way to limit sending verification codes to mobile numbers which can be changed? I'm developing a web based service in which users must validate their mobile phone (using a code sent to their mobile number via SMS) and email (using a verification link). Currently I use time limiting method to prevent sending more than one SMS or email in a specified period. But both of these security factors can be changed by users whenever they want and by changing them, their time limit will be resetted too.

A hacker can automate this process (since I don't want to use captcha in user's panel) and infliction us to send a lot of SMSs. How can I prevent it? One idea is that to lock users from changing these information too fast but I don't know if it is the best way or not because users might fill these informations wrongly and want to change them instantly.

It seems you're rate-limiting per phone number/e-mail address.

You could apply the rate-limit per user instead, and it would prevent the kind of abuse you're worried about.

You should tweak the limit to account for that. For instance two SMS per user per day would allow for one mistake to be made. If the user makes a second mistake she'll have to wait till next day to fix it.


Is there a difference that financial instutitions can see between a VPN and a local IP address? Let's say for instance I want to sign up for Revolute/Paypal/Transferwise, etc.

However I don't live in the country, although I do have a VPN that has an IP in that country.

Question is, does the page request somehow pass along to a banking institution that I am on a VPN, and not on the local IP network?

If the only criteria is your IP (using GeoIP for example), you are safe and the server will not be able to determine that you are using a VPN. NAT is probably used so the VPN gateway replaces your VPN-internal IP with its own, which is what any server you contact will see.

However, if they really try, they could lookup that IP and maybe find out, that this is a server, instead of some IP dynamically assigned to private households. But it's entirely possible that you belong to a company in that country and use this server as a proxy/VPN-Gateway.

In conclusion, if they don't try really hard, I couldn't think of a simple way to reliably determine whether or not you are using a VPN. Thinking twice, using a VPN is not even enough for them. They would want to know, whether you actually are in this country which is even more difficult.


Finding the firewall port that filters internet traffic In my office, we have static IP's for each system. All the internet traffic from our systems are filtered with a Fortiguard firewall. Is it the default gateway where the firewall is installed? How can I find the open ports that are allowed to connect to the internet?  I to ping websites but it always returns "request timed out". I guess the firewall has something to do with it.

I have admin rights on my system and nmap and Wireshark installed.

My static IP     - 10.6.154.202

Default Gateway  - 10.6.144.1

Subnet Mask      - 255.255.240.0

By using the ping command, you are using a protocol and port that is non-standard for Web traffic. Pings are commonly blocked at firewalls.

If you can browse to websites, then you have port 80 (http) open and likely port 443 (https).

What you need is a program that can do the same thing as 'ping' but not using ICMP and using specific ports that you want to test. Nmap can do that as can many other tools. The process you want to do is called 'firewalking' (walking the firewall ports to see what is allowed).

But I have to say that it sounds like you need a little more knowledge on the basics of networking before firewalking will make sense. It also sounds like you have no good reason to know what ports are allowed and that you are trying to bypass the security of your company's network.

Maybe if you explained why you need to know the ports that are open, we can be more specific...


Are the SSL Digital Security Certificates based on Kerberos Network Security Protocol I just want to know if digital certificates use the kerberos session key algorithm.

No they are very different in the most basic sense.  Kerberos uses tokens for authentication built using a symmetric cipher.  SSL allows you to pass secret data between two machines and uses asymmetric cryptography for authentication.  It is possible to use kerberos and ssl together,  but it is less common.


What is the main difference between Wireshark and Network Miner? Is there an example in terms of forensics where Wireshark may be the only method to extract the data for in your .pcap file?

NetworkMiner is a great tool for automatic extraction of files from a packet capture. It's also surprisingly useful and good at extracting messages such as emails. What it isn't any good for is manual packet analysis, which is where Wireshark shines.

See here.

Within that link, it's a short post from reddit with someone who asked a similar question. I feel that was the best answer on there for you, and I have some personal knowledge to include.

Wireshark is a very good tool to analyse packets between your network and a specified network that you're monitoring. It's especially powerful if you know how to identify network protocols such as TCP, DNS, SFTP etc. It's filtering system is also very useful, and as stated in the above quote, NetworkMiner is especially good for message extraction and I also believe it is good for MITM network monitoring.


Egress filtering on an office network? With an office network most companies will use ingress filtering to add a level of security, however few take advantage of egress filtering to protect their networks. The use of egress filtering will of course cause issues for some users as it requires policy changes for all new software that is deployed but does the protection it offers for instance against botnets outweigh the cost of extra management for most organisations?

What are the pros and the cons of Egress filtering? Specifically when referring to the network of a medium sized software development business.

From Area 51 Proposal Question

PRO: strict control over everything that moves out of your network (and by extension, much of what moves in it).
CON: Your users feel the control. Considering that you're a development business, your users are pretty much technical, and would probably resent it.
CON: Considering that you're a development business, and your users pretty much technical, they are likely to legitimately install new programs, in the course of their work (how long was it till skype was allowed through?), and it will be difficult to keep track and update the filters.
PRO: your users are in effect restricted in what they can install :)
CON: Don't even consider this for each machine, while not completely pointless, its much easier to bypass.
PRO: As you mentioned, it can block certain usages of botnets and other unwitting malware.
PRO: It can hypothetically assist (as a first step) in data leakage prevention.

UBER-CON: It is trivial to bypass in most malicious scenarios by simply tunnelling over any ports/protocols you DO have open (this includes many types of adaptive worms), whereas in the non-malicious cases it's a real **tch to deal with.

Bottom Line: Egress filtering is a very good tool to give you control, but not very good for security.


How much detail to publicise when a software vendor patches and issues an advisory? I am interested to hear what the community's thoughts are on detail provided by a software vendor along with a fix and a security advisory.

For example, let's say that some kind of severe vulnerability was privately brought to a vendor's attention. It was fixed it, a new release made, patches and published a security advisory published.

In this security advisory, how much information would you expect the vendor to disclose?

In my mind two things need to be weighed up:

Going into too much detail and giving a scent to the black hat world as to the existence of the flaw and how to find it, who may react quicker than the vendor's customers
Providing detail in the name of transparency and customers wanting to know exactly how severe this thing is

Is #1 a valid concern, or is it a case of...

The "normal" way of doing things is:

Whoever finds out the flaw contacts the vendor.
Vendor makes the patch, and publishes it, pushing it to customers with a vague but scary description ("fixes a flaw allowing for remote code execution").
A few weeks later, details are published. If all went well, the initial discoverer makes the publication, in full agreement with the vendor, so that due credits are attributed; and the vendor adds a link to the publication details in his own documentation.

For instance, this is what happened with the SSL-related flaw dubbed "CRIME": browser vendors were warned several weeks in advance, and pushed patches. Occasionally, the vague description can be enough for some people to guess what is happening a few days before actual publication. The dance is a matter of delicacy, especially with opensource software, because patch source code is often quite revealing about the exact nature of the issue.

One psychological side of the issue is that vulnerability hunters are a tough crowd who may react, sometimes, in somewhat heated emotional ways, if they feel that vendors don't react appropriately or fast enough. Software vendors would usually prefer to keep flaws secret, but if they have to accept publication, then, at least, they really prefer to have some advance warning. The "due credits for prior warning" barter is an arrangement which has a high probability of convincing most bug-hunters not to push the exploit right away on public channels, so software vendors will support this "normal way".

Ultimately, when the dust has settled, all details should be published, because full disclosure is a great foundation for trust.


Configuration for Windows account mapped to IIS certificate authorization I need to connect two servers in different locations in order for one of them (Linux stack) issues HTTP periodic requests to the other (Windows stack) using cron based jobs.

On the Windows machine, I am going to set up an IIS with a self-signed certificate to authenticate to the client (by pinning the certificate) and to encrypt the connection over SSL.

I am also going to configure IIS to request client certificate to authenticate the Linux server. I have gone through a tutorial to configure the Certificate Authentication which involves mapping the certificate to a user account.

I am not happy with the idea of having a user account created for a remote server because I wouldn't like anyone logging into the (Windows) server with that account.

With this in mind, if I really need to create an account on the Windows machine, how should I configure it so it only can be used to authenticate the IIS's requests from the Linux server?

You're right to be concerned with creating a new user account just for this task. A much easier approach is to use an application key inserted into the request header. Since you're using self-signed certificates, this leads me to believe that this is a one-off solution and won't be scaled to hundreds of clients. Here are the steps to make this happen.

UPDATE: this alternative solution will have no impact on the IIS hosted application since URL Rewrite will process the request before the application. To immediately drop failed attempts, update the action section of the URL Rewrite rule to the following. Note that this will cause failed requests to not appear in IIS logs.

<action type="AbortRequest" />

Install URL Rewrite on IIS

This is a Microsoft module that isn't installed by default and provides functionality similar to mod_rewrite.

https://www.iis.net/downloads/microsoft/url-rewrite#additionalDownloads

Create URL Rewrite Rule

Add the following rule to the web.config for your application. It will look for a request header of AppAuthKey (which you can change/personalize) and a value of joshua (not case sensitive and should be something more complex). If either is not present, the 401.4 will be returned.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Application-Request-Header-Filter" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                    <conditions>
                        <add input="{HTTP_AppAuthKey}" pattern="joshua" negate="true" />
                    </conditions>
                    <action type="CustomResponse" statusCode="401" subStatusCode="4" statusReason="Access denied." statusDescription="Authorization failed by filter." />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Edit curl command

Update your curl command to include the request header as follows:

curl -H "AppAuthKey: joshua"

No Need for a Client Certificate

Using this method doesn't require a client certificate. Normal SSL (should be TLS1.2) will suffice as long are you're using strong ciphers. More information about this can be found at the following OWASP page:

https://www.owasp.org/index.php/Hardening_IIS#Ensure_TLS_cipher_suites_are_correctly_ordered

UPDATE #2

@AlphaD brings up good points regarding various policy settings one can use to further limit accounts. I would recommend against this since it goes against configuration management. Taking that approach introduces configuration requirements for the system hosting the web application that may or may not impact other services. The preferred method is to architect the web app for portability so little of the hosting system is required. Suppose it makes sense to highlight some key points as to why it’s preferred to use an application key in this instance rather than a local or domain user account on IIS.

Local User

If the user is local to just the web server hosting IIS, then that account will be able to authenticate to any other website and/or service hosted by that server. Make sure permissions on all other resources are reviewed because by default the account will be a member of the local "Users" group which has a surprisingly wide breadth. Additionally this account has Read access on the file system (NTFS). If another website is misconfigured, this user could be used to authenticate and read its contents. Authentication via this account will most likely use Basic Authentication which means the credentials are Base64 encoded (not encrypted) and placed into every request header. (Just like my recommendation of adding a custom request header for authentication.) Lastly, using local user accounts makes system management difficult. When migrating the website to a new server, a new account must be created with permissions updated and properly scoped. That logon information then needs to be updated in the consuming curl script(s). It doesn’t make your application portable.

Domain User

Same as local user, now the scope of where this user can authenticate has expanded to the entire domain. This includes Read access to much of active directory and other services advertised in the environment. Authenticating with this user will be a bit more secure since NTLM or Kerberos can be used as long as AD is accessible and your Linux host is configured for AD auth. Otherwise Basic Auth will probably be used. Account management becomes a bit easier since it will fall into the realm of domain account management instead of system account management and often (not always) there are well established procedures for domain account management.

Application Key

Preferred method since no user account is required and limits the scope to just this application. Making the weak point the communication channel (secured via TLS and strong ciphers) and the content directory which should have limited access anyway.


How can this input-sanitizer function be defeated? There's a Classic ASP application at my job that is (I believe) highly vulnerable to SQL injection. I want to prove to management that this code isn't secure, but all I'm able to do is insert "SQLINJ" log records in the database:

Public function preventSQLInjection(lstr)

    BlackList = Array("--", ";", "'", "/*", "*/", "@@", "@",_
                      "alter ", "begin ", "create ", "cursor ",_
                      "declare ", "delete ", "drop ", " end", "exec ",_
                      "execute ", "fetch ", "insert ", "kill ", "open ",_
                      "select ", "sysobjects", "syscolumns",_
                      "table ", "update ", "=")

    preventSQLInjection = lstr

        For Each s in BlackList
        If ( InStr (lstr, s) <> 0 ) Then
            execSqlQuery "INSERT INTO AccesLogs (datetime,ip,action,comments) VALUES ('" & formatDate(date) & " " & formatTime(time) & "','" & request.ServerVariables("REMOTE_ADDR") & "','SQLINJ','" & replace(lstr,"'","''") & "')",connectionstring
            preventSQLInjection = "DONOTUSEIT"
            exit for
        End If
    Next

end function

From my understanding the easiest attack would be on the AccessLogs table itself, because of replace(lstr,"'","''") which "sanitizes" the SQL-Injection attempt and logs it.

I KNOW that this code should be ditched and all executable SQL should be executed with actual commands and parameters - I hate concatenated strings with a passion.

I want to demonstrate management that the page is very vulnerable, like, sysobjects is blacklisted, but not sys.objects so if I can inject executable SQL it must be possible to get then entire database's schema without sweating.

How can this function be defeated from, say, the username and password fields on the login.asp page? Or am I making this all up and this code is perfectly secure?

I want to prove to management that this code isn't secure

You could spend the rest of your (perhaps short) career doing so, over and over as they add to the blacklist.  I suggest trying to educate them instead.

Read the OWASP SQL Injection Cheat Sheet and related sheets referenced therein, and then be able to present that to the decision makers and answer questions rationally - OWASP is a very reputable source.

Also read Why We Shouldn't Roll Our Own - in particular, the Phil Zimmerman example is an example, from a very well known cryptographer, of why "well, I can't defeat it" does not mean "it" is secure.

If you must try to provide an example, try playing around with various encodings; hexadecimal is clearly allowed, so pull up your ASCII Table for use with 0x and CHAR(), and perhaps also play around with HTML escape characters or Unicode (UCS-2, for SQL Server).

See if you can use 'set quoted_identifier off' as well.

As kiBytes said, try mixed case - the most common SQL Server collations are all case insensitive.

If anything works, you'll need to go back to educating them that just because you found N holes doesn't mean there aren't X holes remaining, some of which you will not find before attackers do.


Use openssl to individually verify components of a certificate chain This is related to another question, How to verify a signature of one entity by another using OpenSSL CLI?

I used openssl s_client -showcerts -connect www.google.com:443 to collect three certificates from google.  Call them g0, g1, g2, where:

g0 is a leaf cert signed by Google's intermediate CA
g1 holds the intermediate CA public key and is signed by GeoTrust CA
g2 holds the GeoTrust public key and is signed by EquiFax CA

My goal is to demonstrate that this is a valid signature chain, step-by-step, using the OpenSSL CLI.  The intuitive try is this:

$ openssl verify -CAfile g1 g0

But it turns out that OpenSSL is using certs from its trusted store (see How to verify a signature of one entity by another using OpenSSL CLI?).  So instead I kill the trusted store as @dave_thompson_085 suggested in a comment to the above-referenced question.  But this doesn't seem to work:

$ openssl verify -CApath /dev/null -CAfile g1 g0
g1.crt: C = US, O = Google Inc, CN = Google Internet Authority G2
error 2 at 1 depth lookup:unable to get issuer certificate

So how do I correctly issue this verify command in such a way that I can specifically check whether g1 has signed g0?

$ openssl version
OpenSSL 1.0.1f 6 Jan 2014

I've more-or-less solved my problem as follows:

There is an option to verify called -partial_chain that allows verify to output OK without finding a chain that lands at self-signed trusted root cert. However, -partial_chain doesn't exist on the version of OpenSSL that I have, nor in any later version of 1.0.1.  Here's the run-down:

OpenSSL 1.0.1f -- This is the latest for Ubuntu 14.04; it has the heartbleed fix
OpenSSL 1.0.1s -- This is the latest in the 1.0.1 line, and likely to be the last; must be installed by hand in Ubuntu 14.04
OpenSSL 1.0.2g -- Currently the latest in the 1.0.2 line; this does support -partial_chain
OpenSSL 1.1 -- This is currently in alpha and has even more options, but I didn't explore it

So, with 1.0.2g or later, one can do the following:

$ openssl verify -CApath /dev/null -partial_chain -trusted g1 g0
g0: OK
$ openssl verify -CApath /dev/null -partial_chain -trusted g2 g1
g1: OK
$ openssl verify -CApath /dev/null -trusted /etc/ssl/certs/EquiFax_Secure_CA.pem g2
g2: OK

(Note that -partial_chain was not needed in the last command since the Equifax root cert is self-signed.)

This satisfies my question, but requires a version of OpenSSL that is not yet available on some distros unless you hand-install.  If you are stuck with a pre-1.0.2 version, you probably have to use @Anthony Geoghegan's method.

Note: There is an option listed in the verify docs called -no-CApath which purportedly obviates the need for -CApath /dev/null, but it's not available on 1.0.2g or earlier, based on my tests.  I assume it is available in 1.1.


PDF User Password always give access to the Owner Password, even when encrypted with AES-128 I've been messing around with qpdf, and noticed something that seems huge: that a document's Owner Password is essentially useless, as it can be easily unset, and therefore that only the User Password offers any real security for a PDF.

For example, when I set a User Password and an Owner Password on a PDF:

qpdf --encrypt "zeus" "zeussecurity" 128 --modify-other=n --extract=n --annotate=n --form=y --use-aes=y -- "Unsecured.pdf" "Secured.pdf"

...all that's needed to unset both of them is the User Password:

qpdf --decrypt --password=zeus Secured.pdf Secured_decrypted.pdf

When I set only an Owner Password on a PDF:

qpdf --encrypt "" "zeussecurity" 128 --modify-other=n --extract=n --annotate=n --form=y --use-aes=y -- "Unsecured.pdf" "Secured.pdf"

...I'm able to unset it without a password at all:

qpdf --decrypt Secured.pdf Secured_decrypted.pdf

Notice that qpdf is not a brute-forcing program and this all happens in less than a second, so this isn't a case of password strength - the passwords are simply being bypassed entirely.

Is this normal behaviour for the security on a PDF, or some sort of bug/edge case that I've run into?

Yes, that's normal. Only the user password offers any real security; the owner password is pure snake oil (thanks Adobe). I'll make the same comparison I always make: if the owner password actually worked as advertised, it would be equivalent to effective DRM, which is well-known to be impossible.


Anything better for cracking passwords than John if I have root? If I used an exploit to gain root access, but my ultimate goal is cracking the passwords for each user, what is the fastest way to do this?

I know I can use john on the shadow file, but if I'm in a timed environment with limited CPU power, is there a faster way that takes advantage of already being root?

If your ultimate goal is to actually get the password in plain text, then unless there's severe misconfiguration or undiscovered flaw in the password hashing method used, then no, there isn't a faster way to crack password than brute force.

Few points you could exploit: if you can get the shadow file out of the system, you could do brute force in more resourceful cloud systems like AWS or Compute Engine. Or if you can get the password salt and/or iteration count ahead ahead of time, you may be able to precompute a rainbow table.

However, most attack scenarios don't really need the plain text of the password. If you already have root, you can already do everything you ever needed to do, install ssh key for future login, alter sudoers to gain privilege on your non-root account, alter the kernel/OS to hide your changes, delete logs, etc.

If you really needed the plain text of the password, you can try altering sudo/su/sshd/bash/gpg binary to a trojaned version so that the next time the real admin typed in root password, the password will be sent to you. This may be helped by a little social engineering to convince the real admin to login to the system sooner rather than waiting indefinitely for that to happen who knows when.


Password strength metrics In the question Source code as password I suggested using a combination of entropy and as @Lawtonfogle put it 'meatspace difficulty'. As suggested in the xkcd comic correct staple horse battery is a better password than  Tr0ub4dor&3 since it has both more entropy and is easier to remember.

Are there password strength metrics which take both entropy and ease of memorization into account?

Clarification: I'm interested in an "information theoretical" answer. In other words, assume that the password is converted to a form where the entropy is 1 bit/bit and then stored using a cryptographically secure perfect hash.

Say you use Diceware you can generate a memorable, secure passphrase.

  For the technically inclined, each word in your Diceware passphrase yields 12.9 bits of entropy, the way passphrase security is measured.

If you want a passphrase to be uncrackable, ever, using today's technology (and the technology of the foreseeable future), you need 128 bits of entropy in your passphrase.

Therefore you need 10 dicewords to achieve this level of entropy:

128/12.9 = ~9.9

You can use a list memorising technique to connect the words in a memorable fashion. You could also use this technique to link it to the purpose of the passphrase. This is the type of technique that artists such as Derren Brown use in their stage shows. For example, the "tricks" where they remember whole telephone directories.

If the passphrase is stored hashed using a key stretching algorithm, you could get away with less entropy. This is because for every password an attacker tries, they have to run the hashing algorithm a number of times, known as the iteration count. The iteration count will cause any brute force cracking of the passphrase to be sufficiently slowed. If you want 10 bits less, then this is the equivalent of 1024 hash iterations (2^10) using, say bcrypt. For 20 bits less, then this is 1,048,576 iterations (2^20). So if you went for the latter, you could make your password slightly easier to remember by using 9 dicewords. However, if you're using a memory linking technique, an extra word won't hinder memorability of the passphrase - it would just be slightly easier to type in each time it is used.

  Are there password strength metrics which take both entropy and ease of memorization into account?

If you're measuring password strength in an objective way the only metric is amount of entropy. Entropy does take into account the passphrase generation method. If the average English word length is five letters, a password generated using Diceware would be 50 characters long on average if we're going for 10 words (for simplicity, we're discounting the character symbols used in Diceware). A 50 character lower case password completely randomly generated would normally have 235 bits of entropy - as we can see though, as the method of generation is to use whole words generated by five throws of a six sided die we only have 128 bits.

With the Diceware approach, the aim is to remove the memorisation portion from the equation, so we're left with the mathematical calculation of entropy only. We make memorisation of the passphrase a solved problem so we're just left with an objective "strength" value, based on the time required to brute force it.

You don't have to go for the full 128 bits. Just be aware that a targeted offline attack on a passphrase with less strength will be cracked eventually. A 128 bit passphrase is more important where the passphrase protects something that can be accessed directly - such as in password-based-encryption where cracking the password will enable an attacker to read the encrypted data. It is less important where the passphrase is only used as an authentication mechanism, for example where it protects an online account. It is advisable to regularly change your online passwords if they are a lesser strength because if an attacker has managed to retrieve hashed passwords, they will be cracked given enough time - although I disagree with the 90 day period usually mandated.

Edit:

So I would recommend a (separate) memorable passphrase with sufficient entropy for situations where you need to be able to type the passphrase. For example, as the master password for your password manager, for Operating System logins, or to authenticate you for full disk encryption. For online accounts, I would recommend the use of a password manager to generate a completely random 128 bit password that you can't remember.


How to protect data on your hard disk if it is in an unfriendly environment? The essence of the problem as follows:

There is a server located on the side of our company.

There is a hardware client module, which is in a public place, which communicates with the server via a secure protocol.

The client module contains the key with which it is authenticated by the server.

We need to make sure that the key could not get into the wrong hands, in case of theft of client module.

A key condition is the absence of agents which would have to be administered, for example, to connect the encrypted volume when module is booting.

Does anyone have any ideas how this can be done?

It's going to very hard, almost impossible, to do that in a simple way.

If you just wanted to protect the key, it would be easy: just put the key inside a device that is tamper-resistant like any token or smartcard. In a smartcard, someone can perform computation inside it, but can't access the code, or a stored key, etc.

Your problem is a bit deeper than that: given a computer that is outside your control (client environment), no matter how long it is turned off, etc, you want to be sure that when it tries to connect to your server, it hasn't been changed / messed in any way.

And to that there's no fully possible way to guarantee that. It's the third rule:

Law #3: If a bad guy has unrestricted physical access to your computer, it's
not your computer anymore
(source: http://technet.microsoft.com/en-us/library/cc722487.aspx)

Specially if your computer can be turned off as a regular use.

Think that someone could try jamming the GPS signal, or opne your case and remove any special hardware you put, or try to change the OS of your computer, or put a device between the computer and the keyboard, or remove your HD and copy everything, or...

If you just want to protect some key, go with tokens or smartcards. But that wouldn't prevent someone from accessing it the same way your original software would do.

If you want to protect the client module from being stolen, put some armed guys at its side. Or tell us more about exactly you want to protect, so we can elaborate a bit more.


Is it possible to decrypt a satellite TV signal without using a smart card? And if it is possible, why has it been decided to keep using a smart card for this task?

I will be grateful if you can provide some practical examples on how to bypass the use of a smart card (if possible).

A satellite TV system must face the following challenge: it is one-way. The receivers cannot do anything but receive; they cannot emit anything.

The generic problem is known as broadcast encryption. In practice, things go that way:

Each subscriber has a smartcard, and that card contains a key Ks specific to that subscriber.
The media stream is encrypted with a key K. That key is updated regularly.
Along with the media stream, the publisher sends K encrypted with each Ks in circulation. That is, every minute or so, thousands of small blobs are sent in some "holes" in the data stream (apparently there is sufficiently free bandwidth for that); all these blobs contain K, but encrypted with the key of a subscriber.

Thus, a given decoder will just wait for the blob which contains K encrypted with his card-specific key Ks, and use the card to obtain K and decrypt the stream.

When a subscriber is no longer a subscriber (he ceased to pay), the publisher simply stops sending the blob containing K encrypted with the corresponding Ks. The next time K is updated (it happens several times per day), the ex-subscriber is "kicked out".

In older times, media publishers had the habit of doing everything "their way", which means that they designed their own encryption algorithms, and they were very proud of them, and kept them secret. Of course, such secrets were never maintained for long because reverse engineering works well; and, inevitably, these homemade encryption algorithms almost invariably turned out to be pathetically weak and breakable.

Nowadays, the publishers have begun to learn, and they use proper encryption. In such a situation, the only recourse for attackers is to clone smartcards, i.e. break their way through the shielding of a legally obtained smartcard, to get the Ks of that card. Breaking through a smartcard is expensive, but not infeasible, at least for the kind of smartcard that are commonly used for such things; it requires a high-precision laser and an electronic microscope, and is rumoured to cost "a few thousands of dollars" for each break-in. Attackers do just that.

Publishers react in the following way: with traditional police methods. The cloning method is worth the effort only if thousands of clones can be sold, as part of some underground market. Inspectors just masquerade as buyers, obtain a clone, see what card identity the clone is assuming, and deactivate the corresponding subscriber identity on the publisher side, evicting all clones of that card in one stroke.

From what I have seen, the break-clone-sell-detect-deactivate cycle takes about two weeks. It is more-or-less an equilibrium: the non-subscribers who accept the semi-regular breakage of connectivity are in sufficient numbers to maintain professional pirates, but they are not numerous enough to really endanger the publishers' business model.

We may note that Blu-ray discs are a much more challenging model, because readers can be off-line and must still work; and though each Blu-ray reader embeds its own reader-specific key, there is not enough room on a Blu-ray disc to include "encrypted blobs" for all readers in circulation. They use a much more advanced algorithm called AACS. However, for satellite TV, the simple method described above works well.


Does Skype use audio watermarking? Today on CNN they conducted an interview with a career criminal, who spoke by Skype on condition of anonymity.  It occurred to me that, if Skype uses digital watermarking to embed identifying information in the audio stream, then this criminal has potentially blown his cover, at least to Skype and to any other entity with knowledge of the watermarking technique.

Skype is, of course, a closed-source program that is known to surreptitiously access third-party configuration files (for reasons that may or may not be nefarious), and it is claimed that law enforcement agencies have the ability to eavesdrop on Skype conversations.  However, I don't know whether anyone has ever alleged or investigated claims that Skype uses imperceptible audio watermarking to covertly embed identifying information, such as the originating Skype account ID, MAC address, IP address, operating system details, etc.

Have there been any leaks or admissions by Skype confirming their use of such watermarking?  If not, has anyone attempted to use technical methods to detect the presence and/or contents of such watermarking?

As far as I know, there haven't been leaks or admissions that Skype uses this kind of technology. However, other techniques can be used.
First, law enforcement agencies can ask Skype to give them certain data about a Skype account:

In response to a subpoena or other court order, Skype will provide:
• Registration information provided at time of account registration
• E-mail address
• IP address at the time of registration
• Financial transactions conducted with Skype in the past year, although details of the credit cards used are stored only by the billing provider used (for instance, Bibit, RBS or PayPal)
• Destination telephone numbers for any calls placed to the public switched telephone network (PSTN)
• All service and account information, including any billing address(es) provided, IP address (at each transaction),
and complete transactional information

Note that billing addresses and data related to financial transactions can be more useful than IP and email addresses.
In addition to that, there is an interesting technique for forensic analysis of audio and video recordings, which doesn't rely on watermarking: electrical network frequency analysis.
The basic idea is that you can detect the fluctuations of the frequency of power distribution networks (usually, around 50 or 60 Hz) in audio and video recordings. Since the fluctuations are known by the power distribution company and vary according to the power grid, it is possible to geo-locate any speaker, potentially including a Skype user, at least in an approximate way. These are two sample papers on the topic.
Since Skype is a (closed-source) software, it is possible that it sends system information such as the OS and the processor being used by the user , but I haven't found any evidence of this so far.


I have recovered my credit card PAN (6 chars masked) and expiration date on a merchant site, acceptable or not? I have a credit card saved in X merchant. I only see the last 4 digits in the UI.

I have launched a 3D secure payment transaction by using my saved card. Then I have noticed that even in the failed transactions browser posts back my stored credit card information (PAN's 6 chars masked + expiry date) to the X merchant's website.

IMHO this is a security risk. I would not do this as a developer. But what about PCI DSS? Is this complies with PCI DSS?

  The first six and last four digits are the maximum number of digits that may be
  displayed.

Reference

It looks like PCI DSS allows displaying PAN like this. But I could not find any information about masking expiry date. That's the point I have no answers.

Printing the expiration date on a receipt is a possible violation of the FACTA laws in the USA. But I don’t know if it’s a violation of the PCI DSS. Check with your QSA to find out if printing expiration date is allowed.

On the other hand, if there aren’t any valid reasons for printing it, don’t! I mean really important valid reasons, not just because marketing or fraud prevention thinks it would be a good idea.


The application of HMAC vs CMAC vs DAA So HMAC, CMAC, DAA are different algorithms for generating MAC based symmetric block ciphers. If all use symmetric ciphers to produce MAC, what is the key difference between them? In other word, why do we need all these types if we get MAC anyway?

Thank you

DAA is a specific deprecated government standard for authenticated encryption. It is not something you would want to use. In particular, it is a modified version of CMAC using the insecure DES cipher.

HMAC uses a hash algorithm to provide authentication. It is usually quite fast. CMAC on the other hand uses a block cipher in CBC mode, making it a lot slower. The only reason CMAC, which requires double the number of calls to the block cipher for encryption, would be used is if it is being used on an embedded system which already has hardware acceleration for the cipher, making it easy to re-purpose it for authentication. In general, you will want to use HMAC.


What to do if stuck with website that has poor security? I have a student loan account with a company, not the biggest company but big enough to where they should have their act together. Today I couldn't remember my password to log into my account dashboard. I clicked "forgot password" and they prompted me with 5 questions. First Name, Last Name, last 4-digit SSN, birthday, and zip code. All information that is easily acquirable if trying hard enough, not to mention all information that is included in their periodic emails about payments. Upon typing in the information the site responds saying I have been authenticated and gives me my password in plaintext.

So now not only is it incredibly easy to retrieve lost password details, they dont even send it to your email they just display it on screen, on top of that they store the password in plaintext in the database. This is an account that has details of my multi-thousand dollar loan as well as my bank details for auto-payments. Fortunately the one detail not given is my username, which is my full SSN, so that is the last thread of security; however, if they store passwords unhashed I'm sure my SSN is not either, making this even worse.

So my question is, given that this is a loan that I can't just up and leave is there/what are any precautions or steps that I can take to make this potentially more secure? Would it be worth emailing them and badgering them to upgrade their security or should I just pay as quick as possible and get out? If I do warn them, what types of threat should I say they are vulnerable to in hopes to scare them into a patch?

Financial institutions in the United States are obliged by the Gramm-Leach-Bliley Act to ensure the security and confidentiality of personal information. What you describe is a flagrant violation of the FTC's Safeguards Rule.

I would immediately file a complaint with the FTC.


Landlord will be watching my data traffic, as mentioned in the lease agreement I am moving to Germany, and in the contract I signed I had to accept that all my data traffic can/will be checked by the apartment owner. The contract states:

Flatrate, aber hinter 30GB Tarif priorisiert, aslo etwas langsamer
Ja ich weiss, daß meine Daten überprüft werden.

Which translates to:

That after using an amount of 30GB data, the speed can/will be slower.

And the critical:

Yes, I know that my data is checked/investigated

Later in the contract one can read the following

Im Rahmen der gesetzlichen Bestimmungen (Anti-Terror-Gesetze und TKG) kann das Protokollieren der Daten erfolgen. Im Mietpreis ist eine FLAT-Rate enthalten, dabei können jedoch einzelne Ports gesperrt sein oder bestimmte Verbindungen mittels Traffic-Shapping bevorzugt oder verlangsamt werden. Bestimmte Geschwindigkeiten werden nicht zugesichert. Die Verbindung funktioniert nur, wenn DHCP eingeschaltet ist (z.B. bei Windows IP-adresse automatisch beziehen).

Which translates to:

In accordance with statutory requirements (anti-terror laws and TKG)
to log the data can take place. a FLAT rate is in the rental amount,
but it can individual ports to be blocked or certain compounds by
traffic Shapping preferred or slowed. Certain speeds are not
guaranteed. The connection works only if DHCP is enabled (eg
automatically when Windows IP address relate).

Since I really needed this apartment I was forced to accept this. But not anywhere does the contract says that I can not make it difficult for the landlord to check my traffic.
So my question is: would it be possible to make it difficult for the person watching my data traffic to see what I am actually doing on the internet? As you probably can tell, I do not know alot in this field.
Internet is provided via LAN, but I am going to use a D-link dir-635 router. And I am running Linux Mint.
I am not familiar with the prices of 4g/LTE in Germany, so I can not say if that is an option yet. I do not think I can get my own internet installed, and since the internet is provided in the rent (whether I want it to or not) it feels redundant to install a personal internet.

FINAL (hopefully) UPDATE: Well after all the very interesting and valuable discussion, it seems to me as though initial thoughts were correct. From the updated question, I would say that the restrictions are pretty standard for Germany.

My recommendation is that you ignore the noise and the concerns and simply make use of the service. Unless you have some very specific security needs that you haven't shared, using HTTPS wherever possible (which is best practice anyway) is sufficient.

In any case, the other options discussed would all add overheads to your traffic which would use up your 30GB even sooner and slow things down.

There are several things you can do. Provided that the terms and conditions of use are OK with them.

You don't say what country you are in but you might want to get the terms of use checked by a lawyer since some terms may not be legally permissible anyway.

Here are four of the main ways you can protect your Internet traffic from the prying intermediate.

Make sure you always only connect to HTTPS sites

When you use HTTPS sites, the traffic is encrypted between you and the endpoint. Your landlords infrastructure will not be able to do more than examine the destination IP address, port and DNS. In particular, things like banking and health sites will remain secure.
Use a VPN

A VPN in this case is a 3rd party service that encrypts ALL of the traffic (not just web traffic as in 1) between your machine and the VPN host. This prevents any inspection of the traffic at all and it will appear as though you only talk to the VPN destination.

Unfortunately, it is possible that common VPN end-points might be blocked or even a smart security system used that will dynamically identify VPN traffic and ban it. Check the terms of use from your landlord carefully.
TOR

TOR is a way to obfuscate connections across the Internet and is often associated with "the dark web". However, it has legitimate uses as well. Unfortunately, it can add quite an overhead to traffic and may be unacceptably slow. Typically TOR will be used for web browsing, other network traffic would not be affected.
Use the Mobile network

If you are fortunate enough to live in an area with a) good (4G/LTE) mobile coverage and b) an affordable data tariff. Then using a 4G/LTE mobile router may be an option. You can get some staggeringly good data rates.

Don't expect to be free of restrictions though. Many tariffs don't allow device sharing, you'll need a special tariff for mobile data. You might not be allowed to use all services (like VPN's) and you are more likely to have national-level restrictions applied such as the UK's national "firewall".

It goes without saying (so I will say it anyway!) that you should ensure that you are staying within the letter of the laws of your locality & the legitimate terms of use of the landlords network. However, none of the above are illegal in most countries (well in most Western countries anyway) as long as you are not using them to do illegal activities. TOR and VPN's may possibly be illegal or at least get you unwelcome attention in certain countries.

UPDATE: Without question, the most security would be provided by a VPN.

However, that will only be useful if the landlords network allows VPN traffic. In addition, VPN's also carry an overhead so things like real-time traffic (Skype voice/video for example) and online gaming would be impacted quite significantly.

In addition, VPN's will normally come at a cost though there are some discount codes around that might help.

It is possible to set up your own VPN if you have a server on the Internet to run it on. Most VPS hosts wont allow it but some will as long as you keep it private.

The real question is - do you really need to be bothered? That's why I mentioned HTTPS first. Since this protects your information to sites and since all decent online services already use HTTPS, you might find that this is a storm in a teacup.

UPDATE 2: As some others have pointed out. There are many flavours of VPN. A commercial service will be the easiest to consume but you need to do your homework to find the best for your region. Commercial VPN's can also be relatively easily blocked both by end point and by traffic inspection. Some VPN's require specific ports to be open on the network and these might not be available. Test before you buy. In general, those offering SSL-based or OpenVPN-based are likely to offer more options and be easier to get through any blocks.

Another form of VPN is to use an SSH client such as PUTTY (for Windows) connected to an SSH server (perhaps on your own or a friends VPS). You can throw in a local SOCKS proxy client and then you will have a very configurable private VPN service. Not especially easy to set up though if you don't understand the terminology. Note that many VPS services ban their use for even private VPNs.

Another thing to note is that there are several ways for security infrastructure to spot VPN traffic and therefore block it. Known end points for commercial services and known ports for VPN types are the easiest but it is possible to examine traffic patterns and work out that even apparent SSL traffic (e.g. if using port 443 for VPN) isn't actually.


How exactly does the NVIDIA Tegra Fusée Gelée exploit work? Just yesterday a vulnerability--Fusée Gelée--was found in the Nintendo Switch NVIDIA Tegra chips that will purportedly allow linux to be loaded onto the devices, among other things.

However, even on the FAQ page, I still don't see anything about how this vulnerability allows arbitrary code to be run.

How does this exploit actually work?

On 2018-04-23, the ReSwitched team publicly released their exploit. The FAQ you linked has not been updated since (as of the writing of this post). A summary of the exploit is available in the vulnerability disclosure report:

  The USB software stack provided inside the boot instruction rom (IROM/bootROM) contains a copy
  operation whose length can be controlled by an attacker. By carefully constructing a USB control
  request, an attacker can leverage this vulnerability to copy the contents of an attacker-controlled
  buffer over the active execution stack, gaining control of the Boot and Power Management processor
  (BPMP) before any lock-outs or privilege reductions occur. This execution can then be used to
  exfiltrate secrets and to load arbitrary code onto the main CPU Complex (CCPLEX) "application
  processors" at the highest possible level of privilege (typically as the TrustZone Secure Monitor at
  PL3/EL3).

The report also contains specific details of the exploit. As the report states, it has been known by multiple entities for some time. More details relevant for end users are availailable in the Q&É.


Partially forgotten encryption password I encrypted important files with Veracrypt and I remember most of the password but some parts are forgotten. I need some advice as to what would be the most efficient way of getting the encryption password.

My operating system is Windows.

I've been trying to get the password for months now. Any help would be appreciated.

To elaborate further on Mike's comment. You will need an idea of the last known password and then use John the Ripper to produce a wordlist mutation (similar) passwords. You will need to create a rules configuration file for John, the wordlist will give a smaller password set if thought through carefully. Hence, a smaller keyspace to brute force; reducing overall brute force time.

root@kali:~# john –wordlist=mustangwords.txt –stdout –rules:convtolowerplus000 > newmustangwords.txt

  Basically this is broken up as follows:

john self-explanitory, start John the Ripper
–wordlist= specifying the word list we want to mutate
–stdout output the words generated
–rules: this is the rule set we generated in the configuration file
> output the results to a new text file

Next, you will need to brute force the VeraCrypt header key this can be done with vUte. vUte is a VeraCrypt Bruteforcer written in BASH. As I understand the header key can be obtained via use of a hex editor, A back-to-front TrueCrypt recovery story: the plaintext is the ciphertext. For context, Is there a reason to use TrueCrypt over VeraCrypt?.

As I understand HashCat can do a similar process, with less intermediate steps. However, I am not familiar with this. Furthermore, due to the nature of this brute force, it is not known to be a particularly fast crack. VeraCrypt uses PBKDF2, see About how fast can you brute force PBKDF2?.


How to select secret identifier? For an ecommerce website I need to create an identifier, that will represent the user's order. It can't be order's ID in database as it's assigned in predicateble manner. So it needs to be some pseudorandom string (ideally a-zA-Z0-9), that will offer increased security, because it won't be guessable.

The number can be tested using the web server itself on well known URL. But only with the speed of about 50requests/s. Also, from the pool of possible secrets only approx. 1M (which is an estimate of number or orders in the end of the website's lifetime) will be used.

What is a correct length of the identifier to provide enough security?

Note: Still the easiest way to get to the data is to brute-force admin's password, which is in many cases quite simple, but that's not a thing I can change :(

I assume that you want identifiers which are:

unpredictable: external entities ("attackers") must not be able to guess the next identifier, even given knowledge of all previous identifiers;
unforgeable: it must not be possible, from the outside, to "get lucky" and produce a valid identifier;
unique: each generated identifier should be distinct from all previously generated identifiers.

What makes a given identifier "valid" is, ultimately, that it is registered on a the server as such. In some contexts, you might want to be able to verify validity without having to talk to a database.

There are several methods:

Use randomness. Generate a sequence of bits from a cryptographically strong PRNG. If you get enough bits (i.e. 128 bits or more), then the identifier will fulfill the properties above with overwhelming probability. Most operating systems offer an appropriate PRNG (e.g. /dev/urandom on Unix-like systems).
Use a counter and a key. Let the generating server know a secret key K, and a counter C. The key is for a block cipher such as 3DES. When you want to produce the next identifier, increment C, then encode the new C value as a block of the size needed by the block cipher, and encrypt it. For instance, 3DES uses 64-bit blocks. Thus, take the counter value (an integer in the 1 to 1000000 range), encode it as a 64-bit integer (which will thus begin by a big bunch of zeros), and encrypt that, yielding a seemingly random 64-bit value.

The second method has the advantage of allowing verification by knowing the key K, without having to check in a database: decrypt the 64-bit identifier (with K), and see if this yields an integer in the expected range (1 to 1000000). The attacker, not knowing K, will have a hard time producing an "identifier" which, when decrypted, falls into the expected range. The method with a block cipher also allows for shorter identifiers, because it guarantees uniqueness through the fact that the block cipher is a permutation.

Let's put some numbers on that. You expect about one million identifiers, which is close to 220. Your identifiers have length n bits. An attacker choosing a random identifier has probability 2-n of "guessing" the next identifier, and probability 2-(n-20) of guessing one of the valid identifiers that the server will generate throughout its life. You have to choose n depending on your constraints (you want "security", but you probably also want to keep the identifiers small).

With the random selection of identifiers, you may encounter collisions if you generate identifiers which are too small. Very roughly, since you will produce about 220 identifiers, probability of encountering a collision will be about 2-(n-39), so you will want to use n ≥ 64. With n = 64, you have probability about 1 in 30 millions that you will ever encounter one collision throughout the server lifetime: that's probably low enough risk to be tolerated.

With the encryption method, you can tolerate a much shorter n: at least 20 bits (if you just want to make the next identifier unpredictable), more if you want to prevent the attacker from producing valid identifiers (not necessarily the next one, but one of the 1 million identifiers that your server will ever produce). This method, though, has some implementation issues:

It needs a secret key to be generated, stored, kept safe, but not lost if a hard disk fails. If the server uses multiple front-ends or back-ends, then the key will have to be shared between the relevant machines.
It uses a counter. There again, counter management can be difficult, or be a bottleneck, in multi-machine architectures.
There may not be an available standard robust block cipher with the block size that you wish to use. There are theoretical ways around that but nothing standard and well-vetted yet.
It uses cryptography, which is always a slippery path. Don't invent your own crypto. If possible, don't implement your own crypto either. These things are hard.

The easy way is to use randomness. Some systems offer UUID (known in the Microsoft world as GUID). The "version 4" UUID are generated with a PRNG, containing 122 bits worth of randomness, which would be sufficient for your needs; however, there is little guarantee that any given system which produces UUID values really uses a cryptographically strong PRNG. Indeed, there is a big difference between something which ensures uniqueness between collaborating users, and a system which is unpredictable.

So use a strong PRNG explicitly, and get the bits. "128 bits" is the default all-purpose size. As was explained above, chances are that you could use less bits, e.g. as low as 64, but that requires thinking and quantifying risks; it is much simpler to just produce 128 bits and be done with it.

If you need shorter identifiers for some reason (e.g. a human user will have to type them on a smart phone...), then you may envision a system with a block cipher, but this is fraught with perils. You will have to understand thoroughly what you are doing. Thus, this is possible, but most probably expensive (thinking time is what costs the most in software development).

In all of the above I talked of bits. That's because bits are what the machine is using internally. Ultimately, you want characters: this is obtained by simply encoding the bits with an ad hoc method, e.g. Base64. With Base64, each character is worth 6 bits, so 64 bits become 11 characters (actually 12, because Base64 mandates a final size which is a multiple of 4 characters, but the last one will always be an '=' sign). With 128 bits, you get 24 characters (the last two being '=='). Other encodings are possible, e.g. hexadecimal or Ascii85. That's really up to you. Base64 has the advantage of already been implemented in most programming framework.


What are the risks of buying a used/refurbished computer? How can I mitigate those risks? I bought a used computer that appears to be wiped clean, but can I be sure?

It all boils down to which kinds of threats you want to migitate against - a determined attacker has many more options of leaving malware on your computer than just your hard drive, but it's getting increasingly complex to do so. If you're a rocket scientist working on the newest version of ICBMs you have more to fear than a college student who uses their computer for a few class assignments and some of the newest games (but in the rocket scientist's case, you won't be allowed to use self-bought used computers anyway).

Also, it depends a bit on how competent a presumed non-malicious previous owner was in protecting against malware.

And of course, "wipe clean" can mean anything from "deleting personal files, then emptying the wastebasket" to "reinstall the OS" to "completely overwrite the disks with random data/zeroes, then do an install from scratch".

The typical threats you should migitate against are random malware infections that the previous owner caught somehow. Wiping the disks clean, then reinstalling the OS should be enough to get rid of those.

Some computers, mainly laptops, come with a "recovery partition" that allows you to quickly reset the computer to factory condition; I wouldn't use that. First, because a virus might have altered the install files as well to survive a reinstallation; second, these recovery partitions often come with a lot of crapware which the manufacturer installs because they're paid a few dollars by the crapware maker. Better download an installation DVD/USB medium from Microsoft/Ubuntu/whichever OS you're using, and do a fresh install from that.

Besides that, there's many more locations that could have malware, but it's unlikely to find them on your used computer unless you are specifially targeted.

The computer BIOS might be altered to do stuff even before booting, for example, it could have a keylogger trying to steal your passwords, or even keep a few cores of your CPU busy mining bitcoin for the previous owner. It can't hurt to check the manufacturer's website for the newest BIOS update, and flashing the newest version of it, even if that's the version you already (seem to) have. This is already quite paranoid, but still something you can do in a few minutes so doing it won't hurt you much.
The hard drive firmware itself could be altered. Someone published a proof-of-concept a few years ago who installed Linux on the hard drive - no, the computer didn't run Linux; the hard drive itself ran Linux, ignoring the fact that it was supposed to be a hard drive (see http://spritesmods.com/?art=hddhack - on page 6, he adds a backdoor by replacing the root password hash with a known one every time the disk reads /etc/shadow, and on page 7, he boots a linux kernel on the disk itself).
The CPU microcode itself could be altered to do .. stuff, including ignoring any further microcode updates. Unlikely that this could be done without cooperation from Intel, but still a possibility if the NSA is trying to target you. (However, if the NSA were targeting you, "hope he'll buy the spiked used computer we put on ebay for him" wouldn't be their primary strategy, I assume).

So, if you're just a random guy, wiping the hard disks and doing an OS reinstall from scratch provides good protection against the kinds of threats you can reasonably expect.
However, if you have any reason to assume someone is actively targeting you - this includes MDs keeping patient data on their computers, credit card processors, ... - "Just don't buy used computers" is the first thing in a long chain of measures you need to take.


Is it a good idea to disable WHM backend and only enable it through ssh when needed? I have recently set up a managed VPS and it came per-installed with CentOs and WHM.

I have configured SSH logins to use private keys and i can SSH into the server with root privileges.

I realize that i lack a great deal of knowledge on how to look after a server properly but at the moment i can not afford a professional. And as such my approach might be extremely foolish and if so i would be grateful for any advice.

Here is what has been troubling me: I can access WHM panel as well as cpanel over HTTP but so can anyone if they tried (hackers and bots) and try to brute force into the backend. Now i was thinking whether it is advisable to block the ports used by WHM on the server to disable the web login, through SSH. And when i need to use the WHM backend i can first log in to my VPS through SSH and unblock the ports.

q1: Can such an arrangement ever result in me being locked out of my server?

q2: Will this provide any real security?

q3: Is this an overkill?

AS i said i am total beginner when it comes to server security and i am probably approaching the issue the wrong way. Any advice or link to a related resource will be much appreciated.

Q1: As far as you only block the panel ports (you are not filtering the ssh port by error, for instance). As far as you still can ssh in, and don't forget  how to and reenable the panel, it shouldn't lock you out of the panel.

Q2 & Q3: You are reducing the exposure surface, so yes you will improve your security. If everything works as it should, you won't ever need it. But things don't always work that way :)

There's another step you can take for limiting the access to cPanel. ssh supports tunneling connections, so you can make WHM/cPanel available only on the loopback device (127.0.0.1), in this way it can only be reached from the machine, and when needing to access, you would connect to the box with a ssh tunnel, and point your browser to the port at your machine where you "redirected" the server port (details on how to perform the ssh tunnel vary depending on your ssh client).

PS: Remember that even if you are logging in with, root can still log in with its -hopefully secure- password unless PermitRootLogin is set to without-passwordin sshd config.


How does a hacker reach a back-end file to exploit it? I read this post: How does hacking work? and I saw that Chris Dale answered the question with some PHP exploit instructions. However, how does a hacker can read a PHP file (or another back-end file), since it is in a server? What do hackers do to reach a back-end file in the first place? is it done with pre-made tools like Metasploit or network tools then, after being able to read the file by the tool, they write custom exploits to achieve what they want? I wonder too if Javascript is easier to exploit because a section of the program usually is in the front-end (I mean files that aren't node.js ones). I don't have prior knowledge in hacking.

"Hackers" don't really do (or need to do) what you are describing. In some cases, a misconfiguration may allow for a remote user to view the text content of a PHP script file (e.g. maybe a backup file with a file extension not normally executed by the PHP interpreter, or some arbitrary read vulnerability), but this is not required to construct a working exploit.
In general, I'd say there are at least two ways an attacker may find vulnerabilities without reading the source off the server:

The application is a well-known open source product (e.g. WordPress), and the attacker downloaded the source and found a vulnerability that way, or they found an existing vulnerability that applies to the version on the target server.
Certain design patterns immediately raise red flags to the trained eye. If I see in the URL something like /?file=store.html, this looks like it could be used for directory traversal/LFI/RFI (e.g. maybe replace the file parameter with ../../../../etc/passwd to test). Or, if the website lets me directly or indirectly run system commands (e.g. "Enter an IP address to ping"), it may be worth attempting shell escapes (8.8.8.8$(cat /etc/passwd)) to see if there is a command injection vulnerability. These type of blind attacks are often more of an art than science, as it can take quite a bit of intuition and assumption on the attacker's part to figure out how the system works and where a vulnerability may exist.


Why should I use firewall to block ports with no running services? A firewall is for blocking / limiting access to specific service / port.

I know that it can be useful for allowing only certain IPs to a port (for example I don't want to have SSH open for the whole world).

Imagine that I have server that is running apache2 (port 80 & 443), SSH (port 22), mysql (it is bound to localhost, so it doesn't listen on a public interface).

Why should I even care to block all other ports except 22, 80 and 443, if there is no other service listening on it (for example on port 8080)?

Can someone explain this to me?

Blocking not in use ports is part of security in depth (or layered security) it makes it harder for an attacker to find unintentional publicly accessible services. And if an attacker manages to access the server through some exploit to not have an easy way to create a reverse shell.

It also makes it so that your server has less things to do (than continually drop packages for not in use ports. )


Which AES key length to choose for OpenVPN? I plan on using OpenVPN on client devices which are small embedded machines, so I must balance between speed and security.

The OpenVPN documentation says that it is "general wisdom that 1024-bit keys are no longer sufficient". This refers to the asymetric keys used for the key exchange.

I should now choose an encryption method. My first thought is to take AES-128, but I'm not sure whether this is (in the "general wisdom" sense) still secure enough for the upcoming (10?) years.

Is there a consensus on this point?

In particular for OpenVPN: are other things more security relevant than the AES key size?

AES key size and RSA key size do not relate to the same thing.

RSA, DSA, Diffie-Hellman... are algorithms involved in the initial steps of key exchange, and they come from asymmetric cryptography, which uses a lot of mathematical structure (big integers with special characteristics) to achieve its goals. That structure is what makes them run at all, but it also is their weakness, since it can be leveraged to break them. To avoid that, these algorithms must use very big integers, traditionally 1024 bits or more. Some people consider that 1024 bits are no longer sufficient because computers get faster over time.

AES is symmetric cryptography, which is conceptually simpler: the same key is used to encrypt and to decrypt. There is no mathematical structure here, only a bunch of bits. The attacker has no leverage, and his only recourse is to try all possible keys (that's called "brute force"). 128 bits are more than enough to defeat brute force.

To make an analogy, a RSA key is a wall made of sand, while an AES key is made of steel. Both can be strong enough to block an incoming rocket, but in the case of sand you will need more of the stuff.

AES accepts three key sizes (128, 192 and 256 bits); all three are fine. In fact, 128 bits are slightly better because AES-128 is slightly faster than AES-192 and AES-256.


Should I avoid this token-based authentication scheme (that's not OAuth)? I've dealt with OAuth before but I'm not too sure about the API I'm working with now. My question is basically, is this woefully insecure?

As I understand it, oAuth does the following (roughly):

Service X gives me a key and a secret
I ask the user to grant me access to service X
I send my key and secret to Service X to check. Service X gives me a request token, which I send over with the user.
User confirms they want to let me in, and the service sends them back to me with a token I can keep in my database, and use to make service API calls on their behalf
At some point the token expires, but the service knows who I am, so I can just ask them for a new one

However, the API I'm dealing with works like this (all over https, obv):

They give me an API key.
The user gives me their username and password
I transmit them to the service along with my API key, then discard them
They service sends me back a token I can use to make API calls on their behalf (using the token and my API key), which I store in my database.
At some point, the token expires and I need to get a new one so the user must re-authenticate.

Am I right in thinking that the main weaknesses of this scheme compared to OAuth are as follows?

there is no guarantee that the request comes from my server, so if anyone broke into my db, they could make API calls at will for all my users, using my API key, which they could get from analysing the POST I have to send when authenticating a given user
I have to go on reauthenticating the user with a password etc because it's basically just dangerous to have such data floating around
I'm obliged to provide an HTTPS connection for the user to type in their service password in the first place

It's not life-or-death stuff - it's not people's bank accounts etc - but it would be nice to be reasonably confident there won't be an Exxon Valdez dataspill.

Thank you for any help or advice.

This initially jumps out at me:  "The user gives me their username and password"

With their username and password you can do a lot of damage.  With OAuth it is easier to have granular control of access.


How to stay anonymous in public wireless network? If we are accessing a public wifi network, does changing mac address at certain intervals of time keep us anonymous forever? Is there anything other than mac address to identify a user in an AP?

Partly, yes...but mostly no - there are many other things that can identify you.

The Media Access Control address is used on the local network segment only. Yes, it is (supposed) to be unique to each network interface device, and sometimes can be changed/spoofed.

So to a slight extent, regularly changing your MAC address will provide you with some degree of anonymity against basic analysis on the WiFi network you're connecting to - they won't see the same MAC address twice in their WiFi controller logs. More advanced techniques (e.g. Packet inspection) will still be effective against you - see #1 and #2 below.

However, there is more to anonymity than just your MAC address. You may also want to be anonymous to the machines on the internet you're connecting to, or to any observers/agencies performing bulk surveillance:

HTTP connections are visible to the local network and internet. You might accidentally reveal identifying information by accident. For example, you might login to a poorly designed website that sends the username in cleartext. You might transmit a long-lived advertising cookie that was previously observed.
Your web browser might act in a unique way, or your machine might transmit a unique series of packets that allows your computer or browser to be identified. This is known as browser fingerprinting, or device fingerprinting.
You might physically visit the same WiFi location multiple times in an observable pattern. Even if no one sees you, the security cameras will. It would not matter how well you spoof your MAC address if there are other ways of tying you to the traffic.

To remain anonymous in the broad sense of the term, you need to consider every aspect of your actions. The WiFi network you connect to is only a small portion of what you need to consider.


Can information sent over unencrypted http still be seen if I'm on an encrypted wifi? I was booking a haircut online and noticed that when they made me sign up for an account, the credentials were not being encrypted (or at least that's what firefox was telling me).

It's not a huge deal because it's just an account that I use to book haircuts, but it got me wondering, how much of a security risk is this if I'm on a WPA2 encrypted wifi (and can be reasonably sure no attackers know the password)? Are there other points of attack at which the data could be seen besides sniffing the packets over wifi?

Your data would only be protected by WPA2 to the router. Beyond that, if it is not protected by TLS/SSL (HTTPS), your data was most likely sent in the clear. As for how much of a risk? Not much considering it is only used for haircuts. If someone had a network tap anywhere between the router and the haircut website, they could see your data in the clear.