Do SS7-based attacks affect landlines? I am aware of the risks of SS7 for mobile users. Attackers can get location information, send spoofed texts, cause DoS and intercept phone calls/texts.

Do those risks still apply for landlines? There is no roaming support, so I would assume call interception would be harder as the attacker wouldn't be able to say "this SIM is roaming on my network, send me all the calls!" to the home network's HLR.

In search of an answer to this question, I decided to do some research and see if I could find out myself.
Your thinking seems to be on the right track:

60 Minutes showed Karsten Nohl, a German computer scientist, remotely
attacking U.S. Congressman Ted Lieu’s cell phone and listening to his
cell phone calls... The spying was allowed by security bugs in the
global telecommunications network known as Signaling System No. 7
(a/k/a SS7), which allows carriers to connect so they can offer
roaming and texting. According to Nohl, SS7 will be used for the next
10 to 15 years until its replacement (Diameter) is implemented, and
Diameter is also vulnerable. — Landlines still a safe way to communicate but telephone companies want to drop them

Most of what I could find does not mention anything about landlines being affected. I can only find mentions of mobile phones being affected:

Who is affected by the vulnerability? Should a hacker gain entry to the SS7 system on any number of networks, or if they are used by a law enforcement agency as part of its surveillance, anyone with a mobile phone could be vulnerable. — SS7 hack explained: what can you do about it?

Another article detailing this issue mentions that SS7 is 43 years old but focuses exclusively on mobile technology that was hardly existent then.
President Trump recently made headlines as well because of the SS7 vulnerabilities.

Trump has been asked to give up his third iPhone but wants to keep it as “unlike his other two phones, he can store his contacts in it.” And while he’s encouraged to use the White House’s secure landline for conversations, he reportedly doesn’t want the calls going through the switchboard and logged for senior aides to see. US intelligence agencies believe spies from China and Russia are eavesdropping on Trump’s calls—even those using the secure iPhones—by intercepting them as they travel through national and international cellphone networks. — China and Russia are reportedly eavesdropping on Trump's phone calls: He's been advised to use the White House's secure landline

Note the mention of secure landline. The government uses encrypted landlines that ordinary consumers do not. It's possible ordinary landlines may also be somehow vulnerable. The article does not say whether an ordinary landline would be more vulnerable. Secure landlines have been mentioned in more than one article:

Mr. Trump’s aides have repeatedly warned him that his cellphone calls are not secure, and they have told him that Russian spies are routinely eavesdropping on the calls, as well. But aides say the voluble president, who has been pressured into using his secure White House landline more often these days, has still refused to give up his iPhones. — When Trump Phones Friends, the Chinese and the Russians Listen and Learn

The government currently uses Secure Terminal Equipment for its secure landline communications. This replaced STU-III, which was used from 1987 until 2008. To be clear, this is not technology that ordinary civilians would normally be using.
I do find this all a little ironic considering that Signaling System 7 was intended to replace in-band signaling, which allowed anyone with a tone generator to reroute calls on Ma Bell's analog long distance network. SS7 is still more phreak-proof in the sense that end-customers can no longer do that.

The SS7 system CCS-7, which dates to the 1970’s, is riddled with security vulnerabilities like the absence of encryption or service message validation. For a long time, it didn’t pose any risk to subscribers or operators, as the SS7 network was a closed system available only to landline operators — Primary Security Threats for SS7 Cellular Networks

Given that mobile phones were barely in use when Signaling System 7 replaced the multi-frequency based signaling system that had been in place since the 1940s, I don't think it's exactly fair either to say that SS7 was designed with vulnerabilities, because they weren't vulnerabilities at the time we transitioned to it.
To answer the question, the security risks seem to be mostly surrounding location and access to content on the device, and since none of that applies to landlines and I found references recommending using landlines to circumvent SS7 security issues (despite the fact they rely on SS7 for long-distance as well), I can say that landlines are certainly a much more secure choice and are likely not affected by it. If anyone else finds something, though, I'd like to hear it; there's very little circulating online about how landlines are affected.
Recent update:
According to NIST, landlines may not be immune after all:

The U.S. National Institute of Standards and Technology (NIST)
announced in July 2016 that organizations should no longer send one
time passwords to mobile phones. The reasoning? This approach is
simply not secure. NIST—which both corporations and U.S. regulatory
agencies look to for cybersecurity compliance—determined that thieves
can too easily steal one time passwords sent to phones via SMS text
message. (The same applies to voice codes sent over landlines,
according to the agency.)


Why do I need two parameters in an HTTP parameter pollution attack? I'm reading about HTTP parameter pollution and I'm confused about one thing. If there is an endpoint like this,

https://security.stackexchange.com/editpost/?postuid=19348

and you tried a HPP attack, that looked like

https://security.stackexchange.com/editpost/?postuid=19348&postuid=1

Wouldn't the backend still try to verfiy that it's your user's post you're trying to edit? through the cookies you send along with the request

Why could this work,

https://security.stackexchange.com/editpost/?postuid=19348&postuid=1

and why can't you just edit the URL like this?

https://security.stackexchange.com/editpost/?postuid=1

The idea would be that different parts of the server code interpret the request in different ways, resulting in an application that is vulnerable to HTTP Parameter Pollution.

For your example /editpost/?postuid=19348&postuid=1 the query string would be parsed differently for the code parts that carry out authorization (those would have to check for authorization on postuid=19348) and actual editing (those would have to edit for postuid=1).

This isn't a regular problem in modern web applications because parameter parsing is done by the framework usually, in (modern versions of) php for example, $_GET["postuid"] would contain the same value for both code fragments, making a HTTP PP attack useless.

HTTP PP used to be a big problem (and still is, whenever this is the case) when parameters are parsed "by hand", i.e. on the application logic layer. That opens the door for different people implementing this parsing differently.


Why aren't we using multiple algorithms to protect against attacks like SHAttered? Simple question: Both MD5 and SHA1 are susceptible to a collision attack. It's reasonable to assume that SHA256, the next algorithm we're switching to, also has such an issue, but one that's hidden because of the requirements to find such a collision.

The thing is, why don't we use multiple algorithms to verify file integrity? like, calculate multiple checksums using multiple algorithms for the same file and only declare it acceptable if all of them match? I mean, finding a collision for MD5 right now is doable on smartphones, and finding one for SHA1 has been proven feasible with the SHAttered attack. however, if you had to find a collision for both MD5 AND SHA1, wouldn't that increase the time needed as well?

Clarification: While this particular suggestion may actually be in use in places, what I'm talking about is: why isn't this technique commonly proposed as an alternative to upgrading to SHA256?

Using multiple hash functions is simply the same as defining a new hash function, only much slower than a "better" secure hash and with little justification for the design.

So while it might indeed be harder to find a collision in your ad-hoc H(x)=MD5(x)||SHA1(x) than finding a collision in the components, it is far less efficient and likely less secure than purpose-built functions like SHA2-512 or SHA3-512. Even SHA2-256 has shown no weakness in the last decade of cryptanalysis.


Crosswalks (aka Matrix) for InfoSec Compliance Standards Looking to find a reference that maps the various control standards (i.e. HIPAA, PCI-DSS, GLBA, ISO) to each other.

I envision the answer being a spreadsheet that outlines the controls for one standard (say ISO-27002) as row items and the other standards (PCI, HIPAA, GLBA) as columns with the relevant control number:

ISO | Desc                  | PCI | HIPAA | GLBA
-------------------------------------------------
A.1   Data Classification    3.2.1   I.8     2.7
A.2   Asset Management       3.6.1   283.1   7.9

etc...

Here are a few examples of what I'm looking for, but something more comprehensive that includes all of the standards:

http://www.qcert.org/sites/default/files/public/documents/cs-csps_mapping_nia_policy_iso_27001_pci_dss_v3.0.pdf
https://www.informationshield.com/papers/ISO27002%20PCI-DSS%20V3%20Policy%20Map.pdf

Are you familiar with the UCF Common Controls Hub at https://commoncontrolshub.com/? It allows you to create an "Authority Documents List" using your example standards and download a spreadsheet that lets you compare them and identify gaps and overlaps. Very cool.


Will a search page vulnerable to XSS affect other users? If I manage to enter javascript in a website search bar that will then run the javascript on the results page, it only runs on my local session in my browser right? So unless the website stores my javascript-filled query and displays it elsewhere to other users, it won't do anything to other uses will it?

