What does the EC_POINT_FORMAT TLS extension protect against and what is the risk of not using it?

TLDR: not much

Sending the extension is basically to inform the peer whether you support compressed points, since support for uncompressed points is mandatory (if you support EC ciphersuites and certs at all).

If you don't support compression and don't send the extension, there's conceivably a risk the peer may send you a cert/chain and/or ephemeral key that uses compression, which you cannot process so the handshake fails, even if the peer might have been able to use an uncompressed-point cert/chain and/or key or some other negotiable ciphersuite that would have worked. But RFC 4492 5.2 explicitly prohibits the client from doing this, and general Postelianism should discourage the server although 4 is at best ambiguous. Not to mention I've not seen any implementation of EC that doesn't support compression in the first place.

If you do support compression but don't send the extension, there's a risk the peer may fail to use a cert/chain with compressed point(s) even though you would have accepted it. If it does not have another cert/chain (and related parameters if applicable such as DHE) for a ciphersuite supported by both parties, this may mean the TLS connection fails entirely, and depending on the systems and users involved, might provoke them to use alternative communications that are insecure or less secure. If it does have another cert/chain without compression and is able to complete the handshake, it wastes a very small amount of bandwidth which almost certainly doesn't matter and the resulting connection might possibly not be as strong as it could have been, but if both parties are configued and implemented correctly it should still be sufficiently secure. There should not be any issue with the ephemeral key because the server can decompress that if necessary.


How to process or manage Key-Encryption-Key using HSM?

If the encryption/decryption of the data is taking place on the HSM, the KEK will decrypt the DEK for performing encryption/decryption operations. All key management, key storage and crypto takes place within the HSM.

If the encryption/decryption of the data is taking place in the application, you could interface with the HSM to extract the DEK and do your crypto at the application. All key management and storage would remain within the HSM though cryptographic operations would be handled on the application server.

If the encryption/decryption of the data is taking place in the application and the application holds the DEK secured with the KEK, you may retrieve the KEK from the HSM, decrypt the DEK and do your crypto. All key management and storage is handled between the HSM and the application and cryptographic operations would be handled on the application server.

You can use the HSM however best suits your requirements.


Risks posed by docker daemon running as root

The docker daemon does run as root, as it interfaces with the host operating system in a farily fundamental manner, however that's no different than most/any system daemon that makes use of linux capabilities which require that privilege.

This doesn't mean that using docker is insecure, just that you need to be careful with how you use it.  Luckily there is already some fairly good security configuration advice available on this from Docker themselves and in the form of a security configuration "best practices" guide from the Center for Internet Security

A couple of practical considerations which you do need to be aware of when running docker.

First up is that if someone is a member of the "docker" group on the host, they're effectively root on the system as it's possible to use docker to escalate privileges in this case. So you need to treat membership of that group on production hosts with care.

Docker uses Linux capabilities to restrict what actions a user inside a container can take, so just being root inside a container doesn't necessarily mean automatic root on the host.  That said you do need to be careful with things like volume mounts (so if you mount a system directory from the host into a container for example) as this can allow a root user inside a container to make changes to files on the host.

You can also reduce the capabilities provided to a container fairly easily, which can improve the security of the process further.

Also remember you don't need to run processes in containers as root, you can run as other users with a bit of configuration, and this mitigates the volume mounting risk.

I find that the way to think about containers is as processes on the host. If you compare running things in containers to running them directly on the host, I'd say that the container architecture is likely to add security rather than remove it, as you've got a better defined interface between the process and the host and more control over what the process can do on the host.

Also it's worth nothing that a richer user mapping architecture is coming fairly soon to docker (planned for 1.9) which will add some more options for restricting actions in a container.


How to mitigate the consequences of being tracked by fingerprint2.js?

Assuming you are referring to this project which exposes a fingerprinting library under that name, the only effective way to avoid fingerprinting without blocking the script is to use a browser that has a common fingerprint. Unfortunately, browsers have so many fingerprints that the only reliable way to do this would be to use the Tor Browser, which enforces a uniform fingerprint among all users. This may be a problem on financial sites as they may block connections from anonymity services.

If you want to get your hands dirty, you could write a userscript that bypasses the fingerprinting script. You would need to find out how exactly the website is using that script. For example, if it just looks for a fingerprint in the form of a hash and will refuse to work if one is not uploaded, your userscript could instead upload a dummy hash. This requires you have at least a basic understanding of JavaScript.


How many rounds of hashing is enough for a password manager?

I'm currently writing my own little password manager

That's your first mistake. Something this complex has many subtle pitfalls that even experts sometimes fall into, without plenty of experience in this area you don't have a chance making something even close to secure.

  stores the key in an SHA256 hash

Uh oh...

This doesn't necessarily indicate you're doing something wrong, but I have strong doubts that you're going to do it right. I assume you're talking about a master password being hashed here? The master password should be turned into a key using a KDF like PBKDF2, bcrypt, or Argon2, then this key is used to encrypt the stored passwords.

If you want to have a way to verify that the password is correct, storing a hash of the key should be fine, but you MUST NOT store the key itself...if you store the key anyone who gets access to your storage has everything they need to decrypt all the passwords!

If you aren't talking about hashing a master password and you do mean an actual randomly generated key then I have no idea what you're trying to accomplish here, but you shouldn't be using a slow KDF with a large number of iterations.

Alternatively you could be hashing the master password twice, once to store as a hash to later verify that the password the user enters is correct, and again to use as a key for encryption. Depending on how this is done it could range from a design flaw to completely giving away the key.

Edit: After seeing the full code it seems to be a fourth option: you store a hash of the password to later check if the entered password is correct, then you hash this hash to use as the key, which is nearly as bad as just storing the key itself.

  I create the hash by doing the following:

def sha256_rounds(raw, rounds=100001):
    obj = hashlib.sha256()
    for _ in xrange(rounds):
        obj.update(raw)
        raw = obj.digest()
    return obj.digest()

It's not really clear what raw is here, but I'm assuming it's the password. What you're doing is an unsalted hash using SHA256. Don't try to create your own KDF!

  After it is created it is stored with the following:

key = base64.urlsafe_b64encode(provided_key)
length = len(key)
with open(key_file, "a+") as key_:
    front_salt, back_salt = os.urandom(16), os.urandom(16)
    key_.write("{}{}{}:{}".format(front_salt, key, back_salt, length))

So, you're creating the key by hashing the password, then adding a random salt to the front and back? Not only is concatenating 2 different salts to the front and back non-standard, it's not accomplishing anything here because it's done after the KDF has already finished! You're just adding in some random values for the sake of having them there.

To show just how bad this is (as of commit 609fdb5ce976c7e5aa1832670505da60012b73bc), all it takes to dump all stored passwords without requiring any master password is this:

from encryption.aes_encryption import AESCipher
from lib.settings import store_key, MAIN_DIR, DATABASE_FILE, display_formatted_list_output
from sql.sql import create_connection, select_all_data

conn, cursor = create_connection(DATABASE_FILE)
display_formatted_list_output(select_all_data(cursor, "encrypted_data"), store_key(MAIN_DIR))

While it may be a good learning experience to try creating a password manager, please please don't ever use it for anything remotely important. As @Xenos suggests, it doesn't seem like you have enough experience that creating your own password manager would really be beneficial anyway, it would likely be a better learning opportunity to take a look at an existing open source password manager.


Is there any security reason that mail services like gmail or yahoomail limit the size of file attachment?

MTAs often virus scan, DLP scan, or perform other scans that take CPU time.  Sometimes a MTA is on a bandwidth constrained network link.

Base64 encoding bloats a message from its binary size by 33%, which increases pressure on disk and on the network.

Exceeding these limits will cause a denial of service attack against the MTAs, or even against the host itself in the event of a NDR return message.


Upgrade my Dell Inspiron laptop for PenTesting

There are several things you could do and what I am able to make of your question is that you want to be able to run virtual machines in your native OS (Windows 8) with some speed. I'm sure you've figured out by now that running Kali in a VM can use a lot of your host systems resources which you can control by adjusting the RAM allocation the VM has in Virtualbox's settings as well as how many core its allotted to use and several other small setting adjustments you can make. Try out different configurations and see what is the best fit for you. Now if you're really dedicated to learning penetration testing and if your willing to make major system changes then you could install Kali as your native OS and either Dual boot Windows 8 with Kali or remove Windows all together. By doing this you are isolating your Operating Systems without dedicating your session in one to supplement the other.


What can an attacker know with knowledge of a device's BD_ADDR?

It varies by device but in a nutshell with the BD_ADDR attackers can now make use of knowing the devices hopping pattern allowing extracting of data to be possible.

The attacker can then force a rekey of the Secret Link key by impersonating a device that was paired with the target allowing them now to be paired.

The piece where you say decline pairing would not necessarily happen as the device may well believe the impersonating device is indeed on the known device list and not see it as being attacked.


GnuPG: Why is my Ed25519 signature 144 bytes long rather than 64?

OpenPGP doesn't produce a raw Ed2519 signature.  It includes additional data about what was signed, the hash that was used to pre-hash the data, the key that was used to sign it, and other information.  For example, if you use gpg --list-packets on the signature file, you get this:
# off=0 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=1
# off=2 ctb=90 tag=4 hlen=2 plen=13
:onepass_sig packet: keyid AA05320C465CBDC8
        version 3, sigclass 0x00, digest 8, pubkey 22, last=1
