Why is ECC more vulnerable than RSA in a post-quantum world?

The current challenge in building a quantum computer is to aggregate enough "qubits", entangled together at a quantum level for long enough. To break a 1024-bit RSA modulus, you need a quantum computer with 1024 qubits. To break a 160-bit elliptic curve, which has a "similar strength" (with regards to classical computers), you need something like 320 qubits. It is not that elliptic curves are intrinsically weaker; on the contrary, they still seem somewhat stronger than RSA for the same "size". Rather, the strength ratio for a given size is not the same when considering classical computers versus quantum computers.


It depends on what you mean by "no sanity check" is performed on the input parameter. If this means that the application takes the parameter, concatenates it into a SQL query and sends it to the database, the application is vulnerable for sure. Only blocking * is not enough to protect against SQL injection.

Never assume the site is safe, if you have doubts about it! Even if you are not able to create a working exploit, you should recommend implementing database queries using prepared statements (or similar mechanisms). It is considered best practice and there is usually no reason not to use them.


What are the risks in returning digitally signed payloads over an insecure HTTP connection?

It depends on the requirements.

If you send public data on unauthenticated connections, and the only requirement is that the recipient can make sure that the data has not been tampered, then digital signature on the data is enough.

The pilars of security are Confidentiality, Integrity and Availability. Encryption helps for the C part, signature for the I part. As you do not use any encryption, nothing protect confidentiality, so you should not authenticate clients on such a system (the password could be intercepted), nor send confidential data.

An example use case could be the delivery of revocation lists.


Why would DB with URL access be less secured than without such access?

It's not necessarily inherently less secure, just often practically.

In the first place, adding more software adds more things you have to secure.  Phpmyadmin has had its share of vulnerabilities, and now you have to worry about those in addition to the MySQL ones you had to worry about before.

One fairly standard thing to do with MySQL is to limit the privileges of accounts to only accept logins from a small whitelist of IPs (for a small app, that can be just localhost).  But as soon as you install Phpmyadmin, you've provided a proxy of sorts for MySQL access from anywhere - unless you take extra steps to lock that down as well.

Web interfaces like this can be set up securely, but they just add another administrative tool that you need to secure; if you learn how to use the commandline mysql over ssh, then you can eliminate one entry point for an attacker.


If the connection uses proxies which are correctly implemented, discovering the ip through http or tcp can be difficult. You may have some luck in getting closer to the ip using DNS instead.
for
If you generate the page dynamically to contain an image located at a domain that you control, e.g.

<img src="http://123123.deanonymize.mydomain.com"/>

the browser will perform a lookup on 123123.deanonymize.mydomain.com. This will result in a recursive DNS-query that eventually will reach your dns for mydomain.com. The query will originate from whatever dns the victim is using, typically the ISP. So, while it will not give you the exact IP, it may point you in a general direction.

AFAIK, this method works even if the victim uses TOR in vanilla mode, see https://trac.torproject.org/projects/tor/wiki/doc/PreventingDnsLeaksInTor for more information.

Another way may be to use a java-applet to figure out the IP at the client side, but I'm not up-to-date on what limits are in place for that nowadays.


How smart is storing passwords and usernames in files?

The most PHP applications perform login by querying a database to validate the user-provided credentials. Databases have many advantages over plain-text files. Though the big issue here is not only the security of the database itself (of course you better use a strong password to access your database) but the security of your application in general.

That means that if you prefer/insist on using PHP for user-validation/registration etc... you better follow good and tested practices rather than re-inventing the wheel, not only for the validation but for every part of the application (since a seemingly minor bug can lead to full application compromise and database leakage). Now, as is widely known no system is 100% secure, so even if a security-breach occur for some reason you don't want all those user-credentials to be leaked in public. So the best way to avoid that is to save the hash (pick a cryptographically strong hash function like bcrypt etc...) of those creds rather than save them in plain text.

Finally, it's important to mention that there are web-frameworks (like Django, Ruby on Rails etc...) that by design offer a lot of security features out of the box (in my opinion PHP lacks in this part) while in PHP you have to code "carefully" and follow good practices.


Should I take care when entering incorrect passwords in untrustworthy websites?

I have the problem that I usually use 4 passwords that I use quite often.

All of your other trouble stems from this. If you're concerned about security (and you should be) then stop it.

  Is this a serious security concern for me?

Most definitely YES.

Whether this particular site discloses your information or whether one of your "important" sites gets hacked, this technique of yours can seriously bite you. Hackers expect you to re-use passwords on other sites, so they will definitely be looking for this behavior and definitely will try to exploit it. Your plan of having one password for "important" sites and one for "unimportant" sites is also common, so hackers will expect this as well.

You need to use different, unique passwords for all the sites you care about. One password used at paypal and nowhere else, one for each email account and nowhere else, etc.

I'd strongly recommend using a tool like KeePass or LastPass. Both rely on client-side encryption, so no secrets are ever visible to any third party.


Duress capability to clear hard drive encryption keys making disk unrecoverable in Windows?

You can use the Clear-Tpm Powershell commandlet to do this programmatically, rather than using the TPM management control snap-in.

You could also use ATA Secure Erase on any modern SSD. This tutorial shows you how to trigger an ATA secure erase command on Linux. For Windows you'd need to write your own code to send the ATA commands to the disk - you'll need to consult the ATA command reference (section 1.8 explains how to use SECURE ERASE) and do some DeviceIoControl calls to execute those commands.


Is it possible to bypass 2FA and access bank account in this system?

Your experiences are in no way universal. It's possible that many banks in your country do authentication that way, but it's not the case in the USA. Your question title makes it sound like you're talking about online banking (which usually just uses conventional username+password credentials, with sometimes the option of a second factor, once you're past account creation), but I assume you actually mean "Is it possible to pay with a card online without an OTP"?

In a strict sense, the answer is obviously yes; I can both sign into at least one of my banks or pay from several of my cards (though my usual one notifies me about certain payments) without any kind of OTP being involved at any step.

With all that said, let's look at the actual situation of your bank, and its 2FA implementation. There's a few things that need to be confirmed:

Is the OTP generated securely (that is, not predictable in any way)?
Is the OTP long enough that you can't just guess a bunch of times and brute-force it?
Does the OTP have brute-forcing protection, so you can't just set a script to trying for a day and get it anyhow?

