When do system access policies start to become source of security incidents? Consider the assumption we are dealing with systems handling secret information which is crucial for an organization's existence. I would like to know what is a good balance between security requirements and usability when it comes to password complexity, password change policy, multi-authentication factor requirements and so on...

Are there best practices for this topic?

I know several situation which might jeopardize security due to a severe policy:

Writing down passwords since they are either so difficult to remember or because you have to change it so often.
Intentionally letting the PKI card in the laptops even when unattended.
Saving password in plain-text either. Even worse when they use Excel files offering a vast menu of users and passwords to hackers.

Many organizations face this problem, with employees being the "weakest link" in security. Overall, password based authentication has proven to be a gap. Employees cannot reasonably be expected to remember eleven or twelve passwords that they must change monthly. We recently faced this issue in my organization and came to a few conclusions.

Two-factor authentication coupled with a single sign on solution (SSO) will make employees happier and reduce the risk profile of multiple stand alone password entries.
For two-factor authentication, media devices such as flash drives are not the best form, but it is better than nothing. Employees will leave them in their workstations unfortunately. A stronger form of two-factor would be implementing a cellular verification (Duo Mobile offers this). When a user attempts to sign on, they will be asked to check their cell phone. If it is a smart phone with the Duo Mobile app, a notification will appear in their task bar asking for approval of the login. If not, text messaging features can be used for an access code. This can also work with an office phone (not the best option, but requires the attacker to be physically at the employees desk).
If you are going to use a very strong two-factor authentication, SSO is a must to keep employees from becoming overly agitated. The two-factor authentication should be configured for a password vault which has browser plugins for SSO and stores other passwords for retrieval, allowing this solution to work with applications that do not support an SSO method. During our research, LastPass and AuthLite had these options available. They also had features which would manage password changes for employees, automatically changing the employees passwords after an expiration period. Since the passwords were system generated, it took away the password re-use headache.

In the end, we went with a password vault that offered SSO capabilities coupled with flash drive two-factor authentication (for cost purposes) to access the employees vault.


mutual authentication between two clients I understand how mutual authentication works between a client and a server, however I am unsure how I would be able to get mutual authentication between two clients A and B?

What would be the best method for this?
Is the SSL/TLS PKI implementation secure or is there a more secure
method in theory?
I have read about TLS-SRP, how would this improve security and how
could I achieve mutual authentication with this model?

"Client" and "Server" are just formal names for roles in situations where there is a natural asymmetry. Namely, one talks first: that's the "client".

This is how it goes in SSL: the protocol is defined to operate on a bidirectional transport medium. One of the entities talks first and sends a ClientHello message. There is no absolute requirement that the notion of "client" and "server" that SSL uses matches the notions of "client" and "server" for the underlying connection when that connection is a TCP socket over the Internet. It just happens to be that way.

In all generality, any authentication protocol between two systems (let's call them "A" and "B") works by sending messages to each other, and one of the systems will be the first to talk. As long as both A and B know who is supposed to talk first, through some convention, then the protocol will work. The convention is easy to obtain when there is an asymmetry, e.g. the software on one machine is not the same as the software on the other. For instance, for the Web, one system uses a Web browser (e.g. Firefox) while the other uses a Web server (e.g. Apache), and standards define what either is supposed to do.

Just imagine a phone call. Someone dials the number of the other. Normal behaviour is that the person who receives the call will talk first (and say "hello"). That's exactly the concept you want. If these two talking person want to run some authentication protocol, they will have to agree on their respective roles (they can call themselves "client" and "server" if that's their wish). Using the dialer/receiver asymmetry is a natural way to bootstrap that convention. But they could use just any other convention; for instance, they could use the lexicographic order of their names (Alice is the "client" and
Bob the "server" because 'A' is before 'B' in the alphabet); or their birth date; or they may try randomly; or whatever.

That being said, in the specific case of SSL, there normally are certificates and the machine with the "server" role shows a certificate to the "client"; the "client" may also show a certificate to the "server". Certificates prove bindings between keys and identities, but this has any value only if the identity has some meaning. I.e., when the server shows its certificate to the client, the important point is that the server's certificate contains the server name, and the client expects a very specific server name (the one from the URL). Similarly, when the client shows its certificate to the server, this makes some useful authentication only if the server can find in the certificate some notion of identity which makes sense for him.

A more interesting situation with SSL is SRP: with this variant, no certificate at all. Client and server authenticate each other relatively to their knowledge of a shared secret (a password). They still must agree on who talks first ! And there is an extra point, which is the entity with the "server" role does not need to store the password itself, only a hashed version thereof (with some algebraic structure). In that sense, who assumes the "server" role is not completely arbitrary with regards to security: even in a mutual authentication protocol, security characteristics achieved on both sides may differ.


Deauth as a protection In the case that there is an ongoing attack in my network, where the attacker is using WLAN to access my network and I recognize it, would it be possible to send a broadcast deauth in my network to temporarily stop the attack (as a "bruteforce solution")?

Are there possibilities for the hacker to protect himself against deauth packages (assuming he is not able to change the router settings)?

Short answer: Yes.