# off=17 ctb=cb tag=11 hlen=2 plen=11 new-ctb
:literal data packet:
        mode b (62), created 1614339913, name="",
        raw data: 5 bytes
# off=30 ctb=88 tag=2 hlen=2 plen=117
:signature packet: algo 22, keyid AA05320C465CBDC8
        version 4, created 1614339913, md5len 0, sigclass 0x00
        digest algo 8, begin of digest 7b 76
        hashed subpkt 33 len 21 (issuer fpr v4 5D36E7C775DD890CC342A38EAA05320C465CBDC8)
        hashed subpkt 2 len 4 (sig created 2021-02-26)
        subpkt 16 len 8 (issuer key ID AA05320C465CBDC8)
        data: [256 bits]
        data: [256 bits]

This indicates that there is a compressed packet, a one-pass signature packet (which is used to specify parameters used to allow implementations to compute the signature without seeking), a literal data packet (with the data "test\n"), and a signature packet.  The signature packet indicates that this is a type 0x00 (binary data) signature using hash algorithm 8 (SHA-256) and created by key 5D36E7C775DD890CC342A38EAA05320C465CBDC8.  There are two 256-bit values at the end, which are the Ed25519 signature itself.


Why would a user agent string be executed?

In addition to the fine information provided by @TildalWave, there are also cases with very poorly written or parsed browser sniffers. Sometimes people have a tendency to just drop the code in their project and not really understand it leading to the spread of any flawed methodology. The problem most arises from the types of sniffers that pass the value of your UA to a function to decide which "page" to load and what values to set to mitigate issues in IE, Firefox, Chrome, or Opera. What happens is that if a person passes a well crafted UA to your code and you do not properly "sanitize" it before handling it in your core, you could allow it to find a vulnerability. They can hijack an active session, grab unencrypted cookie data and/or place them, etc.


Compatibility between OpenSSL 0.9.8r and OpenSSL FIPS Object Module v1.2?

Firstly can you please check that in the initial PEM file it contains actual RSA private key. If you cat the contents of the file it should say something like this:

-----BEGIN RSA PRIVATE KEY-----

I highly suspect that the file you think is the private key does not actually contain a private key.

Depending on how the original system was using the certificate they may be a p12 file (certificate + chain and private key) somewhere which you could extract the key from. But if this was taken from a system running Apache then Admins and Devs like to give the key a .key extension and this would just be the actual RSA key not a p12.

As a side note I also suspect that the passphrase to the key is not the Base64 encoded version but a the actual decoded string which in this case is

  zL&g6.

If you do find a .key file then you don't need to do anything. You should be anble to issue the openssl s_client command and do a test connection to the server using client auth e.g.

openssl s_client -connect host:443 -cert cert_and_key.pem -key cert_and_key.pem

If you do need to extract the private key from a p12 please refer to this for further help:
https://stackoverflow.com/questions/9497719/how-to-extract-a-public-private-key-from-a-pkcs12-file-with-openssl-for-later-us


Common SSL/TLS Vulnerabilities risk classification

First, you selected a great idea for a project. Scanning a HTTPS Site and generating a report on the vulnerabilities with the specific SSL/TLS stack is small enough to be doable and useful still.

The problem with LOW/MEDIUM/HIGH classification for these vulnerabilities is that some of them are really easy to pull off, like heartbleed, but the result is not always very useful. Again, in the case of Heartbleed, you get to read some memory, but dont control what is read. It might reveal a certificate or session ID, but will probably be more junk than anything useful. That is why it's Exploitability was rated at 10, but the impact was a low 2.9.

Sometimes you have the opposite, where a misconfiguration which is uncommon will give remote root access, but the conditions to successfully exploit it are difficult. This would give you a low exploitablity score, but a high impact

You should consider using a standard formula, to determine risk, such as the one from OWASP. Risk = Likelihood * Impact

They have a more complex model for determining severity:


How does a phone call / SMS message verify my identity

Does the verification process actually add any value from a security standpoint?

It is an anti-spam system. Here's how it works.

Each phone number can be used to re-activate accounts a small number of times before it won't be accepted anymore, and each Gmail account can send to a limited number of recipients every day.

Because most people don't buy things from spammers, they need to work with lots of accounts in order to send enough email to make money. If we think an account might be being used by a spammer, we lock it until the owner provides a phone number. So, spammers need to have access to a large number of phone numbers to unlock all their accounts. This is very expensive for them but pretty easy for most regular people. In most cases it is expensive enough for the spammer that it becomes unprofitable for them to spam, so they give up.

source:-https://productforums.google.com/forum/#!topic/gmail/r_EfrI4BQU8


This is a good example for a case where usability and security do not go hand in hand.
A user wants usability: They want to be able to click the link and be unsubscribed. They want this to always work (not just X amount of time after receiving the email, and definitely not with X being 15 minutes or an hour).
You want security: You don't want an attacker do be able to force-unsubsribe your users.
Now lets analyze these needs:
Usability
The usability one is rather important. If you do not allow easy unsubscribe:

your brand will suffer an image damage
your emails will be treated as spam
you are in violation of the CAN-SPAM Act (see eg here: The law also requires that the unsubscribe mechanism must be able to process opt-out requests for at least 30 days after the transmission of the original message)

Security
So you are using a securely generated, long, random token, meaning that an attacker cannot just brute-force your unsubscribe form to unsubscribe a large portion of your users.
At most, an attacker can unsubscribe single users after they somehow revealed their unsubscribe token.
So what's really to worry about? No attacker will use social engineering to get the unsubscribe token of users. They will also not hack into the email of your users or your database just to unsubscribe them from your newsletter.
So the only likely attack scenario is: A user accidentally posts your newsletter including their unsubscribe token to a website. Someone sees this and decides to unsubscribe that user.
This may cause a small annoyance to you and possibly the user, but it is a scenario which is unlikely to happen often.
Conclusion
A correctly generated random token is enough for an unsubscribe link.
The dangers of this token being revealed are low, and using any other mechanisms (such as requiring logins or expiring the token after a short time) are generally not acceptable.
At most, you could expire a token after 30 days. But that also means that you need to have more than one token per user.


If you create and verify the hash, it will detect errors that occurred on the write option. As you point out, read errors can't be detected as they will have occurred before the hash.

According to the ShoeStringForensics blog, you can verify the copy with:

dcfldd if=/dev/sdb1 vf=/media/disk/test_image.dd verifylog=/media/disk/verifylog.txt

You should redo the copy if the hash check fails.


Covert channels and side channels are hard to eliminate.

Additionally, many of the open problems in computer science have implications for security.

There is a need for formal ways to specify software, and there is a need for formal ways to specify security requirements.

The difficulty we have proving program correctness for critical programs the size of operating systems, means that it is difficult to prove that widely used security critical code (IP stacks, OpenSSL) is correct.

The inability to efficiently check for ambiguity in a grammar, means it is hard to prove that an authority carrying message will exercise only the authority intended.

The inability to prove halting for a broad and interesting subset of programs makes it hard to reason about denial of service and resource hogging.

The inability to tightly bound aliasing statically means it's hard to statically prove that data does not leak from one part of a program to another.


Smartcard authentication SSH remote client

You can use ssh-agent to add a smart card and then forward agent to the other host. This will let you authenticate on the second host from the first using your local smartcard. In short:

eval `ssh-agent`               # if the agent is not running yet
ssh-add -s /path/to/pkcs11.so  # probably /usr/lib64/opensc-pkcs11.so
                   # or Ubuntu: /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so
# enter your pin
ssh-add -l                     # should list your smartcard
ssh -A shell.provider.com      # should not prompt for pin
ssh shell.provider2.com        # from the shell.provider.com


Why do we need External dtd in blind XXE?

Finally, after doing a hard search I come to a point Parameter Entities are not allowed into Internal DTD subset i.e.

<!DOCTYPE r [ Not allow to set parameteried entity.]

If I am wrong then clarify me. I read that on this XML doc.


The message in an alert() box is always displayed as plain text. You can't inject code here.
Setting the src of an image to a user-controlled value can't lead to XSS, but some other less severe vulnerabilities as explained in this thread.


Best way to distribute your key is by using one of the key servers that are available, such as keyserver.ubuntu.com, pgp.mit.edu or keyserver.pgp.com.

If you use Seahorse (default key manager under Ubuntu), it automatically syncs your keys to one of these servers. Users can then look up your key using your email address or keyid.

If you wanted to post your public key on LinkedIn or your blog, you can either upload the key to your server or just link to the page for your key on one of the keyservers above. Personally, I would upload it to one of the keyservers and link to it, as it is easier to keep it up-to-date in one place, instead of having the file in loads of different locations. You could also share your keyid with people, and they can then receive your key using gpg --recv-keys.

If you wanted to post your public key on Facebook, there is a field to place it under the Contact Info section of your profile. You can also change your Facebook security settings to use this same public key to encrypt their emails to you.

For example, here's my public key.

To my knowledge, there are no risks associated with publishing your public key.


No, they are not case sensitive.  To quote RFC 5280 (emphasis mine):

  When the subjectAltName extension contains a domain name system
  label, the domain name MUST be stored in the dNSName (an IA5String).
  The name MUST be in the "preferred name syntax", as specified by
  Section 3.5 of RFC1034 and as modified by Section 2.1 of
  RFC1123.  Note that while uppercase and lowercase letters are
  allowed in domain names, no significance is attached to the case.

The referenced RFC 1034 echos this:

  Note that while upper and lower case letters are allowed in domain
  names, no significance is attached to the case.  That is, two names
  with the same spelling but different case are to be treated as if
  identical.