Beyond ways that an attacker might bypass the OTP, they could also just get it sent to them. Phone numbers in general are not good for 2FA; it's too easy to maliciously port somebody's number (the carriers don't care). That's assuming you can't just steal the device and see the OTP above the lock screen (if a lock code is even set) or, if necessary, remove the SIM and put it in your own device. TOTP apps (such as Google Authenticator) plus a lock code, or a hardware token (such as a Yubikey) are much more secure.

Finally, consider that the system you described isn't actually two-factor authentication. Both factors are conventionally going to be a "thing you have", and while they're different things, they're both commonly carried in a purse or pocket, and sometimes are carried together (phone cases that also have slots for payment cards are somewhat popular around here). Yes, the phone might not be usable without its lock code or SIM security code (either of which are a "thing you know"), and the payment card details could be memorized rather than carrying the card (turning it into a "thing you know"), but the scheme overall still doesn't really fit the strict definition of 2FA.


Does it make sense to implement OAuth when no 3rd party is involved

While it isn't necessary to have the complexity of OAuth when authenticating against your own system (because you can share your actual user account data) if you want to provide that level of isolation to the user server, then using OAuth does still afford you advantages.  At that point you would simply be implementing a stand alone OAuth provider which your various services could use as a single sign on across your system.

You could also then allow users to use their profile as a single sign on for other services if you so desired by making the OAuth account usable by other sites.


How well can Tor + VPN secure my anonymity on the internet?

No. Just installing Tor and a VPN does not make you safe. Even if Tor was resilient against attack and VPN was secure and trustworthy, they would only mask your IP. Many people using Tor were caught, not because Tor was defeated, but because they made a mistake. They logged in to a social network or used it on a school computer or had cookies in their browsers or allowed javascript/adobe flash player to reveal their IP and many more. Being completely anonymous against the government of the United States is an open problem. Even if there was a way, there would be no way to show, if it really works or not.


It is a preprocessor to Snort and can't be used in anything but Snort unless you, essentially rewrite Snort's decoder and preprocessor structure. But why would you do that when you can just use Snort?


How to use a token to differentiate between a valid logged in user and an attack?

When you open a new tab and access linkedin the copkie which contains the session is automatically transmitted to linkedin. Linkedin checks the session and if it is valid you are logged in.

A CSRF is usually only required for modifying requests, e.g. if you update some of your account settings or something like that. When the page with the form is transmitted to your browser linkedin adds a hidden field with the CSRF token into the form. If you submit the form the session cookie and the CSRF token are send to linkedin. Linkedin checks the session and if it is valid it checks the CSRF token. If the token is missing the request should be ommitted.


What's the use of challenge password in build-key-server and build-key from Easy-RSA?

"Challenge password" is an obscure and usually useless feature. -> Leave empty.
If your CA allows this, then the Challenge Password will be required of anyone who tries to get the cert revoked. -- But from what I understand there are few (or none?) CAs that actually use this. (Please leave a comment if you know otherwise.) So leave it empty if you're unsure.
What's the intended use of a "Challenge Password"?
As far as I understand it the idea is this:
If you have a rogue admin who has access to the cert and key then that admin could revoke the cert and DOS you.
But if you have a CA that will challenge the rogue admin to supply the "Challenge Password", then the rogue admin may not have that password and then you're safe from that DOS.
(The CP is NOT included in either cert or key. Only in the CSR. And you don't need the CSR for daily operations, so presumably operations personnel might not come into contact with the CSR file and therefore not know the Challenge Password.) (But bear in mind that you still have to worry about a rogue admin who has your cert/key. A lot. So from my understanding you gain exactly nothing from having a "challenge password" in the first place. -- Correct me if I'm wrong. I've got the feeling I'm missing some essential idea here. -- Maybe this is meant to allow revocation by somebody holding just the certificate and the password but NOT the private key.)
Further reading
The (too short) official definition is here: RFC 2985: PKCS #9: Selected Object Classes and Attribute Types Version 2.0, Section 5.4.1: Challenge password
The question comes up regularly:

https://superuser.com/questions/376179/confusion-with-pem-pass-phrase-and-challenge-password
https://serverfault.com/questions/266232/what-is-a-challenge-password

Further source:

Randall Perry, "OpenSSL-Users" mailing list, 2014-05-22, Re: CSR challenge password: What's the point?


How would you store a 4 digit pin code securely in the database?

If you are worried about a "leaked database" scenario (rather than the online cracking vector, which can be mitigated by per-user, per-IP, per-site rate-limiting and lockout) then you are right that hashing is not enough.

Even using the most complex sequence of hashes & salting e.g. bcrypt(pbkdf2(sha256(pin),salt1),salt2) you are still going to be vulnerable to anyone who can see (e.g. from a source code/docs leak) what algorithms are used and who can find your salts (normally stored in the same DB/table) -- they can just run the same series of hashes, and even if it takes a minute for each that's only 7 days to try them all. So you would basically be relying on security-by-obscurity.

In this case it would be worth encrypting the password hashes with a secret key (which can be kept separately from the source code, only accessible to trusted "production security operations" users, never re-used in pre-prod environments, changed regularly, etc.). That secret key will need to be present on the server which validates/updates PIN codes, but it can be kept separately from the user/pin database (e.g. in an encrypted config file), which means that Little Bobby Tables won't automatically get access to it when he snarfs the whole of T_USERS via SQL injection, or when someone grabs a DVD with a DB backup on it from your sysadmin's desk.

[Normally encrypting the hashes is not recommended, because its better to use a secure hash, good salt and strong password/phrases, and encrypting the hashes can give a false sense of security. But if you can't have strong passwords then there aren't many other options -- beggars can't be choosers...]

You could combine the PIN with a password -- but in that case why bother with the PIN at all? Just require a strong alphanumeric password. (If the PIN is used in combination with a smartcard or token or similar, of course, then it can add to the overall security.)

We could use a bigger (6/8 digit) PIN. Its not feasible to make a digit-only PIN be secure from brute force: at 1B hashes per second, we'd need 16 or more digits to push the brute force time beyond a year. But adding a few more digits might be enough to make the online attack easier to detect and block -- with only 10K combinations its going to be hard to set "slow-force" thresholds low enough to make an attack infeasible. Unfortunately, you have likely have physical constraints (hardware selection) which preclude longer PINs.


One way Hashing: Salts' randomness or Globally uniqueness

It seems as though you understand that hashing is a one-way cryptographic function. A string hashed without a salt using a specific algorithm will always produce the same result. Hashes are not meant to be decrypted, they are meant to be compared to.

A string of password hashed in MD5 without a salt will always be 5f4dcc3b5aa765d61d8327deb882cf99. When the user enters their password to enter the super secret website, their password value (in this case password) is hashed, and compared to the hash that exists in the "users" table for that user. If the two hashes match then access is granted.

Because we know that a string's hash will always be the same without a salt, massive amount of strings hashes can be pre-computed in to what are called Rainbow tables. If a database gets compromised and no salt has been used, it is often trivial (depending on the algorithm and complexity of the password) to determine the password by comparing it to a hash that exists in the rainbow table.

By adding a randomly generating salt to the string and then hashing it, you make things exponentially harder to attack the hash with pre-computed rainbow tables. To do so, the attacker would have to guess what the salt would be, then generate their rainbow tables again. This becomes very inefficient and removes this as a viable option for password compromise.

So if our web application for my user-record has a salt of Sup3rS3cr3tS@l7, when I log in or change my password that salt will be appended to the password string. The value that is then hashed is Sup3rS3cr3tS@l7password and the MD5 hash becomes 8e28474b10084728115870bcae270298

Salts do NOT need to be used globally - a salt can be randomly generated at account creation and stored in a column in the users table.

DISCLAIMER Don't use MD5, as this was purely for demonstration purposes.


Is OATH TOTP and / or Google Authenticator vulnerable if an attacker has (N) previous codes?

The TOTP specification points, for the security analysis, to HOTP. HOTP uses a counter, shared by both parties, and "resynchronized" every time a successful authentication occurs; TOTP replaces that counter with knowledge of the current time, which is also a shared value. As such, almost all the security analysis of HOTP applies to TOTP.

The security analysis of HOTP uses the formal tools and notations of cryptography, but boils down to the following assumption:

Let T denotes the time to perform one computation of H.  Then if A is
any adversary with running time at most t and making at most p oracle
queries,

                   Adv(A) <= (t/T)/2^k + p^2/2^n

In practice, this assumption means that H is very secure as PRF.

The important word here is PRF: it means that the "H" function (HMAC/SHA-1) behaves, in the view of the attacker (who does not know the key) like a function chosen "at random" among all possible functions. We give the attacker access to an "oracle", which is a machine which knows the key, and computes HMAC/SHA-1 over inputs chosen by the attacker; the attacker can send p such queries. The expression above means that even under these conditions, the probability that the attacker successfully predicts, after all his queries, the output for one extra input (that he did not send to the oracle), is still very low (the "advantage" is what extra success probability the attacker has over pure luck).

Right now, it seems that HMAC/SHA-1 behaves as a PRF. Nobody has found any indication to the contrary. This holds even in the face of the known structural weaknesses which seem to allow (theoretically) some computing SHA-1 collisions.

From this assumption, the security proof of HOTP (as exposed in RFC 4226) establishes the following result:

Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m).  Let B
be any adversary attacking HOTP using v verification oracle queries,
a <= 2^c - s authenticator oracle queries, and running time t.  Let T
denote the time to perform one computation of H.  If Assumption 1 is
true, then

     Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n

In practice, the (t/T)2^-k + ((sv + a)^2)2^-n term is much smaller
than the sv(q + 1)/2^n term, so that the above says that for all
practical purposes the success rate of an adversary attacking HOTP is
sv(q + 1)/2^n, just as for HOTP-IDEAL, meaning the HOTP algorithm is
in practice essentially as good as its idealized counterpart.

This last paragraph is what you are after: under the assumption that HMAC/SHA-1 is a PRF, it is proven that giving access to a lot of previous one-time passwords does not given any advantage to the attacker for guessing the next one, at least no more that what he would get out of an "ideal" version of HOTP in which the one-time passwords are obtained through pure unpredictable magic.

Summary: No need to worry. Resistance of HOTP (and TOTP) to the situation where many previous one-time passwords have been recorded is part of the security model of HOTP, and it has been specifically shielded against such an occurrence. The shield here relies on an assumption of security on HMAC/SHA-1, which, while not proven, is about as good as these things can get (notably because it is quite possible that the fact that a function family is a PRF might be mathematically impossible to prove; see this for more on that subject).


Does the Web Cryptography API prevent a bad server from slurping cleartext?

It doesn't. That's excusable, because it cannot.

The server sends the code. If the server is hostile or compromised, then the code sent by the server may be malicious. It doesn't matter what the API does: the code sent by the server can avoid using it, or otherwise send all the data in cleartext to the server.

The reason to have cryptographic primitives that don't expose keys is mostly to protect against a server that's trustworthy, but that delivers code that can be partially exploited. If the attacker can arrange to run arbitrary Javascript code in your browser, you've lost. If the attacker is restricted in certain ways, e.g. if can only extract certain information or can only infect certain pages, then adding protections such as non-exposed keys makes it harder for the attacker to obtain the data they want.


Preparing to change over to new GPG-key - what to do with my old ones?

Thanks for the comment response, that helped a little bit.

These are general recommendations, YMMV and you can always tweak them to your own needs.  This is just a good place to start and things to keep in mind, but proper security posture is an individual endeavor, not a one-for-all thing.

First off, don't sign your new key with your old one.  If you haven't used the old key before then it doesn't have an existing chain of trust, so using it to sign something isn't adding much (if any) weight to the identity assertion.  And once you revoke the old key (our next step) then it will add zero weight to any claim made.  This is only useful if your old key has been previously used as it helps assure other folks that the new key isn't a scam (they trusted the old key, which is telling them to trust [signing] the new one)

Note: whenever I say "key" I mean the same as what you seem to be calling "main key".  I will specify "sub-key" when talking about a use-specific descendant of the "key".

Secondly, revoke your old key -- make sure to put the reasons in the revocation (reason is either "no longer used" or "superseded"), and put in a description that includes your new key ID "Key has been replaced for logistic reasons, new KeyID is 12BC-A29D".  Once you have the revocation certificate created, publish it to the public key servers (really, just send it to MIT, it'll make it from there).  This takes care of turning off the old key; you've revoked it and listed it as unused in the public servers (with a hint and how to find/validate your new key).  At this point you can totally forget about your old key.

Always Remember :: When removing keys from public key servers you MUST issue a revocation certificate and submit that to the server.  Even if some servers include a "delete this key" field, they're lying at it won't fully delete it.  The only way to truly cancel a previously published key is to issue a revoke.

Now, on to your new key.

You've got a decent start here.  The normal recommendations are these:

Make your key time-limited.

Normally this results in people making 1-year (I use 13 months) expiration dates on their keys.  Then they will perform maintenance yearly, during which they'll extend the expiration and send the updated key to the public servers.  This provides protection against lost/unused keys, they'll automatically expire unless you take a regular action to refresh them.

Make a revocation certificate up front

This is in case of loss. The general recommendation is to have either a "no reason" or "key compromised" revocation certificate made just after you make the new key (before you submit it to public servers even).  Then to print this certificate (I highly recommend an OCR font) and throw it in your physical safe keeping location (a safe at home, a bank deposit box, where ever you'd keep important & hard-to replace documents like original birth certificates or original social security cards and passports).  Should something happen that causes you to lose control of the key, you will still have a way of revoking it; that makes it a really good just in case item.

Don't worry yourself about the sub-keys

I'm not saying don't use sub-keys.  I'm just saying that you are using a well made PGP implementation (I have GPG on all my machines, regardless of OS) that handles all of that for you.  You raise several points regarding Sub-Key IDs or sub-key attestation and management, and while those are things that we have to worry about on the design and implementation side they aren't things an end-user need to fret over.  The GPG software has created a Key Pair for you, and (at your instruction) created a set of managed sub-keys for specific purposes.  When you use GPG to sign something, it will automatically use the proper sub-key; same for encryption & authentication (if you create an auth key and have something that'll use it).  If you want to dive into how PGP works, that is a whole deeper pond, but for just using it all you need to worry about is "your key" (what you seem to be referring to as the master) in GPG -- the software will handle the rest from there.

Your key is you

That PGP key is now leveraged as an identity source.  People can verify something was done by you simply by checking a signature.  Don't muddy up the waters by creating entirely separate keys.  If you need, you can add more User-IDs to the existing key (useful if you get a new email address, or if you need to attest to a new persona you carry).  If you want to sign something, use the signing sub-key of your key; that's the whole reason for sub keys.  If you ever get something that was handled by a PGP key with the master ID of 6742F54F27B19AC2 then you know it was from me.  The key is you, don't fragment your identity into multiple keys, but also protect your key just as surly as you'd protect your birth certificate and passport.  Your protection can vary from adding a passcode to the PGP key (GPG should have prompted you to create one, but you could have chosen not to) up to offloading the private-key component onto a smartcard (I do this, with a YubiKey) to give you that multi-factor and physical possession safety net; this is very much one of the "what is best for you personally" items.

TLDR -- Don't sign the new key with the old one.  Issue a revocation certificate for the old key and submit it to the public servers.  Make sure your new key has an expiration date, you can make it not-to-far-out and just extend it regularly.  Don't worry about manually managing which sub-key to use.  Don't create 2nd (or 3rd) keys for different purposes.  Do protect your key as if it was enough information to steal your identity (because it is).


Can two locations in the same city at the same time have the same IP adress?

Details here depend on your specific ISP setup, but it might well be that multiple customers share the same public IP address. This is called NAT or in case of ISP CG-NAT (carrier grade NAT). It is pretty common for ISP in mobile networks but is also not uncommon with cable or DSL. The main reason is that there is a shortage of public IPv4 addresses so ISP often own less public IPv4 addresses than they have customers.
If this is the case in your specific situation depends on your ISP - thus ask the ISP.
Note that even with one public IP per customer it might well be that these change over time and thus a different customer is assigned an IP one had before. If the ISP assigns a fixed public IP to a customer is again specific to ISP and kind of contract - thus check with your ISP or read the contract.

Should I just change my ISP and get a new IP adress?

Each ISP has a pool of IPv4 they can use and different ISP use different pools. It does not change the general problem though, i.e. that it might be that the IPv4 is shared with others. Ask the new ISP for details.

Is this the ISP's fault for giving two households the same IP?

Unless a fixed public IP address is explicitly mentioned in the contract their is usually no obligation to assign a fixed IP address to a customer.

Could I be blamed for anything they do online?

Blaming somebody is often done without fully understanding things. This does not mean that they are right nor does this mean that this can result in legal actions against you.


ASUS RT-AC68 login page is redirecting to some Amazonaws page?

Your router is just glitchy.

"router.asus.com" returns a 301 redirect to "ec2-54-202-251-7.us-west-2.compute.amazonaws.com/find/router.html" (at least for me; it may redirect to other Amazon datacenters for people in other locations), a website hosted on Amazon's cloud.

The website itself appears to attempt to find your router's IP address by making connections to 50-someodd domains such as ""rt-n10pv2" or "findasus.local", and counting on the router's DNS resolver to intercept the request.  This is rather fragile, as any change to the default DNS settings can break it.


How would you explain CSRF token to a newbie? How is it safer than cookie based approach?

I think you might be misunderstanding a little. Injecting malicious data into scripts isn't really relevant to CSRF. Its sometimes used in conjunction with it, but that would more accurately describe XSS. A CSRF token wouldn't prevent something like this.

A CSRF vulnerability is when you are able to trick a user to perform some action that only they are authorized to perform, without their knowledge.

Lets say you are logged in to your banking website and there is a form to transfer money to somebody where you enter the persons account number and the amount you want to send them and then push submit.

That form will be POSTed to a particular url and the request will look something like this.

POST /transfer

Host: bankingsite.com

Cookie: xxxxxxxxx

Sendto=12345678&amount=1000

Now the application will look at your cookie to determine which account to pull the money from.

Now imagine on my website I create a form that posts to bankingsite.com/transfer that sends 1000 to my personal account and I overlay it with a "Click here to win a free iPad"

Now if you were to click on it, it would generate the same exact post request if you were logged into the banking site because your browser would determine that you have an active session with bankingsite.com and it would add your session cookie to the request.

Bankingsite.com has no idea that you didnt fill out that form on their website. They think it is a legitimate request and they proceed to transfer your money to me without your knowledge.

The problem here is that the session cookie is sent along with the request. A CSRF token is different than a session cookie because the CSRF token wont be sent along just because the destination domain matches.

So lets say you code up your banking application to send a csrf token back using a custom header when the user loads the transfer money form. Then when the user submits the transfer form, you pass along the csrf token as a hidden field and validate it on the backend before you authorize the transaction.

Now you have just made it impossible to execute the attack scenario above. If somebody clicked on that free ipad button, the request would contain the cookie and post data, but no valid csrf token because the attacker doesn't have access to it and the request would be denied.


Credential theft by browser conferencing software?

it will be much easier for you to switch to another desktop (all modern OS support multiple desktop).
and start a clean session there when you are on a conf call.
this way you will not accidentally switch to another app/window that can reveal confidential information.


Your file input has probably affected the value of EDI in some way, or caused control flow to take a path it would not otherwise take.  I would normally look a few instructions back and try to determine how EDI came to have that value, or perhaps break at the beginning of the function where the crash occurs and step through it (or a few functions further up the stack).

Another relatively new option would be to use WinDbg's time travel debugging feature!  You can let it run in the debugger until the crash, then step backwards in execution to figure out how you arrived at the crash.

Obviously, if you have source, you'll be much better off looking at it that way in parallel to figure out what happened.


What is the security risk with weak references?

The linked article is speaking in very general terms because it is talking about a generic implementation of weak referencing in garbage collectors. They are stating the potential confidentiality issues because, at the abstract level they're working on, the specific types of side-channel attack which may be presented are entirely up to individual implementations.

For a start, it's important to understand what weak references do.

In a garbage collected system, the GC is tasked with clearing up objects which are no longer in use by the program. The detection of whether an object is in use is often implemented via reference counting, in which the program stores reference metadata alongside the object to aid the GC, incrementing and decrementing the reference counter as and when consuming objects and scopes enter and exceed their lifetimes. The traditional types of reference are usually called strong references.

A downside to strong referencing is that you can't observe an object without preventing the GC from disposing of it. For example, you may want to provide internal debug commands which display information about allocated objects within a collection, without creating a strong reference which causes the object to permanently sit on the heap until your program exits. This is where weak references are useful - they indicate to the GC that the program is still interested in the object, but that it is not strictly necessary for the object to remain. More importantly, they implement a procedure by which the application can check (or be notified) whether the GC has removed the object, and most likely some locking mechanisms which ensure that the GC cannot remove the object while executing code is directly operating upon the object.

The specific implementation of a weak reference falls down to the general memory architecture and type paradigms of the language, and the GC itself is often considered a black-box. Relying upon specific behaviour of the GC, outside of documented concrete behaviour, is poor practice for user code. However, as an attacker in a specific scenario, you have the benefit of being able to study the internals of the specific implementation in use and use them to your advantage.

As a theoretical example, let's say there's a GC whose disposal process for weakly referenced objects works as follows:

Is there memory pressure?
Have you disposed all objects with zero references, weak or otherwise?
Is there still memory pressure?
Prioritise objects which have not been accessed for a long time.
Prioritise objects which have fewer weak references.
Prioritise objects which are larger in size.

Now, if an attacker can detect that a specific object has been disposed (some GCs allow for user-defined finalisation code, which may leak the event externally in some way) then they would know that there was memory pressure, other objects may well have been cleared off the heap too, the object they know was disposed probably wasn't accessed for a while, it probably only had one or two weak references, and it may be larger than others on the heap.

This could be very useful information for a range of side-channel attacks, or even for coordinating other attack types such as timing attacks. It could also be useful when understood in the context of a specific application, e.g. if a weakly referenced object is only continually accessed while the user is present at the system, its disposal may well indicate that the user is not at their station.

The important thing to keep in mind, here, is that the vulnerabilities are theoretical, and the article is simply trying to get GC implementers to keep these issues in mind when designing weak referencing functionality.


Preventing firmware hacking with read only OS

This won't work. Malware from, say, the Internet can operate solely in RAM, then tamper with the firmware, bypassing the write-protection on the disk.

In fact, this is used frequently because traditional anti-virus solutions only monitor disk writes and reads. By remaining only in RAM, malware can reduce the risk of detection.

More advanced threats will write itself to firmware, where anti-virus doesn't scan, so it can remain on the system while being very difficult to detect. Therefore, the malware will move between firmware and RAM, without writing to disk or being removed if the computer is shut down or the disk is wiped.

See, for example, this Wikipedia article on fileless malware.


Passing generated keys to another process

Your problem is transmission of a secret piece of data; that the piece of data is a cryptographic key is mostly irrelevant (it just means that it is really secret). Thus, what you want boils down to making sure of who gets it.

Since you talk about processes, I assume you are talking about a transfer within a single machine. "Who" then depends on the security model of your operating system. Common OS use a model with "accounts", each process being linked to one such accounts and having the privileges associated with that account. There is one "master account" (root on Unix, Administrator on Windows) which has all the rights, and you cannot defend against that.

Given that, let's see your proposals:

"As a return value": this cannot apply. A "return value" is what is sent by a function to its caller within a single process. In your case, there are two processes.
"Written to a file": I would advise against it. A file leaves traces. Once the data has made it to a physical medium, then you must maintain the access controls to this medium forever. It seems best to keep the whole thing in RAM as much as possible.
"Encryption and a socket": encryption is fine as long as you already have keys distributed, so you are solving the chicken-and-egg problem by stating that you already have another egg/chicken, which does not solve things. On the other hand, for a socket which is local to a machine, you may have ways to make sure that the process at the other end of the socket is owned by the expected account; it is called getpeereid() on Unix-like systems.
"Inter-Process Communications": this is a generic name for ways for two processes to talk to each other, and it includes local sockets. The choice is large (and very OS-dependent); the important point being that you can obtain the effective user ID of the other process, as getpeereid() does.

On a Unix-like system, you can use a local socket, either anonymous (created with socketpair()) or named (a "Unix domain socket", as it is); an anonymous socket pair is possible if your two processes have a father-son relationship which allowed them to exchange file descriptors. You can also use pipes, there again anonymous, or through a file-based rendez-vous point (a "named pipe"), in which the filesystem contains the meeting area, but the data remains purely in RAM. SysV shared memory, mmap() with MAP_SHARED over /dev/zero,... there are many possibilities, each with its own methods for access controls.

On a Windows system, the possibilities are even more varied, due to the long history of successive layers of inventiveness in this OS (they never drop anything -- they are good at backward compatibility -- but they also redesign whole subsystems every two years, so the IPC methods tend to accumulate; back in 2003, I counted no less than 9 methods for that, and I am sure there are now others).


If I understand the setup correctly, on the one hand you authenticate to the application to retrieve some data from it and then, independently, a Windows share is accessed (probably triggered by the application).

In that case the user who is logged in can access the data without the application anyway. He may not know where to look for the data but if the rights are set up correctly on the share it is more a way to hide from him what he has access to than to prevent someone else to access it.

If the above assumptions are correct there are no obvious security issues with this dual access.


Is hiding my Java desktop app inside a VM the best way to protect my Java source code?

This question is bordering on product recommendation request / opinion, but I'll try to answer the parts that are on-topic.

First off, good reverse-engineers are good. With enough skill and time, java source, java bytecode, c++ source, and native assembly are all equivalent in terms of showing an attacker how your software works.
Building on @Zymus's comment, you're starting with conflicting requirements, you want to:

Give out your source code to people / machines that you don't trust, but
You don't want it to be reverse-engineerable.

If the computer they are sitting at is able to understand and run your code, then (with enough effort) so can the human. Full Stop.
When your starting point is "I want to give them my code, but I don't want to give them my code", I'm not surprised that you can't find a solution.

Directly answering your questions:

can an attacker read my Java code from inside a VDI disk image ?

Well, can the computer read (and run) the Java code from inside a VDI disk image? If so, so can the attacker.

Obfuscating the source code is NOT enough,

Okay, we're back to the conflicting requirements here; obfuscation is the act of making code that can still be run by a machine, but is hard for a human to understand. You say that's not good enough: you want to allow the attacker to run your code, but not read your code. That doesn't make sense.

is my native code relatively safe from reverse engineering ?
Still another way: to e.g. use C++ to write the most security critical code, compile it to real native, and expose my unimportant Java source.

Why do you assume that native code is harder to reverse-engineer than Java? Sure, there's more learning-curve to reverse-engineering assembly with tools like IDA Pro compared to reverse-engineering java with jad, but for a skilled reverse-engineer, the effort is very similar.

I like @Zymus' suggestion: if there are bits of code that you don't want the attacker to have, then don't give it to them; run it on a server and provide an API that only exposes the (less sensitive) input and output.


What keys are involved in an X.509 certificate?

A certificate does not "use" keys, it contains keys. That's its job. The certificate contains the public key of an "entity" (a human being, a job function, a server...) and an identity (which designates the said entity in an hopefully unambiguous way). Besides, the certificate is digitally signed by a certification authority, and that signature is to be verified with the CA's public key (which is not in the certificate we are talking about; rather, it is to be found in another certificate which has been issued to the CA itself).

All these public keys have corresponding private keys, which are, naturally, not in the certificate themselves (since they are private); each private key is mathematically linked with the corresponding public key, in a way which depends upon the algorithm type.


Suspicious SMS about activated phone service

This seems to me like it very much could be a cramming operation or a premium SMS scam.  The US has cracked down on both practices in recent years, but they haven't disappeared completely, and of course, the situation is different in other countries.  It would be wise to monitor future bills to make sure that there's no extra charges resulting from this.

(It could also be legitimate, not that I'd make that assumption based on the ignorance of an entry-level worker at the phone provider.)

At the very least, if this is malicious, by responding, your family member verified that it's active number, and that the current user is relatively easy to scam.  That's information that's valuable to scammers.

As to how you address that, your guess is as good as anyone's. I agree that going back to the same clueless idiots that didn't help the first time isn't a great idea, and that the phone company's customer service line would probably be a better approach. Having said that, if there was an easy, one-size-fits-all solution to not getting scammed, people wouldn't still fall for basic scams that have been around for decades, but they do, so don't get your hopes up.


Have there been any instances of malware in custom ROMs for Android?

Not in any of the popular ones as far as I've heard. But you're free to build one yourself, which would then mean that it has happened.


Is an encrypted hard drive immune from malware if it is not mounted when using a LiveCD?

It's protected in the sense that malware cannot be installed on the unmounted encrypted drive. However it's still possible for the encrypted drive to be damaged or destroyed if the drive can be written. A simple dd to the raw unmounted drive can destroy it.

 ----  Edit  ----

If the encrypted drive is a bootable drive, then there is an unencrypted boot partition that could in theory be modified in an "Evil Maid" equivalent.


A NAS is a computer. It has a "smaller" CPU (usually an ARM in the 200 MHz range) but it still runs a "normal" operating system (often a Linux derivative) with all its normal software and assorted vulnerabilities. When a SSH server has a buffer overflow, it is vulnerable, even if the outer box does not "look like" a computer.

To be considered secure, a NAS, just like any other computer, must be managed, with prompt installation of security fixes. This is where the problem lies: contrary to what happens with full-fledge desktop computers, NAS vendors rarely distribute security patches on a daily basis. There is an inherent latency which means that when a vulnerability is found, attackers have a few weeks (or months !) of head start before the fix is packaged and installed in the majority of deployed devices. This is a rather big issue. It turns 0-day exploits into 0-month exploits.

My advice would be to refrain from putting such a device "on the Internet" unless you replace the OS with another one which you control, and offers low-latency security updates (and, of course, you do check them and install them with all due alacrity). For instance, you can install Debian on QNAP NAS.


Can I pass a cryptographic hash of a user's password to Kerberos while creating principals?

You cannot use a hash of the user’s password; you need the password itself. Kerberos is a shared-secret system: the Kerberos authentication servers (key distribution centers, or KDCs) share a secret with each principal in the system: for a user, that is a set of keys derived from the password.


How to recover a lost zip file password (Extract Zip Spec '2.0')

If the Symbols As!@$123 are the parts you password was orignally made of I'd recommend creating a customzied bruteforce using these Symbols in order to get the password.

For this you could use John The Ripper or Rarcrack.

Otherwise; as KanekiDev said: good luck brute-forcing the 12-20 long password.


CSRF on GWT apps : bypassing the Same-Origin policy

Your application uses AJAX posts with the content type set to text/x-gwt-rpc.

  In other words, is it possible, with an html form, to submit a request that just contains text in a body, instead of key-value pairs in the body ?

According to the HTML specification, it is only possible to set the following content types for an HTML form:

application/x-www-form-urlencoded
multipart/form-data
text/plain

Therefore it is not possible to set it as text/x-gwt-rpc and have it understood by the browser.

This denotes the "GWT-RPC Wire Protocol". With some content types, it might be possible to "trick" the browser into sending another type of payload by using text/plain. For example, here is how it could be done with a JSON payload, although it will be sent without the correct content-type header.

<form enctype="text/plain" method="post">

<input type="hidden" name="{&quot;foo&quot;: &quot;bar&quot; }//" value="" />

<input type="submit" />

</form>

would be sent as

{"foo": "bar" }//=

Not perfect, but you get the idea.

  Or is there another attack angle for such cases ?

If your application is not checking the content type of the submitted form server side, it might be possible for an attacker to construct an AJAX request and POST that cross-domain to your server. For example, they may set the content type to be text/plain, which is allowed cross domain without an OPTIONS request.

The allowed cross-domain content types for AJAX request exactly matches the content types allowed via an HTML form.

An option for you could be to add a header to your requests such as X-Requested-With and then verify this server side. As this header cannot be included in a cross domain request without the server opting in via CORS, this will protect your application against CSRF attacks.


Security risks posed by user generated filenames on a webserver

Yes, all user controlled input poses a potential security risk and should never be trusted.

But, if the file name is a threat to your application depends on how you process the file and the file name internally. I would suggest to sanitize the file name when the user executes the file upload.

For test cases, best practices and prevention methods see the Unrestricted File Upload page at OWASP.


How to decrypt AES CCM with salt on Windows?

Do you mean you don't remember the name of the tool you generated it with?
If so, I think it is https://bitwiseshiftleft.github.io/sjcl/demo/

You can paste your JSON in the blue Ciphertext inputbox and your known password in the top left green Password inputbox, and your secret message should reveal itself when clicking on the blue decrypt arrow.


In the real world, that's not practical.  Amazon isn't going to let you in the door of their data center to insert a CD into one of their cloud computers.  Has that stopped Amazon Web Services from existing?  Has that stopped people from building many successful businesses in Amazon's cloud?  The existence (and profitability) of AWS suggests that they're pretty trustworthy.

Instead, we try to install the software security agents on freshly built machines, and exercise a bit of trust that they weren't maliciously modified in the meantime.  It's a practical approach that covers most of the attack surface.

Consider the inverse:  How would you know if the CD you would use to install the agent is a genuine image, and not a clever forgery that contains a root kit?  How do you know the server doesn't have a malicious chip created by an untrustworthy foundry, and installed by an unscrupulous motherboard vendor?  How do you know some shadowy attacker hasn't installed a COTTONMOUTH-III board in the machine's USB tower while it sat waiting to clear Customs?  At some point, you have to let go and exercise some trust.  The trick is to never let the inability to achieve absolute perfection keep you from getting to a state that's "good enough".  Yes, there's always a gap, a hole in the process, something that could be exploited by the right person at the right time.  Minimize the gaps, certainly, but be aware they're going to exist regardless of what you do.

A more rational approach is to perform a risk assessment and risk analysis. You have a finite security budget -- everyone does. Do you want to spend it all on carrying CDs around to your servers on the tiny chance it's already infested with a rootkit that you're completely unaware of? Or would it make more sense to spend it on a more immediate threat or urgent problem, like implementing a network intrusion detection and response system, or training your users to recognize phishing attacks, or auditing your TLS configuration?

Hit the realistic problems first.


What reason do we have to believe that AES is unbreakable?

I disagree with your characterizations about RSA and DHE.  We believe they are secure because there are no significant known attacks on modern implementations with reasonable key sizes that cause either to break in practice; it's the same reason we trust AES.  No one has published a method to break secure implementations with practical attacks.

We do know that if given an oracle (or sufficiently powerful quantum computer running Shor's algorithm in polynomial time) that factors RSA moduli or solves discrete logs that it would be possible to break RSA and DHE.  This doesn't mean there couldn't be an alternative way to break RSA/DHE that doesn't rely on factoring numbers or solving discrete logs.

For instance, there are plenty of ways to break badly designed RSA (e.g., use a low exponent, don't use a secure padding scheme, choose p and q that result in a small d, etc.) and none of these require some advance to break integer factorization.


OpenPGP keys on smartcard: what is the real-world security gain of keeping master key offline?

I'm not a cryptographic expert but here is my point of view.

Both methods you talk about are storing the keys offline. Secrets stored in smart cards cannot be read. The goal of a smart card is to keep the private key out of the computer. You can communicate with your smart card to do cryptographic operation but you can't extract the private key.
So your first scenario is a bit far from reality as it is unlikely to happen.
The second scenario is also not realistic. Usually, you need to enter a pin code to use your smart card. So if someone steal your smart card, it can't use it. Some smart cards can be automatically deactivated after a number of wrong pin. Anyway, when you see that your smart card has been stolen, you can "revoke" it.

So I would say that from the security point of view smart card and offline storage of cryptographic keys are equals for your usage (storing openpgp keys). But for an everyday usage of your personal keys smart cards are a better solution. It's also easier to manage smart cards in organization than offline computer.

Here is good article to complete my answer : Strategies for offline PGP key storage


OS Fingerprinting difficulties with nmap and zenmap

The fingerprint for this match in the nmap-os-db file looks like this:

# GS-Z3 Data logger, connected to an Energy Display Meter offered by www.energydisplaymeter.co.uk. BGB WebRTU Z3. Firmware Version : 2.05.03 (19), Config Filename: BGBConfig_07_01.bin
Fingerprint British Gas GS-Z3 data logger
Class British Gas | embedded || storage-misc
SEQ(CI=I%II=RI)
OPS(R=N)
WIN(R=N)
ECN(R=N)
T1(R=N)
T2(R=N)
T3(R=N)
T4(R=Y%DF=N%T=FA-104%TG=FF%W=800%S=A+%A=S%F=AR%O=%RD=0%Q=)
T5(R=Y%DF=N%T=FA-104%TG=FF%W=800%S=A%A=S+%F=AR%O=%RD=0%Q=)
T6(R=Y%DF=N%T=FA-104%TG=FF%W=800%S=A%A=S%F=AR%O=%RD=0%Q=)
T7(R=Y%DF=N%T=FA-104%TG=FF%W=800%S=A%A=S+%F=AR%O=%RD=0%Q=)
U1(DF=N%T=FA-104%TG=FF%IPL=38%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)
IE(DFI=S%T=FA-104%TG=FF%CD=S)

All those R=N lines mean that no response was received. Note that Nmap tells you this also: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port

This, combined with the tcpwrapped version line, indicates that either the link between you and the system is faulty (many dropped packets and closed connections), or there is something between you and the target that is filtering and manipulating connections.


What are the pros and cons of using live CDs vs VMs for malware analysis?

The main two things that come to mind are the threats that can compromise you when using them.  In both cases, the threats are fairly rare.

For a VM, the main threat to your system is a virus that is able to exploit the hypervisor.  Such a virus would be able to escape the VM and infect your system.  VMs also have the benefit of being able to do a closer comparison to the state change caused by the virus to determine exactly what it does.

For a live CD, such a virus would be a hardware resident virus that is able to corrupt the hardware in such a way that it survives a reboot to your normal environment and is then able to spread.

Both are pretty unlikely to be problems from all but the best attackers, however, a hardware resident virus is a far bigger (if much rarer) threat than any software virus since it would be basically impossible to remove. Because of this, I would personally lean towards VMs, however the most truly paranoid individual could use a VM running off a live CD.


Can someone without the WiFi login and no physical access to a router still access it with the admin login?

This may be possible using cross-site request forgery. In this attack, the attacker triggers a request to your router, for example by including an image on his site:

<img src="http://192.168.1.1/reboot_the_router?force=true">

When a user visits his site, this triggers a request to the router.

The attacker's site can trigger requests, but not view responses. Not all routers are vulnerable to this. Setting a non-default password certainly protects against CSRF1.

There are plans to block such requests in the browser, but these haven't been implemented yet.

Edit 1: Setting a non-default password protects against CSRF in some cases. The attacker can no longer forge a request to login using the default credentials. However, if you are already logged in to the router he can use your current session.


How can a company ensure cybercriminals destroy hacked data after payment?

How can the company be certain that the data is destroyed,

It cannot be certain. The only hope that it is part of the criminals business model to maintain a good reputation in that one gets what is claimed.
But business models might change. For example if the existing ransomware business does not provide enough profit anymore it might be worth checking if one can get more profits from previously collected (and not actually deleted) data.

... what reparation can it get if it is found later that the data is passed on after payment?

None. They are dealing with criminals in the first place.


My system is being attacked or it is attacking

Reading the alert you have windows file sharing turned on(CIFS) and another machine 114.50 tried to connect and use an exploit related to CVE-2017-0144 . It would appear from the alert 114.50 is infected, run your AV/cleaner on that.


Script / method to erase USB flash drive content after a certain number of uses

You want a DRM, not an "integrity" solution

First a small vocabulary precision. The "data integrity" term you use doesn't seem appropriate regarding your needs.

A data integrity method would ensure that the data on the flash drive is genuine and/or cannot be in a corrupted or incoherent state, but this do not seem to be your concern here.
A Digital Right Management (DRM) method, according to Wikipedia, "is a term referring to various access control technologies that are used to restrict the usage of proprietary software, hardware, or content.

So what you need is a DRM solution, and not a data integrity solution.

Possible, but only on an industrial or semi-industrial scale

There is no really viable protection relying solely on the OS or any data publicly stored on the thumb-drive. Indeed, it is trivial to dump the raw thumb-drive content and restore it later to put it back in its pristine state.

So, you can forget about self-deleting content, standard encryption which will be of no help against this, do not even think about storing a counter in some unallocated zone of the file-system (such tricks were used to protect CD-ROM's in the late 90's but will be of no help here).

Some other answers suggest the use of an Internet-based service. This is how DRM-enabled PDF documents work: the document themselves are encrypted and upon each opening the decryption key is requested to some Adobe server. This may work, but you have better ensure that your software requesting the key and the protocol it uses cannot be reversed or replayed, otherwise the end-user will be able to get around your protection. All security will rely on this, and given enough time and determination consider that your software will eventually be broken, it just a matter of profit vs. efforts needed.

The solution I suggest doesn't require any Internet access from the end-user and gives a good protection against reverse engineering attempts by keeping the security system out of the reach of end-users.

A firmware-based solution

You will need something not reachable to the user, and this will most probably mean you will have to customize your own firmware for the job.

Following my idea, the storage area of your flash drive should be divided in three zones:

One public and relatively small zones containing just enough material to initiate the boot procedure (it needs to be accessible to a standard BIOS),
One very tiny zone accessible only to the firmware (and never accessible to the computer) storing the counter and, possibly, some other configuration and/or authentication material,
The largest zone, accessible to the computer only after a successful internal authentication.

The boot process would go as follow:

The BIOS read the publicly accessible boot sector and initial boot executable,
This initial executable initiates some custom authentication procedure with your firmware to unlock access to the main data,
If the authentication is successful and the maximum number of allowed unlocks not reached yet, the firmware increments its internal unlock counter (stored in his private area) and then effectively unlock the main storage area,
Once the main storage is accessible, the boot process can continue as usual.

Potential weaknesses

First potential weaknesses I could see:

I do not know which application you intend to run on such thumb-drive, however an end-user may try to extract and copy the unlocked content (whether directly from the USB drive or from the mounted RAM disk) if your software allows him to do so (for instance if he is allowed to open a shell with root access). So you may want to restrict the user's privileges on the running system to prevent this.
Your initial boot executable may use some obfuscation technique to prevent the authentication procedure to be easily leaked. In the hands of determined attacker, expect dead and live analysis since they can for instance connect your thumb-drive to a virtual machine to simulate a boot process and analyze the exchange between the initial executable and the thumb-drive.
The good news is that, even if the authentication process and secrets are reversed, this will not allow to tamper with the unlock counter or unlock an already locked thumb-drive.
Your firmware may be overwriteable. When selecting a provider for your chips, you must ensure that they offer the possibility to lock any further update or rewrite of your firmware code. This may not be obvious, but there is actually plenty of USB devices where the firmware can be rewritten by end-users, see BadUSB. Since your security relies on your firmware, this may be an important criteria for you.
If the value is high enough, a determined attacker may be willing to access directly the data stored in the NAND storage chips inside the thumb-drive. If this is a concern for you, you may want to implement on-the-fly encryption in your firmware so all stored data will be systematically encrypted.

Feasibility / credibility

Custom flash drive: A quick search let me find several open sourced USB keys with customizable firmware already available in retail and wholesale, however they were targeting the more profitable market of security tokens which mean they add a more costly cryptographic hardware to the key. Most chances are that cheaper already-made USB keys can be found at lower price.
Custom firmware: Creating his own firmware may sound highly technical, but I do not think it really is. USB chips provider also provide the associated development framework which include libraries acting as an abstraction level over USB low-level operations and placeholders for the user's customized code. As a sample here is a random documentation for such a library so you can get yourself an idea. The main prerequisites are to know how to write C applications, how to use an IDE, and have only a basic understanding of how USB works.
Divide the storage area and control access to each zone: This is not my invention, as far as I remember this is how the DRM extension for SD cards is implemented. To learn more on this topic, this specification is confidential however some part of it (at least) leaked on the Internet despite the non-disclosure agreements. I am not reinventing the wheel.
On-the-fly encryption: There are already USB token providing on-the-fly encryption, however to achieve good performance they bundle some cryptographic hardware. Since encryption is not your first goal here, and if you really need to encrypt the storage area (ie. if you fear that your users will take your flash disks apart and access the raw NAND chips content directly), you may still be able to do without such hardware but you will have to restrain yourself to very low resources algorithms. In fact, with a flash drive limited computing resources, you may go more toward some data obfuscation scheme than a true highly secure encryption algorithm.


Zero-days are found in exactly the same ways as any other kind of hole. What makes a security hole a "zero day" relies exclusively on who is aware of the existence of the hole, not on any other technical characteristic.

Holes are found, usually, by inquisitive people who notice a funky behaviour, or imagine a possible bug and then try out to see if the programmer fell for it. For instance, I can imagine that any code which handles string contents and strives to be impervious to case differences (i.e. handles "A" as equivalent to "a") may run into problem when executed on a Turkish computer (because in Turkish language, the lowercase for "I" is "ı", not "i") which can lead to amusing bugs, even security holes (e.g. if some parts of the system checks for string equivalence in a locale-sensitive way, while others do not). Thus, I can try to configure my computer with a Turkish locale, and see if the software I target starts doing weird things (besides talking Turkish).

Part of bug-searching can be automated by trying a lot of "unusual combinations". This is known as fuzzing. It can help as a first step, to find input combinations which trigger crashes; anything which makes the target system crash ought to be investigated, because crashes usually mean memory corruption, and memory corruption can sometimes be abused into nifty things like remote code execution. However, such investigations must still be done by human brains.

(If there was a fully automatic way to detect security holes, then software developers would use it to produce bug-free code.)


One of the key factors (pardon the pun) of RPKI is the network of 'trust anchors' (think CAs) that validate the ROA certificates. You need to check with them to see if the submitted ROA is valid.


How SplashData knows about Worst Passwords used by users annually

Your first link says what the source is:

  This list is from files containing stolen passwords posted online during the previous year.

In a perfect world this would not happen. Not only would everyone salt and hash their passwords with an expensive algorithm, security would also be good enough that password lists won't get stolen. Unfortunately the world we live in isn't perfect.

Leaks from large databases happen all the time.

There are still large services which store passwords in plaintext. Most at least hash their passwords, but then they either don't salt them, or salt them but then use an algorithm which is fast enough to make brute-forcing of weaker passwords feasible (like those from the SHA-family, for example).


Debug mode for an application but removed in production

In the code you posted, the username and password could be easily extracted from the compiled binary.

If you're going to do it this way, use a preprocessor directive like #if DEBUG so that the code is not even compiled in a release build.

This still leaves your other environments vulnerable, so I wouldn't hard-code the username and password at all and instead use a password manager to auto-fill it. Additionally, a development username and password probably shouldn't be valid in a production system.


I have figured it out. The problem was Network Manager, after I have stopped it and ran arpspoof everything worked like a charm. The traffic was flowing without any problem.


While logged in to Google etc., can a malicious site discover my ID?

This really depends on the sites you're logged in to and how alert you are as a person. I can imagine the following scenarios (not specific to any of the sites you mentioned, but just general scenarios):

Sensitive information is transmitted in the URL: For each request, a  session ID is transmitted in the URL. In this case proxy servers will log the session ID and anyone access to these log files is able to perform session hijacking. This information could also be stored in your local cache, anyone having physical access to your machine might use it.
Cross Site Request Forgery: Missing or poor implementations of anti CSRF tokens could lead to un-validated actions on your behalf because the origin of the request is not validated. An example of a poor implementation of anti CSRF is transmitting these tokens in the URL (see #1.)
Cross Site Scripting & Insufficient cookie settings: If a website does not properly secure its cookies (e.g. missing the HTTPOnly attribute) and an XSS vulnerability exist in the same website, your session ID might get stolen while visiting a malicious site (e.g. cookie stealer).
HTTP Resonse Splitting: Also known as CRLF injection (%0A%0D) is a vulnerability due to the lack of input validation. It may lead to poisoning of the client’s web-cache, cross site scripting, theft of sensitive information and other.

Does this apply to the sites you mentioned? Unfortunately yes, it does! Although most of these sites are known to be secure, every once in a while certain vulnerabilities are discovered.

A question you should ask yourself is, should I always have an active session while browsing possible malicious websites?

Another question could be, why do I browse possible malicious websites with the same browser I use for the sites mentioned?

Your bonus question:

I would like to invalidate the "fully patched operating system". There are 0days out there that are not reported to the manufacturer(s) (that's why they're called 0days in the first place). There's no such thing as being 100% secure.

Your router: We've seen in the past that even though the router's remote administrative interface was not enabled, there was a backdoor in a specific router which could access the administrative interfaces with a specific User Agent (no credentials required).

Having said that, it doesn't mean you should get paranoid.


Can you trust the URL shown when 'hovering' on a link?

the onclick javascript action is performed first (did this once to hash a password in browser in a form) and afaik that would enable the site to direct you somewhere else. So no, the destination can be changed between clicking and following the link.


Loki How to crack the password hash OSPF?

Hash authentication of protocol packets is not on by default in OSPF, you'll only see hash digests if digest authentication is on with a pre-shared key configured. If you're looking for the encrypted digest packets you'll find the information you're looking for in RFC 2328 section D.3

'Using this authentication type, a shared secret key is configured in all routers attached to a common network/subnet. For each OSPF protocol packet, the key is used to generate/verify a "message digest" that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Since the secret key is never sent over the network in the clear, protection is provided against passive attacks. `

Looking forward in section D.3 it looks like the way forward is to look for the key ID, then pull the length of the digest from the auth len section. Then all you have to do is read that length from the back of the packet, minus any footer, and you have the digest. See D.4 as to how it is generated.


When encrypting individual files in directory for cloud storage, is storing IV and salt with the file wrong?

As @Limit commented,

  your entire security is dependent on your password. If an attacker has access to your directory, they can access both your salt and IV.

So it should not be a problem storing these.

Your password is going to be the most important item you need to protect :-)


What is Cloud KMS? What's it's purpose/benefit of KMS? How does it work? How do I use it? (AWS KMS, GCP KMS, Azure Key Vault)

KMS allows you to encrypt/decrypt data without ever seeing your master keys. It makes managing encryption keys simpler because there's nothing you can do that can allow you to leak the master key.

They can also manage the choices of encryption algorithm, and the mechanism for upgrading algorithm choice. So these decisions are made for you so you can't accidentally configure weak encryption parameters.

Also note though, that the cynical part of you should also notice that the pronunciation of "Cloud KMS" is very similar to "vendor lock in". It makes it really hard to switch cloud provider as you can't easily move your data without also decrypting everything first. Some KMS solutions allow you to import your own key, which can reduce your surface, but brings you back into having to protect your master key and since most Cloud HSM don't specify the encryption parameters and algorithms in a vendor neutral term, you still can't easily decrypt your data even if you have a copy of your imported master key.

Probably the biggest advantage of a Cloud KMS though is logging and auditing. Building your own logging and audit infrastructure for key usage is normally non trivial, but it comes out of the box with most Cloud KMS.


BadUSB is no problem for internal devices. It is more the other way around, you should not connect external USB Devices to your computer.

BadUSB works in the way that you think a ordinary i-phone charging cable or a USB stick or most likely a manipulated smart phone to your computer. But in realty the device acts as keyboard, mouse and or network card,and therefore is able to change or exfiltrate or monitor data on your device.

I don't think someone will use BadUSB against you,but if you think you need protection one solution would to make it impossible to connect any external USB devices to you laptop.

There are software solutions which make it hard to use BadUSB. But they are not easy to implement or use and you need to know what you are doing to make them work.


Why do 256 bits SSL certificate show "256 bytes" for key size?

I've seen many places refer to "256 bits certificates" in SSL encryption.

You are most likely thinking about 256-bit symmetric cipher key sizes. There are no 256-bit certificates, but there are plenty of 256-bit symmetric keys (e.g. keys for AES, a common cipher in TLS).

  when I look at these certificates in browser I see 256 bytes instead.

With the eight bit byte, 256 bytes is equal to 2048 bits, which is a common RSA modulus size, and thus a common RSA key and signature size. Public key cryptosystems like RSA require a larger key because they are attacked not using brute force (in which case 256 bits is more than secure enough), but through various other mathematical methods. In the case of RSA, the best known method to break it is integer factorization. Securing against factorization requires a modulus size of at least 2048 bits, or 256 bytes.

  am I reading this wrong or should it instead be "256-bytes certificates"?

What you are looking at is the RSA public key, not the certificate.

For more detailed information, see How does SSL/TLS work?.


How to Delete duplicates in CA Bundle Certificate File

Although you didn't say so, I'll mostly assume openssl. Lots of software uses PEM format for certs (which is base64 as you showed PLUS the dashes-BEGIN and dashes-END lines, those ARE NEEDED), and quite a bit uses a file containing multiple PEM certs called a bundle, but AFAIK only openssl, and apps calling it, uses a PEM bundle file for trusted CAs.

For info, the length of the base64 lines differs because of following different standards. The PEM RFCs which first defined base64 said 64. The MIME RFCs which are now more widely used say 76.

Option 0: don't bother. An openssl "CAfile" works just fine with the same (CA) cert occurring more than once. It takes a little more memory, but on modern desktop (or higher) systems you probably can't even measure the effect of less than a few thousand extra certs.

Option 1: canonicalize. Filter each cert through openssl x509 with all defaults (which is copy, inform PEM, outform PEM) i.e. openssl x509 <oldfile >newfile. The result will consistently use 64-char breaks. As a bonus, you can specify -subject to add a (fairly) readable name at the beginning of the file -- which openssl or apps using it will ignore, but other apps might not.

But for both 0 and 1, if you have different certs for the same CA, such as an expired one and a renewal, or a broken one and a fix, which aren't duplicates by your definition, that will NOT work reliably; openssl to date (1.0.1) uses only the first cert found for a CA (issuer) name and AKI if available, which if you aren't careful is the wrong one. (1.0.2 is announced to have changes in cert chain validation, and I haven't looked at the details yet, so this may change.)

Option 2: use name hashes. Use the openssl "CApath" or "CAdir" method in addition, or instead: create a directory in which you put each CA cert as a file, and everytime you add one do c_rehash (on Unix, or Windows if you install perl, or else a BAT-ified equivalent). If your new cert and any existing one have the same hash of subject name you will get links (or names) with a suffix other than ".0". Two certs with the same subject hash e.g. abcdef01.0 and abcdef01.1 ALMOST certainly (not quite) have the same Subject i.e. CA name, but may or may not be the same cert; compare those specific files.

Note that having constructed a "CAdir" in this format, openssl commandline and at least many apps allow you to use it instead of "CAfile"; some even give the mostly-outdated advice that it's "more efficient" (in 1995 it made a difference, today it's probably 0.1 msec instead of 0.2 msec).

Other tools: if I've guessed wrong about openssl, you can do the canonicalize option by importing to and exporting back out from the Windows keystore, the Firefox keystore, or a java keystore. I expect Mac, Apple, and Android have similar capabilities but don't know them.

The first two have convenient (but tedious) GUIs; for Windows I believe there is still a commandline form but, typical for MS, they change it everytime you blink so I stopped trying to keep up. These also have the property, possibly bad or possibly good, that if you leave these certs in the truststore and don't delete them, your respective browsers (IE and maybe Chrome, or Firefox) will trust website certs from those CAs.

For java (assuming JRE in your PATH, else use pathname)

  keytool -keystore whatever [-alias x] -importcert -rfc -file certfile
  keytool -keystore whatever [-alias x] -exportcert -rfc -file newfile

or even easier: if you import and leave in one JKS all the same certs as your PEM bundle, each with a unique -alias you must specify, and you try to add another copy of a cert already in the JKS, it will warn you. It won't detect certs with the same CA, however.


How does a system authenticate a user using a hash function, after it has been salted?

When you hash the password the first time (when the user registers), you use a salt and store both the salt and the resulting hash in the database.

The second time (when they try to log in again), you use your username to pull the salt and the hash out of the database. You use the salt to hash their password input, and compare the two hashes.

You may be wondering "but if someone gets access to my database, they have all the salts - isn't this a huge problem?". The fact that they have the salts isn't a problem, since the purpose of the salt isn't to add something "secret", it's to ensure that if two users have the same password they have different hashes since the hashes were created with different salts.

If you didn't use salts, or if you used exactly the same salt for every user (unfortunately not an uncommon mistake), there will be a lot of duplicate hashes (since some people will use the same password, and those identical passwords will all have identical hashes). If someone gets access to your database, they can look for the hashes that appear most often, concentrate on cracking those hashes, and for each one they manage to crack they have access to multiple accounts. By salting each hash differently, chances are very high that there won't be any duplicate hashes - the different salts mean that even duplicated passwords will have different hashes. For each hash they crack, they get access to exactly one account - no more. That's the purpose of the salt.


How can user send malware code via input=file

For an attacker this is a 2 step process
1 - upload malicious file
2 - execute it

So if they already have an input=file opportunity to get the file onto the system then it's all about step 2.

The attacker has multiple options such as
- RCE (remote code execution) vulnerability, they then execute it themself
- Social Engineer or wait for a user on the system to execute it (for example if they're uploading a resume , they wait for the HR staff to open it)
- If it's a web server , they upload a webshell, then make a web request through a browser to that newly uploaded page/shell ... causing the web server itself to execute it


Access-Control-Allow-Origin possible threats on static JS file

I don't think it can really cause any harm on a Javascript file. The problem starts when this is possible on a web page.


Can I use crypto.getRandomValues to create a private key?

Well, for one, ECDSA is not an encryption scheme, but a digital signature algorithm.

The generic purpose of a crypto API like window.crypto is to give you access to implementations of some cryptographic algorithms. These implementations may be based on software or hardware. In particular, an implementation may be a piece of tamper resistant hardware (a HSM or a smart card) that can generate keys for some algorithm, and store them, without ever letting the key exist outside of the hardware. generateKey() handles such cases. With getRandomValues(), you can only generate a bunch of bytes in the RAM of the computer.

Moreover, private keys often need some mathematical structure. In the case of a ECDSA, a private key is a big integer in a definite range (1 to n-1, where n is the order of the curve subgroup generator); if you want to produce such a key yourself, with getRandomValues(), then you must use some big-integer arithmetics to make sure that your value will fit in the proper range. There again, generateKey() will produce a key with the right structure for the algorithm at hand.


Where to download a list of email accounts hacked from Adobe?

I could not give you a direct link to the file, but you could search for a file called "users.tar.gz", which has a file size of about 3.8 GB. With the search engine of your choice you should be able to find the file within minutes.


security of PKI, Certificates, certificate authorities, forward secrecy

Yes, MITM attacks are thwarted if you can make sure that you use the right public key. Certificates are a public key distribution method which allows precisely that.

The point of the certificates is that you just need to "know" the CA public key in order to be able to verify all certificates that the CA has issued -- there can be millions of those, and it also works on the certificates that the CA will issue next week. So while certificates do not totally remove the need for a source of trust (an a priori known public key), they sufficiently concentrate that need so that the practical problem of key distribution is solved.

Gaining confidence in a public key can be done through other schemes than certificates; for instance, SSH does it by caching (you trust the server public key because you can verify that it is the same key than the last time you contacted it; in a way, SSH realizes timewise trust concentration, whereas certificates do it spacewise).

Perfect Forward Secrecy is achieved with SSL when you use the 'DHE' suites -- for "Diffie-Hellman Ephemeral". The important word here is "Ephemeral": the actual private keys which protect the session symmetric key are dynamically generated, and never stored (these are Diffie-Hellman keys); therefore, those keys are supposed to be immune to disclosure. The keys which are stored (e.g. in a private key file) are used only for signatures, so stealing them does not give the ability to decrypt past conversations (it gives the ability to impersonate the server for ulterior conversations, though). PFS is not about actual key breaks, but about key stealing, which is, in practice, a much more plausible attack path. The DHE cipher suites ensure PFS by never storing the key exchange private keys.


Why do we authenticate by prompting a user to enter both username and password? Does prompting the password only suffice?

I think the issue is in requiring passwords to be unique. If I entered my desired password, and you told me I can't use it, it's already in use, then I know that I can log in to a random persons account with the password that I would have wanted.

So, you need a username, which is unique, and can be known to everyone. Then you have a personal password, which is not necessarily unique, making even harder to guess.

While you are at it, hash and salt that password.


How can mom monitor my internet history from a distance?

Be careful about assuming too much. You say that you know "surefire" that your university is spying on you, but your only evidence is that your mom is computer illiterate and you're "sure some of them know more than they should" about you (WARNING - this is a red flag for those of us not in your situation, you do indeed sound extremely paranoid).

If you don't use the university network (which seems unusual when you're on campus with your computer, but I'll take it as given), then your university has no interest in your browsing history, full stop.  If someone there in some way helped her get access to your activity, they could go to jail.

You wonder if your mom has conscripted your neighbors into her spying scheme (another red flag).  Unless your neighbors are the absolute pinnacle of unscrupulous busybodies, they have no interest in your browsing history - they could also go to jail.

Very few people could legally help your mother to spy on you, and no one is interested in breaking the law to spy on you.

The ISP could theoretically provide her some of your browsing history:

If they offer some sort of network monitoring service for child safety, then they would provide her whatever they offered to provide her, but it's highly unlikely that such a service actually keeps records, and more likely that it is meant to just block content - if you're not being blocked, such a system wouldn't care what you're doing.
If you fall afoul of the DMCA by downloading copyrighted content and the copyright holder both discovers you and sends a notice to your ISP, that notice would be forwarded to your mother as the ISP account holder.

... ISPs are big, they have a lot of customers, and storing browsing history takes up a lot of space they for information they don't want to be legally liable for (e.g. if they record browsing history, they can be subpoena'd for it), so it's unlikely that they could provide this information to your mother.

That's assumption 1.

You then say that she knows what you browse whether you access it over HTTPS or not.  This categorically rules out any sort of "from a distance" spying - once your request leaves your browser, no one knows what that request is until it reaches the server it's going to.

What this means practically is that if you use HTTPS URLs, someone (theoretically) could know that you went to YouTube, but they couldn't know what you watched.  They could know you went to Wikipedia, but not which articles you read.

If someone is capable of breaking HTTPS encryption, that person has far more lucrative opportunities than helping mothers spy on their sons.

Even if you're mistaken and only HTTP URLs are affected, it still requires someone to basically perform an illegal wiretap to access that information because, as we've determined above, no one who has direct access to your browsing history is interested in keeping it or showing it to anyone.

Which leaves us with what is by far the most likely scenario:
There are oodles and oodles of spyware programs out there that have varying degrees of legitimacy - as others have said, many are marketed as tools to give parents just this level of access.  Your mother could have found such a tool by typing full sentences into Google easily enough, and they're probably one-click installers just for people like her.  Have you confirmed that there is no hardware device like a keylogger installed on your machine?  All of these methods get at your history the moment it's created, before it has a chance to be encrypted or go over the wire.  They are also the most legally defensible ways for someone to view your browsing history.

A big honorable mention goes to the person in the other answer or comment that suggested that if you have a browser profile logged in on a computer that your mother has at her house, then she can view your ongoing internet history as if it were her own.  Simplest fix would be to browse in in-cognito mode (or equivalent for your browser if not Chrome), it won't record your history.

As for what to do about all of this, I'm going to go the tough love route:

Talk to your mother.  Tell her to back off, or if she won't tell her she's welcome to view your history but it won't change what you look at.  You're a big boy, act like it.
Pay for your own ISP.  As I've stated I don't believe this avenue is being exploited to see your information, but if she's paying for your service and using that as a justification to spy on you, then it's time to take the next step to separate yourself from reliance on her.
Reformat your computer.  If there's any concern that something is installed that you can't find, just backup your important documents, erase the thing and start over.  Don't put a bandaid on a bullet hole by using ways to hide your traffic from spyware.
This one I'm just throwing out there to see if it sticks, if it doesn't describe your scenario then sorry, I'm mostly keying in on the above mentioned red flags: if you're off your meds, get back on them.


Got it working a little after asking here (shame on me). Root The Box is configured to devel mode by default. So, after configuring your files you have to set it to production mode.

./rootthebox.py --setup=prod

And yes, you do have to be an admin user so you can start the game after loggin into your account. Damn, I lost so much time with it! Hope it can help someone someday.


Cryptography in simple words anout one idea?

This is a very broad question. How the cryptography operates depends completely depends on the type of encryption used (a specially secure DB, a DB file encrypted, encryption using special SQL constructs or application based encryption. etc.). Then it also depends on the key system used, public key or secret key encryption and how the key management and access conditions are setup.

If you take a birds eye view then encryption doesn't make sense: to decrypt (and, for symmetric ciphers, also to encrypt) you need access to a secret key. So instead of securing your data you now have to secure a key. This key may however be generated in advance and is much smaller than the data. But more importantly it may have a different protection and may be restricted in access.

The more protected and least accessible the key is the more secure it is. This comes at a price of course. Say you'd use a passphrase or a private key on a special device. In that case you need to supply the key during booting of the DB, and you may need to provide continuous access to it without breaking the security measures.

So onto your questions:

  How I can use an encryption model so that this encrypted data (user/pass/token) can be seen by an admin, but not seen (encrypted) by others?

By encrypting the data in such a way that it only can be decrypted by a private or secret key held by the admin. Sometimes a data key is e.g. encrypted with the key of the admin, and that data key is in turn used to encrypt the data in the database (so you get a hierarchical structure where the security of one key depends on another, higher level key).

  I'm not sure I understand. Where is the encryption key being stored, and how is access gained to it? What is the encrypted data and its relation to user/pass/token?

Where the key is stored depends on the system. Hopefully it is stored in some kind of secure store, e.g. protected by the operating system. But it may also be a static key in the application code or stored in a configuration file.

Banks and such tend to store the most sensitive keys in HSM's (if the keys need to be directly accessible) or off-line (on an offline storage device that can be used by a hardened laptop). On smart cards and HSM's the keys can only be used, not retrieved (exported) except for back up purposes. Using the keys generally requires the user or system to authenticate to the storage device.

But books have been written about key management, and in the end you may need to read a few to fully understand how to handle keys.


Why is it okay to run NGiNX or Apache Web Server as root on port 80/443 and not your app directly?

Here are a few details that might help clarify the situation:

Ports less than 1024 are (in most OSes) privileged ports that require root to run anything on them.  This is intended as a security feature to make it more difficult for an attacker to host services on important ports on a compromised server.  As a result, root is required to run anything on port 80 or 443.
While Nginx and Apache will run on port 80 or 443, as little as possible is done as root.  Both immediately spawn a non-root subprocess to work from. The master root process is only used to bind to the privileged ports.  Nginx also doesn't run any "apps" itself, but instead communicates with the app running as a completely separate process - hopefully also a low-privilege one.
You don't want to run your application as root because then if someone finds a RCE vulnerability in it, your system will be very compromised.  Of course any RCE vulnerability is bad, but running your application as a low-privilege user is just part of defense in depth, and generally a good idea.

So to spell it out, you don't want to run a custom app directly on port 80/443 because doing so requires you to be root, and you don't want to do that because it's just inviting more trouble in the event of a compromise.  However, this is no different than anyone else.  While Apache and Nginx will run as root, any application hosted through them typically does not.

This also means that a RCE vulnerability in Apache or Nginx would be very valuable to attackers (if it happens to affect the portion of the application running as root) and, while they do happen, I would say that they are substantially less common than RCE vulnerabilities in your typical web application. That's why it is better to let Apache/Nginx listen on 80/443 instead of your app.


Blocking executables at the firewall in the enterprise

It is common to block (and then whitelist) executables however this has the burden of upset users and then overworked support staff who need to maintain the whitelists.

What we're seeing nowadays is slightly more sophisticated tools that introspectively look at the EXE to see if it "looks" like malware.  One of my clients uses wildfire which will poke around with the executable in a sand boxed environment to see if it triggers any standard behaviours of malware.  Like a lot of these solutions, the vendor will use standard heuristics as well as have connected systems back to a NOC that will investigate new malware and send out new patterns to each firewall straight away.

These types of tools also come with consoles with visualation and the goods ones can integrate with your SIEM.