When you enter something in a search bar and it gets executed, it is called reflected XSS because the payload is reflected from the URL (e.g. https://example.com?search=[javascript code]). If it would be stored and displayed to others later it would be what is called, well, stored XSS.

I read your question to be something along these lines: "Is reflected XSS really that dangerous since it only runs on my computer?"

You are correct that reflected XSS will only run in the browser of the person who visit the link - in this case you. Doing refleced XSS on yourself is a bit pointless, since you only need to hit F12 to fire up a console if you want to run some JavaScript on your own machine.

But now think about what happends if you craft an URL that you fool others to visit (send it in an email, post it on Twitter, post it on a forum, etc). Now the JavaScript will be executed in their browser. You could create a link that will log passwords entered by the user who clicks it or steel that users cookies. That is dangerous stuff.

So while stored XSS is arguably more dangerous than reflected XSS, reflected XSS is still a serious issue that should be fixed promptly if discovered.


DDoS using websites instead of bots? What if a ddos attacker hits public websites (google, amazon etc) with some requests but spoofed the souce ip to the victim's ip. Now the responses will be sent to the victim's ip.
Attacker can rotate between the millions of public websites so that the site wont find anything suspicious.
This seems like an easier way than having a malware botnet to do it. The attacker is just using the websites as botnet. Anyone can just do it with the personal computer (or faster and high bandwidth aws/azure VM) and with just 10-20 lines of code.
Why ddos attackers are not doing this instead of buying botnets?

What if a ddos attacker hits public websites (google, amazon etc) with some requests but spoofed the souce ip to the victim's ip. Now the responses will be sent to the victim's ip.

The protocol used for web sites is usually TCP based, i.e. HTTP/1 and HTTP/2 are both TCP based. While spoofing of TCP is theoretically possible the necessary bandwidth for this wildly exceeds what gets reflected back, i.e. it is not really usable for an DoS attack since the attacker needs much more bandwidth by its own than what the DoS target receives.
HTTP/3 instead is implemented on top of the QUIC protocol which itself is implemented on top of UDP. While UDP by itself is vulnerable to easy IP spoofing the QUIC protocol makes sure that it cannot be used for amplification. With QUIC (and thus with HTTP/3) the attacker needs at least as much bandwidth by its own than the DoS target should receive.
In other words: web based DoS using IP spoofing will work worse than what would be achievable if the attacker directly attacks the target and will work much worse than use of a Botnet.
See also Is it possible to send HTTP packet via spoofed IP?


How Safe Are Encrypted Websites Really? I was at a coffee shop and had to (I mean had to) check something on my bank account and another account. I figured since the two websites I was viewing were encrypted, and because my computer (I'm on a Mac) has a firewall, and I don't share through a cloud or such, that my information is safe. Google is encrypted from the moment that you search, and I connected to the actual wifi of the coffee shop (I had to accept their terms in order to do so).

So I was using HTTPS the entire time. I contacted the bank tech support and they confirmed that their whole website is completely encrypted. Same with the other account. Was I safe? There was a person nearby who looked as if he was doing something suspicious on his computer as far as hacking/networking.

I'm an enterprise penetration tester for my company, and breaking into systems is what I do day in and day out.  I'll share some of the techniques I use to perform man-in-the-middle attacks, to give you an idea of what to look for (as well as how to defend).  If none of these scenarios sounds like something you encountered, then there's a significant majority chance that your encrypted communication wasn't compromised.

HTTPS is only as secure as the dependencies it was built on.  In typical circumstances, HTTPS does its job just fine.  However, when one of the foundational requirements isn't met, it is vulnerable.  Breaking just one of the links in the chain can compromise the communication believed to be encrypted.

Attack using tools such as BEAST, CRIME, and/or BREACH tell us that knowing some plain text in the message being protected allow the encrypted tunnel to be reversed/broken.

Attacks involving the Heartbleed vulnerability are another example of a flaw in the SSL protocol that allows attackers to retrieve data which should have been encrypted.

Attacks using a rogue wireless access point and a tool like SSLStrip show us that just because we typed "HTTPS" doesn't mean it'll be there the next time we look.  This is a very simple to implement attack scenario which returns a significantly high degree of success (I typically see ~90% success rate from the penetration tests I'm asked to perform).

Yet another way would be for a hacker (read: not a law-abiding penetration tester) to break into a certificate authority and generate working certificates for sites they wish to intercept communications for.  A hacker a few years back who called himself "Comodohacker" compromised multiple certificate authorities, which are the businesses/organizations which issue SSL certificates for the websites we connect to via HTTPS.

Finally, a simple but incredibly effective attack would be to generate a self-signed cert.  The cert will "technically" good, but the CA will be untrusted.  From a computer user's perspective, all you will see is a message saying that the Cert is good and the CA is unknown, with a yes/no box asking "Do you want to proceed?".  In an attack scenario, after the user clicks yes, they would see that the communication channel is HTTPS, but won't know that they are connected to a rogue internet proxy that's intercepting and decrypting traffic.   (Note:: This technique commonly used for legitimate purposes as well, such as a corporate SSL proxy scanning all outbound communication for company IP and trade secrets.  The difference there is that the org will typically add the signing authority to a list of trusted authorities on the company owned computers to prevent the message box from popping up.)

Of the scenarios above, the CA compromise is the worst one in this list due to it being undetectable directly.  For that reason, and also since it's not very common anyway, I don't worry about it.  The others are what need to be looked out for.

BEAST and successors are now client side attacks.  Most of the vulnerabilities they exploit can be mitigated by keeping your operating system, internet browser, and other software up to date.  This has to be done on a regular basis.

The Heartbleed vulnerability was more than just client side.  Servers deployments of OpenSSL  on every popular website were equally as vulnerable.  If you're patching regularly, I also wouldn't worry too much about this one.  Most successful attacks against this vulnerability were made against servers owned by websites (i.e. nothing we can do but change passwords).

The last scenario (the self-signed cert) is typically the most dangerous threat to look out for on this list.  While there are legitimate uses for the technique itself, I personally do not care.  I never click yes when asked to trust an unknown certificate authority, and I'd recommend anyone else do the same.

One side note in case it's relevant - I personally wouldn't use the Safari internet browser.  Apple finally patched their browser in November of last year for the BEAST exploits, but it took them more than 2 years after the BEAST exploits were released to do so.  Even though Safari is patched currently, I'm concerned about their lackadaisical approach to IT Security.


Extracting Individual Records from NTDS.DIT I am working with an extremely large NTDS.DIT file. It is about 20gb.

Originally, I was attempting to dump all of the hashes from the NTDS.DIT file. I tried using meterpreter domain hash dump, smart hash dump, and just simply hash dump on the domain controller. Each time, I received errors from Meterpreter.

Once I ran into this, I used the shadow copy trick and got a copy of the NTDS.DIT file, and began to extract all of the hashes (using libesedb and NTDSextract). However, it has been almost a week, and even though libexedbexport is still running, I am hoping I can get some information quicker than 3 weeks (currently on pace for 3 weeks).

So my next step is trying to extract individual records based on username. I've done some googling, but I haven't been able to find any method of extracting just one or several hashes more quickly.

Is this possible? Is there an application that I can use to do this? Any help would be appreciated.

Here is one method, and the bonus is that it is all done remotely -- https://www.dsinternals.com/en/retrieving-active-directory-passwords-remotely/

The author also shows how to dump the whole thing, but of course this isn't recommended. You could also copy the dit file locally, split(1) it, and then exfiltrate the files piece by piece.


Prevent CSRF on public website with no login I am working on a web project that let a person send a request form to my API.
Every visitor can send a request through that form without login.

Currently the API generates a token when the page is first opened, and the token is then sent back with the POST request form.
But that one token can be used to send another POST request. Even worse if an attacker knows the token, they can send a POST request with some script without visiting the website anymore.

Currently I invalidate the token after some period of time. But in that mean time, the attacker can send multiple request with an ajax script.
I intend to invalidate the token after each POST request, but that doesn't prevent the attacker to send multiple POST request because they can also request a new token before each POST request.

Is there any way to stop an attacker from sending multiple request from a malicious script, without using the form on my website?

First of all, this is not request forgery, since there is no logged in session to take advantage of.  It makes little sense to trick a user into submitting a form on your behalf.

That said, a standard CSRF cookie would do the job.  Generate a unique value for the cookie you already use, on each request.  Then check that it is only used once.


SQL injection across multiple tables If a website has multiple web apps, each of them connected to different tables in a database and all of the apps are protected from SQL Injection except one; can that one web app be used to read/modify/attack other tables in the database through SQL injection?

Yes, depending on the underlying database security a single SQL Injection attack can affect other tables in the same database and even tables in different databases or in very specific cases tables running on different database instances.

It is even possible to update/read from multiple tables at one time using a single database query.  Since you tagged your question as mysql here is a MySQL query for updating multiple tables:

UPDATE Books, Orders
SET Orders.Quantity=Orders.Quantity+2,
Books.InStock=Books.InStock-2
WHERE Books.BookID=Orders.BookID
 AND Orders.OrderID = 1002;

Reading is as simple as using a JOIN:

   SELECT t1.name, t2.otherColumn
   FROM Table1 as t1
   LEFT JOIN Table2 as t2
   ON t1.id = t2.id

Obviously the effectiveness of these queries will depend on the underlying table structure, but you can absolutely read from unintended/multiple tables using SQL Injection.

An example of when this would not be possible is if the tables in question all belong to different schemas, each with a specific account that can access.  Example:

app1.ImportantTable
app2.OtherTable
app3.BigTable

If each of these schemas is configured to only allow a different user access then there can be no unintended access.  So if there is a App1User setup in the database that can only read/modify the app1 schema, it will not be able to select data from tables in the app2 schema.


Can phone services be affected by DDoS attacks? Phone lines run on servers, people like to overload servers with botnets. Can a phone line be affected by a DDoS attack?

Realistically, there are so many ways to make a phone botnet, so would a phone botnet realistically be able to cause a DDoS attack to phone lines?

I imagine if it was possible to DDoS a companies support service phone lines, it would be all over the news but then again, what do the news know about hacking?

A denial of service with local impact against a single or a limited number of phone lines is easy: just call them and if they drop the call then call again. As long as you call them the line is blocked for any other calls, i.e. denial of service. Even phone numbers which can handle multiple calls at the same time (for examples emergency lines) can be flooded. This process can be easily automated, both for modern VoIP lines and also for old POTS lines (which can be usually reached by VoIP too). It does not even need to be distributed, i.e. with VoIP a single computer can be used to keep multiple calls at the same time open.

For more information see the numerous hits you'll find when searching for phone denial of service or voip denial of service, like:

Krebs on security: DHS Warns of ‘TDos’ Extortion Attacks on Public Emergency Networks
Cisco: The Surging Threat of Telephony Denial of Service Attacks


User-friendly TLS certificate validation I'm designing an application in which clients generate their own TLS certificates ad-hoc (there's no central authority).

When two clients interact for a first time, I need for them to mutually check their peers' certificate. I know that fingerprints are generally used for this, but I need to keep this more newbie-friendly, hence having them check 20 hex characters (SHA-1) doesn't sound very convincing.

I though about representing the same fingerprint with the characters 0-9a-zA-Z (giving me 62 characters to represent the same value), but it's still 13 digits long.

Is there any common (or maybe not as common) way of having two users validate their mutual certificates? This is a real time, low-latency application, so multiple round trips are possible.

EDIT
Users can exchange information in person in this scenario, so saying (or showing) a code to one another is possible. However, I'd like to avoid them having to eyeball 20 characters and manually check them, mostly for user-friendliness.

Here's three ideas.

Use a CA
As the commenters already said: Have them trust a CA. It's less painful. And it scales much better. Each participant will only have to verify the CA's authenticity once and then they can communicate with every other participant. (Then of course, you will have to trust the CA, very, very much. -- But I consider this a good trade off in your case.)

Human-to-Human audio method: Use the PGP word list
If you really want the "1-to-1" individual verification, then use an octet word list. It maps each hex byte (0x00 to 0xFF) to one or more words.
PGP has done this:
Wikipedia: PGP word list

Machine-readable image method: Use a QR-code
One instant-messenger that I use is called "Threema". And they emphasize end-to-end-security and you don't need to trust a CA. Alice doesn't need to verify Bob's key in order to IM him. But if Alice wants to verify Bob's key, then both meet face to face and Bob presses a show-my-key-as-QR-code button in the app. And Alice selects Bob's contact data and then presses the scan-that-person's-key-via-QR-code button.

(There are three levels of trust in the app. The best level of trust is reserved for the people you have met face to face. Weblink: Threema Levels (Archived here.))


Security issues for a Java program that is a consumer of streaming radio Are there any security issues I should be aware of when opening a Socket connection with the url/port of a streaming radio station?

I have written some code to do this (no web stuff, just some Swing/awt and a Socket connection); Now I am beginning to wonder if there are any security vulnerabilities that I should be aware of.. Any comments on this will be appreciated.

You can simply use SSLSocketFactory instead of SocketFactory for your client server application. That way, the communication between the two will be totally encrypted. You can secure your client server app in less than a day, if you know basic Java. Here's a tutorial.


Is this FTP transfer secure? Do I need a new FTP client? I am using a very old FTP client.  I have checked the "secure (SSL)" box in the connection editor.  As far as I know, the server supports explicit FTPS but not implicit FTPS or SFTP.

When I log in and do a transfer, I see an "AUTH SSL" command, but no PBSZ or PROT lines.  Here is a sample:

Finding Host ftp.softronics.ch ...
Connecting to 62.2.182.131:21
Connected to 62.2.182.131:21 in 0.087, Waiting for Server Response
220 ProFTPD 1.3.3a Server (Softronics FTP) [62.2.182.131]
Host type (1): Automatic detect
AUTH SSL
234 AUTH SSL successful
USER <DELETED>
331 Password required for <DELETED>
PASS (hidden)
230-8278412.12 KB used - authorized: 15728640.00 KB
230 User <DELETED> logged in
SYST
215 UNIX Type: L8
Host type (2): UNIX (standard)
FEAT
211-Features:
 XSHA256
 MDTM
 MFMT
 TVFS
 AUTH TLS
 UTF8
 MFF modify;UNIX.group;UNIX.mode;
 MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
 XSHA1
 PBSZ
 PROT
 SITE MKDIR
 SITE RMDIR
 SITE UTIME
 LANG bg-BG;ko-KR.UTF-8;ko-KR;en-US;zh-TW;fr-FR;ja-JP.UTF-8;ja-JP;zh-CN
 SITE SYMLINK
 REST STREAM
 XCRC
 XMD5
 SIZE
211 End
PWD
257 "/" is the current directory
CWD /Backups
250 CWD command successful
/Backups  loaded from [Directory Listing Cache]DIR51BB.tmp
Starting request
TYPE A
200 Type set to A
PASV
227 Entering Passive Mode (62,2,182,131,230,178).
connecting data channel to 62.2.182.131:59058
data channel connected to 62.2.182.131:59058
STOR avgsugarPrint.csv
150 Opening ASCII mode data connection for avgsugarPrint.csv
transferred 4392 bytes in < 0.001 seconds, 34312.500 Kbps ( 4289.063 KBps), transfer succeeded.
226 Transfer complete
Transfer request completed with status: Finished
PWD
257 "/Backups" is the current directory
PASV
227 Entering Passive Mode (62,2,182,131,216,236).
connecting data channel to 62.2.182.131:55532
data channel connected to 62.2.182.131:55532
LIST
150 Opening ASCII mode data connection for file list
transferred 11296 bytes in 0.270 seconds, 326.833 Kbps ( 40.854 KBps), transfer succeeded.
QUIT
221 Goodbye.

What is happening here, as far as security goes?  Is it good enough?  Are the username and password being sent encrypted?

Thanks.

D.

Username and password are protect since the control connection is switched to TLS using AUTH SSL before the login credentials are sent. But it is unknown how good they are protected, i.e. if they are protected with a strong or weak cipher and if the servers certificate was checked properly. Especially properly checking the certificate is a well known problem and since the client is old chances are high that no check or nor proper check is done and the connection is thus open to man in the middle attacks.

Apart from that no PROT command is issued which means that the data connections (i.e. directory listing, transferred files) are not protected.


Google Accounts login - is it good enough for financial services? I am wondering - is using Google Accounts login (in a setup similar to this) secure enough for financial services (you can assume that if someone logs into your account, your money gets stolen)?

On one hand, if you tell the users to create a new Google Account for the service, add 2FA and so on, you would be relying on a company with a lot of experience to prevent unauthorized login attempts. At the same time, some people will use their main Google account to log into everything and their accounts will probably get compromised, and rolling out your own solution means you have to play catch-up with years of security expertise and new vulnerabilities.

What is the consensus on how secure Google Accounts login is in this scenario?

No.

I'm not even talking about whether it's good enough for finance or not, I'm just saying if Google is the only way to login to your service, then I won't use it, and neither will do other privacy-conscious users.

Now, on the technical side. Using third-party logins is less secure because a failure on the third-party site will also affect yours, and the third-party site can itself impersonate any of your users. With your own login, you only have to defend your infrastructure. With third-party logins, you have to defend your infra and hope the third-party's infra is secure.

On a legal side, having your own login system means you have better control and auditing over who did what and when, where as with Google (or any third-party service) all you have is "someone pretending to be X logged in at that time from this IP". Whether they did password recovery beforehand, or had 2FA enabled is something you don't know and can't enforce. When something goes awry, you won't be able to prove it's the user's fault of not securing his account well enough and will have to pay, where as with your own system you'll be able to say "at X in the morning someone reset your password and you didn't have 2FA enabled. Sorry, it's not our fault, now you better work on securing that email account".

Finally, secure logins aren't that hard. Correctly hashing passwords, not doing stupid mistakes like sending the password in emails, using captchas to thwart bruteforce, locking out IPs after multiple failed logins and providing 2FA using standard protocols is all you need to be secure. In comparison, this is what my bank's login process looks like :

Yes. My bank is one of France's largest banks, and their login consists of an 8-digit user ID followed by a 6 digit (no letters, that would be too much to ask) secret code, that you have to enter in a cute little security theater because according to their "experts" someone capable of keylogging isn't capable of taking screenshots of where you click. There is obviously no 2FA, and I wouldn't be surprised if the secret code was stored in plain text. The only good thing is that they lock out IPs after 5 login attempts, but that's about it.

So assuming you do everything I told you above, you'll be more secure than one of the largest banks here; as a little extra precaution you may use a random user ID instead of something known like an username or email (but that makes the user remember two things instead of only the password, which in turn may make them choose a weaker/easier to remember password or to reuse one they already have).

Of course, security of logins isn't the only thing you need to do especially on a finance website. You should also make sure your own servers are secure, so you need to have IDS, monitor every service, check logs often and prepare to act quickly if something appears fishy.


Setting up a secure modem & router with ISP I am looking to setup new internet service with an ISP and would like to purchase my own secure modem and router.

Googling doesn't seem to give me the list of what I'm looking for, are there any router/modem suggestions for someone just looking to preemptively secure his network as much as possible from the get go?

Also, please add or change this list of things that I could use to help with added security:

Encrypt with WPA-2 with AES
Hide your network name
Turn off UPnP (is this easy to do?)
Setup a guest network for guests and IOTs
Turn off WPS
???

Encrypt with WPA-2 with AES: Make sure the router you get has that capability. Most do, since WPA-2 has been around a while.
Hide your network name: A setting in the wireless router. Hide "SSID" or similar. Also, most wireless router will have this. Users will have to manually input the SSID however.
Turn off UPnP (is this easy to do?): Yes. Another setting in the router. Turn it off. Enabling UPnP is not advised, as you have surmised.
Setup a guest network for guests and IOTs: Good idea, make sure wireless router has these capabilities.
Turn off WPS: Just make sure WPA-2 is on for each wireless interface. If you select WPA-2/AES as the auth method, that's the only way anyone will be able to connect.
???: If you really are serious about security, put a UTM firewall behind the ISP equipment instead of a router. The SonicWall SOHO 250 Wireless N Base Security VPN Firewall can do what you want plus much more, and is reasonably priced.


Are there any security concerns for CGI scripts written in pure bash? I'm working on a project that would use bash and FastCGI to create a pseudo-CMS.

Are there any kind of security concerns to watch out for within FastCGI itself over a well written bash script (for example buffer overflows, and the like)?

Buffer overflows aren't really relevant to bash. Something you do need to take care of is input validation. You need to validate all user input to prevent any form of injection.

You should have a look at the OWASP Testing guide as they cover all sorts of vulnerabilities relevant to web applications. It's largely language independent although the examples might be more focused on real programming languages designed to write web applications.

P.S. I really need to know: Why are you writing a CMS in bash?


how much time does it take to fully destroy a deleted video from SD card? I have deleted a video from my SD card six months ago. How much time does it take to fully destroy this video file on the SD card? If I wanted to recover this video, is it possible to recover?

When you delete something from an SD card (or most mass storage media) it doesn't actually get deleted. The space on the card where the file is stored is simply marked as unused and will be reused when space for a new file is needed.

Whether or not the file can be restored with data rescue software depends on how much new space was needed in the meantime for creating new or enlarging existing files.

If there were no write operations on that SD card after the file was deleted, then it is very likely that it can be recovered. But if someone created a couple new files on the card in the meantime, then there is a good chance that some or all blocks of the deleted video were overwritten.


localhost to localhost ICMP traffic that is suspicious.. any idea of what is creating this? I keep seen this on my tcpdump output.. is prob something very simple and logical but I can't see to see any process with lsof or netstat doing a ICMP request to it's own 127.0.0.1 every 2-3 secs... anyone have any idea of what is creating this? thanks in advance..

tcpdump -i eth0 ! port 22  and ! port 2222 and proto ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
05:18:27.467081 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 369
05:18:27.467083 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 369
05:18:27.476988 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 369
05:18:27.476991 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 369
05:18:27.496957 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 369
05:18:27.496959 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 369
05:18:27.516949 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 369
05:18:27.516951 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 369
05:18:27.817068 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 374
05:18:27.817070 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 374
05:18:27.836987 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 374
05:18:27.836989 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 374
05:18:27.846966 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 374
05:18:27.846968 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 374
05:18:27.866970 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 374
05:18:27.866972 IP localhost.localdomain > localhost.localdomain: ICMP localhost.localdomain udp port 37064 unreachable, length 374

As per this StackExchange answer, you can find it using lsof by looking for st=07 on a raw socket:

# lsof -n | grep -i st=07
ping      19241            gowenfawr    3u      raw                         0t0     477269 00000000:0001->00000000:0000 st=07
# ps aux | grep 1924[1]
gowenfawr    19241  0.0  0.0   8596   832 pts/0    S+   07:26   0:00 ping localhost
#


Why is there no web client for Signal? I’ve read about E2EE (end to end encryption) of Signal in web clients on a Signal Community discussion forum, and wonder why they say that the browser is insecure for E2EE and native apps are secure.
I think the security issues for clients are the same. It can be harder in various systems based on their security polices, but all of the clients are prone to various attack surfaces like MITM, viruses and rats and other malware. And something more important they emphasise is the delivery for javascript files, but doesn’t that use HTTPS? I guess if anyone could break the HTTPS security they can do anything more dangerous than what we think about.
We want to develop some chat service like Signal with a web client, but this article confused us. Should we ship a web client or not? Please explain this.

Yes HTTPS is used. The thread doesn't say that the web app will be completely insecure, instead it says

This effectively reduces the security of your end-to-end encrypted communication to that of your SSL connection to the server

Which means that anyone who can control the SSL connection to the server can now intercept and break your e2ee communications. So who exactly can control the SSL connection?
Well, if a (state-level) attacker controls/compromises a CA, they could issue a fraudulent certificate for the Signal server and attempt to MitM the SSL connection (this threat is limited by the use of certificate transparency.) As @multithr3at3d pointed out, TLS inspection proxies at workplaces are a much more likely form of MiTM and could cause problems if your employer was interested in compromising your private conversation. However, in such a case, the employer owns the machine and would probably just install a keylogger on it, so you have bigger problems.
However, the larger threat here is that the SSL connection, as well as the content being served, is controlled by the Signal server. This means that if the server is compromised or goes rogue (which can easily be achieved by a government serving Signal a subpoena or the like), then it can easily modify the js files served to the client in a way that allows them to intercept the communications. This effectively defeats the point of end-to-end encryption, which is that nobody other than the sender and the recipient should be able to read the contents of the communication, since the server now has the power to compromise the communications at will.
This threat is amplified by the fact that such malicious modification of the code served can be done in a targeted manner. The server can ensure that only a specific user/client is served the modified malicious code. This significantly reduces the chances of the modifications being detected and exposed.

Actually we want to develop some chat service like signal with web-client, but this article made us confuse about should we ship a web-client or not, can anybody please explain it?

This depends on your threat-model (or rather the threat-model of those who will be using your chat service). Will those people just be using it for chatting with friends or communicating with colleagues? Or will it be used by whistle blowers trying to coordinate the disclosure of classified information with journalists? You will have to consider whether the risk outweighs the benefits and decide for yourself whether or not to ship a web client.
If its the former, then having a web client will not be a very big issue. This is closer to the use-case of WhatsApp and WhatsApp does have a web client.
If its the latter, then you had best follow Signal and stick to using desktop clients and apps which can be signed and their integrity verified.

As evident from the comments some people are confused about why these issues don't apply to the app and desktop client.
The reason is simple. The app/desktop client has to be downloaded once. It is also digitally signed so its integrity can easily be verified. If you are paranoid, you can also download Signal's publicly available source code and compile it yourself. If Signal attempts to publish a malicious update, they will have to publish its source code as well, and the chances are much higher that someone will notice the unexplained changes before any damage happens.
With a web app things aren't so simple. First of all, even if the web pages are digitally signed, checking their integrity and ensuring they match the publicly available source code every time is absolutely impractical. Secondly, a web app consists of several web pages. Checking the integrity of all of these even once would be a painstakingly difficult task.


There a few differents way to do this:

On windows there are the tool windiver who can modify packets on the fly
You can also use a virtual machine with Linux to use several tools like netsed, hexinject, proxyshark, mallory,...
On the Linux VM, you can use MITM framework which have many features like intercept packets on the fly and edit it, sometimes it can inject shellcode in binary,... One popular framework is MITMf


Is JQuery in chrome extension a security concern? This is the relevant part of my manifest.json file:
"content_scripts": [
    {
      "css": ["style.css"],
      "matches": [
        "<all_urls>"
      ],
      "js": ["jquery-3.5.1.min.js", "content.js""]
    }
  ]

I noticed that now I have jquery on every page I go to and I was wondering if it's a security concern.
I don't do anything fishy but I wonder whether some sites could try to exploit having jquery in scope.
My extension is supposed to work on every page so I can't blacklist certain sites.
I downloaded jquery from the official CDN once and it's now in my extension.

No, you don't have to worry about it.
Having jQuery in your extension doesn't pose any security risk. Javascript is used to run the code on the client-side of the browser if any malicious website wants to run JS on a system, they can embed it within their evil website itself;  They don't have to rely on an extension to provide jQuery to do malicious things.
As @pcalkins pointed out in the comment, the browser is sandboxed and even extensions cannot execute anything outside of that.


Is simple authentication safe if over HTTPS? Background
For my app I need to know if users have entered the correct email password combo. Pretty common stuff. I'm using HTTPS, and salting and hashing the passwords.

Question
Now, what I am wondering is if I should literally respond from my server with JSON that says successfulLogin:true/successfulLogin:false?

My thoughts
To me that seems fair, but I am not certain if this would be easy for someone to fake and send. Something else I am doing is that I'm sending a key with the POST so that the PHP script will only run if its key and that key match.

Authentication

The server must take care of the state (e.g. is the user logged in or not), not the client. While it is perfectly fine to send JSON with information about the state (e.g. yes, you are logged in) over HTTPS, it is the server that must remember if the particular user is logged in or not. The server can never trust the client.

The way you do this is to use a session variable on the server, i.e. a variable connected to this particular user, that keeps track on if she is logged in or not:

$_SESSION["loggedin"] = true;

Then everytime the user requests information that should only be available for logged in users, you need to check that this session variable is indeed true. That way it does not matter if someone fiddled with your JSON response - unless they provided the right password the server will still not view them as logged in.

Read more about sessions in PHP here and here.

One more thing - if your client holds sensitive data that should not be made available to the userunless the server authanticates her then this is quite a different situation, and you would need to take further precautions. The same is true if the client performs actions on behalf of the user.

Sending key in POST

  Something else I am doing is that I'm sending a key with the POST so that the PHP script will only run if its key and that key match.

Not sure what you are saying here. This could be completely superfluous, but I am not sure I understand it correctly.

Rolling your own

Keep in mind that doing a complete authentication system is not easy. There are loads of pitfalls other than those covered in this post. Instead of rolling your own, I would suggest you check if there is some existing PHP framework that you can use.


Top 10 dangerous mistakes in C programming? What is the top dangerous mistakes in C programming?

for example misusing a strcpy causes a stack-overflow and code injection.

I'm looking for at least 10 bad programming pattern in C.

The topmost dangerous mistake in C programming is using C. This is an unpopular assertion, but decades of experience back me up.

C is a nice programming language in that it allows you to express operations in an "abstract machine" (that's how the C standard puts it) which will get translated efficiently into machine code (the translation tools runs fast and the result is fast). However, this translation comes at a high price, namely that they are no safeguard for mistakes, and there are a lot of "undefined behaviours" lurking in the shadows. Pointer aliasing rules, for instance, are almost never understood correctly, leading to seemingly good code which will fail (sometimes in ways which create exploitable vulnerabilities) when a newer compiler is used or an optimization switch activated.

Looking for a "list of mistake" is the wrong mindset. You want a blacklist: things to avoid, under the assumption that "everything else" is safe. You should want a whitelist: a list of allowed ways to develop, at the exclusion of everything else. Successful C programmers are programmers who are able to maintain their own discipline to never use any construction that they do not master from end-to-end; and by "mastering" I mean the ability to describe how the C compiler will translate that into assembly opcodes, including all the possible optimizations that C compilers are allowed to make.

A good way to "use C" is to write the one or two routines which really need speed in some optimized C, and the rest of the code in a safer language which will allow for faster, easier and safer development (e.g. Python, C#, Node.js, Perl... the choice is large).


OpenID Connect: How to maintain a single sign-on experience between multiple web clients of the same umbrella application? I'm considering how to take a fairly complex tiered application with multiple web apps that delegate back to the same application server, and migrate it to use OIDC authentication with auth code flow. I am anticipating using identity server 4.

My question is: what would be accepted best practice in terms of maintaining a single-sign-on experience between these different web client applications (i.e. user signs into one, she's signed into them all until she signs out).

https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis suggests:

  Note that the audience (aud claim) of the [id token] is set to the client's identifier, which means that only this specific client should consume this token.

This suggests that I should consider my backend application server to be my single 'client', and have my web apps share that same client ID. I can imagine doing this by storing the id token browser-side in a secure cookie.

https://connect2id.com/learn/openid-connect seems to validate this idea:

  Put into a browser cookie the ID token can be used to implement lightweight stateless sessions.

But I wonder if it's security best practice to keep an id_token in a cookie.

I wonder if there are any other approaches - like:

Considering each web application a separate 'client'
When the user logs on to a second web application, have them direct back to the OIDC provider, which would automatically create a client token for the new client based on some notion that they are still basically 'logged-on' to the OP.

It seems like this must be a solved problem. What is accepted best practice here?

You essentially get SSO out of the box with IdSrv4.  Once you're logged in to IdSrv, your browser will send the IdSrv cookie together with each request to IdSrv.  So when your first web app sends an auth request, you'll be asked to authenticate at level of IdSrv - at that time, that auth cookie is created and (depending on the flow you're using) a code and/or tokens are returned to your client app.  When your second web app sends an auth request to IdSrv the browser sends over the auth cookie together with that request, so you will still be authenticated at level of IdSrv (assuming the cookie hasn't expired) - code and/or tokens will automatically be returned to your second client without the user having to provide his/her credentials again.

I would advise against reusing the same client ID (and thus client secret) across various web apps: in case the client secret is exposed for one web app, it's exposed for all, and that's something to avoid.

The identity token is typically very short-lived - the only reason to hang on to it (after using it to authenticate at level of your client app) is to pass it to the endsession endpoint as an id_token_hint when you're logging out.

Hope this helps :)


Is it safe to call an untrusted service with jquery.ajax and dataType 'jsonp' From what I understand, the JSON-P technique generates a script tag into the DOM of an HTML page to get across the single-origin restrictions imposed on the XMLHttpRequest JavaScript API for AJAX calls to web services not supporting CORS. Usually, the script embedded in this way only contains a callback and in this way transfers the JSON payload that I'm interested in. However, AFAIK the called JSON-P service could also deliver arbitrary JavaScript and in this way hijack my webpage.

I'm wondering if I really have to trust the JSON-P service provider not to do this? Or do JavaScript libraries and/or browsers sanitize the JSON-P responses and in this way prevent these kind of attacks?

For example for the JQuery ajax function, the use of JSON-P is enabled by setting the rather harmlessly looking attribute dataType: 'jsonp' - so maybe these kind of calls are not as bad as I think they are?

No it is not safe. You are correct that the JSONP service could deliver arbitrary JavaScript, which is then executed as part of your site.

Because JSONP is essentially a hack to get around the same origin policy, it is not possible for a JavaScript framework to perform sanitisation.

These days, CORS is the preferred way to call external sites. An alternative approach is to have a server-side script on your site that proxies calls to external sites.


How does the mobile security technology APNS and 3LM work? APNS is an iPhone technology that assists with mobile push.   3LM is a BIOS-level security technology embedded in certain Android phones.

I recently got off the phone with Boxtone and they said they leverage those technologies to enforce corporate policy (password length, remote wipe) to each device.  I'm right now weeding through the sales pitch and am trying to get solid technical answers.  Other products that might be comparable include MobileIron, Zenprise, and Airwatch.

How does 3LM and APNS work to achieve policy compliance?
What are the benefits/limitations of these technologies?
How can I use them as an administrator/non-programmer?
How can I use them as a developer?

APNS is a way of pushing updates from third party application servers to the iOS devices. It has nothing to do with the security. Apple believes that it saves battery life having push technology over traditional background processes(pull technology).

3LM is a MDM (Mobile Device Management) software. With the emergence of Bring Your Own Device (BYOD) initiative in the corporate world, the employee's phones and tablets must be protected by malware. These technologies maintain a whitelist approach (sometimes also a blacklist) meaning only the above mentioned softwares can be installed by the employee from the Android Market.

In some worst cases, corporation will have their own Market or AppStore and employees can download apps available on those appStore.

p.s: You cannnot play Angry Birds :(


Web application vs web service security My question is about the difference between usual security expectations from a web application (intended to browser navigation) vs SOAP web service.

For a web application, an acceptable solution for secure communication is HTTPS (tranport level).
However, in large companies, the web application is behind a reverse-proxy/load-balancer (and a web application firewall on top of it).
The reverse-proxy is able to decrypt the communication, and we expect it to decrypt the communication so as to analyse the traffic. Then it sends it to the web application in the private lan (sometimes in plain HTTP).

For secure SOAP web service, HTTPS can be used, but as explained in http://msdn.microsoft.com/en-us/library/ms977358.aspx, XML encryption (message level) is promoted so as to prevent intermediary points, such as the SOAP message router, to have access to the message. Then the SOAP message is sent (still encrypted) to the right service provider in the private lan (only then the message can be decrypted).

In my eyes, the reverse proxy has the same position as the SOAP message router.

In this case, why would there be stronger security expectations to SOAP web services ? Or am I wrong and has my vision of web application architecture a weak security?

For a web application, an acceptable solution for secure communication is HTTPS (tranport level).

It is only acceptable if it provides adequate security for the application. It might be the case if you're talking about a control channel but it might be insufficient if you're exchanging messages (these are just examples, there are many other possible cases).

  In my eyes, the reverse proxy has the same position as the SOAP message router.

That is incorrect: a reverse proxy will see the raw, unencrypted traffic between the endpoints and everything that happens "behind" it will also have access to the messages cleartext. Using SOAP encryption you can preserve all the benefits of using a reverse proxy while maintaining end-to-end message security.

  In this case, why would there be stronger security expectations to SOAP web services ? Or am I wrong and has my vision of web application architecture a weak security?

It's not a question that can be answer in general: the type (and level) of security that is required will depends on what the application is doing.

One important different between using HTTPS security only or SOAP security is that you can maintain the security of the SOAP message much monger and further away than simply the TCP connection. You can save the SOAP message to a database directly and it will still retain all its security properties.


Uncovering encryption codes What is the complexity level of finding an Encryption code when the source document and the encrypted one are available? In practical terms: Malware in the computer sends a document to the TPM and gets an encrypted version.

The complexity level will be down to the algorithm attempting to test against, the skill level of the attacker, the speed of the machine(s), and time.

Your scenario is a known plaint text attack. Where by the attacker adjusts their results based on what is inputting and then outputted.

You say attacking a TPM, while this is a reasonable example as the TPM in most modern computers makes use of strong algorithms such as AES I don't think even malware could conduct a meaninglful known plaint text attack against it in a feasible timeframe. Therefore in direct answer the complexity would be very difficult and impractical.


Don't trust the client? I am a web developer, and have been trying to learn a bit about security, and the thing that seems to be the biggest principal is just to trust the client with as little as possible. Is this a correct idea? What situations would the rule not cover/be incorrect for?

"Don't trust the client" means that whatever input comes from the client might have been sent maliciously, because you can't control it. So, for example, this means that authentication and authorization must be checked and enforced server-side. If you let the client validate anything and then tell you "ok", a malicious user could just skip the validation and send "ok" to the server anyway. In general this also means that any kind of input validation must be enforced server-side.

If you don't trust the client, you are basically protecting against all the vulnerabilities that are related to input validation. But that isn't enough of course. There are other types of vulnerabilities. For example, there's output sanitization, there's the confused deputy problem that might lead to CSRF (Cross Site Request Forgery) or clickjacking, there are issues related to wrong authentication schemes, misconfigurations, etc. Even timing attacks might be a problem in some cases. As you can see, not every security problem can be solved by input validation.


Using old ciphers in email security My email provider still supports old SSL_RSA_WITH_RC4_128_SHA ciphers. What does that mean for me?

If I use an updated system (Ubuntu 16.04) and an updated client (Thunderbird 52), shouldn't it use this ciphers?

But when there is someone with an older system, he would still be able to connect to the server and would not be rejected and send his credentials and content with bad encryption. Is that the unique problem?

Are you talking about the connection between the MTA and MUA? If so then the the possible attack would be downgrade attacks on the secure channel during the handshake. But as you say, unless you are being actively attacked, the OS/MUA should negotiate at the highest supported cipher suite


Facebook login with profile picture? When I use Facebook, after I log out, I can see my profile picture on the login screen of Facebook. With great curiosity, I click on the profile picture (while I am still logged out) and Facebook logs me in again!

How can Facebook allow me to log in just via clicking on the profile picture on the login screen, without any password? What about library PCs and other shared computers? Isn't this extremely dangerous?

This is a feature of Facebook to make logging in easier by not having to enter a password every time.

How does it work? Cookies.

Facebook uses cookies to identify you so that when you log out, you're able to login again without a password. This feature can be disabled as follows: Settings -> Security and login -> Login using your profile picture -> Turn off profile Picture login.


OpenVPN kill switch on Linux How to prevent IP leak on Linux when OpenVPN fails to connect to the server while I am surfing on the net?

I read about kill switch, but after some internet searches I found out that is not implemented in OpenVPN.

Unfortunately, the previous (since deleted) answer is incorrect and will allow deanonymization because it allows any connection over port 1194, not just traffic originating from OpenVPN. You should use a simpler firewall which does nothing more than block all non-OpenVPN client output to the outside.

If you do not have an openvpn group, create it. The -r makes it a system group.

groupadd -r openvpn

Once it exists, add this line to your OpenVPN configuration file to run with this group.

group openvpn

Now you can set the firewall to block output for all processes other than the OpenVPN client. You do not need to specifically whitelist any ports, just the correct group and the TUN device.

# Flush the tables. This may cut the system's internet.
iptables -F

# Let the VPN client communicate with the outside world.
iptables -A OUTPUT -j ACCEPT -m owner --gid-owner openvpn

# The loopback device is harmless, and TUN is required for the VPN.
iptables -A OUTPUT -j ACCEPT -o lo
iptables -A OUTPUT -j ACCEPT -o tun+

# We should permit replies to traffic we've sent out.
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED

# The default policy, if no other rules match, is to refuse traffic.
iptables -P OUTPUT DROP
iptables -P INPUT DROP

If everything worked, you should now have access to the internet only through your VPN. You may need to make some tweaks depending on your particular setup (for example, if you need access to other devices on your local network), but this should be a general solution. In order to make these changes persistent, follow your distribution's instructions on saving firewall settings.

Please understand that VPNs are not designed for privacy or anonymity. Even when using a proper firewall, there are countless ways to circumvent its supposed protections, even if the VPN claims not to keep logs. If you need actual anonymity, you should instead use something like Tor.


How is truncation according to PCI DSS secure? In section 3.3 of the PCI standard, it says that when displaying PANs, limiting visibility to the first 6 and last 4 digits of the PAN is considered secure. Doing some quick math, on a 16 digit PAN, taking into account the checksum requirement, this leaves only 100,000 card numbers to brute force in order to get the one I want.

If a hash were supplied as well, this would be stupidly easy to crack, but what's stopping me from spamming some e-commerce site with a script until it tells me I'm right? That shouldn't take very long either. I know having to guess the 3-digit security code is going to bring me up to 100M guesses, but not everyone uses this code.

My company's database supplies me with name, address, card type, truncated PAN, and expiry date of the card/holder, and this seems like plenty of info for an attack (at least social engineering). If I'm reading the PCI standard correctly, this also complies with it.

What am I missing?

I'm using this handy table (page 2) for quick reference

I think it makes more sense in the context of how much extra information is being given away, rather than how easy it'd be to brute force the remaining digits.

A PAN is not entirely a random value, it's made up of:

  a six-digit Issuer Identification Number (IIN) (previously called the    "Bank Identification Number" (BIN)) the first digit of which is
  the Major Industry Identifier (MII),
  a variable length (up to 12 digits)    individual account identifier
  a single check digit calculated using    the Luhn algorithm

http://en.wikipedia.org/wiki/Bank_card_number

Therefore using this information:

  My company's database supplies me with name, address, card type,
  truncated PAN, and expiry date of the card/holder

You could probably narrow down the first 6 digits pretty easily to quite a small set of possibilities.

That only leaves the last 4 digits, one of which is a check-digit and therefore doesn't contain any additional entropy.

So basically you're only giving away 3 digits, even if all 10 that are allowed are exposed.

  this leaves only 100,000 card numbers to brute force in order to get
  the one I want

I'm guessing it would be fairly hard to execute such a brute force attack as most payment processors would lock you out very quickly.

PCI DSS also says:

  Note: It is a relatively trivial effort for a malicious individual to
  reconstruct original PAN data if they have access to both the
  truncated and hashed version of a PAN. Where hashed and truncated
  versions of the same PAN are present in an entity‘s environment,
  additional controls should be in place to ensure that the hashed and
  truncated versions cannot be correlated to reconstruct the original
  PAN.

Which should prevent the attacker from staging an offline brute force attack.

Also, these are the minimum requirements. It states in principle 7 that:

  Requirement 7: Restrict access to cardholder data by business need to
  know

I imagine displaying all 10 allowable digits to customers would fall outside "need to know". Perhaps the last 4 are required to identify which card is which, but most users wouldn't need to know the first 6 except perhaps to be shown what type of card it is.


Is there any way to determine the location of a laptop based on its MAC address or serial number? If I have the MAC address and S/N of a Lenovo 3000 Laptop, is there some way for me to find exact street location of this laptop ? This machine was stolen from me last year and was my back up machine . Contained all my personal info prior to 2009, some of which I now desperately need. I believe I have the 2 exact street locations where it could be, and an email address for each location.

I would really appreciate any help or direction or referral you could give. I am non technical.

If I have the MAC address and S/N of a Lenovo 3000 Laptop, is there some way for me to find exact street location of this laptop ?

No, there is not. You can get somewhat along the way if you pre-provision the system with software intended to "phone home" (the IP address will point to the ISP, and the ISP can determine which account was using that IP address at a specific time), but unless the perpetrator is specifically after your data, most likely among the first things they will do is possibly wipe the system clean, and then sell it to get some money. Or possibly just sell it. Alternatively, if they are after your data and have any reason to believe you have pre-provisioned the system with software intended to "phone home", they may simply remove the hard disk and use it in another system (which also completely bypasses operating system access controls).

MAC addresses are only used on the local network segment and are not routed, so never make it onto the Internet. The serial number might be accessible through some sort of remote administration software if you already know where and how to look, but it's not like the computer is likely to (should be) broadcasting that information across the Internet to anyone who merely asks.

The serial number will be useful for the police, since as pointed out by Brian Cain it allows them to identify the specific computer and the fact that it belongs to you, if it is found. Hence, if/when reporting a computer stolen, it is always good to identify it as uniquely as possible; the specific make, model and serial number will go a long way.

  I believe I have the 2 exact street locations where it could be, and an email address for each location.

If you have this information, you should be giving it to the police. They will be able to make good use of it, if you can show that it is reasonably likely to be correct. Using it on your own to try to get your computer back may actually itself be illegal in certain locales.

  Contained all my personal info prior to 2009, some of which I now desperately need.

Like I said above, the most likely thing that happened is probably that whoever took the laptop wiped it clean.

If you have a copy (backup) of the information that was on the laptop (which it sounds like since the stolen laptop was your "backup machine"), then restore the backup and use the information from there. If you don't have a backup from back then, at least start making backups now. Also, keep the backups physically separate from the computer itself, such that if one is able to steal the laptop they aren't also able to steal the backup.

Having a solid backup regimen in place will also protect your data from a number of other threats, not the least of which being disk crashes or user errors. Without having specific statistics, I believe it is safe to say that deleting the wrong file yourself is much more common than having your computer stolen.


Are deleted offline calendar events in Android actually deleted? When an Android app deletes a calendar event in a local (offline / non-synced) calendar, does Android's Calendar Storage (com.android.providers.calendar) actually delete the event or does it just flag the event as deleted?

The reason I ask is because I was shocked to discover that one of the most popular Android calendar apps, Business Calendar 2, includes deleted events in export files.  If you look at the export files, the deleted events are there in plain sight.  Furthermore, if you import the files back into Business Calendar 2, the deleted events now appear as regular events.

This means that if you had an event entitled "Deliver confidential documents regarding project X-Ray to client Albatross" in your non-synced calendar, and you then delete the event, it is trivial for anyone with access to your device to restore that event in seconds.  No forensics tools are needed.

It also happens to make the Business Calendar 2 export files practically useless, except as way to discover events the user had deleted.

Is this a flaw in Android (KitKat), a critical bug in Business Calendar 2, or a combination of the two?

Maybe not an answer to the question, but useful info for those who find this question while having this problem:

For people who use offline/local calendars, and notice their .ics export contains deleted events (even recurring events, and events from years ago):

It seems that indeed, deleted events are only "marked for deletion", meaning they still appear in exports. (This problem seems to be fixed in newer Android versions, and may have only been a problem for users of offline/local calendars.)

You can observe this problem by using the Calendar Import-Export app on Android systems which are affected by this problem. Look at the event counter, it stays the same when deleting an event via your calendar app. On newer Android versions, the counter does decrease.

Edit:

I've updated the answer. It seems the problem occurs regardless of which calendar app you're using (like Etar or S Planner). I'm guessing the problem is caused by the com.android.providers.calendar system app instead (which stores the calendar events).

The problem seems to be fixed on newer Android versions.

The problem was reproducible both with Etar and S Planner on Android 6.0.1. The problem was NOT reproducible with Etar on Android 9.0, but that's probably because of the newer com.android.providers.calendar system app, and has nothing to do with what calendar app you're using.

Related quote from the developer docs for CalendarContract.Events at android.com:

  There are two versions of delete: as an app and as a sync adapter. An
  app delete will set the deleted column on an event and remove all
  instances of that event. A sync adapter delete will remove the event
  from the database and all associated data.

Related resources:

https://softwarerecs.stackexchange.com/questions/28142/offline-calendar-for-android-with-at-least-basic-functionality
https://stackoverflow.com/questions/37429313/does-com-android-providers-calendar-remove-deleted-events-or-just-flag-them-as-d
Local calendars: Remove events from database, not just mark them deleted #624 (github.com/Etar-Group)


Is the pfx that contains ssl the same pfx that is used to sign an application I have a ssl certificate in a pfx.  I am using this to secure an https application.  Can this same pfx be used to sign an exe?

The reason I am asking is that this pfx gets shipped with the application and the domain points to localhost.  I just want to know if there is harm in shipping this pfx such as signing an exe.

If the PFX file contains your private key and is then shipped with your application, then all machines that have your application have your private key. Unless you are confident about the security of these machines, then you have compromised your private key.

In general, you should not require the servers private key/PFX file to be sent to clients. Although you may need to send private keys to clients if your server is authenticating the clients using the certificates (mutual SSL). In this case you would need a unique private key/PFX per client.


OpenSSL, x509: what's the significance of CN (Common Name)? With regard to these three items

Certificate Authorities (CA)
Gateway certificates
End-point Certificates (client-cert)

What is the significance of the Common Name CN with regard to the a VPN? Does the Certificate Authority have to have the CN of the Gateway Cert? Any other information about the CN with relation to VPNs would be great.

How are they used for authenticity of the certs?

I'm using StrongSwan v5.x if it matters.

Historically, the Distinguished Names in certificates (specified by X.500) were meant to designate an entity within the Directory, which is the global, worldwide, tree-structured repository for identity management data. The Directory can be thought of as a giant LDAP server with delegation to sub-servers, in a way somewhat similar to the DNS. In reality, though, the Directory never existed, and LDAP is a practical subset of the Directory Access Protocol. Still, the naming principles remained in force.

A DN is an ordered sequence of typed named elements, which, for the Directory, should come in the order: Country, State-or-Province, Organization, Organizational Unit (possibly several), and then Common Name. X.500 is rather open-ended and other orderings are possible (and the format supports putting several name elements at the same level), but the rough idea is that the Common Name is the lowest level of the hierarchy. Thus, the Common Name for an entity, any entity, is the most precise naming element.

Since the Directory does not actually exist, you can put just about anything you want in the Common Name, subject to the following restrictions:

Encoding must comply to the X.509 ASN.1 specification: the Common Name is limited to 64 characters (64 code points if using UTF8String, as you should, per the standard).
The IssuerDN of a certificate must be equal to the SubjectDN of its issuer. Equality rules are theoretically case-insensitive, but the rules can be complex to implement in a full Unicode world, so you'd better make sure that you have byte-to-byte equality, which will work properly everywhere.
The certificate of a SSL server must contain the server name as expected by the client (if using HTTPS, this name will be the one in the URL). This is specified in RFC 2818. The Subject Alt Name extension is normally used, but the Common Name serves as backup in case this extension is missing. Since SSL client implementations have not always strictly adhered to the relevant RFC, it is best, to avoid issues, if the SSL server's certificate contains the server DNS name as Common Name (fully qualified name, as in "security.stackexchange.com").
When a certificate, or an identity extracted from a certificate, is "shown" to a human user, the Common Name will figure proeminently. For instance, if using smart card logon on a Windows system, then the logon screen will show the Common Name in big letters when the smart card is inserted. So you'd better make the Common Name meaningful for the common man.

In the case of a VPN server, the certificate from the client is for the sole usage of the server. The server interprets the certificate contents, including the Subject DN and its Common Name, in any ways as it sees fit, including ignoring it altogether. For instance, in a Microsoft IIS + Active Directory context, when a client is authenticated through a certificate, the server will use the User Principal Name as found in the Subject Alt Name extension, under a Microsoft-specific OID. The Common Name might be displayed to the human user, if there is a human user (e.g. as part of a certificate selection popup), but will be ignored for authentication purposes.

Generically, your client's certificates will have to contain whatever is required by the authentication system that the VPN server uses, and since that is highly configurable, this depends a lot on the local context. For instance, the VPN server may delegate authentication to a RADIUS server, in which case the certificate characteristics (including the Common Name) will be described by the RADIUS server documentation; for the VPN server, this would be just an opaque blob.


Is it necessary to upload subca to browsers trusted certs or is rootca sufficient? We have set up a subca to sign certs and we have deployed the rootca cert to a browser but we still get security warnings unless we upload the subca cert to the browser.

My understanding is trusting the rootca cert should be sufficient. Is my understanding wrong or does it look like there is something wrong with the cert chain? Inspection of the certificates and chain shows the chain is correct and we haven't got mixed up in all the testing but I could be wrong :)

thanks

It is enough to have the root-CA in the browser. Your TLS server needs to provide all the intermediate certificates in the TLS handshake though, so that the client has all the necessary certificates to build the trust chain from server certificate to the trusted root CA. It is a common error to forget to configure the server accordingly, i.e. often only the leaf certificate is sent but the chain certificates are missing, are in the wrong order or are the wrong ones.


Do passphrases need to be run through PBKDF2? Almost impossible to brute force? Passphrases normally contain more data then passwords and can provide more entropy. It seems like it would still be hard to brute force a passphrase w/o using PBKDF2, assuming a user didn't select a famous quote, movie line, etc... I define a passphrase in this example as at least 22 characters.

For example, if a user used a DiceWare generated passphrase of 6 words from a 10,000 word dictionary, we would get 10,000^6 number of possible phrases.

If a super computer could do 33.6 X 10^15 operations per second and it took 2,000 operations(w/o PBKDF2) to try 1 guess it would take (10,000^6)/((33.6 X 10^15)/2,000) or about 1887 years to brute force in the worst case.

Does this and the above example make sense? Thank you very much!

Passphrases normally contain more data then passwords and can provide more entropy. It seems like it would still be hard to brute force a passphrase w/o using PBKDF2, assuming a user didn't select a famous quote, movie line, etc... I define a passphrase in this example as at least 22 characters.

What you're saying here is that there are passphrases which have large entropy. This doesn't prove anything. There are shorter passwords with large entropy. Length doesn't correlate so much with entropy when it's a human doing the choosing.

(Note: I'll use password and passphrase interchangeably from now on, because there is no difference between the two, technically speaking. A passphrase is a password that happens to consist of several words in a human language concatenated together.)

Entropy of a password made of 8 printable ASCII characters: 52 bits
Entropy of a password made of 4 Diceware words: 51 bits
(For uniformly random selections. The Diceware list consists of exactly 7776 words.)

The more randomness goes into a password, the harder it is for a human to memorize. If you use a slow hashing function rather than a fast one, you reduce the entropy that a password needs to have to escape cracking. It's a trade-off between spending more CPU time and requiring humans to memorize more.

Given that even decent passwords strain the capabilities of humans to memorize (and keep in mind that most people have tens if not hundreds of passwords), the choice is clear: you must provide them as slow a password hashing function as possible.


Why set up DMARC for SPF if it's already set up for DKIM? I have SPF and DKIM. I'm planning on adding DMARC to tell receivers to expect SPF and/or DKIM. I've read that it's best to set DMARC up with both SPF and DKIM, but I don't understand exactly when having it for both would be better than having it just for DKIM. Is there some scenario where having DMARC for SPF and DKIM would classify emails better than just having DMARC for DKIM? How common is that scenario?

I don't think there is a simple answer for your question. Both SPF and DKIM are by their own useful in fighting spam but they miss the alignment between the claimed sender in the mail header compared to the SMTP envelope (SPF) or the signature (DKIM). Only DMARC provided this important alignment and adds a policy how do deal with failures on top.

But, by allowing either DKIM or SPF to provide the necessary alignment DMARC it is sufficient to successfully spoof one of these. This means either to successfully misuse an overly broad SPF policy or to make use of the usually shoddy implemented  DKIM signatures to change the content of the mail while keeping the signature intact. Thus, by requiring only one of SPF or DKIM to succeed DMARC lets the attacker focus on the weaker problem.

Therefore, one recommendation could be to implement one mechanism properly and strict and don't implement the other one at all and this way taking the choice of the weaker target from the attacker. In this case I would favor to implement DKIM, but implement it properly: sign all relevant mail headers (there are many), oversign all of these to protect against header duplication and also make sure that the signed mail is 7 bit clean. For more on this see Breaking DKIM - on Purpose and by Chance (disclaimer: this is my own research).

The advantage of implementing only DKIM is that one can focus the resources of doing this thing right. Apart from that it provides the stronger protection if properly implemented. But, their is also a big disadvantage of not doing SPF: SPF is far more widely implemented than DKIM or DMARC and thus the chance is only higher that an anti-spam solutions implements only SPF but not DMARC and/or DKIM. While the numbers vary a lot from different sources, in the mails I had access to about  40% were covered by SPF but only about 9% had a DKIM signature and about 6% a DMARC policy.

In summary: the best thing is probably to have both strong DKIM signatures and  small and strict SPF policies. Doing this properly is not as simple as it might look like. With a more limited set of resources it might be thus preferred to get one of these right (recommended: DKIM) and skip the other one completely so that an attacker does not have the choice to pick the weaker problem.


How vulnerable is Windows XP Embedded SP2 as of today? A few weeks ago, I have been replacing and managing IT inventory. What caught my attention, was that a lot of thin clients are still running Windows XP Embedded SP2.

That made me think about the possible vulnerabilities since those thin clients won't be replaced unless there is a valid reason to do that (e.g. stopped working or has various security issues).

What are the risks of still using those thin clients and should I replace them as soon as possible?

There are 625 relatively serious Windows XP SP2 vulnerabilities listed:
https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-739/cvssscoremin-5/cvssscoremax-10/Microsoft-Windows-Xp.html

I'm not sure how many are unresolved in the latest available security updates.

Either way using an OS unsupported by the vendor is playing with wet dynamite.


Is better to have as password a sentence or first letter of the sentence? Which is better master KeePass password to prevent any type of bruteforce between theses two type of password :

Complete sentence invented by user like : I like cheeseburger,
tomatoes and fries ! :)
Each first letter of the word with lower and
higher case : Ilcb,tAf!:)

Edit : My hesitation come from the fact that the sentence indeed is longer but, it composed of real words which could be taken from a dictionary.

Short Answer :

Thanks to @Royce Williams, I can conclude that the best password generation method is random words with some char like :

shoes, tomatoes ! meal computer car

Neither - they are usually effectively equivalent.

This is because:

password crackers are very aware of non-random, human-understandable passphrases - and can (and do) emulate both subtypes at high speed, and
injecting memorable additional sequences like "!" and ":)" is just as well known and "simulatable", and
the effective entropy of either kind of passphrase-based construction technique once the methodology is known to the attacker are virtually identical.

It's #3 that is the most important lesson here, and why raw bruteforce is irrelevant: because the effective entropy of this method - how much work a real-world attacker has to perform - is dramatically less than the bruteforce entropy. This is because the psychology of naive password-memorization strategies is well-known to the attacker.

In your specific methodology, you only have to remember about eight things to remember the password:

the fact that you're using a passphrase at all (this is a freebie for the attacker, because they will be attacking passphrases as a class)
the rough meaning components of the original phrase (liking, food, and which two foods, perhaps roughly four pieces of information) (since the phrase makes grammatical sense, much of this is also easy for the attacker)
the fact that you did or did not use whole words vs the first letters (since there are only a few options here, this isn't hard for the attacker to exhaust both variants)
the placement and location of the two additional items (attackers know that people tend to put the special-character "extra" stuff at the end)

If the attacker had no idea at all in the history of password psychology that anyone would ever do this, you'd be in pretty good shape. But attackers know very well how people think about passwords, and what they do to "chunk" them into "memorizable" components. (In other words, your methodology does not adhere to Kerkhoffs' Principle).

So an attacker only has to "bruteforce" the psychologically likely effective entropy of your password. The attacker doesn't have to bruteforce all possible characters of length X; instead, they can dramatically reduce the things they have to guess by only trying the same possibilities that make them easier for you to remember.

By contrast, the most effective passphrases are random passphrases: five or six words, drawn purely randomly from a wordlist of, say, 20,000 words or more (20,000^5, or 3.2x10^21). Even if the attacker knows everything that you do about the construction methodology - exactly how many words are in the list, and exactly how many words you selected, and how you separated them, etc. - the sheer volume of possibilities is resistant to bruteforce. You only have to memorize five words - but they are so many possibilities that trying them all would take a very, very long time. If you do the math of this, you'll quickly start to understand.

(And the concern about "using words in the dictionary" is a leftover from old password complexity requirements that were trying to prevent people from using single words from a dictionary. The underlying principle - avoiding "guessability" - is a good one, but it's totally OK to use a large number of random words that happen to be in the dictionary)

Any password system whose strength is based solely on a large amount of randomness will always be stronger than one that isn't.


Can malware transfer itself between iPhone and Windows laptop? I have an iPhone which I suspect was hacked. So, I have restored the iPhone using iTunes on my computer. When connecting my phone to my computer, can any spyware files transfer from the phone to my computer and vice versa?

If I already restored my iPhone but I connected it again to the laptop (assuming the laptop was infected), would it be possible for this infection to transfer itself to my phone?

There are examples of virus/worm style software which has been able to bridge between systems on differing operating systems. Its certainly possible on a theoretical basis.

In practice the cost and effort required to author something this sophisticated puts it out of the reach of your average malware author. For a similar cost you could attempt to build something which bridges via a WiFi exploit and infect the laptop without ever needing the iPhone to be plugged in.

What is more likely is if your backup of the iPhone was from after the phone became infected and contains the infection. Depending on the infection vector its plenty possible for you to end up re-infected simply by restoring from it.


Protecting account ssh keys from root How can users ssh private keys be protected from root stealing and attempting to brute force them? I cannot use selinux as the vendor will not support the app when it's in use? Thanks

Do not give the keys away from your owned and maintained hardware. If you don't have a root on your computer, user Smart Card (or Yubikey).

As already said, nothing protects your keys (or data) from physical access and root user. Not even SELinux (root can do everything, if is unconfined!). Cryptography does the job only partially (encrypted keys can be brute-forced, but it is not feasible if you have passphrase strong enough). But trusted hardware can not be brute forced and you know exactly when it is used (requires confirmation, pin, whatever).


If the NSA forced every US Cert Authority to hand over their keys what would be the threat? Say the NSA hands Comodo an NSL and forces them to give up all their signing keys and whatever else they need. Then do this to every other CA company. What would be the side effects of this?

This is similar to what is going on in the UK right now with the Investigatory Powers Act, which gives the UK government the power to effectively perform man-in-the-middle attacks against every UK citizen. A Security Stack user @Matthew gives a great answer here explaining how something like this would occur. Although, in the UK it is more likely they would force citizens to install their certificate rather than force companies to hand over theirs.

That being said, it would be highly unlikely that the NSA could do this, CA's aren't all located under the jurisdiction of the US government.

If this ever happened they could essentially perform man-in-the-middle attacks/intercept and decrypt any HTTPS traffic of their choosing (if they got every CA to comply). They would be able to read all your HTTPS traffic. So your conversations, your banking information, anything and everything would be theirs as much as it is yours. As @John Deters mentioned in the comments, "All Bad Things could happen".

Unless it were mandated by law, there would be ways to ensure that your traffic isn't snooped on or modified, even though they hold all the keys. VPN's are one way, which could encrypt your traffic with a key they do not hold. But, this would not guarantee safety in a world where the NSA has this sort of power.


Panopticlick performance for Tor Browser not great. Why? These are the results for the Panopticlick test on Tor Browser that I just performed:

Is your browser blocking tracking ads?   Partial protection
Is your browser blocking invisible trackers?     Partial protection
Does your browser unblock 3rd parties that promise to honor Do Not Track? No
Does your browser protect from fingerprinting?   No, your browser has a unique fingerprint

I am surprised at these findings, especially since I was under the impression that Tor Browser does not provide fingerprinting data unless you accept it, or that it would be good at blocking trackers.

Why would it perform so poorly? Is it better to add anonymising add ons to regular browsers and use them instead?

Bits of identifying information

The quality of a fingerprint is measured by the number of "bits" of identifying information. The more bits of information your fingerprint contains, the more reliably your device can be distinguished from other devices.

These bits of information are obtained by testing how your browser behaves in different situations. For example, whether or not cookies are enabled provides one bit of information (either they are enabled, or they are not enabled).

If we assume that the testable behaviors are evenly distributed, then any configuration with n bits of information occurs with probability 1/2^n.

However, the actual math surrounding this becomes somewhat more complicated due to certain settings being more popular. For example, most users have cookies enabled because that is the default in their browser; therefore, having cookies enabled does little to distinguish you from other users. But, if you are the rare person with cookies disabled, you will be more identifiable.

Does the Tor Browser allow fingerprinting?

It is impossible to not provide any fingerprinting information because the information is collected as a boolean value: either your browser supports a feature or it does not. However, it is possible to reduce the uniqueness of that information by trying to match other users.

If you look at the user agent information in Panopticlick while using the Tor Browser, you will notice that it is pretending to be installed on the Windows operating system even when it is running on a Linux. This is because Windows is currently the most prevalent operating system worldwide. Thus, it provides the least amount of "uniqueness" to your fingerprint.

Furthermore, it is more important for Tor users to all appear identical than it is to attempt to match another fingerprint. This is because it is possible to identify that someone is using Tor by the IP address that is connecting to a website. Thus, the fact that they are a Tor user is impossible to obscure. However, if all Tor users have the same fingerprint, it remains impossible to tell which Tor user connected to your website.

Does installing add-ons help?

It depends on whether you are installing add-ons into a normal browser or the Tor Browser:

The Tor Browser: Probably not. If an add-on you install disables one feature in the Tor browser and nobody else installs this add-on, you will be the only user on the Tor network with this fingerprint. However, if the add-on is included in the Tor Browser for every user, then it might be possible to change your fingerprint characteristics for the better.
A Normal Browser: Yes, privacy add-ons can provide an enhancement over the browser's default configuration. However, the Tor Browser is better overall because it contains many modifications that are too difficult to perform via add-ons alone. Additionally, the Tor Browser has protection against more than just device fingerprinting.