(The modification referenced as part of RFC 1123 was to allow the first character of a legal host name to be a digit, and is unrelated to case.)


No, there is not.

You can find out the top ports from /usr/share/nmap/nmap-services then use the -p switch to slice and dice as many chunks you see fit.


Which shell is more secure, mksh or bash?

I am asking from perspective of someone who writes shell scripts that parse untrusted input

I would not recommend any of these shells to parse untrusted input, because it is far to easy to make errors with the shell syntax which can cause unwanted command execution. This is not a  problem how secure the implementation of the shell itself is, but how hard it is for the developer of the shell to securely handle untrusted data - and bash and (m)ksh do not differ much in this case.

Have a look instead at languages like Perl, which offer a taint mode to handle untrusted data. This way you are forced to sanitize the data before you can run commands with it, which makes it much safer.


Is it already the right time to say goodbye to TLS1.1 support on web servers?

Let's put the question the other way: What do you gain by disabling TLS 1.1?

Security

You and your quote seem to be implying that you want to move to TLS 1.2 because it's more secure than TLS 1.1. That's not really the case.

TLS 1.2 did add new crypto, for example you can now use AES instead of 3DES, or ECDHE instead of DHE. At the moment, there are no known attacks against those ciphers so you can't directly say that it's for security. 1.2 also replaces MD5 and SHA1. That is a security improvement, but for something as short-lived as a TLS connection, it's unlikely to be a major weakness.

So while TLS 1.2 offers newer crypto algorithms, the old ones are still considered acceptable, so it's hard to make a straight security argument.

Performance

Because of the newer ciphers, you will get slightly less server load when using TLS 1.2. TLS 1.3 will offer improved performance at the protocol level as well. These by themselves may be reasons to switch, but it really has nothing to do with security.


Is it safe to disable SSH host key checking if key-based authentication is used?

Short answer: Yes and no.

First of all, let's get things straight. How does key-based authentication work in SSH anyway? Once the SSH connection reaches the authentication phase, the client signs a bunch of data (this includes the session identifier) with its private key, then sends the signature to the server to verify it.

Signature verification pass -> Authentication successful.

How does a MiTM attack in this case then? The attacker sits between you and the server. For a successful attack he needs you to start a session with him, and he needs to start a session with the server. Whatever you send to the server, will actually go to him and he has the ability to modify it and send it to the server, and whatever the server sends you will actually go to the attacker and the attacker can modify it and send it to you.

Have you noticed something interesting? There are two sessions here (keep this in your mind). Each session is going to have its own session identifier because the generation of the session identifier isn't determined by the server or the client alone. In other words, the signature you use to authentication to the attacker will be different from the signature the attacker has to use to authenticate to the real server.

The attacker doesn't have the client's private key, meaning it won't be able to come up with a signature that the real server will accept. That's why this kind of full MiTM will not be possible.

So it's safe to disable host key/fingerprint checking, right? Not exactly. It's true that because the attacker won't be able to authenticate to the server, he won't be able to execute malicious commands on it. BUT

Remember when I told you about the two sessions? The attacker won't be able to establish session with the real server, but he can easily make you establish a session with him. The attacker will simply accept whatever signature you give him and trick you into thinking that you're now connected to the real server. You'll send him commands (and possibly some process-specific passwords) and he'll happily reply with whatever makes you happy.

Granted, there's no real danger to the server here since those commands aren't really reaching the server. It's just that there's no telling what you'll actually be sending the server (now the attacker). You might send keys, passwords (think, when you modify your password the server will ask you for the current password), and other sensitive information.

Bottom line is: If you're willing to accept the risk of connecting to a fake server that will know what you're sending to the real server, then disable host key/fingerprint checking. Otherwise, keep it enabled.

References:

RFC 4252 7. Public Key Authentication Method
RFC 4251 9.3.4. Man-in-the-middle


Why don't you try a nmap -Pn -p 0-65535 scan against the host. The device may not report any ports because it is not responding to pings. Also, is the dns entry there when you perform a nslookup? What happens when you ping -a the phantom device? Can you track the location to a subnet specific to a switch and then look at the stats on the switch? What does the DNS server say about the hostname or address in question?

I don't think you have done enough enumeration.


Yes, you need to start from somewhere to ask about where nodes are, but that doesn't mean you have to use one of the ones that are in the provided list.  You can use whatever node you trust.

Every distributed system requires asking for other systems that are part of the network, otherwise you would just have to try IPs at random until you found someone providing the service you are looking for.

It is decentralized because peers will tell each other where to find more peers.


You should always validate user input.

For example, since you're expecting an URL, you could check that the submitted string starts with http:// or https://.

submitted_url.start_with?('http://', 'https://')


Whether or not those services are a threat is subjective and depends on your threat model. Whether or not they exist and can DoS a victim's mailbox with varying levels of effectiveness is not. Those services do exist and they can completely flood and deny service to someone's mailbox. In fact, you do not even need to use those services. For a long time, there have been quite a few ways to screw someone over, including manually signing them up to a large number of spam lists, or publishing their email in plaintext in comments on heavily-spammed or spun blogs and fake articles. It's the digital equivalent of signing someone up to receive a hundred free Bibles or delivering a dozen pizzas to their house. While I can't say if Mailbait works, the concept of DoSing someone's mailbox by getting them on spam lists does.


Log files on the server? Would be a start for seeing what is going on. Check your access controls for the site and server too. But if the server has been compromised these won't be reliable.


Is it safe to login using HTTP on a WPA2 protected home network?

I think you already know everything you need to answer yourself.

The only layer of security it's the WPA2 encryption, so, basically any attack against it would show the credentials since it's plain HTTP, so... there's capturing the four-way handshake and breaking it to decrypt the traffic*, there's the Downgrade attack, there's the KRACK attack and pretty much any other MITM Wi-Fi attack, UPnP on your router, etc.

So... It all comes down to your security practices, and the hardening of your home router.

*To your question: Yes if he captures the four-way handshake and the traffic in which you logged in, he's ready to bruteforce for the password and decypher the traffic he captured (Offline).


Secure password generation for different websites

It's only as secure as the master password. Everything else relies on the the assumption, that the algorithm is not disclosed to an attacker aka security through obscurity. Oh, and you just disclosed your algorithm to the internet.


How to prevent / take action against "Merchant Name" fraud?

There are warning from various watch group and authority, e.g. Scamwatch. The complicated part is that many fake online shops are not operating under the same region as the consumer, i.e. the scammer may already close the bank account and run away with the money.

In fact, this is a search engine fault that is not easy to deal with: affected company can only combat it by investing in the brand protection process:

Add a scammer warning page related to various scam
Do a search on potential organisation name abuse and report it to the search engine portal.
Add a link to official scam watch web page
Report fraudster domain name to authority and prominent security portals/vendors

Here are some scam/phishing portals that you can use.

Phishtank : https://www.phishtank.com/
Google safe browing : https://safebrowsing.google.com/safebrowsing/report_phish/?hl=en
report for OZ : https://www.scamwatch.gov.au/report-a-scam
Report to at least 5 major Antivirus Vendors, e.g. Avast, Avira, Bitdefender, Kaspersky, Malwarebytes, Mcafee, Sophos, Symantec, etc.
report the fraudulent domain registrant as phishing and abuse to correspondence registrar

(Update)
Can the Bank act upon the merchant name that uses a similar name as a legitimate entity?  Well, it depends. One big issue of an online purchase is that the user has no way to verify whether the merchant is inside the country. To credit card clearing house like VISA, they are actually dealing with a merchant number instead of merchant name, so there is never an issue for the fraudster to provide a similar merchant name when it operates inside another country. Stopping the fraudster using the legitimate organisation name will take time. It is better to take down the fake web shop to stop subsequent fraud.


What role does cryptography play in anti-piracy?

One possible model for preventing software piracy is Trusted Computing. The hardware platform is "trusted" in that it should be tamper resistant and will refuse to run non-authorized code, or divulge the contents of the RAM. This is the model employed by game consoles, e.g. the PS3. This relies quite heavily on symmetric encryption (so that important code and data is protected against prying eyes) and digital signatures (the hardware will refuse to execute code which is not properly signed). Sony goofed it up by reimplementing ECDSA improperly (and doing a few other stupid things, e.g. their disk encryption system is pathetic) but the model still holds.

Of course, tamper resistance is expensive, and the contents of a PS3 can be extracted with relatively little cost -- but still not immediately. Sony, with its complex assembly of encryption and signatures, and by enforcing mandatory firmware upgrades (by rejecting access to the PlayStation Network for people who did not upgrade), succeeds in keeping piracy at low levels, and, more importantly, concentrating piracy into the hands of not-that-many actors, at which point regular police operations are effective. Cryptography is only part of the mechanism, and the real core of the anti-piracy system is the long arm of the Law.

HDCP is a standard for encrypting audio and video data while in transit over wires; this is meant to allow for, e.g., a movie to go from a Blu-ray player to a compliant TV without being copied by any device placed in-between. There again, this relies on symmetric encryption, asymmetric key exchange, and signatures.

A cryptographic mechanism related to Trusted Computing is Broadcast Encryption. This is specifically used in Blu-ray. This is a way to symmetrically encrypt data such that:

every Blu-ray player in the world has its own decryption key;
players refuse to play unencrypted data;
a given disk "includes" the encryption of the movie for every single player key.