The deauth-packages are part of the management control frames used in 802.x communications. That means, they are usually handled in driver-land.
So if it is not an advanced attacker (who'd probably go about this a different way anyways), you'll successfully make the attackers wifi-controller disassociate from your network.

But let's consider a worst case scenario:

Your attacker is dropping every 802-Deauth-package he's receiving. His tools are capable of constructing raw wifi frames, he's in total control of his wifi driver.

Even if you could not disassociate him, your router will still pretend the deauth happened and will discard all future packets. The attack would therefore stop non-the-less.

Also, I would not call it a brute-force last resort either. An Intrusion Detection System will be able to specially block the attackers MAC-Address.


TLS: RC4 or not RC4? I was reading another interesting article by Matthew Green today, saying that

  if you're using RC4 as your primary ciphersuite in SSL/TLS, now would be a great time to stop

As far as I'm aware RC4 has been up'd on the list of ciphersuites to protect against BEAST and Lucky 13. (and hence why websites like Google use it presumably). Tools like SSLlabs still warn you if you don't use RC4 as far as I can tell...

Matthew Green then states that

  In the short term we have an ugly choice: stick with RC4 and hope for the best, or move back to CBC mode ciphersuites -- which many sites have avoided due to the BEAST and Lucky13 attacks.

What I therefore wonder about is which of these attacks are more likely / easy to execute, and what should the practical recommendation for TLS ciphersuite be?

(by practical, I mean something available today and compatible with most servers/browsers)

First things first: don't panic. Don't do anything rash, and take time to think.

The slides which have appeared today describe new results on bias in RC4. RC4 generates a key-dependent stream of pseudo-random bytes, which is then XORed with the data to encrypt (decryption is identical). It was known that the output of RC4 was slightly biased, i.e. some byte values were more probable than others, especially in the first bytes of output. This leads to the possible following attack: assuming that a given secret message m is repeatedly encrypted, each time with a different key but always at the same position in the stream, then observing the encrypted data would allow to recover the message m. Indeed, if at position j key stream byte x is more probable than all other 255 values, and the attacker observes that encrypted byte value b happens more often, then he will guess that x = b XOR p for plaintext byte p, thus p = x XOR b.

It was usually assumed that though RC4 has biases of that kind, they were not really vulnerable in the practical usage of RC4 in, say, SSL/TLS.

The new results add a few more biases to those which were known, and in a more systematic way, and and gives measures. The measures partially confirm the stance above. Of course, the slides are prone to take an apocalyptic stance and to warn of utter breakage, because: 1. researchers need to do a bit of marketing and advertisement on their results, so as to attract funding, and 2. it is the Bernsteinesque style to shout that the End of Times is nigh, and that everybody else is wrong.

What the figures say is that it takes a few millions of connections for the attack to work. In a practical SSL/TLS setting, where the target is a cookie value, you won't open a new connection more than once every 15 seconds or so, because the browser and the server will "keep the connection alive", so it would take one year of 24/7 Web surfing, always on the same site, always immediately after the browser or the server decided to close the current connection, to become susceptible to this attack. Therefore, don't panic. There is no reason to rush and delve into cipher suite settings. Yet.

RC4 should still be phased out in due course. Indeed, the biases are slight, but bigger than previously expected ("we" thought that the "few millions" were "1 billion or so"). The safety margin is becoming quite thin. RC4 got a revival lately due to the BEAST attack, but it was already considered as a temporary measure. Indeed, the BEAST attack no longer works because workarounds were found.

One way to "fix" RC4, which has been suggested many times, is to drop the first 256 (or 512 or 1536 or whatever) bytes of output, since these are the most biased of them (the graphics in the slides show that quite clearly). But this would not be compatible with RC4-as-we-know-it, so it would make little sense to force that on SSL/TLS. If SSL libraries must be modified to implement a better algorithm, they may as well use one which is already standardized, i.e. GCM (see RFC 5288 for the integration of GCM into SSL/TLS). This would be better than a refurbished RC4 which would still has other biases (slighter, but still detectable, and not limited to the first bytes of output).

For now, do nothing. But see what Google will do. What Google does, the World will follow.

On an immediate basis, if you are really that worried, switch back to AES/CBC (or even 3DES/CBC), despite BEAST which, as explained above, does not work anymore with an up-to-date browser (and if the browser is not up-to-date, then the user has much more pressing issues to fix !).

In an ideal world, this new attack, despite its lack of immediate applicability, will prompt vendors to implement TLS 1.2 + GCM, and the Web will be safer.


Password algorithm to be integrated on a website I have recently started a project to code a secure password protection algorithm to be used on both computers and mobile devices. As I have never done anything like it before, I am a bit unsure of where to start. This code needs to be extremely secure, but also flexible on the front end. I am familiar with Java, C, and Ruby. Any ideas from people who have done similar projects?

It's a really good idea to not do this yourself; it's easy to mess up if you don't know what you're doing.

The short of it is that you want to hash your passwords with a slow algorithm using a per-user salt.  I won't go into much detail, because there are plenty of resources, here and across the web, talking about which hashing function to use, how to store salts, why you need to do these things, etc.

The frontend is completely irrelevant; you just take in user input and pass it to your password-checking function.


Possibility of SQLI in the following request? I was testing an web application which is written in Ruby, Rails framework, when I stumbled on the following request which was sent. I modified the request and now it displays me a part of the query of an SQL. I am not familiar with SQL in Ruby, so I was wondering if the following is vulnerable to SQLI.

POST REQUEST:

PUT /campaigns/**_42789_** HTTP/1.1
Host: test.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/json; charset=utf-8
X-Requested-With: XMLHttpRequest
Content-Length: 31
Cookie: cokies here
Connection: keep-alive

{"email_campaign":{"id":42789}}

RESPONSE:

{"message":"Couldn't find Promotion with [WHERE `promotions`.`id` = ? AND (user_id IN (2170,2313) OR master_user_id = 2313)]"}

Is SQLI possible here?

Probably not.

As you can see, the query uses prepared statements:

WHERE `promotions`.`id` = ?

Of course, this is only a small part of the query, user input may be inserted directly into the query in other parts of it, so you should check if the id parameter is vulnerable anyways. This may actually be the case, 2170 and 2313 for example do seem to be injected into the query directly.

But just seeing parts of a query is no indication that an SQL injection is possible. It just tells you that something went wrong when performing the query.

Of course, sending this error message to the user is a bad idea in and of itself. The average user will just be confused by the message, and an attacker gains some information about query structure - eg that it seems to use prepared statements, at least in parts -, table and column names, and possibly used software, such as the type of DBMS, etc.


What is multi-path malware? I would like to know, in malware analysis, what is meant by "multi-path execution". I read this when I encounter the words in malware detection literature related to Control Flow Graph (CFG).

I looked it up, so i'm no expert, but it seems to mean this.

When code is conditional, for instance by using an 'if' statement, a CPU must decide which 'branch' (the if or the else) to take. However, in modern CPUs, instructions are pre-fetched and some calculations are made on instructions not yet executed, so branching poses a problem: which branch should be evaluated? Multipath execution (http://csd.ijs.si/courses/processor/chapter4/sld072.htm) means evaluating both branches, and discarding the branch that eventually turns out not to be the taken path.

In relation to CFG: when taking multiple branches, multiple edges will be temporarily travelled. However, after the condition has been fully evaluated, only one edge will remain, the others will be discarded.

Have a look at http://en.wikipedia.org/wiki/Branch_predictor for a lot of info on how a modern CPU can deal with branching.

This seems to me as not being a typical 'malware' issue, but a general debugging concept.

Someone correct me if I'm talking nonsense :-)


Is SSL dying? Should I buy SSL certificates for my sites any more? I'm planning to purchase a SSL certificate for one of my sites when I'm concerned about points made in these articles:

WiredTree: The Most Significant Issue With SSL – And How To Solve It
TechRepublic: POODLE vulnerability hastens the death of SSL 3.0
Infosec Island:
IPv6 - The Death of SSL
This POODLE Bites: Exploiting The SSL 3.0 Fallback

Is SSL secure any more? What are they talking about? I thought SSL was bullet-proof, but now I'm confused.

If SSL is not secure any more, with regard to safeguarding the information exchanged between my clients and my server via HTTP, what are my options other than a SSL certificate?

All except the third link refer to SSLv3 (version 3) which is affected by the poodle vulnerability. You should be using the TLS protocol which is the successor of SSL and not affected. You should configure your web server to support TLS 1.0, 1.1 and 1.2, which should cover most devices out there save for a few archaic ones like IE6.0, while still remaining secure. The certificate used for both protocols is the same.

Most mass media websites refer to TLS/SSL as simply SSL. They are actually two separate protocols.

More information here : What's the difference between SSL, TLS, and HTTPS?

As for the 3rd link, it refers to IPv6 superceding SSL. My opinion is that it will take at least a few more years for IPv6 to become the de-facto addressing scheme. In the mean time, an SSL certificate will secure your site. Afterall, you can buy a cert for 1-2 year duration if you are afraid it will become obsolete in the near future.


Can the Windows Schannel vulnerability be exploited by visiting a website? Microsoft has just patched a vulnerability in Schannel that could allow remote code execution (MS14-066). What I can't find are any reliable details on how this can be exploited. I've seen some people claim that it can only be exploited if you're running a webserver on Windows. But the german news portal Heise claims that it is also exploitable by visiting websites.

What is known about possible attack vectors for this exploit? Can it be exploited simply by visiting a website if you haven't applied the update? And if that is the case, does this only apply to IE, or do the other browsers use the vulnerable library as well?

What is known about possible attack vectors for this exploit? Can it be exploited simply by visiting a website if you haven't applied the update?
From [Dailydave] More info on SSLMAGEDON:

Our friends at BeyondTrust have a page on the bug now:
http://blog.beyondtrust.com/triggering-ms14-066
One thing I think people are missing is that this bug works by default
on Windows 7 and above. You can force a client cert down Window's
throat, which triggers the vulnerability regardless of configuration
settings.

From Assessing Risk for the November 2014 Security Updates:

"Most likely attack vector" [...for MS14-066 is...] "User browses to a malicious webpage."

Note: "User browses to a malicious webpage" was changed to "A malicious user sends specially crafted packets to an exposed service" after I wrote the previous sentence.
Does this only apply to IE, or do the other browsers use the vulnerable library as well?
From the document at TLS/SSL hardening and compatibility Report 2011:

In order to assess the SSL/TLS support of modern Internet browsers we had to take a look at the SSL engines they use. Some SSL stacks generally have capabilities that browsers do not make use of per default, the lists below only reflect real default browser usage.
Chrome and Firefox use the NSS engine
IE5, 6, 7, 8 and Safari use Microsoft SCHANNEL
Opera and Safari (OSX) use custom SSL engines

From Transport Layer Security:

TLS support of Opera 14 and above is same as that of Chrome, because Opera has migrated to Chromium backend


How strong is the performance impact of signing when using RSA_AES_256_ECDH To encrypt web communication, I use SSL with a RSA key with a length of 2048 bit, AES key's with a length of 256 bit and the ECDH-algorithm for the negotiation of the AES key's (or to exchange the DH-parameters to compute the AES key's).

As far as I understand, the RSA key pair's are only used the sign the messages for the negotiation of the common secret to encrypt the application data with AES (265 bit). Right?

My question:
Which of these procedures got the most impact of the performance (cpu/ram) to encrypt a communication session with ssl?
The signing of the DH-parameter by RSA by key-length? Or the AES encryption? How is the proportion to RSA signing by key length and AES encryption by key length?

The cost of encrypting data with AES is proportional to the size of such data. If you send 2 terabytes of data through your SSL connection, you will encrypt 2 terabytes of data and the cost of such encryption will completely dwarf anything that happens with RSA. On the other hand, if you send a single byte through your connection, the costs related to AES encryption will naturally be negligible with regards to RSA. So there cannot be any absolute answer to your question.

We can still say the following:

Unless you are developing code that runs on a smart card, both RSA and AES have negligible RAM costs.
AES-256 is theoretically 40% slower than AES-128, but there are other costs (e.g. the HMAC computations) so it can be predicted that the difference in performance between AES-256 and AES-128 will likely be lower. On the other hand, there is no real difference in security between AES-128 and AES-256; AES-256 may better promote your Alpha Male status when dealing with auditors and marketing people, though.
RSA signature time is roughly cubic in the key size (i.e. a twice larger key will mean eight times the CPU cost). This still depends on how the RSA implementation works, and asymptotic costs are always an approximation. It is useless to go beyond 2048 bits, unless, there again, you have to woo your harem into submission by your powerful display of an oversized RSA key.
Performance questions don't exist in abstracto. Performance is to be measured. On a real machine. Until measures have been made, there can be no performance issue, and discussing performance is just a way to spend time in meetings instead of actually, you know, working.


What actually happens in "low voltage fault attacks" I understand they are an attack on crypto algorithms as implemented on various processors, but how do they work? The online papers are too complex for me to understand.

"Fault attacks" are something you do on some hardware:

that is in your physical hands,
but is shielded against intrusion ("tamper resistant"),
and does computations with values that you don't know but would like to ("cryptographic keys").

Example of such hardware are smart cards. A classic scenario would be: you have a smart card for a satellite-TV decoder; you got the card through a normal subscription to the broadcaster; you wish to make 3000 copies of that card so that you may resell them to people who want free/cheap TV. People do that.

A fault attack is when you induce the shielded hardware to get things wrong by changing its environment. For instance, you try to run the card in an oven, at a temperature which is beyond the nominal operating temperature of the card. The attacker's hope is that by analysing what the card returns when it failed, he may gain some insight on the secret values stored in the card (this is of course very specific to what the card computes and how things are implemented in that card). A low-voltage fault attack is a fault attack where the fault is induced by feeding the hardware with a lower-than-normal voltage (in the "smart card" model, the card has its own CPU, RAM and ROM, but the current and clock signals are provided externally, i.e. are under the control of the attacker). For instance, if the card expect 3.3V, you give it only 2V. The real trick here is that the attacker can lower the voltage for only very short durations, a few clock cycles, so as to induce a fault in a specific part of the algorithm execution.


Nmap write output only when all scanned ports are open Can anyone tell me how, or if it possible to get nmap to write output to a file if ALL of the ports defined in the scan are open? Such as in a boolean & statement - i.e. 636 & 902 & 5989

For example, I am trying to find all VMware-related ports in a scan by looking for ports 636, 902 and 5989 being open. The scan I am using is

nmap -T5 -sV -P0 -O -iL dc-subnets -p 902,636,5989 --open > vmware

This works fine in that I can see the open ports and the version data shows 'vmware', however I want to concentrate purely on the ports and only write to file the hosts that have all 3 ports open.

I don't believe that nmap has this capability natively within the program, however it would be relatively easy to achieve this goal with a scripting language after the scan has completed.

For an example when using Ruby you could use something like the ruby-nmap gem to parse your output and return a list of hosts that have those three ports open.


How to hide victim pop-up in clickjacking? I am testing a web application for click-jacking vulnerability. The attack works fine for single clicks, however i am trying to delete a file and the hidden frame (victim) throws a pop-up confirmation.

Is there any way to hide the popup(same as of frame) and trick the user to accept it. I have googled a lot but no luck :(

Frame busting busters also not working.

Please help, Thanks

I am doing something wrong
Click-jacking page code:

Click on the link to get rich now:

CLICK ME!

You'll be rich for the whole life!

Using window.confirm() is a valid method of mitigating Clickjacking when it is not possible to use x-frame-options.  This popup window cannot be framed.  In every browser except for Internet Explorer the origin of the confirmation window is displayed if the domain differs from the parent iframe in the popup because of Clickjacking.  The use of window.confirm() as method of defending against clickjacking has been used by Google.

Using the x-frame-options is still a better method preventing clickjacking,  however there are some cases where it cannot be used.  For example not every browser supports the whitelist feature,  and sometimes sites need a very large whitelist.


Is it safe to store hashes of possibly non-existing passwords in a less safe way? I would like to implement a lockout mechanism that not only protects against same username and many passwords attacks, but many usernames and same password attacks too.

To implement this I figured I need a table to store every entered password that caused a failed attempt. Then, at every login attempt, I check if there was a failed login attempt with the same password.

All the passwords that belong to user accounts are encrypted with bcrypt, have a salt, high cost and all the rest of it. But I can't encrypt the passwords used in a failed login attempt like that, can I? I can't do a lookup with MySQL using the WHERE clause because every time a password is rehashed, the value differs from the previous hash even if it is the same password.

To be able to do a lookup with MySQL using the WHERE clause I figured I need to store the passwords in the failed login attempts table in a less secure way, like SHA512. I know that some passwords entered in a failed login attempt could belong to a user account. So, is it safe to store the hashes  in this format in order to be able to check for failed login attempts? Or is there a better way to achieve this?

If the processing of a failed login attempt, failed because the login name does not exist, incurs a smaller cost on your side than a failed login because of a wrong password on an existing login name, then the attacker may be able to see it: your server responds faster in that case. Therefore, the attacker will still be able to know which login names exist and which do not, and then concentrate only on the existing login names.

If you really want to hide to the attacker whether a given login name exists or not, then you must emulate it properly: regardless of whether the login name exists or not, do a complete bcrypt invocation. Even simply sleeping for the approximate right amount of time will not be sufficient, because your server will be able to "process" many more login operations per second when the login names do not exist, then when the login names exist. The attacker can still notice it.

Though Tradition calls for not revealing whether a given login name exists or not on your system, I'd say that proper password hashing is more important, so you should simply reject attempts on non-existing login names. If you want to hide the fact that a given login name does not exist on your server, then you MUST pay the computational price; but I think it is not worth the effort.

As for detecting brute force attacks, this is normally done with statistics on the source (the IP address of the client machine) than on the target (the name of the target user). If you limit the login rate to one attempt per second or less (or any other "slowness" policy) and per source IP address, then you will detect most brute force attacks, regardless of whether they target one login name or several, existing or non-existing. This is a more robust method, and it also covers your next step, i.e. when the attackers tries different passwords on many different login names (and they can certainly do that !).


Why does IBM's Intrusion Detection System Show Local IPs instead of Public IPs for the Source of an Attack? Security Intern here given the assignment to find the IP address of an attacker using IBM's IDS.

The event or attack in question is entitled X509_Weak_Signature_Algorithm, and from what I understand, this attack involves exploiting MD5 to generate rogue certificates to compromise our servers.

When I go to review an individual event log, I noticed that the attacker's IP address is a Class A local IP.

Shouldn't this be a public IP address because we are being attacked by an external host?

This is not an attack

The IDS is merely telling you that you have an SSL certificate with a weak algorithm. more info

The IP address is the address of your own internal server, that has the weak certificate.


What advantage does HMAC provide in generating short hashes comparing to regular hash function? This question is specific to the Apple/Google Contact Tracing framework. See https://www.blog.google/documents/56/Contact_Tracing_-_Cryptography_Specification.pdf for the cryptography spec.

In this spec, note the Rolling Proximity Identifier (RPI) is generated from the Daily Tracing Key and the TIN using HMAC.

My understanding is that the function to generate RPI only need to be a one-way function with deterministic output from a given input. Then why in this spec a HMAC is used instead of say a SHA256 function with N iteration?

I can only take a guess why they decided to implement this construct, but the first thing that comes to my mind are some security issues.

Using HMAC's prevents several possible attacks against SHA256. SHA256 uses a Merkle–Damgård construction, which is vulnerable to length extension attacks. Even when using SHA256(data||key), using a combination of the Daily Tracing Key and the TIN its much easier to find collisions.

So the RPI does not only need to be a one-way-function it also needs to have a good collision resistance.

Under Security Considerations it says:

  Without the release of the Daily Tracing Keys, it is not computationally feasible for an attacker to
  find a collision on a Rolling Proximity Identifier. This prevents a wide-range of replay and
  impersonation attacks.

Using HMAC's therefore is more complex, but it mitigates or reduces those attack vectors.

If you're interested in the specification for HMAC's they are defined in RFC2104.


Pokki Sandbox architecture. Is it secure? Today I have looked at the desktop application framework - Pokki. The first questions were: how it works and is it secured. What I have found about security architecture: Pokki Security Overview. So my questions are:

1) Is the sandbox architecture secure?

2) How can I test that a pokki application (or any other) has met all the requirements of this architecture (certified)?

Pokki is secure the same way that chrome is.

A Pokki process is severely limited and thus no malicious software can infect your system from within a Pokki without breaking several security layers simultaneously (very unlikely).
There are no tests because the application itself doesn't have anything to do with the sandbox architecture except it runs ontop of it. I fit's a Pokku app then it's secure (in this way)

These security measures only stop malicious software from infecting your system.
It does not secure against anything else.

If you could be more specific about what you're trying to prevent, I could explain further.


User can't navigate to webpage through the UI due to permissions, but are able to navigate to page by pasting the URL. How do I protect against this? In my application, users have certain roles which have permissions. These permissions dictate which UI elements are available to them at the home screen. Many of the elements link to other pages, which many users cannot see because their permissions do not allow them to go to that web page.

For example, a button called button1 links to a random page in the application, let's say http://www.example.com/example.jsp. The user John however, has permissions set that don't allow him to see button1. Therefore John cannot go to http://www.example.com/example.jsp.

The issue I'm having is that if I am signed in as John, and I paste that URL, it will take me to the page.

Obviously this is a huge security risk if an attacker gets the URL to an administrator page for example. So, how can I protect against this? Do I need to verify the user for every single page, checking permissions and making sure that they are allowed to be there?

There are hundreds of pages in this application and that seems very redundant and not efficient to include code on every page to do so. Is there an easier way to do this than the method I just mentioned?

Do I need to verify the user for every single page?

Absolutely. Not only every page, but every request to a privileged resource, e.g POST request to update data, delete, view, etc, etc. It is not just about viewing the pages, it is about controlling who can do what on your system.

It sounds like your entire authentication and permissions system is broken in its current implementation. The steps to remedy this are too broad for this one answer. It would be worth a general search of this forum and the wider net to find solutions suitable for your framework (JSP, ASP.Net, PHP, etc.). Most frameworks have out-of-the-box functionality for solving this problem.

A good start would be this high level guide from OWASP: Operational Security: Administrative Interfaces.


What is the purpose/role of the "alias" attribute in Java keystore files? I've heard conflicting information about the purpose of the alias attribute in Java keystore files. Can someone please clarify on what exactly this attribute is, and what it should be set to when creating a new java keystore for leaf and intermediate certs in a regular Web server chain?

I used to think that alias was just a unique identifier for each entry in a jks file, and as such the leaf would have a different alias from an intermediate cert. Now, I'm not so sure. Can someone clarify?

ALIAS

To answer your immediate question, the alias field should be a unique string to identify the key entry. This applies to all types such a trusted and intermediate.

Documentation

Keytool

  KeyStore Aliases

  All keystore entries (key and trusted certificate
  entries) are accessed via unique aliases.

  An alias is specified when you add an entity to the keystore using the
  -genseckey command to generate a secret key, -genkeypair command to generate a key pair (public and private key) or the -importcert
  command to add a certificate or certificate chain to the list of
  trusted certificates. Subsequent keytool commands must use this same
  alias to refer to the entity.

  For example, suppose you use the alias duke to generate a new
  public/private key pair and wrap the public key into a self-signed
  certificate (see Certificate Chains) via the following command:

  keytool -genkeypair -alias duke -keypass dukekeypasswd

  This specifies an initial password of "dukekeypasswd" required by subsequent
  commands to access the private key assocated with the alias duke. If
  you later want to change duke's private key password, you use a
  command like the following:

`keytool -keypasswd -alias duke -keypass dukekeypasswd -new newpass`

  This changes the password from "dukekeypasswd" to "newpass".

  Please note: A password should not actually be specified on a command line or
  in a script unless it is for testing purposes, or you are on a secure
  system. If you don't specify a required password option on a command
  line, you will be prompted for it

Standards and Practices

I don't think there is any set naming standard and I'm sure you can talk to 10 different people and get 10 different answers. You just want it unique and logical.

The API and Oracle's Keytool don't do a great job of checking for duplicates which is a particular oversight in my opinion considering it's used to identify each entry in a key store.

The best way to resolve duplicates is to generate a new keystore, and add each entry from the old keystore to the new one with unique alias'. You can iterate over the keystore and use its timestamp to identify different certs in a store.


Are there any websites that gather hash sums of different disk image files? For example the SHA256sum of an Ubuntu ISO image, or an OpenBSD amd64 image. Are there any sites?

It's important that the site must use HTTPS or at least it must provide GPG check for the hashes.

The National Software Reference Library is a catalog of valid hashes for OS and application files.  This listing can then be used, for example, to validate installed OS files on a system.  To quote from their site, "In most cases, NSRL file data is used to eliminate known files, such as operating system and application files, during criminal forensic investigations."

I don't know if it includes Ubuntu or OpenBSD, and their index page looks lost at the moment.


Is fail2ban an intrusion prevention system? I know what fail2ban does; it monitors the firewall logs and finds ip addresses that have too many failed logins to ssh; and then tells the firewall to drop packets from those addresses.

So is fail2ban an IPS?

Before categorising anything, it's important to understand the taxonomy first. That way you don't get bogged down in words that could have different meanings.

An IPS or an IDS is defined as a network-level detection control. A Host-Based IPS (HIPS) will also look at internal data but primarily looks at the network.

Given this differentiation, no, fail2ban is not a HIDS because it does not inspect the network (it looks at logs).

If you try to expand the taxonomy beyond its intent, then any host-based control could be considered a HIDS, like anti-virus or an OS-level account lockout on too many failed login attempts.


How to invalidate a session on browser closure? I have a web application where web session need to expire after stipulated period of time. However capturing browser closure event is not a good idea to invalidate a user session.

What can be an alternative solution to invalidate a user session on browser closure ?

Session (in)validation is usually a server concept: a session is "valid" as long as the server considers it to be valid, i.e. grants access to whatever data and functionalities are defined to be session-based.

What is usually done is:

The server has a session timeout. If nothing is heard from the client for some time, then the session disappears.
An explicit "logout" button is provided, when users want to trigger an early session end.

From your question, I suppose that you would like the browser "closure" to act like a logout button. If you can capture a closure event, then that's good. Otherwise, you can use a short timeout (e.g. two minutes) and have some Javascript running in the background of the page to do some regular hidden "keep-alive" activity with the server (e.g. every 90 seconds) as long as the corresponding tab/window is open.

Either way, it is up to the server to enforce a timeout. You cannot reliably handle it client-side only, if only because the client can disappear abruptly without any trace (user's laptop battery is empty, user is roaming in a car/train and goes out of range of a station, user's machine or browser crashes, user is evil and kills his browser just to annoy you... possibilities are endless).


Is it worth padding passwords? I'm using phpass (bcrypt) to hash the password and SSL when it's transmitted, and using PDO (with PHP) to stop injections, is it worth padding the password, so that if the user enters "123456" as the password before it's hashed a prefix and/or suffix are added, so for example

123456

becomes

abcZYX123456£%$£@&$%

(prefix "abcZYX" and suffix "£%$£@&$%")

which is then salted and hashed.

the prefix and suffix could be the same or different for every password

or could it be better to require minimum lengths and combinations

For example:

Must be at least 10 characters, and have a capital letter, number and symbol

Or is it better to just hash and salt the password?

You are better off enforcing a length requirement, since you are already using a strong password hashing algorithm. Since the "padding" is added in the code of your site, it is not strongly protected. Even in the best case, when an attacker does not know the padding, if a user is allowed to pick a short enough password, it is conceivable that it would be cracked, revealing the padding scheme.

For complexity requirements, it is probably best to just give some instant feedback (JavaScript) on the strength of the password to the user as they choose their password. Users will balk at strictly-enforced policies (other than length, within reason), and your choice of algorithm should provide enough resistance to cracking for passwords of a reasonable length.


(Issue) Unusual ads on HTTP websites Most of the things written here is based on my current knowledge of networking, Any kind of help would be appreciated.

I am facing an issue regarding ads on websites not secured with HTTPS (this is my observation). To support my point, i have added images from couple of HTTP websites.

Further information, this problem is browser independent (getting same problem in safari). Ad Blocker is not working.

My Questions,

Is there any way to stop these ads or not?
If yes, then please guide me to eradicate these ads.
Again, all of the provided information is based on my current knowledge.

I am not an expert in networking, so i can only blame security of HTTP websites.

If you require furthermore information or clarity, let me know by writing comments. If this type of question has already been asked, then provide me the link and I need to work on my googling skills.

edit: This problem is not specific to my laptop, These ads are coming on other computers connected to my wifi network.

edit2: I came to know that these ads are coming on other wifi networks too provided by my ISP.

As this happens:

on HTTP websites but not HTTPS
across different browsers and even devices

then this is not an ad-injecting malware but your ISP injecting ads of his own. How to deal with this was explained before, on a different site though:

Only use HTTPS Web sites, make sure you enter "https:" while manually typing in a URL;
Set up VPN connections on your devices, or better, on your Wi-Fi router, so that all your traffic would go encrypted through the offending ISP's network. In some cases, given a proper Wi-Fi device, you might be able even to route only HTTP (port 80) traffic through the VPN, reducing latency somewhat;
Set up an ad blocker. It is understood it's not working out of the box for you, because it's unlikely your ad blocker will have correct rules predefined for your particular ISP, but you can refine those rules.
Get rid of this ISP in favor of a better one. This is the best possible solution.


Separating "function" from "scope" in RBAC I'm trying to formulate an RBAC permission model which allows separation between permissions and the scopes on which those permissions are applied. I have been unable to find a standard model which describes this.

Here's an example:

A Permission consists of an Operation on a Resource:

  (View) (Ops Reports)
  (Create) (Ops Reports)
  (Manage) (Releases)

Roles are collections of Permissions:

  A (Product Manager) can (Manage Releases) and (View Ops Reports)
  A (Ops Manager) can (Create Ops Reports) and (View Ops Reports)

Users can be assigned Roles:

  (Alice) and (Bob) are (Product Manager)s

So far, this is standard RBAC-0. Now let's add another orthogonal layer:

  (Alice) is a (Product Manager) for "Cool New Product (CNP)"
  (Bob) is a (Product Manager) for "Flagship Product (FSP)"
  (Charlie) is a (Product Manager) for ...
  ...

This seems like a fairly common use case.

In a naive implementation, we could duplicate Roles and Permissions for every Product. So instead of:

  (Product Manager)

  (Manage) (Releases)
  (View) (Ops Reports)

we now have:

  (CNP Product Manager)

  (Manage) (CNP Releases)
  (View) (CNP Ops Reports)

  (FSP Product Manager)

  (Manage) (FSP Releases)
  (View) (FSP Ops Reports)

  ...
  ...

This can quickly grow out of hand. How do I model this scenario to avoid exponential duplication?

While role-based access control (RBAC) is a major model for managing the authorizations,
implementing RBAC has some limitations and consequences.

One of the consequences is role explosion, where multiple versions (duplicates) of one role are required to separately manage access to distinct sets of data of the same class.

Role-Centric Attribute-Based Access Control is an extension to the traditional RBAC model to minimise this RBAC limitation.

Each user and object relevant for access control is associated with a set of attributes.

Attributes are assigning access control logic to users, objects, defining how users and  work together, what activities related to an object are available if a relevant attribute is assigned to a particular user.

Several approaches to RCABAC are described in literature:

use attributes to dynamically assign users to roles , for example
assign preset roles to organizational structure positions, assign
roles to business functions to simplify role assignment
treat roles as just another attribute
limit permissions of roles with attributes

Bibliography

Vincent Hu, David Ferraiolo, Richard Kuhn (NIST), Adam Schnitzer (BAH), Kenneth Sandlin, Robert Miller, Karen Scarfone, 2014, NIST, SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations

Jin, X., Sandhu, R. and Krishnan, R., 2012, October. RABAC: role-centric attribute-based access control. In International Conference on Mathematical Methods, Models, and Architectures for Computer Network Security (pp. 84-96). Springer, Berlin, Heidelberg.

Rajpoot, Q.M., Jensen, C.D. and Krishnan, R., 2015, July. Integrating attributes into role-based access control. In IFIP Annual Conference on Data and Applications Security and Privacy (pp. 242-249). Springer, Cham.

D.R. Kuhn, E.J. Coyne, T.R. Weil (2010), Adding Attributes to Role-Based Access Control, IEEE Computer (June 2010).

Other links

NIST, Role Based Access Control Project


sudo systemctl running a webserver a security risk? On linux ami the only way to easily run systemctl for my server is by running
sudo systemctl start node

In the service:
/etc/systemd/system/node.service

sudo seems to be mandatory for the 'enable', 'status', 'start' and 'stop' systemctl commands to work (I know there are tutorials out there to run as 'user' and not need to use sudo, but I have not been able to get them to work)
I have
 [Service]
 User=ec2-user

So the user is 'ec2-user' and no 'root'. So I am wondering if although I am running systemctl as root, the service itself is run as ec-2user.
Potential security risks as I understand include end-user using the webapp and uploading malicious files through the API stack - those files may then save my server for specific end-points (like when uploading a PDF or image), then this is where it gets hazy for me, but  if the end-user instead uploaded 'some kind of script' to put malware onto the server's disk instead of uploading a PDF or image.... then.... because systemctl was run as root, then the script would have might have the permissions to execute on my server or do some kind of 'command and control'?
Or is the fact that systemctl is run as 'ec2-user' and not 'root' prevent malicious files from being uploaded and executed on the stack? And I am therefore safe to run sudo systemctl ... commands so long as the [Service] user is non-root ?
This is a general question, but to have one specific example, I know ImageMagick has been riddled with this kind of security vulnerability

https://imagetragick.com/
https://us-cert.cisa.gov/ncas/current-activity/2016/05/04/ImageMagick-Vulnerability

Services like web servers should be run without escalated privileges, exactly for the reasons that you describe in your question.
While it is true that you must be root to run systemctl, the user that the web server runs under is usually another user with lower privileges.  In the case of apache or apache2, the user is is often www-data, apache, or nobody.
For more information on how to see which user apache/apache2 is running as, see https://serverfault.com/questions/125865/finding-out-what-user-apache-is-running-as
For more information on starting/stopping apache/apache2 using systemctl, see https://unix.stackexchange.com/questions/290923/apache-and-systemctl-status


What are the 'P' values in some cipher string? Most of the cipher strings I see are in the format:

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

However, I've come across workstations with cipher strings that have an additional 'P' value:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521

What are the 'P' values for (what do they represent)? Also, some look like common hashing lengths, but the '521' above is not a typo.

UPDATE:

Sorry, I should have asked my questions more specifically:
1. What is the difference between cipher suites with and without the P-values?
2. Are cipher strings with P-values stronger or weaker?
3. In basic terms, what does the addition of P-values do for the PKI process? Is it a nested/additional message authentication of some sort?
4. Is 521 a hash length? If not, what is it?

P521 is an elliptic curve

“P521” is a dead giveaway for an elliptic curve which SECG and TLS formally call secp521r1 and which NIST FIPS 186-4 calls P-521. An elliptic curve is a mathematical domain used by elliptic curve algorithm such as ECDH and ECDSA.

Curves are generally known by a name that includes some information about the type of curve and the key size¹. The letters “sec” stand for SECG (Standards for Efficient Cryptography Group), and the specifically for the curves described in SEC2. The following P is because the curve is over a prime field (a finite field whose number of elements is prime). 521 is the bit size associated with the curve. The R indicates that certain parameters of the curve were generated at random, and the final 1 is because this is the first (and so far only) secp521r curve.

Curve parameters are typically chosen in such a way as to make calculations faster, given mathematical constraints to ensure that the parameters have the required security properties. In particular, it helps if the size of the field differs from a power of 2 by as few bits as possible, because that allows fast modulo reduction. It happens that 2521-1 is prime. There's no prime that's nearly as nice and has 512 bits or a little less.

In terms of sizes, today, 256 bits is considered enough for elliptic curves for ephemeral key exchange (ECDH) and signature (ECDSA). As usual, larger sizes give more resistance (but being more resistant that “unbreakable in practice” isn't a practical benefit) at the cost of less performance.

Elliptic curves and TLS cipher suites

A TLS cipher suite is a set of parameters that describe how the TLS protocol sets up the keys that are used for the communication. See How does SSL/TLS work? for more information. For example, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 means to perform a key exchange using elliptic-curve Diffie-Hellman (ECDH) with single-use (E for ephemeral keys), verifying the server's signature with RSA, and using AES-128-CBC to encrypt the secure channel and HMAC-SHA-256 to authenticate it. The client and the server negotiate which cipher suite to use at the beginning of the TLS connection (the client sends the list of cipher suites that it supports, and the server picks one and lets the client know which one). The choice of elliptic curve for ECDH is not part of the cipher suite encoding. The curve is negotiated separately (here too, the client proposes and the server decides).

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 is not a thing that's different from TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256. It means to use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 with secp521r1 for the ECDHE part.

Most TLS server software allows the administrator to configure which security parameters it's willing to support. Sometimes this is done independently for each piece (which key exchange types, which key agreement algorithms, which hashes for signature, which elliptic curves, which hashes for HMAC, which symmetric ciphers, which AEAD algorithms, …). Here you select which elliptic curve to support separately for each cipher suite. The choice of which parameters to configure together is a matter of convenience vs flexibility.

¹  More precisely, it's the size in bits of the coordinates of points on the curve. But for all common curves, that's also the size in bits of the private key.


What's this type of leak detection method called? Suppose I want to figure out which of a group of people is distributing my content without authorization.  So I create several different versions of the same content, each with a unique watermark embedded.  Then, when I come across a pirate copy of the content in the wild, I can check the watermark, so I can see which of the original recipients was the distributor.

What is this method of leak detection called?

I believe the term you're looking for is a "canary trap", which is a form of offensive counterintelligence.

This is similar to a suspected double-agent being given false information, which they then leak back to their handlers. This can then be used to show that the agent, being the only one told that information, was the real leak.


Can't get IP of vulnerable VMs I have Kali Linux installed on my computer, I have VMware Workstation 15.5 downloaded on my Kali machine, and I have also vulnerable VMs on VMWare but I don't know how to get IP of vulnerable VMs like necromancer, Kioptrix, etc.

Necromancer is using DHCP, which means that it gets an IP address from your local DHCP server.

Assuming you have the VM connected to your local home network, the
DHCP server is most likely running on your home router. In this
case, you can check which IPs are registered there and should be
able to identify the right systems based on their lease time or
their MAC address (which you can find in the network settings in
VMWare).
If you have configured your VMWare environment to play DHCP, the
VM will get its IP from VMWare directly. In this case you can
simply restrict the DHCP range in VMWare to a single IP and
thereby know, which IP the VM will get.


How can a Mac OS X user protect themselves from shell-shock AND remain connected to the internet right now Seems to me that there is a need to remain online, esp. for business users and that even when this is corrected, there will be a need to go back online to get the Apple patch. e.g. Is removing bash a viable workaround to remain secure for the moment.

Business users can mitigate their risk using their perimeter IPS protection (or palo alto nextgen firewalls) for CVE-2014-6271 but need to wait for released protection on the related CVE-2014-7219 over the next 24 hours.

Source (in my case palo alto):  https://securityadvisories.paloaltonetworks.com/


If I change my private key PGP passphrase, will the old private key+old passphrase work to decrypt already encrypted data? Suppose I have a script that contains my PGP private key in plain text and requires me to manually type in the key passphrase to decrypt some data. Later, I decide that my passphrase is compromised and use gpg to change the passphrase. Would someone that has my old PGP private key and captured somehow my old passphrase be still able to decrypt data?

In other words I am thinking if regularly changing the passphrase would do any good in terms of securing the data or not. As far as I understand, changing the PGP private key passphrase only affects the private key, and public key is unaffected. This leads me to thinking that if someone is in possession of my old PGP private key and old passphrase, he may still be able to decrypt messages, even after I change my passphrase.

I hope that makes sense :)
Thanks

You are correct: the passphrase protects the key, so if both have been leaked, then the attacker can decrypt any previously intercepted messages, and any future messages using the same key.

Remember that the attacker has a copy of the key with the old passphrase in his posession - changing the passphrase on your copy of the key does not affect his copy. Also a passphrase change does not affect the key itself, so any compromises of the key are permanent.

So if you suspect a key + passphrase has been leaked, revoke it immediately and generate a new key.


Working code examples for stack or heap buffer overflows? I understand how this exploits work on the theoretical level, but I can't find detailed worked tutorials that show for example how to overwrite the return adress in the stack when overflowing a given buffer in a given function etc. Is there a database of such shared exploits ?

Exploit-DB is a well-known repository for exploit code and includes a number of overflows.  For example, here's one against socat which includes the steps required to exercise the overflow.  Some exploits have more information, some less, but if you browse enough you should find the sort of shared exploit you're looking for.


How do I share my S/MIME public key? I have setup S/MIME encryption for my email address, and I'd like to allow people to download the public key from my website, rather than having to first receive an email from me.

I want the public key next to the email address on my website's "contact me" page.

Is there a file format/extension commonly supported by various S/MIME compatible email programs?

For a single certificate, a PEM encoded format is common, this is the text/base64 one that is delimited by:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

Most systems should accept .crt and .pem extensions for this file type, the former is slightly preferable for a certificate, .cer may work too.

PEM is an encoding of data using base64 for the data, the underlying binary format is referred to as DER format. Certificates in DER format are often named with .der, but may be named with .crt or .cer too.

PEM and DER are encodings, the extensions .der and .pem are sometimes used, regardless of the type(s) of the encoded data. Sometimes the extension indicates the nature of the data (certificate, key, CRL), but not the encoding...

When MIME is involved (as it will be with HTTP, and email attachments), the MIME type is also an important consideration, some clients may rely on, or prefer this, to determine the action for a file.

The PEM format has delimiters which indicate the nature of the data, and lends itself to "bundling" multiple PEM encoded objects in a single file. This is often used to provide multiple related certificates e.g. a CA chain (but not everything will process all certificates in such a file), or a cert/key pair.
PKCS#7 or CMS (Cryptographic Message Syntax) is the preferred way of encapsulating things, notionally it's for signed and/or encrypted messages, but it's valid for it to contain no message, just certificates.

I recommend you:

make your certificate available in a PEM encoded file with a .crt extension
check the web server MIME mappings are present and correct
optionally create and make available a .p7b file containing the cert and CA chain, this will allow clients to update/install anything missing from their local intermediate CA cache and enable proper verification the chain

Unlike PGP, and presumably related to the different design and distribution mechanism, it's not common to publish a certificate fingerprint, though you can do so, and you may also publish your SKI (Subject Key Identifier) to be thorough.

If you're not familiar with OpenSSL use, this reference site or this online tool and command reference should help with converting. Do not under any circumstances upload a .key or .pfx file ;-)


How to use clipboard manager software more securely? I want to minimize the risks using a clipboard manager or clipboard history software. I want to use it because it really eases my work so not using it is not a good option.

These programs usually store clipboard content on a file to preserve history between reboots. This file is not encrypted so it's a matter to consider.

For start I blocked the program ability to send/receive data with a firewall.
What else do you advise?

If you are only concerned with securing the program's files, then you could use TrueCrypt to create a container, mount it as a new drive letter and the install your clipboard manager there. This way, if someone steals your computer, he would not have access to these files.
Full disk encryption is of course a much better option, because it would protect all the files on your hard disk, in case of hardware theft.

On the other side, securing a program you know nothing about is quite complicated. It is not enough to block the program from using the network. Any other program running on your system may access the clipboard manager's files and send them over the network. So be carefull when installing software from unkown sources.

Besides the general recommendations of keeping your system and your antivirus/antispyware/firewall programas updated I would advise using a simple Clipboard Manager, which offers only the functionality you need. If it is simple it means that less things could go wrong.
Moreover, popular opensource clipboard managers are less likely to contain malicious code, as everyone could detect it by analyzing the sources.


Default or Guessable SNMP community names: public We have detected "Default or Guessable SNMP community names: public" vulnerability in one of our printer through Nexpose. The remediation states we have to secure SNMP installation. What does it mean should we have to disable SNMP services on that particular printer or we have to upgrade SNMP version to SNMPv3?

Rapid7 have written up about this on their blog. They are basically saying that if SNMP isn't required, then it should be disabled so the attack surface is reduced, however if it is required then you should upgrade to SNMPv3 as it has security improvements:

  Confidentiality – Encryption of packets to prevent snooping by an
  unauthorized source.
  Integrity – Message integrity to ensure that a
  packet has not been tampered while in transit including an optional
  packet replay protection mechanism.
  Authentication – to verify that
  the message is from a valid source.

@Daisetsu has pointed out that only SNMPv1 and SNMPv2c use a community string. SNMPv3 instead uses an authentication key, a secret key used for authentication and a privacy key, a secret key used for encryption. (This can be seen in the RFC section 3.1, 4a and 6a).

Both these keys should be different and complex to make guessing attacks difficult, following similar requirements to those linked in the Rapid7 blog.


How do I check that users don't write down their passwords? I have a password policy which states that users must not write and store their passwords down in plaintext. How can I ensure that they haven't done so by writing their password in emails, scripts, documents or files?

As others said, you can't stop them. But you can remove the incentive.

Does your password policy require any of the following?

Changing at regular intervals
Manual entering (password managers blocked)
Complex format (differing cases, special characters, etc.)

If so, you are actively incentivizing people to write the password down. Drop the outdated password policy and your users will be much more likely to play along.

Recommendations based on the new NIST guidelines. There is a nice summary here.


Server closed connection error on several browsers when testing SSL I have uploaded a SSL Certificate to my site www.walksindorset.co.uk.

When I test the SSL rating I receive the error message "Server closed connection" on over 15 browsers which includes Andriod 4.0.4, 4.2.2, 4.3 and IE 6 to IE 8.

I cannot find a solution to this problem. Can anyone help?

I am using a shared hosting package via Fasthosts.

Several of the browsers that are not supported on that list do not support TLS 1.2, which is the only protocol that your sever is configured to use..

Here is an example of some of the browsers you are having issues with viewing HTTPs


Is every client-side language more vulnerable? With web browser plug-ins like Firebug, it is easy to manipulate the source code of client-side language such as HTML and JS. Then are those languages more vulnerable than server-side ones ?

When one is building security for his site, is JS alone totally useless ?

This is a issue of who controls the code. Let's leave out that there are some modern framework like node for JavaScript on the server side.

The languages themselves are not necessarily more vulnerable. Most flaws are not results of the underlying language, but of the various logic checks, input sensitization, etc.

That said, you cannot control the code client side, which means that the local user can modify it. It can also be modified by man-in-the-middle attack on the network or by a man-in-the-browser attack where the attacker has compromised the local machine/browser.

On the server side, they would have to break into your server to modify the code. However, that does not mean the code is necessarily more secure.

While you can modify the JavaScript through your code inspector locally, if you did something malicious, you would be doing it to yourself. Just because you change the code doesn't mean it will affect other users. However, you can create attacks against the page request that you then send to someone else which will result in XSS or CSRF. This would result in an attack being carried out against the user. At the same time, you can change the request so that malicious requests or data are sent to the server which result in a buffer overflow or a code injection (e.g., SQL injection).

One of the differences is that you can more easily craft an attack if you have access to the code. Since you can see the source of the HTML and JavaScript, it may be easier to craft an exploit, but that same knowledge might lead to crafting a SQL injection.

Now, to your last point. You should ensure all of your security checks are performed on the server side because you cannot trust client-side validation since it only affects what's going on in the browser. An attacker locally or MiTM can still change the raw HTTP traffic, which would result in your client-side validation effectively being ignored. Client side validation is a convenience for your users and to save some cycles on your server.


Can IP address considered as a useful feature for intrusion detection? I am trying to build a machine learning model which classifies attacks. My data has a bunch of IP addresses, and I don't know if I should use the IP address as a feature to detect attacks. I found this interesting argument:

"IP can be spoofed by the attacker. Hence, it may be infeasible to use it as a feature for attack classification in intrusion detection systems. Features which are independent and cannot be changed by attacker can be useful in classification problems."

This is pretty logical for me, but I don't know if I should completely ignore the IP address in intrusion detection, especially that my data (log files from different devices) has multi-step attack scenarios,  What do you think?

I believe the IP address provides useful information.

IP addresses can be "spoofed" in the connectionless protocols like UDP and ICMP. If you're worried about DDoS attacks via traffic amplification, the spoofed address is almost critical to discovering what's going on.

Connection-oriented protocols like TCP or SCTP are far harder to spoof (though BGP hijacking means it happens surprisingly often).

Attacks I've seen from botnets often include a large number of compromised machines from some specific ISPs. In some attacks it was just easier to block entire /16s from the attacked services. Once I found the specific ISP it was easy to look up other netblocks they own and block those too, on grounds that either their CPE was hacked, or their users were insecure as a group. Tracking the IPs lets you find out if specific networks have poor security.


Can I control surveillance system remotely without an app/browser? I'm looking to purchase a POE surveillance system that allows me to store the DVR away from the TV, yet still be able to control the system with an external infrared sensor or the App and still watch on my TV.

I don't want to have to view through a browser, but actually be able to view it on a normal TV through the HDMI (or whatever input) and still be able to select the different cameras and navigate on the TV.

Is this particular feature called something or is there a way to do this with some/most surveillance systems?

If you can find a security camera that has HDMI and implements HDMI-CEC then you may be able to control it through your television.


Are Ad-hoc security testing beneficial to small business? While reflecting on enterprise scale security program, I had this question if small scale businesses benefit at all from an ad-hoc security testing?

What are some suggestions that will solve the security problems in a small organization where human resources aren't available compared to that of an enterprise scale?

I would argue that any testing is better than no testing. The problem with ad hoc testing is it runs the risk of creating a false sense of security or is not targeted at the right level. The business feels it has overall increased security due to the ad hoc testing. This may be true, but at the same time, due to the nature of this type of testing, it is quite possible that a major security hole has not been identified.

Security for small business is extremely difficult. In addition to the lack of staff resources available to perform the work, you frequently have a low level of security awareness as well. Getting basic technical configurations right is relatively easy compared to ensuring the users of the system are informed and don't do silly things, such as click on bad links in suspicious emails. It really doesn't matter how much testing of the software and infrastructure you have in place if one of the users is going to accidentally bring malicious code into your network and bypass all your measures put in place to protect the systems.

One of the largest challenges in small businesses is getting the owners to realise that information technology investment is different to other infrastructure investment. When you invest in new physical assets, such as a building, updated furniture and fittings etc, once that investment is paid for, you normally won't need much on-going investment/maintenance. With IT infrastructure, the on-going maintenance and need for on-going investment tends to be much higher. Too often, small business think they can buy a server, possibly pay someone to develop a little bit of specialist software and their done. They fail to recognise the on-going investment required to ensure the server is patched and up-to-date, the maintenance for the simple bit of software to ensure it stays current, is compatible with later versions of supporting software and operating systems and is patched against evolving threats etc.

My approach is to actively discourage small businesses from running infrastructure where possible. I encourage small businesses to take advantage of SaaS and cloud services. As far as possible, limit what IT they are actually responsible for maintaining to the absolute minimum. This can be a challenge as they don't understand all the hidden costs - it looks cheaper to do it yourself. You need to expose the hidden costs to allow them to make a fully informed decision and ensure this includes some basic regular testing/checking, reliable automated backups etc and ensure there is a plan for when things fail. The plan needs to include how to recover from the failure i.e disaster recovery as well as how to continue business while you are recovering i.e. business continuity.

In those situations where the business has no choice other than to run/develop their own software, look for solutions which will limit their need to invest in security. For example, a hosting provider where the hosting company takes care of hardware and operating system security and the business only needs to worry about application security. Work to help the business develop procedures which facilitate good practices and understanding of the risks and try to ensure these actually reflect the real risks faced by the business (rather than just implement good practice, assess the risks specific good practice is designed to protect against and determine if that really is a risk for that business) and recognise you cannot eliminate all security risks - there is never enough resources. You need to identify exactly what the real risks are for the specific business and prioritise them so that whatever resources are available for ad hoc testing are targeted at the highest priorities. Clearly communicate the risks which are not being addressed and what their likelihood and consequence is so that the business can make an informed decision as to whether they need to invest in additional resources.


Why doesn't SMTP check that users are authenticated to send from an address? I think it's a bit different from this question since it's about SMTP, but similar idea. Wikipedia says on email spoofing:

MAIL FROM: - generally presented to the recipient as the Return-path:
header but not normally visible to the end user, and by default no
checks are done that the sending system is authorized to send on
behalf of that address.

So is there a reason why we don't check? It would seem to make sense we'd have some form of digital signature to check.

So is there a reason why we don't check?

Because SMTP was designed at a time where the sender was considered trusted. The origins date at least back to RFC 788 from 1981, i.e. at a time where only comparably few nodes on the internet existed, mails could be easily traced back to the sending node by IP address and sender spoofing was not an issue.

  It would seem to make sense we'd have some form of digital signature to check.

A digital signature would require to have each sender some kind of key or certificate in the first place. Also this certificate would need to be widely trusted because otherwise one could not really check if the sender is the one he claims (i.e. self-signed certificates would not help). One also would need some infrastructure to revoke and renew certificates in case they were compromised.

Instead it is common today to require authentication by the end user. But since SMTP is a hop by hop model where the end user only sends the mail to the first hop and the next hop forwards the mail in behalf of the original user  the other hops are still somehow need to trust each other. There are some mechanism to make at least sure that the claimed senders IP address is somehow associated with the senders IP (SPF), to have some trustable path between mail servers (DKIM) and to align the SMTP.MAILFROM with the RFC822.From (i.e. SMTP envelope with mail header) as done with DMARC. Only, these "add-ons" are not sufficiently employed to broadly protect against sender spoofing.


Is HostGator storing my password in plaintext? I want to bring this up to HostGator, but want to verify my suspicions before making a big fuss.

I asked a customer care representative to help me add an SSL certificate to a site I host with them. When he was done, I received this e-mail with all my login information, and my entire password in plain text (I left the first letter visible as evidence). I set up this password over a year ago, and it was a big surprise to find out they sent it back to me, unprompted, in plaintext:

I immediately brought this up to the representative, who repeatedly tried to convince me that it was OK. I decided to drop it after a few minutes, because I think I should bring it up to someone higher up. Before I do so, is it safe to assume that my password is stored in their database as plain text? If so, do you have any suggestions on how to address this issue with the provider?

Yep, that's a big problem, especially if that was your old password (i.e. not a newly assigned one).

Technically, the password might be stored under reversible encryption rather than plain text, but that's nearly as bad. The absolute minimum standard should be a salted hash - anything less and anybody with access to the auth database who wants to can use an online rainbow table to get back the plaintext passwords in moments - but single-iteration secure hash algorithm (SHA) functions are still easy to brute force with a GPU (they're designed to be fast; a high-end GPU can compute billions per second) so they really ought to be using a proper password hashing function such as scrypt or argon2, or in a pinch bcrypt or PBKDF2.

Also, there is absolutely no way to guarantee that the email was encrypted along the entire path between their mail server and your email client. Email was designed in a day when people didn't really consider such things to be critical, and short of an end-to-end encryption scheme like OpenPGP or S/MIME, email is at best encrypted opportunistically, and may be passed through an unencrypted relay.


Root/Naked domain and DDOS Some services like Github has DDOS mitigation measures for their root/naked domain, but not other subdomain(s).

What so special about the root domain concerning the DDOS attacks?

[1] http://instantclick.io/github-pages-and-apex-domains

You usually set up a host name for DDOS protection by having a DNS CNAME record that points to the DDOS protection provider. This lets the provider adjust the IP address (or addresses) that the domain points to.

Setting up www.domain.com to use a CNAME record is easy. It's not so easy for domain.com because once a host name has a CNAME record, it cannot have any other records, and domain.com would usually have MX and NS records to handle mail and DNS resolution.

However, CloudFlare now supports CNAME flattening which does allow this.


Does fuzz testing produce different output compared to manual testing? I am testing an API and one parameter is vulnerable to SQL injection. When I run OWASP ZAP's fuzzer on this parameter, the input "; or 1=1" results in a successful exploit of SQL injection. However, manually supplying this input results in an Oracle error code and the exploit is not successful.

Is it the case then that fuzzers can result in successful exploits for certain inputs that manual testing cannot? I am trying to understand more about fuzzers and it seems to me that fuzzers can generate certain conditions that manual testing can't generate. Is this correct? If so, why?

[I]t seems to me that fuzzers can generate certain conditions that manual testing can't generate.

No, they can't. The server does not know if an HTTP request originates from a fuzzer like ZAP, a browser or anything else as long as they send exactly the same HTTP request.

The key words here are exactly the same. Since you don't know what is going on on the server, anything could possibly affect the result. Look at the HTTP request you send from ZAP (see demo), and look at the HTTP request you send manually. If you are using a browser for the manual testing, just use the developer tools to see it. An alternative approach is to use a program like WireShark to inspect the requests.

When you got the two requests in front of you, compare them. Where is the difference? That is probably the solution to this mystery.

An alternative explanation would be random behaviour on the server, or a change of behavior because the exploit was fixed. Repeated testing could rule out those.


Is it safe to distribute the server's certificate file with the client? I've been working on making an SSL server/client on C++ using Boost. To load the certificates, I use the following code for each side:
server.cpp
boost::asio::ssl::context ssl_context(boost::asio::ssl::context::tls);

ssl_context.use_certificate_chain_file("server.crt");
ssl_context.use_private_key_file("server.key", boost::asio::ssl::context::pem);
ssl_context.use_tmp_dh_file("dh2048.pem");

client.cpp
boost::asio::ssl::context ssl_context(boost::asio::ssl::context::tls);
ssl_context.set_verify_mode(boost::asio::ssl::verify_peer);

ssl_context.load_verify_file("server.crt");

If I don't add the ssl_context.load_verify_file("server.crt"); line on the client, I get the following errors from both sides during SSL handshake:
server: handshake: tlsv1 alert unknown ca
client: handshake: certificate verify failed
So, is it safe to distribute the "server.crt" certificate chain file with the client? If not, how should this be done instead?

The problem is that your server certificate is either self-signed, or signed by an untrusted certificate authority.  I'm guessing that when you created the certificate, you just did it yourself in OpenSSL, and you did not have it signed by a legitimate trusted certificate authority.  Because it lacks a legitimate signature, your client has no way to recognize the certificate is valid, which is why the client sees the "certificate verify failed" error.
To fix this, there are a few options.

The best would be for you to replace your server certificate with a new one signed by an actual Trusted Certificate Authority (one that your server and client already trust).  That way both your server and client will be able to trust your certificates and each other; now, and into the future.
An option that provides no security is to continue to include the server certificate with the client.  It's convenient, but it directly ties your clients to only that server and certificate.  Your clients will break when your fake server certificate expires, and they'll have to come to you for a new certificate.  What's to stop an attacker who says he's distributing a copy of your software, including his own certificates, promising that it's secure?  Nothing.  Your certificates provide no assurance that the client and server are genuine and are run by you.
A third option (that is even less secure) is to import a copy of your signing certificate into both your server and client's trusted root authority stores.  It's less secure because it exposes your clients to risk, because they'll then trust anything signed by your little fake certificate authority.  I would only recommend this as a good way to learn how certificates and certificate authorities protect your communications; I would not recommend this as a long term solution.


Keyboard forensics? (Physical layer) If I had a strong bootup password that I typed into my keyboard daily to mount my "encrypted system partition"...

Q1) Would it be possible for an adversary to find out my password by analyzing my keyboard?  For example, by breaking it down and finding what characters are used frequently? (Ex: if I typed in my pass every day for like months/years)

Q2) If i bought a new keyboard or laptop, and only typed my password  infrequently (2-3 times) and I rarely used my laptop to type anything else, is it still possible? Or very unlikely?

Q3) If I bought a brand new keyboard, and typed it in once or twice, and then typed in fake keys after I hit "enter".. would this also be very unlikely?
(Ex: if the pass is 12345.. i would type in 12345 ENTER then 67890qweurhdghkjnxxvbmbvxjkbvkjb     etc etc)

EDIT

Okay thanks for all the replies. I feel like I got a grasp on how this works, but just to clarify....

In other words, If I typed in a password every morning, and throughout the day I typed random letters/numbers, there is no way to distinguish... "THESE specific keys (AKA my password), are typed together at THIS particular time"  while the rest of the keys typed are randomly throughout the day etc.........

OR If I typed in a password every morning for lets say a month.... and rarely typed any other keys except ENTER and using my mouse...........And then a year later I started typing like normal,

There would be no way to distinguish, THESE KEYS (aka my password) were typed a lot in THIS YEAR..... and now every other key have been typed for the last month...........?

In other words,
1. I can type 12345 every day for a month and NEVER TOUCH any other key.
2. and 1 year later, I can type regularly most letters/numbers,

There would be no way to distinguish WHEN certain keys or letters were typed? (Ex: There would be no way to distinguish 12345 were typed uniquely at a different timeframe than the rest of the keys)

Does that make sense? (Sorry its a little confusing but I am not the most articulate communicator!)

No, unless you used letters that are not common and entered your password a LOT.  The most commonly used letters of the English language are EATONDSR, I believe.  So if your password contained any of those letters, it would be impossible to know whether you used them in your password or in standard keyboarding.  If, however, you used JXQZ in your password, those would have abnormal wear on them relative to someone who didn't use them.  That might give an adversary a starting point.  However, you would (again) need to enter your password a LOT.

Keep in mind that you generally enter your password once per session.  If you type e-mails, documents, or do other text work the noise to signal ratio would be very high.  The keys used for standard text work would wear LONG before the keys used for your password would.  Even typing your question here created a high signal-noise ration in terms of wear on the keyboard.  Because of that, it would take someone very dedicated to do this.  It would be a lot easier to  attack the machine a different way than to analyze your keyboard.

Edit:  Even if you only entered your password on the keyboard and then used only the mouse, the attacker would only be able to find the keys that get pressed.  They would have no idea of the length of the password and, if you used the shift key once in the sequence, no idea of where you used the shift key.  That reduces the number of possibilities from infinity to a pretty huge universe.  They'd still need to try every possible combination of those letters, out to the max possible length.


How to explain to traditional people why they should upgrade their old Windows XP device? This is an issue I'm recurringly facing: older people from my family (or people who my family members know) can be surprisingly reluctant to apply most basic security measures when they're using their PCs. The particular issues vary, but this time I'm struggling with a really egregious one: the refusal to upgrade from their ~20-year-old Windows XP PC. (Or is this an even older version of Windows? I don't really know as I did not see it yet.)

How can I explain that it is a bad idea nowadays to connect to the internet with such a PC?

I think that this question will only be clear and meaningful if I add an addendum about the mindset of such people... which seems to me to be really peculiar:

They seem to have no notion of obsolescence of things. In their minds, a computer is in good shape if and only if it is capable to perform the tasks they need it to perform (eg. "receive this important document sent to my e-mail address, make such-and-such modifications to this document, send it back"). Thus if they're able to do this it is hard to explain to them they should buy a new PC.
They remember the times of poverty, when it was irresponsible (and actually plain stupid) to replace things carelessly. In their times broken things were being fixed if possible, and only replaced if repairs were no longer possible. Some of them are still poor, so they may have actual (rather than just mental) reasons to refuse to spend a three digit sum on new things.
They seem reluctant to understand how to operate stuff from the modern era. They seem to want a concise, clearly defined order of steps necessary to perform a task (rather than understanding of the abstractions of modern GUIs so that they can operate their PCs regardless of whatever it shows them). If anything strays from this clear order of steps (eg the computer shows them an unexpected dialog) they get confused and may deem their computer "broken" (and call me to "fix" it for them).

Actual example: "I don't know what happens, why can I not get to my e-mail inbox without all of this annoying stuff? It keeps displaying me these annoying messages about passwords and phone numbers! Please fix it for me so that clicking this picture will get me to my e-mail inbox!"
As a result, whenever anything changes in their computer (eg this WinXP is upgraded finally...) that interferes with their well-known, predictable order of steps / responses from their PC it is likely they'll say I "broke more than I fixed". They have a clear definition of "fixing" their PC... "make it behave exactly as it used to".

When told about security (eg that a middle school kiddie next door could break into their PC) they tend to respond along the lines of "Am I working in a three letter agency?" or "Who am I, a millionaire? There's no reason anyone would want to target me!"

Actually, if I think about it, their point of view, even if fallacious, kind of makes sense... They simply treat a PC as a tool like that they're accustomed of, something like a hammer or a (traditional, simple, devoid of electronics) vacuum cleaner... Their approach, listed above, seems reasonable if they were talking about a hammer rather than a PC, I guess...

I'm running out of arguments. In the spirit of this question, may I ask how to talk to such old-timers?

(updated, at the bottom - "The 1950 car")
Forget talking about security.
Don't take the "SECURITY" road. Because if you talk about "security" alone, then chances are good that they are right, and you are wrong, and they'll be clear-sighted enough to realize it.
There is no computer that is completely secure, and there is no computer that is completely insecure. It all depends on what the attack surface is.
This point of view I'm offering will be exceedingly unpopular for the IT crowd, but acknowledge that for your average elder home user (I'm of course not referring to anyone else):

the threat from an email (phishing, ransomware, etc.) is more or less the same whatever your base OS. It might be even be slightly less for 32-bit Windows XP, as the newer malwares are increasingly adopting the 64bit model. Granted, on XP a malware might be able to more easily self-elevate and wreck - in addition to everything the user deems important - also lots of things he cares not a whit about, from the OS itself to other, nonexistent users' and superusers' data. Here, the keyword is "BACKUP", not "fully patched OS" or "shadow copy" or "sandboxing". A backed-up XP is lots better than a non-backed-up Windows 10 Pro.

the threat of a local exploit is virtually nil. They probably have the password, if any, sticked to the monitor anyway.

remote exploits for XP are an extremely remote threat.

inability to access new things, sites, and services, or to install new apps, and do anything else that the user is not interested in doing anyway... is no discomfort at all.

Actually, by openly acknowledging the above, you'll probably come across as more aligned with their way of thinking, which will help getting through what follows.
So... "WHY SHOULD I ABANDON XP?"
For reasons that aren't good for the elder home user, but are so for the rest of the world, the world is moving away from Windows XP. That's a fact. It's leaving Windows 7 behind, even.
This includes applications (such as antiviruses) and web sites.
Windows XP cannot use the more advanced protocols that the new sites increasingly adopt, and there are fewer and fewer maintained antivirus databases that are compatible with Windows XP.
So, by continuing using Windows XP:

they will unable to access more and more sites (home banking ones, most surely).
they will very likely be left without antivirus protection, which is bad whatever OS you run.

It's like you own an old 1950 jalopy. It still drives, why should you change it? Well, imagine some roads no longer accept cars without the new safety measures that you cannot install. Then those roads are closed to your 1950 rust bucket. Yes, it runs, but it might not take you somewhere, for no fault of its own. Or you no longer find some spare parts. You get the drift.
If you use Windows XP in a way that's secure even under these conditions (which means "it never connects to the Internet"), for example you run the house accounting, do a little word processing, print, and have a phone or tablet for everything else... then by all means you can continue doing so.
If you're okay with being unable to access several sites, or find it no big trouble to restart after a large ransomware attack - for example because ten years ago your favorite nephew gave you a DBAN CD with one-click bare metal restore kit for Christmas, and the CD still works - then by all means continue doing so.
In all other cases one should consider to put up with a change in user interface and a usually reasonable expense, and get oneself a new PC with Windows 10.
On that note, you should also verify what applications are now being used and what their closest replacements are. The main real reason for "not changing" is in my experience unwillingness and fear of learning something new. The more the new system resembles the old, the more easily it will be accepted.
The 1950 car
Several commenters have raised very good points, and/or observed that I've been somewhat unclear. Thinking about it, the "old car" is an analogy worth expanding.
First of all no, I am not advising or condoning "no security". Gramps' car is kept in good condition and is equipped with working brakes, alarm and spare tires - a backup, and an updated antivirus.
And Gramps, being Gramps, only ever uses the car to move between the city and his summer cabin upcountry. He sees no reason to get the new Windows 10 Hybrid zero-emission vehicle; to the contrary, he's very much afraid he'll have to re-learn to drive. He doesn't drive for pleasure, to him a car is just like a hammer or a shovel - it's a tool that does its job.
To get him on the new car, I feel we need to understand and accept, first, that all the newfangled gadgets are actually worthless to him, and actually several modern threats will not run against his car because it's too ancient. He simply does too little with the thing to have a significant attack surface, and that surface is already covered by his existing system.
The arguments we have are rather that he still needs updates for something (at a minimum, the antivirus) and those updates are likely to disappear since the user base for 32-bit XP antiviruses is dwindling, and fewer and fewer companies find it profitable to cater to his demographic. When they stop altogether, his "car" will find itself with "brakes" working worse and worse. Until the day he has need of them, because a mail arrives with a new virus, and, well. At the same time, he already has access to less and less resources. What if his bank drops XP SSL browser support? It would be like the nearby gas stations more and more supplying electricity instead of gas.
Another point to consider is how to transition. The fear is having to learn an unfamiliar way of driving. But in this case the metaphor fails, because there are extensions and configurations that can make Windows 10 very close to Windows XP in look and feel. Once this stumbling block has been overcome, chances are that the transition will be actually eagerly embraced.
(I got several relatives off XP, and am only now weaning myself out of Windows 7 in Classic mode. I can relate to those elders :-) ).