OAuth Authorization Flow without external user agent for iOS application

Issue 1 - Avoid using a browser at all.

First important thing to understand is that originally, OAuth2 was designed for 3rd-party API access, which is why flows and security models are designed for use by a third party.

However, in your case, it seems that the OAuth2 tokens will be used only by your application.

The Authorization Code flow is indeed the recommended flow for native mobile applications by the RFCs. The main security mechanisms in place are:

Use of a redirect URI, to make sure that only the intended application will receive the tokens
Use of an authorization token, to mitigate risks of interception of tokens between the browser and the native application (in opposition to the implicit flow, in which it is sent direct in the URI's fragment)
Use of PKCE, for the same reasons

However, regarding the first point:
 - Custom URL scheme: you cannot guarantee that another app on the device will claim the Custom URI scheme
 - Universal URI: it involves bad UI and additional complexity

Using the Authorization Code flow has 3 benefits:
 - Single Sign-On (SSO) with other native or web apps using the same authentication service
 - Allow third-party apps using your authentication service (the OAuth2 way) without leaking user credentials (such as password) to the third-party app
 - Some authentication schemes are available only in the browser, such as WebAuthn

However, if it's tour own app, and you don't need SSO, and you think native UI is better, then my opinion is that it is acceptable from a security perspective. You can use the OAuth2 Resource Owner Password credentials if you just need login/password authentication, otherwise you'll have either to extend this OAuth2 flow or to implement it on your own.

Note that since you don't use redirect URIs at all and a mobile app is not capable of keeping a secret, well, secret (called public client in OAuth2 terminology), you basically can't guarantee that it's really your native app that is calling your authentication endpoint.

Therefore, you have 2 solutions:
- enroll your application with a secret. For instance, it could be a secret that is embedded in a QR-code that is sent by letter to your client
- protect your authentication API against brute-force attacks, and apply strict throttle limits. In addition, do not allow weak passwords, and / or ask for a second factor for more sensitive data

But since it's your app, and it's unlikely you'll install a keylogger on your own app (!), I see no point hashing the PIN (weak password with low entropy by the way). If your mobile OS is hacked and the "virus" has access to your application memory and code, there's nothing you can do anyway.

Issue 2 - Keeping the Access Token safe.

The best practice is to keep the refresh token in the KeyChain, and the access token in memory. When the access token is lost or expired, just request a new one using the access token.

To mitigate risks of stolen tokens for sensitive data, you can:
* limit the lifetime of such tokens
* ask for a second factor for such tokens
* binding them cryptographically to the calling application. This mechanism is called Proof-of-Possession (PoP) and is surprisingly still experimental. You can find more information at: enter link description here and enter link description here


What are the security implications of homebrew and macports?

If I am understanding your question correctly, it boils down to:

  Homebrew changes the permissions of /usr/local/bin from the default drwxr-xr-x root wheel to the less secure drwxrwxr-x myuser admin. What are the risks?

As you point out, your user (or anyone in the admin group, or any virus that manages to run as you) can now install software, including over-writing default system stuff.

How big of a problem is this?

Multi-user system

On a multi-user system like a server where there are other users logged in, this would be a big problem. I don't have access to a Mac, but I assume my linux box is similar enough; /usr/local/bin is empty (nothing to replace) but

$ echo $PATH
/usr/local/bin:/usr/bin:/home/mike/bin:/usr/local/sbin:/usr/sbin

So assuming that other users have the same bash config as me, then it looks in /usr/local/bin first. Therefore I could put a malacious program called ls in /usr/local/bin and the next time someone tries to navigate the filesystem, my code will run inside their user account. The nefarious possibilities are endless.

So I would agree with you that this is a problem on a multi-user server.

Single-user personal computer

For all intents and purposes, there is only one user on your laptop. xkcd illustrates this quite well:

If an attacker / malware / etc has already gotten inside your account, then they have all your data, it's only a matter of time until they keylog you typing your sudo password, so do you really care whether they install further malware in /usr/local/bin or put it in /home/myuser and add that to your path? The end result is the same.


Can I use a CA certificate for two ways (mutual) authentication

No, you cannot use the same certificate for both server- and client-side SSL authentication.

(Well, technically, you can - it won't break anything - but it means that the server private key will be known to N clients, each of which can then impersonate it, so that's just not going to work out.)

If you wanted to do Client SSL authentication, you'd want to issue individual certificates to all your clients.  You can do that with your own CA, they don't need to be signed by a public CA, as long as your server can verify them against that CA.

See also this answer which might be useful to you.


How could supply chain counterfeiting be combated by using a blockchain?

There are essentially two categories of answer to your question: blockchain as a better ledger, and blockchain combined with physically unclonable functions to do the things you seek.

Blockchain As A Better Ledger

Blockchain can function as a better public ledger system than existing paper-based or even traditional, single source, trusted electronic counterparts, in many respects:

It is distributed: Many separate servers maintain individual blockchain logs, ensuring that an outage by some few of them will not deny service to the remaining ones.  You can count on some ledger being available for verification.
It is hard to corrupt: Assuming that more than half of the blockchain servers are honest (and available), the logs among all honest servers will be identical.
It is gaining popularity: Blockchain is growing in popularity due to cryptocurrency, and many companies are starting to consider adopting it for other purposes.  Note, "starting" to consider - there are many issues including the fact that cryptography is hard for managers to get; plus, what is the business model for mining non-monetary transactions?  What do I get out of it, other than "I mine your transactions, you mine mine?"  Maybe that is enough.

Blockchain Combined with PUFs

Driving to the heart of your question, there is research into physical authentication systems that has led to something called physically unclonable functions, or PUFs.  A PUF is a special function of a hardware device, such as a CPU or other computer chip (FPGAs, RAMs, etc.) that responds to a challenge in an instance-specific way.  For instance, a ring oscillator can be created on the chip with a frequency that depends on both challenge bits given to it, and material variances in the fabrication process, and a counter can return the number of counts in a given amount of time.  Since each device is different, it is hard for a forger to predict the number of loops for a particular challenge without having access---current or prior---to the genuine article.

For a device with a PUF, certain points in the supply chain could challenge the PUF and record the results in the ledger, and later, a recipient of the device could verify all the recorded challenges.  There's probably a better way to do this without revealing the challenges, something where the points along the way could log a keyed hash of the challenge/response pairs using a key known only to the recipient.

For other physical entities, you could use a special chemical formulation that reacts differently to other "challenge" chemicals applied to it, so long as what is committed is not the actual response, but a proxy for it (hashed response).  This would have the benefit of ensuring correct sequencing through the supply chain.  If, at any point, someone replaced the genuine article with a counterfeit, they'd have to emulate the chemical state applied to the genuine article up to that point in the chain.  Maybe I am overthinking it.  Why not log hashed, very low dosages of radiation applied to a sensor securely tucked inside?  Or the same with GPS coordinates of the item's path from shipper to receiver correlated to other distinct items couriered by each link in the shipping path?  Etc.

Hope vs. Hype

You bring up an excellent observation, that much of this is hype designed to sell interest in a new technology.  The biggest problem that I see is what's in it for me?  To make blockchain work, each transaction submitted to the record must be "mined" by others in order to be added to the transaction chain.  With cryptocurrency, the reward for successful mining is a slice of the coin.  But how do you reward others for mining more mundane things like transactions?

You could create a company that does this "for a living," but recall that blockchain only makes sense when you have a large, non-colluding set of servers.  There would have to be many companies that would agree to do this.  Further, there would have to be compensation for logging items in the chain.  As with typical service industries, there's a very real risk of many small startups being acquired and folded into a set of few megaproviders, and then they would be able to manipulate the official record.

Summary

To wrap up, I had to think about this question, as it's an important one.  The key things that I would advise are that it's possible, but it's easier for some types of products than for others, and the big barrier is figuring out a reward system for those willing to maintain and commit to the ledger.

Hopefully, others in this thread can contribute to this discussion, or correct any errors I made.

Some further reading:

Bitcoin's Baby - http://www.bbc.com/news/technology-32781244 - a gentle if not too high level of an introduction to Blockchain.
Early Paper on PUFs - https://www.scopus.com/record/display.uri?eid=2-s2.0-34547307341&origin=inward&txGid=A0A55F5E2061FB0740ED8ED25EDB36BE.wsnAw8kcdt7IPYLO0V48gA%3a2


Where can I find a canonical list of elliptic curve names and their aliases?

For TLS there is of course the official list of curves, but there's not a single, comprehensive list of elliptic curve names I am aware of. But when you look at different TLS implementations, you will quickly notice that there is only a limited number of elliptic curves that are supported by all major implementations.

For maximum interoperability, you should use secp256r1 (NIST P-256) or secp384r1 (NIST P-384), as these are used by most CAs for their own certificates, are supported by all major TLS implementations and will also be contained in TLS 1.3 (which only contains a total of five curves (secp256r1, secp384r1, secp521r1, curve25519 (x25519) and curve448 (x448)).

Curve25519 will probably play a major role in the future, as it has has many desirable properties (very fast, easy to implement, avoids leaking information via side channels), but has only recently been included in many important standards.


How to include multiple parameters in sqlmap POST request

You can just comma-separate the parameters you want to test.

In a GET request:

$ sqlmap -u "http://example.com/?a=1&b=2&c=3" -p "a,b"

In a POST request:

$ sqlmap -u "http://example.com/" --data "a=1&b=2&c=3" -p "a,b" --method POST
...
[13:37:54] [WARNING] heuristic (basic) test shows that POST parameter 'a' might not be injectable
...
[13:37:59] [WARNING] heuristic (basic) test shows that POST parameter 'b' might not be injectable
...

Both examples would test the specified parameters a and b, but ignore c. (I also put them into double quotes which isn't actually necessary on Linux.)


I'd recommend to hire someone (or some developer could do that) to educate the QA team using OWASP Top 10 or WASC TC. If you want step-by-step guide how security testing should look like, you can use OWASP Testing Guide, which will give you pretty good picture.


How does Nessus know which services are running in a host?

It really depends on the type of scan you are performing...

By default, Nmap scans report these services by making a guess based on the its nmap-services table. The nmap-services file is a registry of port names to their corresponding number and protocol. Each entry has a number representing how likely that port is to be found open. This file was originally based off the IANA assigned ports list at http://www.iana.org/assignments/port-numbers, though many other ports have been added over the years.

Version Scan

The Nmap version scanning (-sV) subsystem obtains application versions and other data by connecting to open ports and interrogating them for further information using probes that the specific services understand. More info on this service probes database can be found here. This allows Nmap to give a detailed assessment of what is really running, rather than just what port numbers are open. There is also support for community contributions -- if Nmap gets data back from a service that it does not recognize, a service fingerprint is printed along with a submission URL. The output will look something like this:

PORT    STATE  SERVICE  VERSION
22/tcp  open   ssh      OpenSSH 4.3 (protocol 2.0)
25/tcp  open   smtp     Postfix smtpd
80/tcp  open   http     Apache httpd 2.2.3 ((CentOS))
113/tcp closed auth
443/tcp open   ssl/http Apache httpd 2.2.3 ((CentOS))
Service Info: Host:  web.insecure.org

Banner Grabbing

It is also possible to perform banner grabbing on the services running on various ports by using Nmap's scripting engine and making use of the banner grabbing script. The output while using banner grabbing will actually include the banners supplied by the services:

21/tcp open  ftp
|_ banner: 220 FTP version 1.0\x0D\x0A

More details on Application and Version detection can be found here.


Don't give anybody physical access to a device that's running your image. If they have physical access to the device, they can read your image. Encryption wouldn't do any good since the decryption key would have to be readable.

If the device has some tamper-resistant storage such as a TPM or a smart card, this raises the bar somewhat: someone who wants to read your image would have to snoop on some data bus (which requires a bit of equipment). But still, if the device can run it, so can anyone who is physically present.

Obviously, the image should be secured during transport. But since the transport is between locations that you control (from your development machine to the physically secured device), this shouldn't be a problem.

Don't give anyone shell access to the device. You can get away with a sufficiently restricted shell access (no administrative powers), but really, on a WRT system, there's nothing to warrant that.


How to find out where CNAME had resolved to in the past?

DNS does not provide historical records. So unless it's been cached somewhere public in a way that you can access it, there is no way to know what a CNAME resolved to.


What is an example of arithmetic and buffer overflows in a php application?

Arithmetic Overflow

You cannot have arithmetic overflows in PHP, at least not in the sense that the number wraps around, leading to a smaller result than expected (which is the kind that may have security implications).

There are two reasons for this:

if an integer is increased above its limit, it is automatically converted to float.
if a float is increased above its limit, it is automatically set to INF, which is treated as the largest value.

You can try this yourself:

$max = PHP_INT_MAX;
var_dump($max);         // int 9223372036854775807
$max = PHP_INT_MAX + 1;
var_dump($max);         // float 9.2233720368548E+18

$max_float = 1.8e307;
var_dump($max_float);   // float 1.8E+307
$max_float = 1.8e307 * 10;
var_dump($max_float);   // float INF

It works the same way for negative numbers.

But even though you do not have an overflow of integers in the traditional sense, you still might run into problems. Consider for example these cases:

PHP_INT_MAX < (PHP_INT_MAX + 1) // -> false
PHP_INT_MAX == (PHP_INT_MAX + 1) // -> true

Arithmetic Underflow

You can have underflows in PHP:

$min_float = 9.8813129168249E-324;
var_dump($min_float);   // float 9.8813129168249E-324
$min_float = 9.8813129168249E-324 / 10;
var_dump($min_float);   // float 0

As 0 is equal to a number of things, among them NULL, false, "0", "foobar", this may cause problems in some situations. But these problems aren't really a result of the underflow.

Buffer Overflow

Buffer Overflows in PHP may exist because of vulnerabilities in PHP itself, but not because of application code.

Here is a list of some buffer overflow vulnerabilities in PHP.


Double hashing using a relatively new hash and a old, tested one

You should really stray away from rolling your own crypto implementation. Why not use bcrypt for password storage? It's been tested extensively for that and works quite well.

Some advantages it has are:

Resistance to brute-force
Resistance to rainbow tables
Salt generation
Scalable speeds via setting the rounds of hashing
Built upon blowfish algorithm


How can I prove that a certain email was not sent to my account?

The SMTP logs of Hotmail, their provider or any trusted third-party involved in delivering the email could confirm if their servers did or did not process it. (There is no guarantee that logs are available and likely you won't be given that information without a court order.)

But either way you won't be able to prove that they forged it. That's because there are plenty of ways an e-mail can get lost. It might very well be an accident and from their point of view it's equally hard to prove that the email has actually been sent.


Can a provider allowing 2FA with a Yubikey identify me if I use the same key for different accounts?

With Yubikey's alphanumeric one-time passwords, yes:

Each Yubikey had a unique public identifier. The authentication server must know this ID in order to select the correct AES key for the OTP. The proprietary Yubico OTP protocol should no longer be used.

With FIDO U2F, no:

The Yubikey creates a unique keypair for each combination of device+user+service. This is described in the Registration section. The FIDO protocol is newer and focuses on both secure authentication and user privacy.


Biometric authentication in the real world

As I'm sure I posted in one of the other biometric questions, the only places I see it a lot are datacentres. And more specifically, datacentres protecting high value root certs. For this type of environment it is the norm, rather than the exception. Update to say - it is only ever used in addition to all the other controls, not instead of!

Elsewhere, it's patchy - people are starting to use fingerprint scanners on laptops etc., but I get the impression that is just because they are there so might as well be used:-)


A fully updated system will still have insecure or weak cipher-suites enabled.  You can run a tool such as TestSSLServer, written by Tomas Pornin which will give you a list of cipher suites that are vulnerable to BEAST and CRIME.

After you have identified the specific set of insecure cipher suites that affect your system,  you can disable them in Apache's SSL configuration.


Why is spreading malware.scr instead of malware.exe more common?

Probably because user education has focussed on ".exe extensions are bad", so a .scr might have a better chance of being run, especially if the email claimed it was a script to do something useful.


What are the risks associated with relying on IPSec IP Filtering?

Depending on the service the outgoing port is usually different from the incoming port, and is often randomly assigned. So the mirror would be from any port on localhost to 5666 on the remote host. The risk depends on the IPSec mode: transport or tunneling. I would say the most likely threat would be on availability. In transport mone the destination IP and port are in the clear, So an adversary could attempt to flood the destination port.


I believe that Sodium, as an open source project, qualifies for section (e) of the TSU exemption to export controls: http://www.gpo.gov/fdsys/pkg/CFR-2006-title15-vol2/xml/CFR-2006-title15-vol2-sec740-13.xml

(I'm not a lawyer, but this is what is used by the Apache foundation for cryptography-related code, as I understand it.)


How many bytes should an authorization token have?

Since authorization tokens are random, your primary attack vector is brute-force guessing.

In an online attack, your defense strategy may limit the guess rate or total allowed guesses and therefore limit the necessary bit length.

An offline attack is more interesting, if such an attack is possible in your environment. With today's technology, 64 bits (between 10 and 11 characters alphanumeric) is just at the edge of guessable given a fair amount of time and a silly amount of money. On the other hand, 128 bits (between 21 and 22 characters alphanumeric) is beyond the reach of brute-force attacks pretty much indefinitely unless our understanding of time thermodynamics drastically changes.


Dynamic analysis of Swift application using Cycript or gdb

Michael Gianarakis spoke about reversing Swift including hooking at the Hack-in-the Box conference in 2016 -- http://gsec.hitb.org/materials/sg2016/COMMSEC%20D1%20-%20Michael%20Gianarakis%20-%20Reverse%20Engineering%20Swift%20Applications.pdf

In particular, Michael goes over function hooking on getter methods (which work) and setters (which do not), as also discussed here -- https://web.archive.org/web/20151004101419/http://www.eswick.com/2014/06/inside-swift/

Some additional notes on function hooking and the ability to work it all together with MSHookFunction from Substrate is available here -- https://www.securify.nl/blog/SFY20150302/hooking_swift_methods_for_fun_and_profit.html

Here also is an older article on Swift method swizzling -- https://www.uraimo.com/2015/10/23/effective-method-swizzling-with-swift/

Finally, Michael makes mention to using macOS tools such as nm and xcrun to engineer a Swift-aware class-dump, but you can also check out this one here -- https://github.com/BlueCocoa/class-dump/


Can a 0800 and 00800 be from different companies in UK

00 is the telephone prefix to dial international numbers in many countries, including the UK. The 1 to 3 digits that follow 00 are a country calling code, in this case the code is 800 which is an international toll-free number.

As far as I know, 00800 numbers are always toll-free, so this can't be a scam where you are tricked into calling an expensive number.

The 00800xxx number bears no relation with the UK number 0800xxx. So this may be a scam where you're tricked into communicating with a party you aren't expecting. For example, they might try to trick you into paying them something, pretending to be Thames Water giving you the last chance to pay your water bill before they cut you off. Or it could be a different scam copying an 800 number from a different country such as the US. Or it could be some simple spam, perhaps with an invalid caller ID. Or it could be a mistake.


Microsoft uses the CARO naming scheme:

Mitre came up with the CME:

  The Common Malware Enumeration (CME) initiative aims to provide single, common identifiers to new virus threats (i.e., malware) and to the most prevalent virus threats in the wild for the benefit of the public. Managed and maintained by The MITRE Corporation, CME is not an attempt to solve the challenges involved with naming schemes for viruses and other forms of malware. Instead, it is an effort to facilitate the adoption of a shared, neutral indexing capability for malware.

Another article about naming.


How to protect data on your hard disk if it is in an unfriendly environment?

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

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

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

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

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

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

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

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

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


Logging stack traces to a log file is in itself usually not a security issue, but the exposure of information in the log file can be, depending on your threat model, the information contained in the backtraces and the specific user group in question.
One example of a case where stack traces might contain sensitive information is if they could cause user credentials or other PII to be logged for your developers to see, who should not otherwise have access to this information. Another problem might be if the stack traces are exposed to a potential attacker, who may use the leaked information (e.g. pointer values) to circumvent mitigations such as ASLR.
If your security team is asking you to remove that information, I'd suggest you work with them to figure out what information exposure they are concerned about, which threat model applies, and how you can keep the same level of insight without compromising on your security.


GlobalSign Domain Validation CA revocation issue in all browsers

From their twitter : https://twitter.com/globalsign/status/786505261842247680

"We are currently experiencing issues with our OCSP which is causing certificate warning messages. We aim to fix this as soon as possible."

The OCSP is the certificate status protocol - their server is potentially flagging certificates as revoked when they are not supposed to be.  This would be a big issue for them, but from follow up tweets, it appears they may have this resolved.

The OCSP status info may be cached for awhile, though, so it may be awhile before certificate errors go away.


Getting and then distributing a wildcard SSL certificate -- is this okay?

The specific example you use won't work, because it contains multiple levels of sub-domains, and wildcard certs are only valid for a single level.  So a cert for  *.insecureshell.net will work for 1.insecureshell.net, and 2.insecureshell.net, but not 1.1.insecureshell.net, and certainly not 1.1.1.1.insecureshell.net.  However, that doesn't mean a variation on this can't work, at least assuming you actually control 1.1.1.1 and say, 4.3.2.1 as examples.

HTTPS and certificates don't care about the underlying IP address, they only care that the subject name or a subject alternate name in the cert match the host name of the site you're trying to connect to.  For a wildcard cert, this means any single level sub-domain.  So if you control those two IP addresses, and that is where you're hosting your services, you could use the following sub-domains:  1-1-1-1.insecureshell.net and 4-3-2-1.insecureshell.net to reference them.  You then simply have DNS entries for those two subdomains that point at the IP addresses 1.1.1.1 and 4.3.2.1 respectively, and install your wildcare cert on both those machines.  There's really no reason to do this though, generally speaking.  Instead you use service1.insecureshell.net, and service2.insecureshell.net, and you have DSN entries for those names pointed at 1.1.1.1 and 4.3.2.1, and once again, install your wildcard cert on both those boxes, and you're good to go.


How to send an encrypted mail only knowing the PGP fingerprint?

You cannot reconstruct an OpenPGP key based on it's fingerprint. The fingerprint is a hash value of the public key, so calculating the fingerprint of a key is a one-way operation.

But: if somebody only distributes his key's fingerprint, he will almost certainly have distributed his public key on the key server network, from where you can pull it. Given you use GnuPG, the most wide-spread implementation of OpenPGP, use

gpg --recv-keys 01ECFFDFC3C2F3CC

to load the key. You should also be able to use an arbitrary graphical user interface for this operation, or load it from some key server's web site (you'll have to prefix 0x here for key IDs, thus query for 0x01ECFFDFC3C2F3CC.


The Wikipedia article on Key Wrap states:

  Goals (3) and (5) are particularly important, given that many widely deployed authenticated encryption algorithms (e.g., AES-CCM) are already sufficient to accomplish the remaining goals.

Which suggests AES-CCM is an adequate, if inefficient, solution.


Is it true that meltdown and spectre were intended as debug tools?

It's not even remotely true.  Although you can use a Meltdown or Spectre attack to inspect the internals of a program in the way a debugger can, a proper debugger is much faster, easier, and more reliable.


Can password-protected zip files be broken without brute force?

In direct meaning, you mentioned (extracting data), no. But keep in mind, however, that any program (or user), in any password-protected ZIP archive, can (without knowing the password):

browse list of files,
check file types1.

ZIP files can also be "broken" in the meaning, that you can overwrite exisiting, password-protected file, stored inside ZIP file, with another file, named the same, without knowing the password.

All these mentioned operations does not give attacker access to contents (he or she is still unable to extract data), only list it or destroy it. So I'm mentioning this only as a possible side effects, you may be not aware of. Some people treats this as security leaks, stating that for this reasons, ZIP files are insecure, but other my assume that security is not violated, even with these mentioned "additions".

Since contents of ZIP file can be changed, without knowing the password, by replacing a password-protected file with another one, we can speak about complete insecurity in psychological terms (social engineering, hacking etc.). The attacker can alter contents of ZIP file, without knowing the password and claim to its victim that it is unchanged. Victim, without knowing above mentioned side-effects, may incorrectly assume, that archive hasn't been changed or its contents aren't altered, since he or she (the victim) is the only person, that knows the password.

Here you have my simple question about security of ZIP files, which turned out to be a very good readout, with a lot of useful answers and comments.

1Try to send encrypted, password-protected ZIP containing EXE file via Gmail to see this "in action". Gmail will be able to detect, that you're sending an executable file (and prevent you from doing so) even though, it does not know password, your ZIP is protected with. Side note: It is also both funny and surprising, that renaming the very same file, by giving it different extension (i.e. file.not-zip) can completely disarm this "protection" mechanism and allow you to send archive containing executable file. Funny, because Gmail is able to "break" encrypted, password-protected ZIP to "save" user from sending executable files, but "dies" completely on file rename.


Risk assessment Struggling with scenario

Thanks goes to Davy Strain for providing this answer.

The SLE is given in the data so no need to work out the AV/EF, i was overthinking the data.

SLE = 225

Annualised Rate of Occurrence - ARO

80*7000*365 = 204400000

204400000 * 0.2% = 408800

408800 * 30% = 122640

122640 * 2% = 2452.8

ALE = ARO 2452.8 * SLE 225

=>ALE = 551,880


Is there man in middle attack when using mobile phone calls?

Yes if an attacker can create a fake basestation then they can effectively emulate the phone network and intercept calls which are made via that basestation.  This is obviously a relatively local attack (e.g. you need to be close enough to the fake basestation for it to be the strongest signal available)

Some time ago the costs of doing this were pretty high, which precludes low-end attackers from doing it, however more recently there has been some research on using femtocells like the Vodafone suresignal to provide cheap interception of voice calls (more information on one project here


A host key is mandatory for any ssh server. The server can have multiple host keys using different algorithms. If no key is present when the server is started a host key is generated for the server.

An ssh client can authenticate with a wide range of different methods. The two most common are password and publickey. As the name suggests only publickey requires a key. It is very often recommended to use publickey as it has multiple security benefits compared to password, and publickey is also better for the user experience.

The above applies both when using ssh to run commands on the remote machine as well as when using scp or sftp to transfer files. Once your keys have been created the same key files will be used for all three commands.


Security implications of Cloudflare's SSL Full mode (not Strict)

Issues with SSL Full (not strict)

MITM: you can easily put the whole Internet into the scope, and at least your infrastructure provider. With SSL Full you have the following scheme in place:
[user] --- TLS ---> [CloudFlare] --- TLS (self-signed) --> [origin]

On the right side, a self-signed certificate can be used (even not a valid one, compromised, any). And let's zoom in to the right part between [CloudFlare] and your [origin]:
 [CloudFlare] -> Routers -> ISP -> Server provider -> Routers -> [origin]

Because CloudFlare trusts to ANY certificate at the right side in this case, then a malicious actor at any intermediate node between CloudFlare and the origin can put the certificate and intercept the traffic, and neither CloudFlare nor your origin can identify the leak. You don't know whether it happens until you find yourself in the news.
See more additional notes below.

Internal threat and Access control: your engineers can mess up with certificates, replace them, use compromised ones, and redirect traffic through their own MITM server. The strict option narrows down the threat to the people with access to a domain controller who can issue a proper TLS certificate on your origins.

What option to choose?
The thing is that it's up to your risk acceptance whether you're ready to keep the connection of this kind of security level in place. Most likely we trust to CloudFlare's part of the network, and to server provider's part of the network  (infra), and it basically means that you can keep SSL Full for a while. And I would personally recommend to start from SSL Full, but to plan to implement SSL Full (Strict) as soon as possible.
And forget about MITM for a moment: access control issue (internal threat) is a rather severe risk to not get considered.
Likelihood of MITM
I don't know for sure, but the important thing is that you have to apply the likelihood on the sensitivity of the traffic flowing through the channel. E.g. if the origin receives the PII, payments, and so on, you will get the higher severity of any possible breach. If to imagine that you send some trash just for fun through the channel, then you can drop the security of the channel to HTTP and don't bother.
Your ideal security strategy

Step 1: SSL Full
Step 2: SSL Full (strict)
Step 3: SSL Full (strict) with CloudFlare's CA.

Step 3 means to use CloudFlare's CA to issue certificates for your origin servers: users can connect to the CloudFlare's front-end, but users won't be able to connect directly to the back-end without a TLS handshake error, as browsers don't trust to CloudFlare's Root CA. You would also need to whitelist CloudFlare via iptables.
Again, it's up to you whether to use or not any of the options, it boils down to security and risk assessment of your system.


Would encryption bypass some firewall rules?

Using the OSI model of layers is often a good way to spread confusion; it was not initially meant for TCP/IP, and TCP/IP always had trouble fitting in it.

When data is encrypted, it can no longer be understood by whoever does not know the decryption key. However, firewalls don't look at all the data, and encryption does not encrypt everything, because the packets must still be properly routed.

For instance, if the encryption is SSL, then it goes over a TCP connection. The source and destination addresses and ports, and the TCP management details (SYN and ACK flags, and so on), are not covered by the encryption. Firewalls usually work only on ports and addresses and TCP flags, and thus are not impacted by the SSL encryption; firewalls are not even aware that encryption occurs: for them, the TCP stream contents are "just bytes".

There are security-related systems, though, which are impacted by encryption. For instance, all Deep Packet Inspection systems. They are not "firewalls" in a strict sense, but some people refer to them as such on the basis that they may be integrated into some hardware whose primary job is firewalling. DPI has trouble with encryption. To put things bluntly: an antivirus software running on the entry router of your network will not protect you if you download malware over HTTPS.

VPN can obscure the situation, especially if you want to think in "layers".


Use bidirectional SSL with CAC from phone

The CAC seems to be a typical smartcard where the private key is stored on the card itself and crypto operations involving the private key like signing are also done on the card. Such smartcards do not allow extraction of the private key. In fact, that is the main purpose of these cards that any use of the private key should explicitly require physical possession of the smartcard.

In other words: you will not be able to extract the necessary secrets (private key of the certificate) from the card so that you can use these to authenticate yourself without the physical card being involved.


I cant give a scenario but I can tell you the difference in location.
Physical Location in your terms refer to where your access the site from, as in a physical address.  The logical address is what device you are using.  Because Full blown computers are now the size of cell phones, the definitions have to change to better suit the understanding.  Also you can go anywhere off the map and still access data, for this Physical Location is now deemed as a GPS Location Address.  A network address refers to your IP Address.


Is automated and digitized ballot processing inherently more dangerous than manual pencil and paper?

Great answers already about supply-chain attacks, complexity, transparency. I'll give an answer in a different direction: accountability and auditability (basically; how easy is it to do a from-the-ground-up recount?).
With a paper-based system, in the case of disputes, as long as boxes aren't physically lost or destroyed you can always go back to the paper source-of-truth and do a recount. For example, if the voting machines physically screwed up, you can go to the supreme court to get a ruling on whether "hanging or dimpled chads" count, and then go back to the paper and do a recount.
With a computerized system, if something goes wrong and the votes are recorded incorrectly in the database (either by accident or malevolently), there is a much greater risk that that data is just lost and it's impossible to reconstruct voter's original intent compared to a paper system.

TL;DR given the amount of value we place on free and fair elections, and the amount of effort we assume attackers might be going to to try and subvert them, our tolerance for risk here is very low. Paper has fewer things to go wrong, and is easier to go back to the source-of-truth and do a recount.


What do the [-], [+], [!] line prefixes mean in exploit outputs?

They are simply ASCII icons for the type and level of log entries.

Many commandline programs do this, not just exploit code - it makes it easier to read the output.

I'm not sure that there is an established standard, but if you read the source code, you can see what decisions the devs made in their program.


Both, the client and server need to support it to make it work. TLS Fallback SCSV is used as a signaling cipher suite (TLS_FALLBACK_SCSV, value 0x5600) during the handshake. All new browsers (clients) supports it. On the server, you will enable it by updating OpenSSL.

From https://www.openssl.org/news/secadv/20141015.txt:

OpenSSL 1.0.1 users should upgrade to 1.0.1j
OpenSSL 1.0.0 users should upgrade to 1.0.0o
OpenSSL 0.9.8 users should upgrade to 0.9.8zc

Debian and other distributions are deploying backports of the TLS-FALLBACK-SCSV update on OpenSSL.

Also, upgrading alone is not sufficient. You have to disable SSLv2 and SSLv3.

Refereces:
https://alpacapowered.wordpress.com/2014/10/20/ssl-poodle-attack-what-is-this-scsv-thingy/
https://wiki.openssl.org/index.php/SSL_MODE_SEND_FALLBACK_SCSV
https://stackoverflow.com/questions/26406586/how-to-enable-tls-fallback-scsv-on-apache


Is it safe to store passwords on Google drive?

Is Google Drive safe?

I wouldn't say that Google drive is not a safe place to store sensitive information. But I bet you cannot rely on it. When it comes to
protecting your sensitive data/privacy, it is always good to be sure, and just trusting drive is not being "sure".

Solution:

One word, Encryption.

Encrypt your data before you store them in the Google drive. Now you don't have to depend on Google to protect your data security, it is you who should keep
your mouth shut about your key ;)

Note:

Encryption is not always needed when storing normal data which falls under the general category(something like the things you share in the social networks,etc.)

But it is really a great option when it comes to storing your confidential information in drive and in my experience, I am pretty sure that passwords fall under this category.


Virtual Machine Introspection for VirtualBox

you should check the Winbagility project which provides the VMI APIs for VirtualBox (called FDP for Fast Debugging Protocol).

A library similar to libvmi has been written on top of it:
icebox.

I don't believe that they will make a libvmi driver for FDP.
The reason is that they used VirtualBox because it is a cross-platform hypervisor, so no need to be compatible with other hypervisors.

It's a late response, but it may help someone.


How do I serve a webpage on a local PC without revealing my IP-address to end users?

In order to hide your IP address from users you need to make sure that they don't access your server directly, i.e. put some kind of reverse proxy in between. For public sites this can be done by putting a CDN like Cloudflare in front of it. For internally hosted sites this can by done by using services like ngrok or similar.


Why would I sign my git commits with a GPG key when I already use an SSH key to authenticate myself when I push?

When you authenticate to Github with your SSH key, that authentication doesn't become part of the repository in any meaningful or lasting way.  It causes Github to give you access for the moment, but it doesn't prove anything to anyone who is not Github.

When you GPG-sign a git tag, that tag is part of the repository, and can be pushed to other copies of the repository.  Thus, other people who clone your repository can verify the signed tag, assuming that they have access to your public key and reason to trust it.

While it isn't necessary to tag and GPG-sign every single commit, it is wise to provide GPG-signed tags at least on each commit that corresponds to a released version of your code.  You may wish to do more than that, but that is the bare minimum of responsible behavior, as it provides reasonable assurance that:

The commit in question really does correspond to the release in question.
The commit in question (and to the degree that we trust the SHA1 hashes used in git commit history, all of its predecessors) came from the signer (and, if applicable, the signer's team).
The commit in question wasn't tampered with after the signer tagged it.

Note that I said "reasonable assurance", not "perfect certainty"...there are other things that can go wrong with software integrity.  However, providing signed tags at least for official releases is a huge step in the right direction.


You've got a few important ones on your list already, such as spelling mistakes and display names vs. sender address. Also the redirection links are good to investigate before clicking.

But then there are also some serious erroneous assumptions that can get you in trouble:

.txt files are not necessarily safe. Editors have vulnerabilities and sometimes extensions are hidden by your OS which only make it look like a text file.
Good spoofing attacks will generally come from a server that has been compromised and still has a good reputation. IP address look-ups don't necessarily tell you anything about trustworthiness.
Besides the IP address itself, there are many companies that use third party email services to send out legitimate emails. It is hard to tell if an IP address belongs to a legitimate service simply because there are so many.
Trusting the SPF check result in an email header as an indicator of spoofing is a bad practice. Legitimate emails that get forwarded generally have failing SPF checks, while good spoofers of malicious emails generally have passing SPF checks. This is because the SPF check is being executed on the domain that corresponds with the Return-Path address, where bounces / Non-Delivery Reports (NDRs) are sent. While most email clients show the From: field of an email, which is not technically linked to the Return-Path domain.

What to look for then?

DMARC is a newer standard that works on top of SPF and DKIM (DomainKeys Identified Mail). It actually demands alignment between the domains used in both authentication checks, with the domain used in FROM field address. The DMARC result is usually added to the Authentication-Results header. It passes if either one of both SPF or DKIM produces a Pass result in alignment with the From: field domain.

If a DMARC record is not present for the From: address domain, you can check yourself if the SPF domain or DKIM domain (d= tag) match up with the domain in the From: header (not the Sender: header or Reply-to: header or any other header).

Holy grail

There is no such thing as the holy grail of anti-phishing. There are DNS and ASCII-art attacks possibly impacting DMARC results. DMARC can pass on a common domain A while the Display Name used was from common domain B. ex: From: Bank of America <support@uber.com>.
You need to apply all tactics and always think twice when you are requested to fill out PII, credentials, banking information or download attachments or click links.


What exploits are possible in languages like C/C++ other than overflow errors?

Since C (and C++ which can be technically be considered an addition to C) is close to Assembly, Much of the details of the processor have to be modeled and controlled from within its constructions. The easiest example that shows this is the array index overflow bug.
 This bug entails the improper use of an array index in such a way you retrieve a piece of memory that was not allocated to said array.

int[2] arrayX;
printf(arrayX[3]);

A proper compiler will complain in the code block above about index out of scope since a static analysis of the code already shows it. You can also use dynamically created arrays that are of unknown since at compile time and there no warning will be given.

Now, when you enter a function you effectively assign a code return address into the stack. as well as locations for the return "object" in same said stack. This stack is called the call stack and should not be manipulated by the program under normal operations.

With both of these mechanics we can 'trick' a program into running our own code. we do this by adding processor instructions on a known memory location, and manipulate the call stack to change the return pointer to my injected code block. (this is called code injection).

This behavior can be triggered by an overflow error or some other mechanic to adjust the call stack, this is dependent on the OS in operation and the Hardware in use, and is the main way exploits work.

There are however exploits that exploit lower level calls than C offers (basically injecting machine code / assembly into the program code).

In C++ there are additional methods of adding code to an application, through utilization (or abusing) of the Class loading mechanics.

If you want to learn about these concepts I would suggest learning about metasploit. Reading up on how C works in detail (the c bible is a good start)
and try and read the GCC compiler documents.


Are RFID shielding sleeves/wallets necessary for payment cards?

I'd like to say up front that everyone else who has posted here is essentially correct. I thought I would post a different perspective, as I am a user of RFID shielding technology.

Every card in my wallet has a RFID chip in it. Credit cards, ATM cards, Transport card, Office key, Drivers License, heck even my coffee discount card. Also, my passport has RFID.

I purchased a shielded wallet from ID Stronghold, black leather with each card sleeve individually lined with some shielding material (presumably aluminium, though the manufacturer didn't specify). This is important as some wallets only shield the outside and not individual card slots, so they are potentially vulnerable if your wallet is open, or thick/full enough to leave an opening. I also have a passport bi-fold with card slots, made from stainless steel mesh (can't recall what brand that was though.) I can verify that the cards in my wallet are unable to be read by and of the scanners I have tested, however your mileage may vary - as this article discusses, the use and effectiveness of several brands and models may differ.

I have 3 concerns about RFID chips.

Credit card fraud as previously discussed, is the most obvious and very real threat, though not yet all that prevalent (I would suggest mainly because there are still easier ways to get Credit card data).
Accidental card charges. Although this seems implausible because RFID is supposedly limited to operate within a few inches of the reader, but this has been shown to be an invalid assumtion and an incident of this is discussed on this Security Now podcast (there is a transcription if you prefer, search for "contactless" and you'll go right to the relevant section).
Identity Theft. While this is largely theoretical at present, this is the most concerning case.

This technology is not new, and neither are the attack vectors. With the number of cards and identification documents carrying RFID continuing to grow, and the cost of a potential attack diminishing, we can only expect these types of incidents become increasingly frequent.

Ultimately, you need to decide what you believe your exposure is to this type of risk. While I agree that shielding may still currently be important only to the paranoid among us, I would argue that the cost is minimal. My wallet cost no more than a regular wallet, and (though I agree that the individual sleeves are probably less practical) having the shielding built in makes usage no less convenient.


Windows Server: Import HSM-backed certificate into second server

Your guess about certutil is correct and certutil -repairstore should do the trick. The only requirement is that HSM middleware must be installed on a target machine and target machine can access keys on HSM.

Alternatively, you may try to use CertSetCertificateContextProperty CryptoAPI function and set CERT_KEY_PROV_INFO_PROP_ID property that will include provider name and key container name within provider. This information can be retrieved from machine where private key is recognized.


Why would Gmail ask for the last password I remember?

It looks like GMail knows the hashes of earlier passwords for users. While this is not true in your case, treating it as a special case would cost the developers time, and it would provide attackers a clue about your password habits. It is a good thing that GMail doesn't advertise that you never changed your password.


CRIME attack - If Javascript can be injected on the attacked machine, why not directly sending the cookie to a remove server?

Because the JavaScript will be running from a different origin - the Same Origin Policy will prevent example.org from grabbing the cookies from bank.example.com.

Example.org does not even have to have been compromised. A Man-In-The-Middle attacker (let's call her Mallory) could have intercepted a connection from the victim (let's call him Bob) to the benign site Bob visits over plain http. e.g. http://example.org.

Mallory injects some JavaScript into the responses received from example.org which will run in Bob's browser. Because this JavaScript is received from example.org in the eyes of the browser, this JavaScript cannot access cookies on bank.example.com. Mallory cannot manipulate traffic to bank.example.com because this connection uses https, and all cookies are marked secure and/or HSTS is used.

However, using the CRIME attack, Mallory can use the JavaScript to send requests from example.org to bank.example.com and then monitor the network traffic. With enough traffic sent to bank.example.com, Bob's cookie values can be determined.


I'm assuming there is no relation between these mails and any actual new posts to be reviewed, right? I.e., just be cause you receive one of these mails, there does not need to actually be a new blog post to review?

If this is the case, then I can't see any indication of any relation between these mails and your systems (the WP system). In other words, I can't see any reason to view this as anything other than "regular" spam.

As for the links, the fact that they point to your moderation page does not mean an attacker has access to your site`s internals - the url is probably just a standard url for WP sites, with the root url replaced with your site's address.

Edit: As mentioned in the comments below, the real issue is that the mails appear to be coming from the internal mail-server. This could perhaps indicate a breach (?), but should be verified by checking logs for the mail server to make sure the mails are not just manipulated to look as if they're from your server. If logging is not turned on, change that now, and check the logs next time such a mail is received.

(Sidenote: Why would someone do this? Perhaps as a way to try to bypass any mail-filtering system you have in place, in order to sneak in spam that would otherwise be stopped?)


Padding oracle attacks occur when the attacker is in position to submit encrypted messages and observe the key owner when it tries to decrypt them. The attacker then provides specially crafted messages (based from some piece of the encrypted data that the attacker would love to see decrypted) that decrypt to junk but occasionally decrypt to junk-with-valid-padding; in these cases, the attacker learns some information on the data he is after.

If you are in a context where the defender is a server that computes itself all encryption and decryption, and the encrypted messages cannot be altered by attackers, then the situation explained above does not arise, and padding oracle attacks are irrelevant.

So, in your case, you should be safe from these attacks, provided that indeed malicious people cannot get their hands on your database full of encrypted messages. This raises the question of why you would encrypt the data at all -- normally, you encrypt data to achieve some confidentiality that you could not obtain otherwise. Therefore, encryption on the server makes sense only if attackers are assumed to be able to at least have a look at the database contents. In many situations where attackers can see data, they can also modify the data; and this would bring back the issue of padding oracle attacks, or, more generally, the need for checked integrity.

To put it bluntly, if you encrypt the data but make no effort at maintaining integrity (with a MAC or a nifty authenticated-encryption mode), then you are betting that possible SQL injections attacks on your server will be read-only. It is up to you to decide whether you feel safe enough with that bet.


More details here.
High-end manufacturers use expensive challenge-response schemes (the key sends a request, the car answers with a challenge, and the key sends a reply derived from the challenge with some algorithm).
Even so, such algorithms are proprietary, usually not reviewed, and could well be an example of "rolling your own crypto". There are solutions, but to quote the paper below,

Note, however, that a physical implementation of mathematically secure
ciphers still can be vulnerable to side-channel (typically power
analysis) attacks. Also the key distribution/management, when wrongly
implemented like with the Keeloq's manufacturer key, can introduce a
single point of failure into the commercial cryptosystem. In other
words, the chain is as strong as its weakest element, so the marketing
headword 'employes AES' does by far not mean that the product as whole
is secure.

Cheaper manufacturers use a rolling scheme employing a PRNG. Quite often, the car has a "guard period" after receiving a code, in which it will actively not recognize any code, to avoid bruteforcing. Several of these schemes actually relied on the secrecy of the algorithm, and have been broken (link to theory, practice and source code):

Recently it has been demonstrated how the manufacturer key can be
extracted from a receiver device by a physical side-channel
cryptanalysis and how a particular remote control can be cloned
(either knowing a matching manufacturer key without physical access to
the remote, or without manufacturer key but requiring physical access
to the remote)

Still cheaper manufacturers employ a rolling scheme between N codes, which is vulnerable to replay attacks (you get one code) or "stalking" the garage until you get enough codes.
Another vulnerability of remotes is jamming. You stalk a parking lot and fill the 433 MHz band with noise. Out of every ten people that lock their cars with a remote, nine of them will notice that the car lock didn't actually engage. They'll try again, blaming the batteries on the key fob, and finally lock the car manually (or succeed by transmitting from a few inches, which will further convince them it's the fob battery's fault). Maybe one driver in ten will walk away blissfully unaware that his car was actually left unlocked. You can spot him from afar (he's the one who did not turn back) and rob him blind: no need for sophisticated crypto at all. A 433 MHz transmitter and a white noise generator are enough.
Case in point
Your aftermarket key uses a KeeLoq HCS200. This has been proved and confirmed to be insecure:

KeeLoq remote keyless entry systems are widely used for access control
purposes such as garage openers or car door systems. We present the
first successful differential power analysis attacks on numerous
commercially available products employing KeeLoq code hopping. Our new
techniques combine side-channel cryptanalysis with specific
properties of the KeeLoq algorithm. They allow for efficiently
revealing both the secret key of a remote transmitter and the
manufacturer key stored in a receiver. As a result, a remote control
can be cloned from only ten power traces, allowing for a practical
key recovery in few minutes. After extracting the manufacturer key
once, with similar techniques, we demonstrate how to recover the
secret key of a remote control and replicate it from a distance,
just by eavesdropping on at most two messages. This key-cloning
without physical access to the device has serious real-world
security implications, as the technically challenging part can be
outsourced to specialists. Finally, we mount a denial of service
attack on a KeeLoq access control system. All proposed attacks have
been verified on several commercial KeeLoq products

This is not so much due to a shortcoming in KeeLoq's algorithm but in its practical implementation by the vendor. As such, there are claims that an aftermarket key can actually be fixed:

If your receiver device contains a
specialized hardware KeeLoq decoder, it should be possible to flash
your own randomly selected device code into that chip and matching
remotes, following the instructions in appropriate data sheets. In
this way you circumvent the problem with the learning algorithm and
manufacturer key.

(Along with a bounty of information, the page explains why my old garage remote happened to also open the University gate, as I discovered one sleepy morning when I inadvertently picked up the wrong remote - different on the outside, the two receivers must have been identical on the inside).
Update: buttonless fobs
A variation on the concept of "car remote" is the fob. This is normally a passive device (no batteries). It contains a coil that absorbs the nearby electromagnetic field, and if it is powerful enough it awakens and is able to modulate its own absorption. As a result, whatever is transmitting the electromagnetic driving field will experience a sequence of short power losses. By representing a power loss with a 1 and normality with 0, the driver unit will receive something like 000000000...0001101010101110011. The sequence is usually always the same (very high-end units implement challenge-response) and is unique for every fob.
The same or similar technology is used in some contactless cards and keys.
Since this kind of electromagnetic coupling only happens at very short distances, the fob is considered "safe". It most definitely isn't.
Attack 1: while the driver unit is massive (and usually mounted inside a car), it is possible to install one in a suitcase. Pass within one meter from the victim (whose will awaken, believe itself near the car, and transmit the unlock code). Record the unlock code. Profit.
Attack 2: much more expensive, but effective against USD 100,000 cars, so possibly worth your while. Requires two suitcases connected via Internet (put one Android phone in "personal access point mode" inside each for USD 79,98). The first is the same suitcase as above, but it does not record the unlock code, it transmits it to the other suitcase. A coil in the second suitcase starts siphoning energy from the car transmitter. The following "dialogue" (classical man-in-the-middle attack) ensues in the next few milliseconds:

SUITCASE 1: (absorbing)
CAR: (sleepily)...is there a fob nearby? Who's drinking me energy?
SUITCASE 1: Yes, I'm a fob. I'm your fob.
CAR: let me generate a random unguessable number: 12345. Add yours. What's the answer?
SUITCASE 1 (to suitcase 2): get me the answer to 12345 +.
SUITCASE 2 (to fob): My number is 12345. Add yours. What's the answer?
FOB: It's 73219.
SUITCASE 2 (to suitcase 1): 73219
SUITCASE 1 (to car): It's 73219.
CAR: You're correct. Alarm deactivated, unlocking door. Have a nice day.

UPDATE: and now they did it on CCTV, and the "suitcase" is no larger than a box.
This kind of vulnerability requires a contactless, buttonless fob, and can be protected against by wrapping the fob in electromagnetic shielding. This is not the same thing as aluminum, which protects against radio waves. Magnetic coupling is best shielded by iron foil or special magnetic shielding. Also keeping two identical fobs (of different cars) in close contact will work, if riskier, because by transmitting different codes on the same frequency they're liable to confuse the receiver.


Limit Web App Access To Specific Organizations

IP Spoofing is hard. Very, very hard. You can hardly send a couple bytes on a simple protocol using IP spoofing, let alone requiring an answer/response.

Imagine talking to someone, but only being able to speak to them, and not listen to them. IP Spoofing is like that. You must predict all their answers (on protocol level) and give credible answers without ever receiving anything from them. It's not easy at all.

Your main problem is not that is easy to spoof IP (it is not), but that is easy to attack someone at those companies and use their computers as a proxy. A phishing email will end up with someone there executing a program from someone outside, and create a tunnel between the attacker and your application. Unlikely, but way more likely than a IP spoof.

You can safely use an IP whitelist, and only allow people from that list. Usually companies will have a gateway server (and proxy, and IPS/IDS, and virus scanner all in one) and every request will come from this gateway. So it's simple to create such a list.

You said login/password is not an option. Why?


How is validating an SSL certificate against a CRL not inefficient?

..would be quite slow. Am I missing something in this protocol?

You are right that this is slow and these CRLs can be really large.
Therefore browsers usually don't use CRLs. Instead they use OCSP to check the status of a specific certificate or yet another mechanism like CRLsets.


You could compile with the stack protection flag. https://stackoverflow.com/questions/1629685/when-and-how-to-use-gccs-stack-protection-feature is a similar question that asks how to enable stack protection for executables compiled with GCC.


It should work if you have already done the MitM (Man in the middle) or if you are doing ARP spoofing. I think because of your comments that you already have it done because you are watching victim's packages. The nomenclature you are using for BeEF injection is ok if your attacking pc has the right ip 192.168.43.141 and your BeEF is up and running and is accessible by the victim.

Based on your command line I see that you are using Bettercap 1.x . Bettercap 2.x is quite different and configuration is very different than this. Anyway, Bettercap 1.x works like a charm (better than 2.x in my opinion).

In order to "hook" the victim, the victim should surf through some web pages. This is not perfect, sometimes the victim is hooked and other times it is not for unknown reason. BeEF is a experimental stuff, but it works the most of the times. Be patient and try again.


Block Ciphers never incorporate a salt,  this is usually used for hash functions.  Block Ciphers like AES will use an Initialization Vector to ensure that two identical plaintext inputs will not produce the same cipher text output.

Also note that mode of operation that you choose for your block cipher is very important.  Not all modes use an IV,  for example ECB mode doesn't use an IV.  ECB mode can be unsafe for multi-block data, here is an image encrypted with ECB mode:

Related:
Why is using a Non-Random IV with CBC Mode a vulnerability?


Is Tomcat protecting against CSRF correctly?

You are correct, but this requires a specific and rather unusual behavior of the protected web application to work.

You are referring to the chapter "CSRF token is simply duplicated in a cookie" from the portswigger guide. Let me quote the essential part and highlight the crucial "if":

  In this situation, the attacker can again perform a CSRF attack if the web site contains any cookie setting functionality. Here, the attacker doesn't need to obtain a valid token of their own. They simply invent a token (perhaps in the required format, if that is being checked), leverage the cookie-setting behavior to place their cookie into the victim's browser, and feed their token to the victim in their CSRF attack.

Having a functionality that allows an attacker to set the cookie of another user is very uncommon and the actual use cases for such a functionality are limited. Yes, you can craft an artificial scenario, where this CSRF protection can be circumvented, but you will not find this in many applications in the wild.

Beside this important caveat, your analysis is correct.


Does using a different DNS server prevents DNS leaks?

No. The DNS protocol has no built-in security, it is not encrypted. So your ISP will be able to read the DNS request and response regardless of the public server you choose.

Also, due to Server Name Indication (SNI), HTTPS reveals the target domain name during the TLS handshake. So an attacker wouldn't even need to sniff the DNS traffic in order to learn which domain you're connecting to.

There are however projects that aim to encrypt DNS traffic, for example DNSCrypt. But note that encrypting the DNS traffic still doesn't prevent leaking the domain name via other channels such as SNI. So this doesn't replace a properly configured VPN. From the website:

  Please note that DNSCrypt is not a replacement for a VPN, as it only authenticates DNS traffic, and doesn't prevent "DNS leaks", or third-party DNS resolvers from logging your activity. The TLS protocol, as used in HTTPS and HTTP2, also leaks leaks websites host names in plain text, rendering DNSCrypt useless as a way to hide this information.

  Also some VPN providers claims that they don't leak our DNS queries.
  How do they do that?

They configure your system so that all your DNS queries go through the VPN tunnel to their own DNS server and block traffic to the ISP's DNS. The exact measures necessary depend on you OS. Here are some suggestions on how to configure your system to prevent DNS leaks yourself.


How to store encrypted user's data on a server, decrypt only on the client, and store the key elsewhere?

I cannot encourage your idea of an online backup of the decryption key. As soon as the decryption key leaves the devices controlled by the data owners (the users) the whole effort of client-side-encryption becomes worthless.

A secure place for a decryption key can only be defined by the data owners since only they know the value of the encrypted data. You could offer a key export functionality, give some useful hints and leave it to the users where they will store the keys.


Is Deluge safe to use still when it's not been updated since the first part of 2017?

A simple test is to check exploit-db.com for vulnerabilities in this software:

In the case of deluge 1.3.15, there are two Denial of Service vulnerabilities, but no others listed.  Depending on the requirements of the server you'd like to run this on, that may be an acceptable risk.
To be clear, this is only a limitation if running on Windows or MacOS.  Packages for the newest version, 2.0.3 (2019-06), are available for multiple variants of Linux.


Why is the U2F secret key on yubikeys is not programmable, and how to get a universal backup token?

So while reading the U2F overview I realized that what I want is impossible with the way U2F is designed, because device has a counter which is incremented on every authentication (see section 8.1 of the overview linked above)

So it's not about yubikey in particular, it's about the whole U2F. That's sad to me, I really liked the idea of having a clone which is hard to access even for me. Not being able to use that strategy means that we have to come up with other recovery methods, which will be different for every service (e.g. not every service supports adding multiple U2F tokens), and overall it's anyway less secure than two devices programmed with the same secrets.

Alas.

UPD: actually, I've got an idea. There is an open-source project u2f-zero. So the plan is: get two devices, program them with the same secrets, BUT the backup device should be programmed with a small modification: instead of returning a plain counter from the cryptochip (u2f-zero uses ATECC508A), return something like counter+500000. I'm unlikely to exceed 500000 authentications during the whole life, and it's still a small fraction of the whole counter range anyway (which is 32-bit).

So, if I'm unlucky enough to lose my primary token, I go to the forest, dig out the backup token, and it should work for all of my services right away. There is even one nice side effect: after I use the backup token first time, the primary one will be immediately invalidated because its counter is lower.

UPD2: I wrote a detailed article about it: Reliable, Secure and Universal Backup for U2F Token


Verify S/MIME signature with no certificate included

Aside: you mean openssl smime -verify (or the newer and slightly better openssl cms -verify). openssl verify is a quite different operation which verifies one or more cert(s) against a truststore and optionally a purpose.

From the man page which is on your system if Unixy, or on the web at https://www.openssl.org/docs/manmaster/man1/smime.html (emphasis added):

  -certfile file

  Allows additional certificates to be specified. When signing these will be included with the message. When verifying these will be searched for the signers certificates. The certificates should be in PEM format.


HSTS without auto-upgrading HTTP to HTTPS

If the site sends the HSTS header in the HTTP response, than that is against the RFC.
And the RFC also states, that you "SHOULD" 301 the client to HTTPS and I honestly don't see any reason not to.


Basic authentication portected page accessible without header but not from different IP

I'd guess one of two things is happening here:

The server stored your IP against your account: This way you could login access the resource from your IP even without having to auth everytime. Not a bright idea.
Caching: Your computer or ISP was caching that page (if it was the ISP - badly), and serving you that resource instead of resending the request.

Unlikely case: The server had some caching issues and was serving everyone the resource by mistake. The reason it's probably not working anymore is that - the authorization on your IP expired.


The reason to insert Subject Alternative Names into CA certificate

The subject name, in a certificate, is in the subjectDN field, which is a Distinguished Name: a structure name whose initial goal was to serve as index in the Directory hierarchy (the Directory never existed in practice, but it can be imagined as a giant worldwide LDAP server).

Sometimes, there are some usages which call for notions of identity that do not map well (or at all) to the format of a DN. For instance, if a certificate is to be used for S/MIME, then it is desirable to encode email addresses in certificates, and the standard way to do that is through a Subject Alt Name extension.

As a rule, what matters is what applications will do. You can put a Subject Alt Name extension with arbitrary contents in a CA certificate. However, it is mostly useless since CA certificates are meant to be processed by applications who validate certificate chains -- these applications will ignore the SAN extension in a CA certificate. To put things briefly: the notion of identity used by CA certificates is the one needed for building and validating certificate chains, and that uses the DN (from the subjectDN and issuerDN fields). Thus, SAN extensions are not useful for CA certificates.

(Well, mostly. Theoretically, you could use Name Constraints extensions that apply restrictions on subsequent certificates in the chain, including CA certificates, and these constraints take the SAN into consideration. However, Name Constraints, though standard, suffer from lack of support from usual libraries, so in practice nobody uses them.)

(Still theoretically, it is allowed by standards to have an empty subjectDN, in which case a SAN extension must be present and contain a name of type directoryName, i.e. a DN, and that DN will then be used as if it had been found in the subjectDN field. The purpose of this specific point is unclear; I guess it was included to appease the aesthetic sense of some committee member, somewhere.)


How can I confirm I'm vulnerable to OS X "rootpipe" (CVE-2015-1130)?

Your system is vulnerable since the binary is written. The reason you can't simply copy bash is because the written binary will be started with "real" user id dserodio and "effective" user id root. To switch to real user id root, the binary needs to call setuid(0). I've given a sample C code wrapper for this in the comments of my article you linked.

Another option is to copy /usr/bin/python2.7 to /tmp/py, and start /tmp/py. From there you can do 'import os' and experiment interactively with the python methods os.geteuid(), os.getuid() and os.setuid(0). After os.setuid(0) you can launch a root bash with os.system("/bin/bash").


Could an infected .iso file infect a PC that is running a disc burning or drive imaging program?

That would require the disc writing software being vulnerable, and even if someone really tampered the image, the Raspberry Pi is a lot better target than trying to guess what software you use for burning the disc and how to efficiently take that in advantage.

For that, an attacker would have needed to know you were about to update your Raspberry Pi and that you are burning or downloading that image using a vulnerable software. That is highly unlikely. The effort is way too much compared to all the easier methods to get into your system. (Also, knowing all these prerequisites would mean he already has an access, making the effort unnecessary.)


Securely granting local administrative permissions

Use protected users

When a user logs on to a Windows machine with the NTLM protocol, his hash is stored in memory in the LSASS process. An attacker can dump this memory to steal these credentials.

To overcome this problem, a good solution is forcing Kerberos authentication for administrators and banning the plaintext credentials. You can do this with a mechanism called protected users.

/!\ You will need Windows Server 2012 R2 to create the Protected Users security group and hosts must run Windows 8.1 or later to provide client-side restrictions for Protected Users.

When an account is a protected user's member:

default credential delegation and Windows Digest (plaintext credentials) are not cached even when the Allow delegating default credentials policy is enabled
NTLM hash is not cached
Kerberos configuration is improved
Sign-on offline (the cached logon verifier) is not created

Your first option is the good one

  Create a domain security group (PC Admins), add the required domain
  user accounts, and use Group Policy to add the domain security group
  to the local security group Administrators.

That's exactly what you have to do. And your PC Admins group will be a member of Protected Users group.

Bad options

  Deploy Microsoft LAPS

LAPS automatically manages the rid 500 (local administrator) password on domain joined computers, so the password is:

unique on each managed computer
randomly generated
stored in existing AD infrastructure

However, local administrator accounts should not be used to administrate computers over the network. In an Active Directory, these accounts must be considered as backup accounts, in case of loss of network connection.
So LAPS does not fit your needs.

Moreover, it is vulnerable to credential theft but not lateral movement attacks.

  Implement a system that uses TOTPs and/or only temporarily grants
  administrative permissions as-and-when needed

For same reasons as MFA, it is still vulnerable to credential theft and lateral movement attacks.


since it's known that the NSA infiltrated RSA and made their key generation algorithm weaker

If you know that, then you know wrong. You are confusing two things which have no relation whatsoever:

RSA, the asymmetric cryptographic algorithm.
Dual_EC_DRBG, a PRNG algorithm of poor quality and amenable to backdooring.

RSA can be used for asymmetric encryption and for digital signatures. A PRNG can do neither. A PRNG produces an endless stream of unpredictable bits; this is something that RSA does not do. The two things are really different.

Now what is the source of the confusion ? It is twofold:

An asymmetric cryptographic algorithm uses keys that must be randomly generated at some point; the key generation algorithm requires a stream of random bits to work over, normally supplied by a cryptographically strong PRNG (so potentially Dual_EC_DRBG, or just any other PRNG).
One software vendor who implemented Dual_EC_DRBG and supplied it to its customers was RSA Security. That company is called "RSA" because it was founded by Rivest, Shamir and Adleman, the three researchers that also invented the asymmetric algorithm RSA and named it that way for exactly the same reason. Basically, Rivest is called Rivest when he invents cryptographic algorithms, and he is still called Rivest when he founds companies. Anyway, they sold the company two decades ago.

The bottom-line is that RSA, the asymmetric algorithm, is in no way "backdoored". What can be backdoored is the PRNG used in a specific implementation of the key pair generation algorithm. But if you use Dual_EC_DRBG to generate an ElGamal key pair, then you are equally hosed. Therefore, existence of poor, weak PRNG is in no way a reason to prefer ElGamal over RSA.

(If we want to nitpick, it goes the other way round: the known backdoor in Dual_EC_DRBG is easier to leverage if Dual_EC_DRBG was used to produce an ElGamal key than a RSA key. But in all generality, if your key generation tool uses a deliberately weak PRNG, then you lose. Regardless of the type of key.)

What about key length ? By some freak chance, it so happens that RSA, DSA and ElGamal keys of similar size offer vaguely similar strength (this is pure luck since they rely on distinct kinds of mathematical objects). 1024-bit RSA/DSA/ElGamal keys currently evade our cryptanalytic abilities, but they seem to be within reach of Earth-based technology (if you spend a few hundred millions or billions of dollars in building a dedicated machine and don't mind if it takes 6 months to break a single key). 2048-bit RSA/DSA/ElGamal keys are waaaay beyond what can be done with foreseeable technology. Any key size beyond 2048 bits is the equivalent of buying a red sports car to woo girls.

For your specific case:

The "sign only" options will yield keys usable only for signatures, and not for, say, encrypted emails. If you want a key usage for encryption you will need to use one of the first two options.
In older times, RSA was patented (in the USA) so some implementations supported only DSA and ElGamal. Since the patent expired in 2000, any decent implementation of PGP can now handle it just fine.
DSA signatures are a tad shorter than RSA signatures; ElGamal-based key exchange will use a few more bytes than RSA-based key exchange. We are only talking about a few dozen bytes here; any optimization of that kind will be dwarfed by the loss incurred if you decide to use red oversized keys to assert your manhood.


For the scenario you described you should have the root certificate of the main server sign the child server certificates.  The embedded devices would then store the main server's root certificate.

In this way any child server could connect to an embedded device, and the embedded device would trust it because the certificate chain is trusted.

I would then create an SSL certificate for the main server signed by it's root certificate.  This certificate would be used for when embedded devices are connected to the main server rather than a child server.


How likely/possible is it that the NSA have broken common encryption techniques such as SSL/TLS?

There isn't really a reliable way to know for sure.  What we do know from public knowledge is that algorithms exist that allow for fairly efficient breaking of relative prime based algorithms.  We also know that there are now functioning quantum computers though none with sufficient quality or processing power to run the algorithms.

What we can't know is if more powerful quantum computers exist that could crack them.  Either way, even if such computers do exist, it would be expensive and they would only be able to crack a limited number of cases, so your chances of having your information picked up if protected are most likely minor.

It's also worth noting this is only applicable if you are using your own keys.  If you are talking with a US based company, they could simply go to that company to get the information, no cracking of the encryption keys would be necessary.

If you are using your own key and not doing anything nefarious, it is most likely that the NSA wouldn't use the resources necessary to crack your encryption due to its expense.  This of course rules out any very well hidden back doors that "might" exist, but seeing as no cryptographers have publicized such a problem, it is unlikely (though I suppose not impossible) that such a hole exists.

Update: While links are generally discouraged, since someone asked for them specifically.  The DWave Two is a commercially available (though unable to run Shor's algorithm and may not be truly quantum), functioning quantum computer, though not at sufficient qbits or noise levels to be an issue yet. (But who knows what might be not publicly available based on the state of the art.)  Shor's Algorithm is a well known quantum algorithm for factoring large primes.  This greatly decreases the effectiveness of any relative prime derived asymmetric cryptography algorithm (which most common ones are based on.)  Also Grover's Algorithm should greatly reduce the complexity of cracking symmetric cryptographic algorithms, though a simple increase in bit length will compensate.


Limiting the number of duplicate character types in crunch

I don't know how to do it in crunch, but I just wrote a python script for you that will do it.

from random import shuffle, randint
from sys import argv

charset = ['A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z','0','1','2','3','4','5','6','7','8','8','9']

if __name__ == "__main__":
    if len(argv) < 2:
        print("Error: please use like this:\npython rand_pass.py <number_of_passwords>")
    else:
        num_pass = argv[1]
        passes = []
        counter = 0
        while counter < int(num_pass):
            num_chars = 0
            num_nums = 0
            passwd = ""
            i = 0
            while len(passwd) < 10:
                c = charset[randint(0,len(charset)-1)]
                if num_nums < 6 and c.isnumeric():
                    num_nums += 1
                    passwd += c
                elif num_chars < 6 and not c.isnumeric():
                    num_chars += 1
                    passwd += c
                i += 1
            passes.append(passwd)
            print(passwd)
            counter += 1

Usage:
python file_name_gen_pass.py <number_of_pass_to_generate>

It will generate num_pass passwords randomly via a list shuffle and tracking the number of chars/nums. You can refine it probably to reduce false positives but it if you are just doing some baseline brute force testing this should be sufficient to prove your point to a stakeholder.

Edit:
Wrote a C++ implementation for you to appease everyone :)

#include <iostream>
#include <vector>
#include <random>
#include <string>

const char charset[] = {'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z','0','1','2','3','4','5','6','7','8','8','9'};
int main()
{

    std::cout << "Please enter the number of passwords to generate here: ";
    int num_pass;
    std::cin >> num_pass;
    std::random_device dev;
    std::mt19937_64 rng(dev());
    std::vector<std::string> passwds;
    std::uniform_int_distribution<std::mt19937_64::result_type> dist(0, sizeof(charset) - 1);

    for (int i = 0; i < num_pass; ++i) {
        std::string pass = "";
        int num_nums = 0, num_chars = 0;
        while (pass.length() < 10) {
            char c = charset[dist(rng)];
            if (isdigit(c) && num_nums < 6) {
                pass += c;
                num_nums++;
            }
            else if (isalpha(c) && num_chars < 6) {
                pass += c;
                num_chars++;
            }
        }
        passwds.push_back(pass);
        std::cout << pass << std::endl;
    }
    std::cin.get();
}

Just run it, enter the amount of passwords to generate and it'll fire off. It's pretty fast for small amounts. Just run it like so:
gen_pass.exe > pass.txt

Then open that file and remove the first line and run this command: awk '!seen[$0]++' script.py


Is it possible to modify jQuery client code to call a remote API in an unintended way?

You can't rely on any protection from changes in client side code, you can only do your best to prevent them (ie XSS and CSRF). Anyone can run arbitrary JavaScript code on a page as if it were run by that page itself.

Edit:

As an example, if you're using a modern desktop browser such as Chrome, right-click anywhere on this current page then click on the option to "Inspect" the element. A sub-window should pop up and will highlight the element of your choice. You'll notice that you can directly modify some of the HTML on the page through this interface. Additionally, there will be a console tab (along with other useful debugging tabs). If you go to the console tab, you'll be given a screen where you can directly run JS in the context of the page you're viewing. If you have an element selected in the Elements tab, you can change the background of that element by running the following JS code:

$0.style.background='yellow'

Multiple lines may be used (Shift+Enter) or the contents of an entire JS file may be copied and pasted directly into the page using this console window. You'll probably also notice while using it that it has a feature similar to auto complete. This makes testing and debugging JS code much easier.

It is also technically possible for the request to be simply changed in-transit by an installed browser extension or man-in-the-middle, or the request could even be made using completely different JS code that is injected. So basically the only safe bet is to perform all necessary input sanitation on the server side and only do so additionally on the client-side for the benefit of user experience.

Hopefully this thoroughly answers the question.


What kind of TLS certificate should I use for an internal system?

Self-signed certificates should not be used directly in TLS, but there is nothing wrong in building a private CA. You just provide the root certificate to all internal clients and all will work fine exactly like it would with paid certificates. The only difference is that well known root certificates are pre-loaded in browsers whereas you will have to distribute yours.

openssl contains all what is needed for a CA, but your could try easier interfaces like xca


You have a bit of a chicken and the egg problem. On one hand you need to store the password on the other hand you don't want it to be readable by just anyone. The problem is that you will either rely on an algorithm or another secret key stored somewhere on your system to obfuscate and de-obfuscate your password. This is security through obscurity and will only make it a little bit harder for an attacker to guess the used password.

If you plan on distributing your application, this is not the way to go and you should re-think your strategy (for instance displaying the error to the user and requesting him to email it for you instead).

If you are running the application as a single instance my advice is to just leave the password as is and ensure that the file permissions are set so that only the user as which the script is run can read the file containing the password.


How is Facebook locating me when I use a VPN?

If you are using the Facebook app on your phone then you have already agreed to let the app access location services.

Accessing Facebook through the browser on your phone will ask for your location like this:

  m.facebook.com wants to use your device's location

The IP address will indicate a very rough location like a city or region. The check-in feature uses precise locations provided by the location service of your phone. Location services use GSM base station ID data, WIFI SSIDs, MAC addresses and the GPS location if available. The phone will then query a server on the internet using the GSM and WIFI data in order to get precise location information. It is similar on a computer although computers typically only have WIFI.

So you must have allowed Facebook access to this kind of location data. IP addreses and foreign VPNs have nothing to do with precise location data.

Chrome has started implementing Geolocation API since 2010:

  Wifi based location is only supported on Windows and Mac

Geolocation API by browser:

Chrome uses Google Location Services.
Firefox on Windows uses Google Location Services.
Firefox on Linux uses GPSD - http://catb.org/gpsd/.
Internet Explorer 9+ uses the Microsoft Location Service.
Safari on iOS uses Apple Location Services for iPhone OS 3.2+.
Opera uses Google Location Services.

Source and more details about HTML5 Geolocation API


For this your main concern is making sure that the information is only accessible to the intended recipient; which sounds a lot like what public cryptography / PGP tries to achieve.

Unless you want to see if the target non-user has a PGP key published, or if you can get his certificate to encrypt the email with his public key; I think you'd just need to assume that he/she will be the one reading the email.

Another note is that a user can determine whether this person is really who he/she claims to be, maybe by inserting a secret question that only the recipient know. But that would make it a pain to use.


Is there an online public list of generally trusted certificate authorities?

There is no generally trusted list of CA certificates, i.e. different browsers and OS might trust different CA. But there is a list of CA's trusted by Mozilla which is used in various other projects too. At CA certificates extracted from Mozilla you can download both the current CA certificates as PEM and also a script to extract the certificates from Mozillas trust store.


When connecting laptop to internet through VPN via phone's hotspot, should VPN be active on phone, laptop, or both?

Depends on the device you want it to cover. If you activate it on the phone, it will route your phone and your computer’s traffic through it. If you set it up on your computer it will only route your computer’s traffic. If you activate the VPN on both devices, it may cause interference.

Using a USB cable to share internet is substantially safer than setting up a WiFi hotspot, but the latter can also be safe if you set a strong password, and use strong encryption, such as WPA2.


How to prevent replay attacks without exposing stored password security?

... the data stored on the server (hashed password) is enough to complete the challenge

What you describe is a known problem with digest authentication.

An alternative might be to use digital signatures. In this case the client creates a key pair, keeps the private key and publishes the public key. When the client should authenticate itself the server sends a challenge to the client and the client signs this challenge using its private key and sends the result back to the server. The server can verify that signature using the known public key and thus can be sure that the client owns the secret private key. This secret key gets only stored on the client side.

Basically the same mechanism is used with client certificates (mutual authentication) in TLS. And TLS also adds protection against man in the middle attacks and against sniffing or modifying the traffic. So it is probably better to just use TLS with client certificates instead of implementing this by your own.


Approaches to cracking an encrypted zip file

A few suggestions:

Try building a dictionary based on all strings you can find on the system.
Check that the ZIP file really is encrypted, and not just using a dummy header.
Make sure the header is not corrupt, or a cracking tool may fail even if it has the right key.
It's possible that the key is hidden somewhere, and you have to find it to get that flag.
Depending on the level of access you have, the key might be in memory.

Without more information about the specific task, there's really not much anyone can do to help.


Received email from ISP saying one of my devices has malware

Can an ISP really detect this?

The ISP can see all data your systems exchange with the internet (but not the plain text from encrypted data). Based on this he can detect botnets which often show typical behavior.

  Should I action on this and what to do?

Yes, you should action on this since there seems to be malware in your network which is used to disturb other systems on the internet (sending spam mails, DDoS attacks, used as VPN to hide malicious activity and others) and which might also affect your internal network (infect computers, steal data, take data as ransom ...).

If you don't fix the problem you might also risk that the ISP restricts your network or even completely disconnects you from the internet (depending on the terms of service).

Based on the information you've provided it is impossible to say what exactly the problem is though. It might be that your laptop is infected (Antivirus do not offer 100% protection) or that one of your phones or that the router itself. It might also be other devices in your network you are not really aware of, like a TV, printer, IP camera or other IoT devices. And it might be also caused by software you have knowingly installed yourself, but which has a hidden malicious functionality you are not aware of.

The links they provided in the mail seem to be fine so that you can follow these for more information and for the offered botnet removal tool. But if you are in doubt if the mail really originated by your ISP please contact the ISP - it is impossible for us to see based on the information provided what the real origin of the mail is.