A lot of science goes into the details, so that a single disk may indirectly contain the encrypted keys for billions of potential players. The scheme is based on nested binary trees and a "revocation" system: a disk cannot really contain one encrypted key per target player, but it can cryptographically revoke a few hundreds of "bad keys" known to have been hacked. There again, this is a cryptographic system which does not ensure that movie data will not be extracted, but at least enforces the need of an hardware-based hack on a given player, that attackers must do again on a regular basis because widespread leakage of data can be counteracted through revocation. It is unclear whether the Blu-ray protection scheme (called AACS) will stand the test of time, but it surely is much stronger than that of the plain DVD.

A companion technology for DRM is watermarking. Whether watermarking is part of cryptography or not is debatable (and debated). Some cryptographic algorithms, in particular symmetric encryption, are used within watermarking techniques for "randomization" (encryption turns structured data into what looks like random noise, and, as such, is more easily inserted into a given medium without altering much how humans perceive it).

Summary: there is no magic cryptographic algorithm which prevents piracy. If only because encrypted data can be copied as is. But DRM is a wide subject which encompasses many areas, and a few well-designed cryptographic algorithms can be an essential part of a DRM system -- usually to "raise the bar" so that successful attackers will be fewer, and more easily targeted by conventional law enforcement agencies.


There is no thumbprint included in the certificate. What is included is a signature which is used to build the trust chain.

The thumbprint (or fingerprint) is just a hash over the certificate to make it easier for humans to compare certificates. It is not included but computed when needed.


the details of the form is:

<form method="POST" action="https://www.facebook.com/login.php?login_attempt=1" id="login_form" onsubmit="return Event.__inlineSubmit(this,event)"><input name="charset_test" value="€,´,€,´,水,Д,Є" type="hidden">

note the https in the action this means that the submit will happen over https regardless if the current page is http or https

however this does not mean that the original page wasn't modified in transit to add a script that might hijack the credentials and send it to a attacker


Is MediaWiki viable for sensitive information?

There is the Access Control extension.
But, you should also read the Security issues with authorization extensions linked from there.

MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. But with the massive increase of MediaWiki use in corporate intranets and the many CMS-like features emerging, demand for tighter security is emerging.
To help authors of security extensions, this list of the security flaws found in the field is being maintained, so that they can test their extension against each. There are several extensions that claim to give selective read/write access to pages in Category:Page specific user rights extensions, and currently most of these do exhibit several of the listed flaws.

Hopefully, that will help you make your decisions.
Update: Summary from comments, MediaWiki is not a good mechanism for publishing limited-access information.


Why does my MacBook air have so many MAC addresses, according to my router?

After a little research as a result of your additional information prodding.

I don't think this is MAC randomization on your Mac Air.

I believe this is someone else attempting, and failing, to break into your network.

Double-check all your security settings just to be sure.

Your known MAC shows a connection type of "Wireless", all of the others show as "Unknown", indicating they did not successfully authenticate and get an IP address on your network.

The Printer stuff suggests that your Printer is WiFi capable and may not be secured properly. If so, the printer could potentially become an access point into your network.


Are multiple applications of a salted Linux MD5 hash easier to break than one?

applying the same hash function several times makes the hashing process more computationally expensive. The benefit of this is that when other means of cracking the password hash fail (guessing, dictionary attacks, rainbow tables, etc.), and the attacker is forced into brute-force techniques, it takes them longer to try each password, simply because they have to apply the same hash function more often. So if one round of hashing would require one month of brute-forcing, applying it twelve times would increase the estimated time to a year.

https://softwareengineering.stackexchange.com/questions/115406/is-it-more-secure-to-hash-a-password-multiple-times


Is a password or passphrase needed with a keyfile backup to decrypt

In most cases, while you can generate a private key without a
passphrase/password, it is not advised to do so. However, in some situations, it
is necessary, depending on how the system architecture works.

The issue is that the private key is the key to the kingdom. If it does not have
a passphrase, then anyone who obtains the key can use it. If it does, then they
also need that passphrase to use it. However, if the key is part of some
automated authentication process, depending on how the system is implemented, it
may not be possible or it may not be convenient to have to enter a passphrase to
use the key. Often, there is a key agent involved whereby you are required to
enter the passphrase on first use and after that, the key agent will take care
of things (for example, on first connection).

It is possible that your NAS requires a private key without a passpharse due to
the underlying design/architecture. If this is the case and your concerned that
backing up your private key may not be secure enough, then the easy solution
would be to encrypt your backup with another key which does have a
password/passphrase.


Protection against file distributed malware

Usually analysis works only at the level of a single download and it is really hard to do it differently. The firewall has no knowledge that a specific download is only one part of a larger download session and where the rest of the data can be downloaded for a complete analysis.

But depending on the file format the firewall might at least detect that it is a part of a larger download or that this is some unknown data format. And it might have a white list which types of data are allowed and unknown data or partial archives are not part of this white list. In this case the firewall might not be able to analyse the download for malware but it might decide to block the download because the contents is not on the white list.

This kind of situation also happens with download accelerators or resuming of downloads in which case the firewall would also only see a partial download. Some firewalls deal with this case by changing the request of the client so that it results in a full download which then can be analyzed by the firewall.


What devices/types of devices typically have unique associated ID numbers?

Well hardware fingerprinting is done by many rootkits, for instance it's a tool used by the famous cheat-prevention system "Punkbuster" so that even if you buy a new key for the game and even reinstal your system, you remain banned.

They collect different data from your machine of which some  might be relatively unique, like:

MAC-address
Motherboard serial number
device GUIDs

Some of these might be unique, other's wont. Now the idea is that you collect this data and you save it somewhere remotely and assign an id to it. Let's say computer A. Now next time the machine boots some of the ids might have changed, like the MAC address, because the user was spoofing it.

Now you collect the same data again and call this computer B. Now you do this several times and you can also keep track of when the machines were online.

From here you can do a basic filter, if two machines were up at the same time, they probably are two different machines. (first decision node)

Every piece of hardware can be awarded a certain score for reliability (more reliable to stay the same (CPUID (which is disabled these days) or your motherboard serial number), less reliable to stay the same (MAC addresses). Then you can make a scoring system an attach it to a probability.

This probability can then give you a percentage of chance the systems A and B are the same. It's actually just some basic datamining.


How to secure requests to my API from my web widget embedded in third party website

If the token never expires, an attacker can harvest and use the token to access your site indefinitely. Non-expiring tokens can be shared around, with LOTS of attackers using your still-valid tokens.

However, the non-expiring token presents an integration problem. Basically the customer site needs to communicate with your SaaS to obtain a currently-valid token and renew tokens as needed.

You might consider an OAuth 2 type of approach. Your OAuth 2 server hands out tokens (which expire) to the customer website. When your SaaS receives the token, your SaaS validates the token against the OAuth 2 server. If your customers are comfortable with OAuth 2 integration, that might be all you need.


YouTube uses cookies which helps them track you and suggest videos even if you do not have an account.

But using the "Forget this site" from the History tab, you removed those cookies:

  Using "Forget About This Site" will remove all data stored in Firefox
  from that domain like bookmarks, cookies, passwords, cache, history,
  and exceptions [emphasis mine]

source

So, no, YouTube did not have access to all your history, just your history on YouTube since they stored a cookie. Firefox has always had all your history because it is your browser, but YouTube does not have access to it.


Securing internal micro-services - Letsencrypt vs. Self-signed certificates - Best practices

Public certificate authorities generally won't work for internal services as your services are not reachable from the outside, so they have no way to verify that the certificate is being issued to the right entity. For example, if you asked Let's Encrypt for a server certificate for backend0001.myapp.myinternaldomain, Let's Encrypt needs to be able to verify that the request case from that hostname. For internal services, this is usually not reachable from the outside world.

Certificate authority:
Instead, you should have an organization-wide CA managed with the same paranoia as a real CA (you need to absolutely control access to the CA key and ensure that you only issue certificates to the right entity).

CA certificate:
The CA certificate will need to be available to all your servers and clients to be able to validate certificate chains.

Server and client certificates:
Server and client certificates can be issued to your apps and client after verification of hostname or client identity. Deployment of certificate keys is something to be very careful about. You could use something like keywhiz or vault (just some examples, there are many others) to deploy certificate keys only on the correct hosts.

The biggest complexity is making sure that keys are only available to the right parties. Getting that part right is more of a process setup and less about the technical aspects. But then again, the same problem exists with a public CA (minus the CA key issue).


Is there an algorithm to generate digitally signed URL links?

A RSA signature has the length of the modulus: if using the usual 2048-bit key size, then signatures are 256-byte long. Since you want to fit the signature within a URL, which is text-based, you must have some sort of encoding such as Base64, which implies some size overhead; with Base64, 256 bytes will become 342 characters -- that makes for URL of quite respectable length.

DSA (and its highly fashionable elliptic-curve variant ECDSA) offers smaller signatures; you can get very decent security (as much as 2048-bit RSA) with signatures of size 60 bytes or so -- there again, Base64 encoding inflates that to 80 characters.

If you need even smaller signatures, then you must go to less mainstream algorithms, e.g. BLS, which offers signatures twice smaller than DSA. But the maths are fiendishly more complex, and there is no standard, only scientific papers.

Alternatively, you may want to use RSA with ISO 9796-2 signatures (not PKCS#1). You will get 256-byte signatures, but you may then smuggle some of your application data within the signature itself. As a rough approximation, you will get your n-bit security with a total overhead of about 3n bits; albeit with a minimal message size of 256 bytes.

Theoretical limit: if you want a security level of n bits (meaning that attackers are assumed not to be able to run computations which need more than 2n elementary operations), then the signature size cannot be less than n bits either. Indeed, an attacker could try brute force on the signature, trying out all possible signature values and using the signature verification algorithm (which uses Alice's public key, which is public, hence known to the attacker) until a matching signature is found.

However, there is no currently known secure digital signature algorithm which offers n-bit security with n-bit signatures. DSA needs to use 4n-bit signatures to offer n-bit security. BLS lowers that to 2n bits. There have been proposals for some other algorithm types which could reach down to 1.5n bits or so, but right now they all turned out to be flawed in some way.

It may be possible that you could change your model slightly. For instance, Alice and Bob may share some secret value; Bob then does not really trust "Alice" but rather "whoever knows the secret value, which happens to be known to both Alice and Bob". In that case, you can rely on a MAC algorithm instead of a digital signature; you can think of MAC algorithms as signatures where the key to sign and the key to verify are the same.

It is a change of context. Depending on who Alice and Bob are in your system, sharing a secret may or may not be possible. Using a MAC forfeits most chances at non-repudiation. It also means that Bob can himself produce URL that he will accept. Yet, if you can tolerate the use of a MAC, then you can get very short verification elements. In fact, you can even get below n bits because exhaustive search can no longer be applied: since the MAC verification key is secret, the attacker cannot try MAC values and decide whether they are correct on his own machines. To "try" a potential MAC value, the attacker MUST then send it to Bob, and see if Bob is happy with it or not. After a million tries or so, Bob may begin to suspect foul play and apply countermeasures (e.g. cease to respond to that decidedly dodgy requester).

In that sense, a MAC value of length 64 bits ought to be sufficient. That's just 8 bytes -- encodable with Base64 as 11 characters. HMAC is a widely implemented MAC algorithm with good repute.

There is no well-established standard for "signed URL". Every site designer works out his own scheme, which is unfortunate because homemade cryptography is one of the surest paths to disaster. The conceptual model, though, is sound: basically, you want Mallory to convey a message from Alice to Bob, such that Bob can know that the message really comes from Alice, and was not altered or even invented altogether by Mallory. That the message travels as a "URL" is a mere encoding constraint which has no impact on the concept.

A MAC or a signature is indeed the right tool here. Beware, though, of replay attacks: if Mallory has an Alice-signed URL that Bob will accept, Mallory may try to send that URL twice to Bob, to get twice the effect. Depending on your context, this may or may not be a problem. If it is, then Bob MUST enforce some protection mechanism, e.g. remembering past requests to reject duplicates. A time stamp within the URL data (under cover of the MAC or signature) can help Bob keep track of seen URL (i.e. Bob can forget "expired" URL since he won't accept them any more).


Exploiting the delay when a festival ticket is scanned

The vulnerability you're describing is a race condition.

There are several ways to deal with it, but I would go with a SELECT ... FOR UPDATE SQL query, which puts a lock on the selected rows to prevent new writes until the current transaction is committed.

Be sure to check your RDBMS documentation to check how to implement it correctly:

PostgreSQL
MySQL
MariaDB


How to generate cryptographically strong pseudorandom data very rapidly?

Edit: The obviousness was blinding so I missed it. OpenSSL already offers an interface to its own internal PRNG, which is seeded with the machine's /dev/urandom, but then extends it with its own crypto. Just do this:

openssl rand 10000000

to produce 10 millions of pseudo-random bytes. On my laptop, this appears to be about 3 times faster than /dev/urandom, i.e. 11 MByte/s or so. If this is not fast enough for you, read on.

Original response:

It really depends on the involved hardware and context. Since you are talking about a bash script, /dev/urandom and OpenSSL, I suppose that:

You use Linux.
You want to produce a big file full of pseudorandom bytes.
You want a solution which is a scripted assembly of existing, "normal" packages, not a programmatic solution.

Indeed, if you could write your own C code, your best options would be either AES encryption in CTR mode with the AES-NI instructions (on recent PC which offer these instruction), or a dedicated stream cipher (e.g. one of these). On a 2.4 GHz Core2 CPU, I could get 700 MByte/s of pseudorandom bytes out of Sosemanuk. I hereafter suppose that you are limited to scripts.

Using OpenSSL encryption is not a bad idea, but there are details:

Randomizing the length of each chunk is a useless complication.
There is no need to go to AES-256; AES-128 is already fine. AES-256 is 40% slower than AES-128, and adds no practical improvement in security.
When encrypting a long sequence of zeros with CBC, you are actually running the block cipher in OFB mode (encrypt a block, encrypt it again, and again, and again). This is reasonable as long as you remain below the 2n/2 limit, meaning that with AES (128-bit blocks) you don't use a chunk longer than 264 16-byte blocks, i.e. 250 millions of terabytes. Chances are that you won't reach it anyway. In that sense, the "reseeding" is not really needed.
When you "reseed" (if you decide to maintain this feature, which is not necessary), use /dev/urandom, not /dev/random. /dev/urandom is fine for cryptography (the OS boot scripts ensure that the internal PRNG is properly seeded), despite the misguided paranoid qualms of the /dev/random implementation. On the other hand, /dev/random may block, and thus be really slow (nothing is slower than a blocked process).
Beware of strings. bash uses character strings; /dev/random and /dev/urandom return bytes, including bytes of value 0. This may result in an artificially truncated key, and lowered security. This is bad. Instead, you should encode the bytes in hexadecimal and the the -K and -iv command-line arguments with openssl.
OpenSSL may add a header which begins with 8 fixed bytes (thus totally non-random). It does not do so if you use -K and -iv.
OpenSSL will also use some padding so you will get an extra 16-byte block at the end (this is not a problem; the padding is on the cleartext, and encryption "randomizes" it).

This leads to the following script:

#!/bin/sh
key=$(dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum | cut -d' ' -f1)
iv=$(dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum | cut -d' ' -f1)
dd if=/dev/zero bs=65536 count=8192 2>/dev/null | openssl aes-128-cbc -K $key -iv $iv

When invoked, this script outputs a sequence of exactly 536870928 pseudorandom bytes, which are fit for cryptographic purposes. Feel free to modify the bs and count parameters, but remember that dd will allocate a RAM buffer of size bs, so you usually want to keep bs small, but not too small to avoid too many roundtrips into the kernel (8192 to 65536 are usually good values).

I use MD5 here only for the convenience of the bytes-to-hexadecimal conversion (the known shortcomings of MD5 have no influence whatsoever on the security in this case).

This script should work on any decent Linux installation. It uses only packages which should be there by default. On my not-very-powerful laptop, this script produces pseudorandom bytes at the rate of 73 MBytes per second, which is not bad and probably enough for your purposes (if that is not enough, then you will probably have other issues with I/O bottlenecks).


Could my family be receiving my messages

If it is an account based messenger app then it is likely your account was signed into on his phone at some point and not signed out of. "Is it normal?" is relative. If you have never signed into your account on his phone and he has never used your credentials to sign in then no that is not a standard operating model. However, changing your password is always a good idea and if it were me I would just take a look at his phone and make sure you are not signed into it.


Syscalls are disabled with seccomp. What attacks are still possible? How to prevent them?

It really depends on what the file descriptors are connected to.
If they're connected to a terminal, they could be used to modify the terminal including, depending on the configuration of the terminal, executing arbitrary code.  They could also exhaust memory if they're run inside a terminal emulator that has a large backscroll.  If they're connected to files, they can be used to write malicious data that will exploit other programs when read or consume excessive amounts of disk space.
If they're connected to sockets, either directly or through standard input, output, and error over SSH, they can be used to send malicious data elsewhere, such as to exploit vulnerabilities in remote servers, or they can be used to use excessive amounts of network bandwidth, starving more important traffic and potentially causing a DoS.  They could also be used to engage in part of a DDoS attack if they're certain types of sockets.
Note that "malicious" here doesn't just mean an attempt at a buffer overflow or code execution.  It could mean sending data that is intentionally random so as to cause a receiving process to spend excessive resources in error handling.  It could mean sending normal amounts of data in very small chunks so the remote system has to spend excessive resources in processing network packets or parsing the data.  In this sense, you would need to consider anything that causes undesired operation or unpleasant consequences, including a DoS.
In any case, if the process just refuses to read, that can cause a bunch of inconvenience and backups in other areas and could lead to a DoS.  Similarly if other processes expect to read from your malicious process and it refuses to write anything.
How you stop these really depends on what your file descriptors are connected to.  You'll need to consider what happens if the output is voluminous and also what happens if it's specially crafted to be malicious in order to exploit the things that will interact with the output, as well as what happens if your process refuses to read or write anything.


Trace source and destination of an SMS message

There is no location transmitted within a normal SMS message (unless added by the author) so as the recipient of an SMS you won't normally be able to determine the location of the sender.

The location of a cell phone can be determined with varying precision by the Mobile Network Operator and any third parties with access to the MNO's system or data.  The location precision depends on the capabilities of the device, the cell tower(s) it connects to and the quality of the signal.

A determined and well equipped attacker may able to determine the location of cell phone independently of the MNO (by sniffing local cell traffic, using a fake cell tower or side channel attack such as observing the wifi or bluetooth connections of the device, implanting malware on the device etc) and pair this with the timestamp of the message.  (It may also be possible for an attacker to read the mssages, since the A5 stream cipher used to encrypt the message between phone and base station has been shown to be vulnerable).

One other thing to consider is that there are many different ways of sending an SMS and normal mobile phones are only one of these.  For example, MNOs and a very large number of third parties will forward SMS messages which originated from email or web based gateways. In many countries fixed line telephones can send SMS if configured correctly.

The location of the sending device may not correspond the location of actual person either. Many devices can be configured to send SMS without having any operator physically present (uses for that include alarm systems, vehicle trackers etc).


Is it possible to fake the mail server address?

Yes. If you write a program that connects to an SMTP server, you can usually just set To and From variables to anything you want and the server will try to send the email.

Phishing attacks are usually done this way to get you to click on a link to a fake website impersonating a bank, eBay, etc. Email clients like Gmail try to determine the validity of the email (probably by IP/domain of known hosts) and can mark the email as spam.


Linksys Router Tried To Access Local Website

HNAP is the Home Network Administration protocol.

I once ran in to the same issue when I was monitoring my network, only it wasn't with HNAP, but it's predecessor: UPNP.

Your Router should have a setting to enable or disable this feature, but it should be harmless if it's not exposed to the outside.

Basically, your router checks it's arp tables for available devices and sees if they have a HNAP service active by probing the directories you listed above.

I turned off the UPNP Service from my router configuration and things went silent, so I'd check the documentation of yours to do the same.


Is it necessary to sanitize data being passed into the hash_hmac in php?

Generally speaking, any combination of bytes you might send into hash_hmac in the $data parameter will be correctly processed by the function, so no sanitation is needed at that point in your script. However, you'll probably still need to do sanitation at some point in your script, but by checking the mac up front, you'll prevent all those wasted CPU cycles sanitizing data that was actually just a forged request.


Am I at risk for giving my email, name and phone number to a scammer?

Is my bank account at risk?

Not directly. But the scammer can/will work to get a "foothold" using the information they have on you. You are also now clearly on the radar of a scammer and I would consider yourself at high risk.

  Can they use my voice as verification for other trades? (the "Yes scam" that I read about)

I sincerely hope not. If a company allows for verification of a trade with no account information or verification code or any sort of "multi-factor", It would be very concerning. You should check with the company and see what is required for a verbal verification. Also, "Yes scam" is a bit of a misnomer. Not a lot of "voice signature" based verification out there. If an attacker has your account numbers and calls into an automated hotline, it won't matter that it's a female voice saying "Yes" if you're actually a man. That's not checked for as far as I know in the vast majority of those systems.

  What more personal information is at risk?

They will try to leverage the information they have to get into your accounts. If they can get into any account, they will get more information and continue. They will also probably launch a Phishing scheme (don't click email links without putting them in virus total's URL check https://www.virustotal.com/#/home/url, at the very least. Ideally just don't click email links).

  What to do

Change your passwords. Do you have a password in the format of [Name][Date][symbol]? If so you don't have to be a hacker, someone can guess it in 100 guesses probably. Create a strong password (4, 4 letter words with a cap and 1 symbol or number is easy to remember and far more secure than 8 characters).

While you're changing your passwords, check for strange log in activity on your accounts. Notify UFX.


Alternative to sending password over mail?

I commonly use a Password manager to store and share passwords. There are many password managers that have this functionality.

A password is shared from one account to the other, with the notification of the share sent via email to the other person, who can choose to accept, reject, or just ignore the share. The communication of the password is secure, while the notification of the share travels over less secure channels like email, thus using the strength of each method without compromising security. Some products will allow for the share of the password without disclosing the password to the receiver. In that case revoking the password becomes possible.

I highly recommend using a password manager for all of your passwords. Some commercial ones are LastPass, 1Password or Dashlane but there is also the possibility to host one yourself if you don't want to trust anyone. A quick google search of "password manager" should put you on the right tracks.


Malicious script compromising browser extensions

In Firefox or Chrome, is it possible for a web page script to compromise a user installed extension?

Absolutely, extensions are getting their fair share of vulnerabilities. What bugs you need to look out for depends on how the extension interacts with web content. E.g., the LastPass addon for Firefox was shown to be vulnerable multiple times. Due to one of the flaws it was possible for a prepared website to exfiltrate the stored account credentials belonging to different domains by confusing the extension's URL parser.

  What measures can be taken by extension developers to reduce the attack vector?

Just like with regular web applications, you need to validate user input, prevent injections, verify origins, etc. - you can't give a complete list here. Since browser extensions are often implemented using web technologies (JS, HTML, ...), most of the typical web application vulnerabilities apply. Also note that extensions often operate with higher privileges than web scripts which means that an XSS flaw in a Firefox extension can potentially compromise the host.


Best user data encryption design patterns?

There is a spectrum of ways to provide this kind of online storage:

Completely unencrypted: no protection at all
Server-side site-wide encryption: the data is uploaded by the user in its unencrypted form, and stored on the remote server. The server has, for example, a fully encrypted disk. This only physically protects the data.
Server-side individual keys: the server generates keys, provides key management, and provides all encryption/decryption for the user data based on the specific user. The server is aware of the key values.
Client-side encryption: the clients handle the actual sensitive key material, handle all encryption and decryption, and technically handle the all of the key management functions (though the server keeps track of everything for you). The server cannot decrypt the data at all.

It sounds like you are wanting to provide a variant of client-side encryption where the server has no knowledge of the keys, but are caught up in the idea that the server has to provide the actual encryption/decryption service.  You can't have both.  You'll have to determine what your server is actually going to do. Is it simply a storage vehicle? Does there have to be collaboration? Do you want to be able to share the data among users?  All of these questions influence the role the server will play and the actual use case/business case you are trying to solve.

In terms of actually creating the encryption key based on the user's password, you'll want to check out "password based key derivation."  Such an encryption key could function as a master key for the other client-based keys.


How do Access Points manage attempted Passwords?

No, the actual password isn't logged because the four-way handshake ensures that the password is never sent over open air, as this Wikipedia entry explains:

  The four-way handshake is designed so that the access point (or authenticator) and wireless client (or supplicant) can independently prove to each other that they know the PSK/PMK, without ever disclosing the key. Instead of disclosing the key, the access point & client each encrypt messages to each other—that can only be decrypted by using the PMK that they already share—and if decryption of the messages was successful, this proves knowledge of the PMK. The four-way handshake is critical for protection of the PMK from malicious access points—for example, an attacker's SSID impersonating a real access point—so that the client never has to tell the access point its PMK.

You can, however, capture that an attempt was made using Wireshark, which is explained in the WPA Packet Capture Explained tutorial:

  This is quick and dirty explanation of two sample WPA capture files. The first file (wpa.full.cap) is a capture of a successful wireless client WPA connection to an access point. The second file (wpa.bad.key.cap) is a capture of a wireless client attempting to use the wrong passphrase to connect to the AP.

Updating to include Steffen Ullrich's response concerning WEP:

  WEP is also using a challenge response authentication were the transport is not actually transferred and thus cannot captured by a rouge AP, see wikipedia


Preventing insecure webapp on subdomain compromise security of main webapp

This sounds like an insecure cookie scope.  If the application is scoping its cookies to .domain.com then XSS in a sub-domain can lead to an account compromise.

As long the applications are on separate servers, they are not sharing the same database account and cookies are scoped properly there shouldn't be a concern.


Why does checksec.sh highlight rpath and runpath as security issues?

TL;DR: R*PATH has an unfortunate history of introducing new ways of
running untrusted (attacker-controlled) libraries. RPATH/RUNPATH
is usually avoidable and should be avoided.

Firstly, it might be worth reviewing the non-security reasons for why
we want these binaries flagged: distros (Eg. Debian Wiki on
RPATH) don't like that it takes precedence over the local
LD_LIBRARY_PATH and /etc/ld.so.conf settings/configs and
conventions. It makes it harder to reason about libraries through more
visible means than running readelf for every binary we want to think
about, and it complicates life for maintainers who are juggling a lot
of intertwined dependencies through these other mechanisms which are
easily broken by RPATH/RUNPATH. But there are exceptions - here's
Debian's policy:

  The only time a binary or shared library in a Debian package should set RPATH or RUNPATH is if it is linked to private shared libraries in the same package.

Secondly, relative RPATH (i.e. foo.so rather than
/usr/lib/foo.so) can go quite wrong: your user might be running from
a working directory (Eg. /tmp) that's subject to attacker control
who could plant a malicious version of /tmp/foo.so. This was an
observation made in Debian bug #754278 against openjdk.

This might sound benign, but it can lead to privesc particularly on
setuid/setgid programs like IBM's DB2 privesc CVE-2014-0907:
simply run the suid binary from a directory primed to abuse whatever
RPATH is set, and your code will run in the context of the
privileged program. Other examples include Slackware's packaging of
llvm CVE-2013-7171, Gentoo's packaging of Imagemagick
CVE-2005-3582, SuSE's packaging of CVSup CVE-2004-2133, ..).
It's been such a steady trickle that Apple's equivalent avoids relative RPATH in "restricted" (suid/sgid) binaries.

Thirdly, the special $ORIGIN variable (calling executable path) has
been one way of avoiding an absolute path, while anchoring the search
somewhere. But it's had issues: glibc CVE-2011-0536 failed to
expand it properly which gave attackers an equivalent of the relative RPATH case where the author of an executable using $ORIGIN thought they were getting something slightly more robust.

With that in mind, you probably really do want checksec.sh to flag
RPATH/RUNPATH - it's not always bad, but checksec.sh doesn't
have the bigger picture available to make that call for you like the
distro linters can, so it needs manual review.

Addendum: Breaking the links: Exploiting the linker by Tim Brown was mentioned in the replies to your Twitter conversation, this is a great paper on attack surface more generally for POSIX style linkers and astute readers should definitely take a look. The most pertinent thing there not covered already is this:

  On GNU/Linux at least, when the DT_RPATH or DT_RUNPATH exists within the ELF headers of a binary then these will be honoured first when looking for shared libraries. Additionally, the keyword $ORIGIN within this header is expanded to be the path of the directory where the object
  is found, while both . and the empty directory specification are honoured, even for binaries with the setUID bit set. From an attackers pespective, setUID binaries with DT_RPATH are particularly nice, since we can make use of hard links to manipulate the runtime linker into using an $ORIGIN
  which we can control.

... as observed elsewhere in the paper, most systems ignore user-supplied environment variables such as LD_LIBRARY_PATH on setuid binaries most of the time, but as you can see a careless RPATH gives the attacker an equivalent gift.

2nd addendum: ContextIS have a great writeup covering RPATH attacks.


How to block WhatsApp traffic in TP Link router?

When ever someone builds a public service, their goal is to make it available for everyone. That's why it's way easier to find guidance for allowing traffic than denying it and do the opposite. Facebook has published information for WhatsApp Business API Network Requirements, but that page has a link to a downloadable IP address/range list for WhatsApp servers. (The link has removed from the citation intentionally as it seems like a changing one.)

  WhatsApp uses a wide range of IP addresses for its servers. You can
  try to allow all of the IP addresses. However, it is best to just
  allow all outgoing traffic and connections from the above ports.

  List of WhatsApp Server IP Addresses and Ranges (.zip)

From that information we can also deduce that it would be easier to block the ranges on a consumer grade router, as WhatsApp is able to fallback to HTTPS port 443. The IPv4 ranges on the list are from /32 or /26 are are likely to change. If you need to add them to current TP-Link router's Access Control > Target one by one you would have lots of work.

Most of the IP addresses are from Facebook's range 31.13.64.0/18, but that would block all the other Facebook services, too. Furthermore, some of the addresses seems to be random addresses from softlayer.com etc. Pretty much a Game Over for that approach. (For allowing WhatsApp through a firewall, TCP ports 5222, 5223, 5228 and 3478 to 31.13.64.0/18 have been enough.)


~/.ssh/authorized_keys contains the public key, you need the corresponding private key to login. Private keys usually look like ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/something.id_rsa, etc.

Unfortunately you didn't post enough information on what privileges you exactly have / the possibilities your vulnerability provides (can you only read files as root, can you execute anything as root?).


App hosted Oauth login pages: what stops forgery?

There is an RFC specifically adressing oauth2 in native apps: https://tools.ietf.org/html/rfc8252

It advises that the app uses the OS browser (Safari / Chrome) rather than show the login window in a web view or handling the credentials in the app.

But in this it largely aims to train the user in what a login is supposed to look like, rather than to provide specific controls to prevent the app from misbehaving.


Is it poor practice to host multiple web applications on the same domain, in terms of cookies?

Cookies can be also restricted by the URL path. In this case you can use the Path attribute in the session cookie:

Path attribute
The Path attribute indicates a URL path that must exist in the requested URL in order to send the Cookie header. The %x2F ("/") character is considered a directory separator, and subdirectories match as well.
For example, if Path=/docs is set, these paths match:
/docs
/docs/Web/
/docs/Web/HTTP

For the sessions, it's better to have two different ones:

one for the admin endpoint (Path = /admin)
one for the user endpoint (Path = /user)

This will prevent privileges escalation (vertical).
To prevent stealing the cookie, you can add the attributes:

HttpOnly: prevent access to cookie values via javascript
Secure: ensure that cookies are sent securely and are not accessed by unintended parties
SameSite: Protect against CSRF

Finally, make sure that your application does not have any XSS vulnerability. You can find more details about how to prevent of it on:

https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
https://core.ac.uk/download/pdf/53189097.pdf
https://www.ukessays.com/essays/computer-science/prevention-of-cross-site-scripting-attacks.php

Hope it answer your question.
source:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies


Wipe inaccessible hard drive before returning to vendor

Chances are you will have to destroy the drive.

If the internal components of the hard drives are physically damaged, you cannot wipe it short of using destructive methods such as melting or degaussing (exposing it to an extremely powerful alternating magnetic field). You can try issuing the ATA Secure Erase command which tells the controller to do low-level data erasure without actually sending I/O commands from the host, but it will not work if the drive is so badly damaged that the ATA protocol no longer works (which is likely).

Because degaussing involves incredibly powerful magnetic fields, it's not really something you can do at home with a permanent magnet, or even a cheap electromagnet. You will need to either rent a large degaussing machine, or more practically, send in the drive to dedicated hard drive destruction services that will degauss it for you before sending it back with a certificate of destruction. Note that degaussing does not leave any physically-identifiable marks or damage. If you are returning the drive because it doesn't work, then after degaussing, you'll still be sending it back in one piece.


Is this company's claim to have solved MITM attacks true?

TL;TR: there is maybe (or maybe not) some substance to the patent but I consider the claims made in the press widely exaggerated.  I don't see any substance for the claims of helping against MITM. And it addresses different use cases than TLS, so no need to compare.

While there was lots of press end of 2014 about this issue it basically repeats the same fuzzy claims ("privacy", "could have prevented attacks at sony") without getting into any detail.

The patent which they probably refer to is probably System and method of enforcing a computer policy (or similar patents in other countries). Looking at the claims of this patent basically describes the use of a TPM in the client and a centralized server to secure encryption and decryption at the client, i.e. use remote attestation to make sure that only the correct client gets the keys and use TPM to help with encryption/decryption so that the keys itself will not be available in plain for the clients applications.

So yes, it could have probably helped Sony to encrypt its data a bit but I cannot see how it would have prevented theft of the data once the client has access to the data (needs it to work with them) and the attacker is on the client too. And I completely fail to understand how this could help in privacy as claimed in the press. And the only thing it has to do with MITM is probably to make sure that the exchange between the policy server and the client is protected, but it is nothing to do with MITM of the connection between a client and some web server.

So why did we get such unspecific and exaggerated coverage by the press? It might be that the company needs to show its investors that it has good assets because the finances itself don't look that good. And it is very strange then I could not even find an official web site for this company.


Establishing routines on what to do if a PC gets stolen

From personal experience:

Key prerequisite is an effective asset register. Otherwise you wont even know if it is one of your laptops / pc's that is missing or that turns up on the front page of the daily mail (well ok they may help in letting you know it was your device!).
Secondly - Establish a clear requirement and ability for your staff to inform you that a device has gone missing. Problem here will be if they then believe that HR will be involved and lead to sanctions - so be very clear on the users responsibility and that if they have done everything right then it is not a disciplinary issue.
Lastly the big issue will be the lack of full disk encryption. Without this you will have to presume that the data or sensitive information has been compromised and take action on those lines. This could result in your need to contact the information commissioner if personal data is involved.

Basic flow chart for this type of thing:


Smart cards for user authentication - is configuration of PIN complexity important?

As long as the card implements lock-out policies like destroying the key material after 3 incorrect PIN attempts, I'd say a 4 digit PIN is secure. Just make sure there are proper procedures in place for employees to report stolen cards as soon as possible so their certificates are revoked, just for the worst case scenario where the attacker knows the PIN, for example using a compromised PIN pad or keylogger.


Security review: "HTTP header user-agent has been set to (something)"

I dont see how inserting an escaped quotation mark into the user-agent string is a vulnerability.

I'm not certain that this is the case, I think more information is necessary.
The ONLY thing I can think of is that they're possibly exposing a potential for a session hijack.

Basically, PHPSESSID=08rtvlq03bd9d57qor4abjg7q4 belongs to a different user's session, they are spoofing this session ID via a cookie, and are getting a normal response, even though the user-agent has changed from the original user.

Clarification:

User A opens the website, using the following User-Agent string:

Mozilla Compatible (MSIE)

User A is then assigned the following session ID:

08rtvlq03bd9d57qor4abjg7q4

User B (bad guy) then sends a request to the server using a cookie with the same session ID in his/her cookie, however their User-Agent string is:

\"

Your application should then realize this is not the same user, and destroy the session.

I am by no means certain this is the situation, nor would monitoring the user-agent prevent a session hijack, as user-agents are EASILY spoofed, but this is the only potential I see here.


OpenVPN: How safe is a 24-7 open port static key setup? With proper encryption used. (AES256)

Source: https://openvpn.net/index.php/open-source/documentation/howto.html#security

"Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key."


What kinds of SSL certificates are usable for encryption?

Certificates do not provide encryption. Encryption comes from SSL itself. The certificate is about convincing the client that the data it dutifully encrypts is really sent to the genuine intended server, and not somebody else impersonating the server. A certificate for a SSL server can use a key which works only for digital signatures (e.g. a DSA key) and the data will still be encrypted.

The price of a certificate, from a commercial CA, is driven by the following tendencies:

The CA is supposed to perform more or less thorough checks on the identity of who buys the certificate. That's the whole and only point of the CA: to link a "physical identity" with a public key. Such verifications imply human labour, and that can be expensive.
The CA has insurances. When you buy the certificate, the CA becomes liable for security trouble which may emerge from the CA not following the intended verification procedures, as defined in their "certification policy statement". In short words, when you buy a more expensive certificate, you get the right to sue them for more money.
Commercial CA will charge you as much as possible. If a CA sells you a 600$ certificate, then this means that they estimated that they would lose too many sells if the price was 650$. The commercial value of a certificate comes from the fact that the CA root key is already known to the SSL client's browser; for Windows / Internet Explorer, the default list of known CA is managed by Microsoft, and they will not include just any CA. Consequently, the CA market is not totally open, and competition fails to lower prices. Right now, SSL certificates tend to be overpriced. For instance, this allowed Thawte founder Mark Shuttleworth to buy a trip into space and then create and fund the Ubuntu Linux distribution -- so one can assume that commercial CA make quite a lot of profit out of each sold certificate.

You can create your own certificates (OpenSSL is a free tool that can do that, for instance; see EJBCA for something with a nicer interface); homemade certificates are often self-signed (in a certificate, there must be a signature from the issuing CA; the format does not allow omitting that signature field; so it is customary to have the certificate "sign itself" in the case of a stand-alone CA-less certificate). The practical consequence of a homemade certificate is that Web browser will display some scary warnings when they encounter them the first time (but users are quite good at ignoring warnings -- which, by the way, is also a problem, generally speaking).


Would MAC filtering protect against KRACK?

In general, MAC filters (both whitelisting and blacklisting) are completely ineffective against a determined attacker, as MAC addresses can be easily changed and forged using standard system networking utilities.

Additionally, MAC filters do not apply here since this vulnerability allows exploitation from an attacker who is not associated with the network (side note- on a network secured with WPA2-Personal, anyone (associated or not) who knows the network's pre-shared key (PSK) can already decrypt traffic between the access point and stations, assuming the attacker has captured the relevant 4-way handshakes). The KRACK vulnerability allows an attacker to decrypt encrypted frames without knowing the PSK because they can force the client to use a key that is known (a key of all 0's). This is done by sending forged management frames, which are not protected under 802.11i, allowing attackers to effectively impersonate any function of an access point.

So in short, MAC filtering and KRACK are in completely different realms and MAC filtering is not a valid mitigation for this issue. A better solution is to patch clients, as these patches may be available before the router patches. Additionally, there are some settings that may further increase the possible damage from the attack. I suggest you read more about the vulnerability in order to understand what features may be affected.


Calculating Business Impact of Technical Vulnerability Issues

It really has to be done on a business-by-business basis, but it usually boils down to quantifying the impact based on the amount of money that the risk event could cause in terms of lost revenue, the amount of damage that would occur to the businesses brand and status in the industry, and/or the legal fallout (and especially if that legal fallout could include criminal).

You might find what you are looking for from the Open Group: http://www.opengroup.org/

or the Risk Management Institute: https://www.theirm.org/media/886059/ARMS_2002_IRM.pdf


How to calculate our application security debt?

The best advice I have heard is to figure out a list of all of the different types of events that could occur as a result of your security debt.  Next, try to estimate the cost of each of those events.  Next, figure out the likelihood of those events occurring per year.  Your final formula should look something like

Probability(event type 1) * Cost(event type 1) +
Probability(event type 2) * Cost(event type 2) +
... +
Probability(event type N) * Cost(event type N)

For example, let's say you determine that there are two issues which could be exploited by your security debit: SQL Injection + CSRF.  (I've made up numbers to make the math easier):

We expect 5 successful SQL injection attacks per year, each of which would have a recovery cost of $100,000
We expect 10 successful CSRF attacks with a recovery cost of $25,000 apiece

Your estimated cost of security debt for the year in question would be:

(5 * $100,000) + (10 * $25,000) = $750,000


Send the token over TLS.
Sign the token with a couple of private/public keys (i.e. RSA, ECDSA) to prevent tampering (You don't use a secret shared!).
If your token gets stolen, the attacker can only use it for a short period of time. You can set the expiration time to 15min.
JSON Web Encryption (JWE) provides confidentiality of content. You can use asymmetric cryptography to send confidential content. See this example.


Can second internal hard disk cause infection after reinstall?

Short answer: no.

Long answer: Always take extra precautions.

Boot sector virus only works if you boot up from that particular infected hard drive.
If you boot up from the primary drive with Antivirus software, it may detect the secondary hard drive boot sector virus but nothing to worry about.

Nevertheless, to prevent accidentally boot up ANY of the infected drive/media, you should disable the computer BIOS/UEFI option that allows one to select alternate Boot media during computer boot up/power up. Password protect your computer BIOS/UEFI if the computer is also accessible by others.


Do you need to use the same number of rounds for everyone with bcrypt?

The tuning of the cost factor for BCrypt is mainly a problem for server side applications. If the cost factor is too high, the server can become very busy only with calculating hashes, when a number of people try to login at the same time. That's why we try to find a suitable number of rounds for this server.

If you are doing the calculation client side, every client has enough cpu power on its own to calculate even a large number of rounds, the power grows with the number of clients. Web applications should calculate the hash server side though.


What is the difference between exploitable security measures and security theater?

A security measure has a goal: what it would do if nobody tried to work around it. This goal is intended to benefit someone — for example not allowing other people to withdraw money from my bank account, or preventing people from hijacking planes. It may be more or less efficient at achieving this goal, and thus it may provide more or less benefits. A security measure is security theater when its efficacy is negligible.

Blurring license plates is a privacy measure. Privacy is a holistic concern: the goal is not to make it impossible for anyone to know where my car was on Feb 29th 2019, but to make it hard for most people to know where my car was most of the time. Sure, Eve and Francis saw me on that day, but Hanna probably doesn't know that, and even if she knew they would be unlikely to tell her without some serious persuasion. So if she wants to know where I was, she'll have to do a lot more work than a Google image search for my license plate number. Blurring license plates does have a significant benefit to my privacy.

In contrast, the US no-fly list is supposed to make flying airplanes safer. The potential attacker isn't my ex-girlfriend: it's people who may have a network that can provide false papers, and who may be prepared to die for their cause. It's not just exploitable — every security measure is, with the right price or the right army — it's easily exploitable by the kind of people it's supposed to defend against. It's also easily exploitable at zero cost with a trivial workaround: bomb the queue at the airport instead of bombing the plane. It's security theater because it has negligible efficacy.

Additionally, the expression “security theater” is only used when the goal has received some media attention. Part of the connotation of the expression is that someone is making a show of implementing security measures, but those measures are inefficient. If a security measure falls in the forest but nobody is here to hear it, it isn't commonly called “theater”.


What is the purpose of the hashcode used in Exchange OWA HTTP requests?

My (wild) guess is that the "hashcode" is just a reference key used by whatever system enforces the throttling, to quickly locate in an internal database (which could be an in-RAM hash table) the entry which keeps track of the "budget" allocated to each entity. Thus not a cryptographic hash at all.


Is internal or external hosting more secure?

In a generic sense neither internal nor external hosting are inherently more or less secure on their own. Ultimately it's just a different set of trade-offs.

In both situations the amount of security controls, how they are integrated, how they are managed, and response to events could theoretically be the same regardless of location. There is a small edge for the external hosting provider in that they are likely to receive more attacks which may give them more training data for learning algorithms if they are using such algorithms in their defenses. This might make them a bit tougher or stronger in the long run.

That said, there may be many unique flaws involved with the specific ones you mentioned which may give one of those systems more weaknesses or fewer options for control implementation. Loss of access to things like NetFlow data from a switch that can be trusted when a given host has been compromised might be an example of something you may lose with some external providers. Likewise another disadvantage is that an external hosting provider will likely care less about your data than you might care about your own but even this is questionable and depends on the type of provider. I'll also point out that the current popular hosting platforms do not represent what could potentially be done if security were a companies highest priority.

A tremendous amount of security controls can be deployed on 3rd party hosting platforms. More importantly for most types of data, possibly not those involving national security issues, but pretty much everything else the level of security controls that can easily be implemented is far beyond the needs for that data. One thing to note here is that in addition to all the security hours needed to currently protect a given internally hosted platform you may need additional security hours to deal with security issues unique to the external hosting platform.

More than anything the choice becomes one of economic tradeoffs for an organization as a whole. Is it more cost-effective to host somewhere else or does the added complexity of a given platform increase the costs such that the advantages are lost. Likewise do other aspects about the platform allow a business to grow quickly ? This may be a good reason for some organizations to justify an increased expense if it helps long-term.

Ultimately it's what you make of it. External hosting means you have a business partner who in the process of outsourcing some work for you may act as the custodian of your data but you are still the data owner and responsible party for ensuring its security. This is important to note because despite any claims an external hosting provider may make the security work and responsibility for security will still be owned by your organization and ultimately your organization has to be capable of both truly understanding the risks involved and also managing these choices responsibly.

In regards to your statement:

  We need some numbers ammunition as to why hosting in the cloud with a
  proper service/vendor is more secure than trying to run everything
  internally.

What if the results show the opposite due to a massive number of small companies deploying poorly secured cloud instances simply because they are cheaper ? Since it's likely a different set of demographics for who buys these it may have very little value on evaluating which is truly a more secure option.


Practical advantage of requiring VPN for SSH

The first response that comes to mind is: "Only if you want to slow down your SSH sessions even more."

OpenVPN and SSH perform very similar tasks in very similar ways. Assuming that you have set up your SSH in a secure way, you are not increasing your protection against the typical threat scenarios.

That said, if you are extremely paranoid about your encrypted connections getting decrypted (by government alphabet soup, et al.), then tunneling your tunnels might delay them further. But, this threat is the only one that I can imagine that SSH in an OpenVPN tunnel would protect against.