Your link goes down about 3 minutes after the "intrusion" has been detected. It's highly unlikely that the disconnect has been caused by one of these network packets.

The packets look like regular scans (SYN packet to TCP port 22 - that's a classic, the other is a proxy scan - looking for squid at 3128), I have serious reservations that this is something that can disrupt your connection. DDoS it isn't, you'd be seeing a LOT more packets if this was a proper DDoS.

Possible scenarios:

Buggy ADSL router firmware. Try turning off some of the "security" features of your router firewall (e.g. SPI firewall, DDoS protection, etc.), and testing whether this would make any difference. You may also want to look at firmware updates, or running a good open source firmware (e.g. Tomato).

Overheating chipset. Happened quite frequently with el-cheapo routers and poor heat dissipation design - dropping ADSL. Try shutting down your router for a few minutes and starting it again.
Disturbance/problems with the ADSL line (most likely). You need to talk to your service provider, or have a look at ADSL diagnostics, e.g. S/N ratio, BER, etc.

Good luck and let us know how you get on with this.


Is it possible to exploit XSS inside User-Agent header?

It is not possible for an attacker to control the user-agent in a cross site request.   Usually XSS payloads are simple <form> elements with javascript to automatically call .submit() or an <iframe>.

It is possible to exploit XSS via some HTTP headers using Flash. However, flash has a blacklist of http headers.  The user-agent was blacklisted in version 9.0.28,  so once upon a time you could exploit user-agent based XSS.  I wrote the CSRF-Request-Builder to take advantage of Flash's control over HTTP headers.


Does my work know im on hangouts even when i dont download anything . and use a incognito window?

Incognito mode does nothing to obscure your network traffic, so its contents and recipient are always apparent.

Supposing that you use a HTTPS encrypted connection, the contents would theoretically be obscured... but not the recipient.  In this case they might be able to guess that you are chatting by what domains that you request information from, say a bunch of requests to hangouts.google.com.  Then again, someone would probably need to be looking.  You might be able to claim it is a side effect of simply logging into gmail.

If your employer is more draconian they might MITM all HTTPS traffic with a "in house" root certificate on their computers.  In this case they could see everything you say, and have a product that likely captures such statistics.

They may even install monitoring software on the computers that spies on what you do directly, possibly even viewing the screen or capturing keystrokes.

In summary, if it really matters, they can possibly tell, and you really should not use hangouts.

They have no idea what you do on your phone over a cellular data plan...


which site do you use to view details of vulnerabilities?

I tend to start with http://secunia.com for vulns per-product or vendor, pick the CVE references up from there and then view the details on http://www.cvedetails.com


Is VM escape has the same severity as me getting in a car crash?

Depends on your threat model

VM escape vulnerabilities are, in general, rare compared to other classes of vulnerabilities - there are less such vulnerabilities found each year than e.g. critical vulnerabilities in mainstream operating systems or their bundled components. Assuming that there currently aren't any known unfixed vulnerabilities for VMWare, and that you have the latest VMWare version (which is a reasonable assumption most of the time) this means that you're only vulnerable to attack by an attacker exploiting an as-of-yet unknown zero-day vulnerability. In general, this is expensive - such a zero-day vulnerability can be bought or sold for something in the ballpark of $100 000 so you should expect that this amount of resources would not get "wasted" on a low value target.

So the question is whether it's plausible that someone would spend $100 000 to attack you - most people are low value targets, and in this case there's no "economy of scale" where it would make sense for an attacker to attack lots of random computers (e.g. for ransomware or spam) as most such targets wouldn't have VMs and there's little additional benefit; something like Cryptolocker would bring only marginally more revenue to the attacker if it also included a VM escape exploit.

If you consider that your attackers are likely to spend a substantial amount of resources to target your systems specifically, and your systems can be targeted by a VM escape exploit, then you should consider VM escapes as likely, and not otherwise. It's also worth noting that in order to do a VM escape, the attacker generally needs to gain code execution. So if you are intentionally running attacker-provided code (e.g. as an antivirus company or running code tests for anonymous third parties) then the risk becomes much higher than simply running virtualized servers.

Iccording to SANS criteria, that's not low severity but medium severity - "Vulnerability requires significant resources to exploit, with significant potential for loss".


Deriving an authentication password from an encryption password

The more appropriate solution for this kind of thing is a prefix.

For example:

Authentication key = bcrypt("AUTHENTICATION" + $password)
Encryption key = bcrypt("ENCRYPTION" + $password)

However, I should note that BCrypt isn't really designed to generate cryptographic keys. It is a password hashing function, not a key derivation function, and their properties are different. You could probably get away with it, but I would suggest using PBKDF2 or a similar KDF for generating the encryption key. At this point the use of a prefix is redundant, as you're using two entirely different algorithms.


How easy it is to actually perform MITM attack these days

I'll do my best to answer each aspect of your question, but keep in mind that this is a broad topic with many intricate details.

first things first:

  They claim that this is secure enough (as it seems that no sensitive info ever travels unencoded)

Semantic correction - the word  you want is unencrypted, not unencoded. Encoding means that the data is easily reversible, and encryption is in place to prevent an attacker from reversing the encrypted data back to the original value.

  Using a simple MITM attack, attacker can modify webpage JS by adding an event listener that posts card details to the attackers server on submit of the form (that have all the card details). The user and the server wouldn't notice anything strange and the transaction could complete successfully. Is my understanding correct of the situation? Is it really unsafe?

Your understanding is not quite correct for HTTPS sites. Because the data is encrypted, your MITM wouldn't be able to make any changes to the traffic. Remember, the encryption happens between the victim and the website - your MITM proxy doesn't have any control over the encryption. Therefore, all it sees is encrypted data - this makes it impossible to edit on the fly and insert malicious code. Your understanding is correct for HTTP sites, however. MITM attackers are able to manipulate traffic, including injecting malicious scripts.

There is an attack called SSLstrip in which an attacker MITMs the HTTPS encryption by downgrading the user to HTTP (changing https:// to http://). This works because the victim browser thinks the attacker is the website, and the website thinks the attacker is the victim. This is prevented in most websites nowadays by the inclusion of the HSTS header which tells the browser to only access the site through HTTPS. There is a more robust and fairly nontechnical article on this attack here: https://avicoder.me/2016/02/22/SSLstrip-for-newbies/

  And also, is MITM attack something that is very hard to perform, or is it doable with minimal hacking? How is it when comparing Public Wifi, Home Wifi and Cable internet?

MITM is incredibly easy to perform. All wifi traffic is broadcasted - this means that any nearby sniffing devices can read your traffic. If you're connecting to a page through HTTP over public/unencrypted wifi you can assume that whatever information you are sending and receiving is public - all it takes is an attacker nearby with an antenna to read all that in plaintext. To perform a true MITM by having traffic flow through them, attackers can use technologies like WiFi pineapples or aircrack-ng to force users to connect to their wifi network.

You might have heard of WPA/WPA2 wifi encryption. This is the current standard for wifi encryption - if you're connecting to your home router with WPA2 you can be reasonably confident that an external attacker can't intercept your data. WEP has been obsolete for a long time - do not trust WEP encryption to keep your connection secure. Keep this in mind whenever your connect to an open (unencrypted) network - your laptop/phone will generally warn you of this before you connect.

Connecting over cable internet is much harder to intercept/mitm because you're not broadcasting your traffic for the whole neighborhood. In order to compromise this network an attacker will have to gain access to it somehow - either through physical access to a network port, malware installed on a host machine or router, etc. When an attacker has access to a network they then have to exploit that access through attacks such as ARP poisoning or HSRP spoofing. These attacks just MITM traffic - anyone on the network can still sniff (read, but not change) traffic, but keep in mind HTTPS traffic is still encrypted and can't be read.


Converting keys between openssl and openssh

You are missing a bit here.

ssh-keygen can be used to convert public keys from SSH formats in to PEM formats suitable for OpenSSL. Private keys are normally already stored in a PEM format suitable for both.

However, the OpenSSL command you show generates a self-signed certificate. This certificate is not something OpenSSH traditionally uses for anything - and it definitely is not the same thing as a public key only.

OpenSSH does have support for certificates as well, but it is likely that you are not using this support. Also, these certificates are not X.509, so they are incompatible with OpenSSL.

The certificate contains information that is not present anywhere else and each certificate is unique and can not be recreated at will. This means that you need to store the X.509 certificate, in addition to the private key, if you wish use the same key for both OpenSSL and OpenSSH.

If you just want to share the private key, the OpenSSL key generated by your example command is stored in private.pem, and it should already be in PEM format compatible with (recent) OpenSSH. To extract an OpenSSH compatible public key from it, you can just run:

ssh-keygen -f private.pem -y > private.pub

If you want to start from OpenSSH and work your way over to the OpenSSL side, with a self-signed certificate (for whatever reason), here's how:

$ ssh-keygen -f test-user
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in test-user.
Your public key has been saved in test-user.pub.
The key fingerprint is:
ff:36:f1:74:c7:0d:4e:da:79:5c:96:27:2c:2c:4e:b6 naked@tink
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|           . .  .|
|          + o =.+|
|        S+ o * B+|
|         .E o = B|
|          .  + o.|
|           .o .  |
|           ...   |
+-----------------+
$ openssl req -x509 -days 365 -new -key test-user -out test-user-cert.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
$ ls -l test-user*
-rw------- 1 naked naked 1675 Mar 18 21:52 test-user
-rw-r--r-- 1 naked naked 1229 Mar 18 21:53 test-user-cert.pem
-rw-r--r-- 1 naked naked  392 Mar 18 21:52 test-user.pub

From these, both test-user and test-user-cert.pem files are critical to preserve, where as test-user.pub can always be recreated from test-user as needed.


PGP Key publishing on MIT PGP Public Key Server

And that is why there are key signing parties. They're only parties in name, and not in practice. Except if there exists food and beer. A truism if there ever was one.


Could a consumer-friendly PGP-like file encryption application theoretically be secure?

All the encryption stuff with emails is "secure" as long as you can establish the link between identities and public keys. The actual cryptography and format is already implemented by most platforms, following the S/MIME standard, which is fine as these standards go (even the mail application in iOS 5 knows S/MIME). S/MIME normally relies on X.509 certificates.

At some point, there must be a procedure for ensuring the link. The concept of identity of a user is not part of the "computer world". Usual procedures entail a physical meeting between the key owner (the user) and a sworn official who performs the actual validation. This is expensive, this is hard, and this is not necessarily what we want: do we want to bind the public key with a legally defined individual or with whoever controls a given email address (for some appropriate notion of "controls") ? As usual, the difficult part is deciding what we really want with enough precision.

When the link is established, the information can be conveyed through certificates. Certificates have the nice benefit of being transport neutral: since they are signed, they can be obtain by whatever means without any security issue. This avoids having to trust your "central repository". Standards and protocols are ready for that: X.509 is approaching some level of maturity, and the central repository is known as "the Directory". The Directory can be thought of "One LDAP Server to rule them all" (in practice, the LDAP protocol has emerged as a subset of the access protocol for the Directory). There is a minor setback, which is that the Directory does not exist: it is a central, worldwide structure, and such things do not appear unless a clear need for it is found (for instance, the DNS exists because without it, the Internet would be a harsh place; but encrypted emails do not yet have sufficient political push to trigger the apparition of the Directory).

X.509 is meant for hierarchical trust management, which is appropriate for business, and would also be good if we want to use "legal identities" (your name and existence as a citizen are defined by the State which recognizes you as one of its own, and you cannot get more hierarchical than that). For loosely bound communities with a spirit of good-humoured anarchy, a Web of trust might be more adequate (but, though decentralized, the WoT implies more network traffic because trust comes from redundancy of the certification topology). One characteristic of the WoT is that it entitles every user to act as a registration authority: a RA is whoever does the "physical world" steps of verifying the identity of a user (as Tradition goes, in a bar over a pint of Guinness). The OpenPGP format contains the bells and whistles which support WoT management (it could be done with X.509 -- everything can be done with X.509, with extensions -- but the details of WoT with X.509 have not been completely worked out yet).

The "everybody is a RA" is a way to sidestep the issue of defining the notion of identity you want to achieve: every user decides what notion it uses, when emitting the certificate for someone else (signing his public key, in OpenPGP terminology). The bad side of it is that when using a public key obtained from the WoT, you do not really know what you get. The public key has been verified to be linked with... what ? It is not said.

An interesting system is Identity-Based Encryption. It is very lightweight in that it does not need a central repository of public keys at all: the public key of a user is his identity (his name, his email address...). But this still dances around the issue: IBE allows you to use as "identity" whatever can be encoded as a human readable string, but most notions of identity are still bound to the physical world ("I want to send an email to that guy") and there must be non-computer parts in the system.

Summary: for security of encrypted emails, the problem is not support software (it is already there), protocols (we have them) or central repository (the pieces are ready, it just needs to be installed on actual servers -- or, we can do without a repository by using IBE). The problem is deciding what notion of identity you want to use, and setting up the parts of the identifying procedures which are not in the computer world at all.

(Many people around the World seem intent on transferring their lives into their mobile phones. This may ultimately "solve" the problem: we no longer need to send emails to human beings, only to smartphones, and these are computers. I am not sure I want to live in such a world, though.)


Considerations for having Hashicorps vault on the open net

Well, one consideration is potential cash overflow attacks possibly. If an attacker has access to private API keys of yours that function like this:

Make request to API
API logs request and charges your account 1/200 usages
Every usage past 200 usages costs $0.05

An attacker can cause you to go into financial problems like that. See: https://www.owasp.org/index.php/Cash_Overflow

Some other abuse cases for APIs may be found here:
https://www.owasp.org/index.php/Category:API_Abuse

Recommendations? I highly recommend AWS secrets manager or Azure confidential compute. They can both different levels of assurances for the security of your API keys in different ways.

https://aws.amazon.com/secrets-manager/ - Works by providing an API that you can store other API keys in securely using FIPS compliant encryption, then all you have to secure is your secrets manager secret keys/api info.

https://azure.microsoft.com/en-us/solutions/confidential-compute/ - Works by computing secure operations in a TEE (Trusted Execution Environment), a cryptographically secure and logically separated processing unit.


Can an OpenVPN server track the client os type?

Agree with @Ohnana and I have some to add: it is possible via source tailoring to make an OpenVPN client "faceless", without any os/version/libs fingerprint. But if this openvpn is not used as a tunnel for another OpenVPN - first web browser HTTP plain session will tell everything about you


How cloud based web proxy works (ex:Zscaler)?

1) How zscaler see the clients traffic from cloud and how it filters malicious traffic?

Because it is configured as a proxy and thus the client sends its web traffic there.

  2) How zscaler protects the web applications from external threats?

zscaler is not a Web Application Firewall, i.e. it does not protect the web application but the client browsing the web. It is doing this by the usual range of techniques, i.e. blacklists, antivirus etc.


Has my server been compromised? (Ransomware related)

SSH login to my server requires a private key, and root login is disabled.

Is a sensible precaution for ssh.

  Since the sender was was admin@mydomain.tld

If you take precautions for your ssh, do you apply the same to your SMTP? You should at least have SPF configured for your domain. Do you? Is the SPF validated by your receiving MTA? This should prevent you getting emails not from a legitimate source (or at least cut down the noise).

Assuming tat SPF is not working end-to-end for whatever reason, have you checked the email headers to see if it really did originate on your servers? I think it's very unlikely it did, but if this is the case, then you have good reason to suspect that your server or the hosting environment has been compromised.

If not, then think of it as a wee prompt to get your email security sorted out.


Not able to see WebGoat requests in ZAP proxy

Have a look at your Firefox proxy settings again.

By default Firefox will set 'No proxy for' 127.0.0.1 and localhost. If you've got WebGoat running locally then you'll want to clear that field so that Firefox proxies local requests through ZAP.


Is my data safe if I run an android app (a game) on emulator inside a virtual machine

It will gather information about your host machine, but it will not be able to browse your host machine to gather data.


Why re-verify with CAPTCHA on failed form entry?

If the site has a means of knowing it's the same user in the same session, then no. So for example given a cookie or an ssl session then it seems OK to assume it's still a human user (within the limits of captcha).

If it's just a cookie that establishes the session (i.e. this is over http without SSL) then make sure to time it out tho. And you should be using SSL anyhow :-)


Encrypting using AES-256, can I use 256 bits IV?

The IV depends on the mode of operation. For most modes (e.g. CBC), the IV must have the same length as the block. AES uses 128-bit blocks, so a 128-bit IV. Note that AES-256 uses a 256-bit key (hence the name), but still with 128-bit blocks.

AES was chosen as a subset of the family of block ciphers known as Rijndael. That family includes no less than 15 variants, for three possible block sizes (128, 192 and 256 bits) and five possible key sizes (128, 160, 192, 224 and 256 bits). AES, as standardized by NIST, includes only three variants, all with 128-bit blocks, and with keys of 128, 192 or 256 bits.

To further confuse things, some software frameworks got it wrong; e.g. PHP uses "MCRYPT_RIJNDAEL_128" to designate Rijndael with 128-bit keys and 128-bit blocks (i.e. the same thing as AES-128), and "MCRYPT_RIJNDAEL_256" for Rijndael with 256-bit keys and 256-bit blocks (i.e. not one of the AES variants, and in particular not at all AES-256).


If a web server only has a 2048-bit RSA key, can a FREAK based attack still happen?

The RSA "export" cipher suites can work a bit like ephemeral Diffie-Hellman: if the server's "permanent" key is longer than 512 bits, then the server is supposed to generate a new one (dynamically) of length 512 bits, and send it over the wire as a ServerKeyExchange message, signed with its permanent private key. See section 7.4.3 of RFC 2246. The private key you see (your 2048-bit key), the one that is stored in a file or some sort of certificate store on the server, is then used only for signatures; actual key exchange (encryption of the random pre-master secret with a RSA public key) happens with the temporary RSA key that the server generated.

Note that while the server may generate a new 512-bit RSA key pair for each connecting client, it will usually not do so because of the involved CPU cost (it is possible to generate RSA-512 key pairs quite quickly on modern hardware, but the support code for export cipher suites is more than 15 years old and is unlikely to have been optimized over the years). Therefore, many servers that still support RSA export cipher suites will generate a new RSA-512 key pair upon start, and then use it for all incoming clients that want to use such an export cipher suite. The so-called FREAK attack is made somehow practical because of that reuse: it allows the attacker to spend the 8-hour breaking effort before engaging in an actual Man-in-the-Middle (because the victim, a random Web user, is unlikely to wait for 8 hours that his SSL handshake completes).


What are some ways to execute a reflected XSS attach

Point 1. is more of a (DOM-based) self-XSS issue. And as you said, point 2. and 3. are really the same (the attack happens by visiting a URL).

A GET request via a link is the most common way to execute an XSS attack. The link could for example be send to a victim via email or posted in a forum.

But there are other ways. The defining characteristic of reflected XSS is that input is reflected, meaning that the server takes some sort of value from a HTTP request, inserts it into a HTML context in the response, and the browser then renders that response, thus executing the injected code.

POST-based reflected XSS

Reflected XSS can also be performed via POST requests (which are not protected from CSRF).  Eg:

<form action="https://example.com/vulnerable" method="POST">
    <input type="hidden" name="number" value="[XSS payload]" />
</form>
<script>document.forms[0].submit();</script>

In the same manner, a GET request could be send via a form (by changing the method to GET). An attacker might choose this approach if a POST request is required, or if they think that it is more likely that a user visits a page where they can post scripts, and less likely that they will click on a link to the victim site.

Exploiting Self-XSS

Your point 1. might be exploitable if the site is frameable. Some browsers - eg Firefox last I checked - allow the dragging of text into iframes (not out of them though).

By performing a clickjacking attack, an attacker could get a victim to "enter" the XSS payload and execute it.

Another way to execute a self-XSS would be to simply ask the user to post the payload ("can you post this long, HTML formatted post [containing an XSS payload] to your website?", "Can you upload this harmless image [whose filename contains an XSS payload] to your blog?", etc).

Session tokens as (non-) protection

  do session tokens protect us from these approaches?

If your session tokens are always included in the URL, and the page doesn't reflected any input when the session token is missing (and the session token is securely generated), then that would indeed protect against (non-self) reflected XSS that send a victim a malicious link. In the same manner CSRF tokens protect requests against (non-self) reflected XSS.

However, now you have a new problem. Sensitive data in URLs is strongly discouraged. It can easily leak via referers, when users share links, etc. And once that happens, anyone could have access to that users account.


How SearX private instances protects users privacy?

Well, SearX is great, if used by more than one user. At least your family, possibly friends or even everyone in your area. The big search engines would not be able to say who is searching for what, only the private instance would. However, if you want additional protection, try using a VPN/Tor/proxy to hide the IP of your private instance. Without some IP hiding and many users using it, SearX does not actually increase privacy, but privacy is not really what it was mainly designed for. It tries to circumvent censorship by using multiple search engines. It decreases the likelihood someone can control what you are able to see. Imagine for example google not showing its privacy issues and data breaches in its results.


Partially forgotten encryption password for Windows users

The reason no one has been answering your current question and the follow up question is that there is no existing Windows brute forcing software for the Veracrypt header. Your best bet would be to find a way to brute force the Veracrypt header with THC Hydra/Cygwin.


Storing credit card data on behalf of customers: and transfer the data later

If you touch the cardholder data at all, even if only to receive them and immediately transmit them elsewhere, you have PCI to worry about. (Maybe not directly - if you are not taking payments yourself, you don't have that as a contractual responsibility... but the merchants who do must ensure you, as a third-party service provider, are compliant.)

A tokenisation service only allows you to reduce the number of systems that are in scope, by taking storage out of the equation; it doesn't allow you to escape PCI entirely. You would have to create your own workflow for distributing tokens to third parties and authorising them (strongly!) to view the detokenised numbers; and this would certainly be subject to all the rigours of PCI.

Merchants avoid being dragged into PCI scope by letting a payment processor deal with the whole flow of cardholder data - redirecting the user into their processor's web site when it's time to enter card number, and redirecting back out at the end. I am not aware of any service similar to a payment processor that will take those details for you and, instead of doing an transaction, hand them over to a separate merchant party.

Your model is inherently pretty risky. Your merchants will be doing Card Not Present initial transactions without either the security code (CVV2 et al) or 3-D Secure (VbV et al) in this workflow. This puts a lot of liability on the merchant's shoulders, and puts you at risk of legal fun if there is anything at all wrong with your systems.


Open-source alternative for CryptGenRandom?

The simple answer is that if you don't trust CryptGenRandom() then you are doomed. Indeed, CryptGenRandom() is provided by the operating system, and if the OS is hostile then there is very little you can do to defend against it. An hostile OS can inspect all your RAM, log all your passwords, send all your data to external third parties.

The less simple answer relies on a subtlety, which is that you may mistrust CryptGenRandom() while not actually supposing that the OS is hostile. Maybe you consider that CryptGenRandom() is simply flawed, by accident and not by malice, and delivers randomness of poor quality, while no other component of the OS actively tries to cheat on you.

In that case, it becomes sensible to augment CryptGenRandom() with some extra entropy. Entropy comes from physical events and the OS is ideally placed to gather physical events; applications are in a much less ideal position for that. Nevertheless, some people have tried. For instance, there is an applicative entropy gatherer in GnuPG (at least in version 1.4.14, look for the rndw32.c file).

The correct way to gather entropy is to take all the "events" (e.g. "key X was pressed at time T"), concatenate them together, then hash the whole lot with a proper hash function like SHA-256. Then use the output as seed for a cryptographically secure PRNG. In particular, don't shun CryptGenRandom() completely; call it to get some bytes of output (say, 16 bytes), and add that output as an "event" like all the others you gather. The beauty of the hashing is that even if the event is flawed in a malicious way, it cannot lower your resulting entropy; it can only contribute positively (at worst, it does not contribute significant amounts of entropy).

The hard part of random generation is not obtaining entropy; it is estimating how much you got. An hardware event is "useful entropy" exactly inasmuch as any potential attacker cannot predict its contents. For instance, an attacker observing the network may predict the exact moment your machine receives an incoming packet, with precision down to, perhaps, the microsecond. If you time that event with nanosecond precision (Time Stamp Counters are convenient for that -- Windows calls them "performance counters"), then you may consider that each incoming packet yields 10 bits of entropy (because 210 is approximately equal to 1000, which is the ratio between microseconds and nanoseconds). It is all relative to a specific physical context; making a one-size-fits-all RNG in pure software thus necessarily implies a lot of overkill.


What a great question. I think this is one of the things that divides the games industry- do you centralise your servers to keep control over them, but then suffer from lack of flexibility to gamer needs and be accused of ruling with an iron fist or do you give control over to the gamer population and run the risk of malicious or tainted servers.

Three thoughts occur to me- none are ideal, but might be of use.

Announce configs to clients- this won't put off major compromise of the server but will increase the effort required from the malicious party.
Go down the route of trust and reputation, and have gamer rate servers whether they think they are honest or not. This also has issues, and rep can be gamed too but it is another option.
Provide the server software as a module you can query (a la punkbuster and valve's own checks) and disable on inconsistencies. Again, it has been proven again and again that this type of thing will be broken at some point as someone analyses the code to understand what response to send back, and it will annoy server owners, but it will also increase the effort required from the malicious party.


John The Ripper Unknown ciphertext format name requested

Use the "Jumbo" Community supported version of JtR. This has extra hash types and various other optimisations, but may need to be compiled for specific operating systems, such as Ubuntu Linux.

There are some instructions on compiling it at the JtR wiki


SonicWall is a company, now owned by Dell, that makes security appliances.

http://en.wikipedia.org/wiki/SonicWall

I am fairly certain you can find the specifics for any device you own on Dell's website or at sonicwall.com.


HIPAA doesn't explicitly mandate MFA, but because of updates to NIST guidance (800-63), it would be very reasonable to argue that a solution without MFA is deficient to meet something like section 164.312d, and therefore does not meet HIPAA requirements.

That said, whitelisting IPs is a pretty mediocre security solution and is definitely not considered to be MFA.


Hping3

Hping3 doesn't work on layers above layer 4. If your daemon digs through packets, then you need to use -E to fill the TCP data. (You then use -u to end the communication.) But, I'm not sure you can use hping3 to make a connection to a service on a port in the way you describe.

hping3 man page

Connecting Alternatives

It almost looks like you want to use netcat, or sbd, which can send commands.

nc 127.0.0.1 9999


How can a passphrase with 256 bits of entropy practically be constructed & memorized?

A common word of the English language has approximately 11 bits of entropy. That means a 256bit passphrase (passtext?) would require 24 words.

How could one make up a text of that length which is still easy to memorize? You could write a poem. The art of writing poetry and memorizing poems is not hard to learn. It doesn't even has to rhyme. In fact, not rhyming makes it harder to crack. Have fun!

However, we assumed that all words are completely random. In natural language, some words are more likely to appear after others. Poetry also usually conforms to certain rules and structures which further reduces the entropy. This answer on linguistics.stackexchange.com comes to the conclusion that the entropy per word in a poem goes down to about 5 bits per word, so you would need to write and memorize a poem of at least 52 words to get over 256 bits of entropy.


How to protect API from from malicious usage

The API needs to be secure, so don't try to make trade-offs here. It won't be good ;-) However, don't trade-off on performance either, it needs to be very fast so then it will be stable. Use Cookies which are very good (there's plenty of info around here).
Apart from usual security precautions (Cookies etc), the following I found to be the must:

Good limits on number of concurrent requests to Tomcat (or whatever you use, it's normally in web connector directive) - you can load-test it so server is not overloading on full load, so that makes servers not crash under full load but also they got well utilized, for example with ab -c <number of connections>. And then, in front of these Tomcats put load balance to distribute traffic and shield from other attacks like packet floods. Load Balancer should have tuned TCP/IP stack for such scenarios (see below).
Geographically dispersed servers in Cloud, so with GSLB load balancing and autoscaling
Try to use in-RAM cache as much as you can
Use scalable databases, like DynamoDB in AWS, but good MySQL instance will also do, so they can scale-up with your load
Make sure any single API function is not slow, this can be done in unit tests (so with every test run you can see whatever there's no potential target for DDoS), making all API calls very fast you basically make DDoS problems very small and your website very nice.

The above things in bold are what usually I do after developers do their stuff basically to make it faster and more resilient and that's my 4 golden points :-)

From my experience it takes 20GBps network and 4-6 32 core servers to mitigate any spike like that to Tomcats anyway. It just doesn't happen more than that and the resources today are cheap to deal with it, and even on demand. The problem is when something is slow or not scalable like Databases, then the resources go too high and that's the problem.

For developers doing the API the main point is to use in-RAM cache. The rest is infrastructure / server with Tomcat build. I've seen some developers actually doing things like that and that's good and simple approach. So instead of every time checking Cookie with database, keep it in RAM, use sticky sessions etc. Same for other things. Like one poller to database which loads data into RAM every minute and other threads are using it without ever touching DB. I've seen this approach as well.

Infrastructure-wise, it's good to have Load Balancer in front of Tomcats and if it's not Cloud one, then you can do following.

Setup normal load balancer like HAProxy and put limits for each server, so in case of large number of real HTTP requests you can process them and forward to Tomcats, other software might be able to drop or filter bad requests base on configured rules - you could try Varnish Cache which is Cache, but for Load Balancer with filter it's also excellent and you can program your own logic.
Tune the TCP/IP stack of load balancer so it's resilient to large number of requests or SYN packets. So following tuning is effective:

No IPTABLES on it (just filter things on switch)
Disable SynCookies net.ipv4.tcp_syncookies = 0
Try net.ipv4.tcp_tw_recycle = 0
And net.ipv4.tcp_tw_reuse = 0

The last two can help achieving a lot's of incoming new connections per second.


In the context of FIDO U2F, when is a new ephemeral key reused, or cached?

First a quick FIDO U2F Cheat Sheet here (because it is easy to get lost...)
www.neowave.fr/pdfs/FIDO-U2F-CHEAT-SHEET.pdf

Regarding Page 7:

FIDO U2F stored identities are based on public and private keys (asymmetric cryptography), each website service account makes the FIDO U2F device (it can be FIDO U2F USB Security Keys, FIDO U2F NFC Cards and FIDO U2F BLE Devices soon) generating its own key pairs. This is not like a standard PKI smart card solution where most of the time there is a shared user identity certificate. But... each just after being generated on the FIDO U2F device, each public key is digitally signed by a "production private key" inside the FIDO U2F device before being sent back to the server. The FIDO U2F provides a "production public key" inside a "attestation certificate" attached to the public key and public key signature. This "attestation certificate" and associated production public key may be the same on several devices from a same production batch ("batch of devices") and info inside this certificate is signed by the "Manufacturer Private Key"... and if you make products that are certified by the FIDO Alliance, you can (not mandatory) even register the "Manufacturer Public Key" on the official metadata service here: fidoalliance.org/mds/ where info is signed by the Fido Alliance private key (root cert here: mds.fidoalliance.org/Root.cer)

So.. as you see, even if "user keys" are anonymous and isolated/different (ephemeral keys) for each server/services, there is still a kind of chain of Trust you can find and use. (Note: for many reasons, most of services are not verifying this chain for now)

Regarding Page 9:

This is a note about standard PKI devices (smart card protected by PIN) not about FIDO U2F. Since asking for a PIN for each action with standard smart card PKI based solution may be tedious, this PIN entry is sometimes "cached" to simplify user interactions and this may break part of the solution security. This is a way to explain the FIDO U2F user experience choice: using name and password THEN FiDO U2F device as a secure second factor (without PIN protection).


Is it possible to go undetected on a WiFi network?

One thing you can do is disguise yourself. Look at the devices on the network and pretend to be like them. Change your hostname to match their naming scheme, change your MAC address, and if you feel really cool, expose the same types of services on the same ports (granted there is a lot of ways to go wrong there...). If the devices don't have general access to the Internet (for example, if it's an IoT network where HTTP is blocked but NTP isn't), see what ports the other devices are using and try to use that to communicate with your external server (which can then translate the traffic into standard web traffic if necessary). Be warned there are ways to detect suspicious traffic that's using the wrong port.

However, that's all targeted at sophisticated networks. If you're dealing with a home network with a cheap WiFi router, you can sometimes evade detection by... using a static IP address. Some routers will only list DHCP clients in their web admin pages.


Can web sites detect whether you are using private browsing mode?

Note this answer was given in 2011. Today the answer is an unequivocal YES -- as of this writing in 2020 there are reliable techniques in wide use and have been for a while. Please see one of the good current answers below 1 2 for more up to date information.
I'm not sure you could reliably detect private browsing, but I think you may be able to apply some heuristics to make a good guess that a user is using various privacy-enhancing features. As indicated in my comment on the question, whether this is good enough or fits your application depends on what you want to be able to do in reaction to detecting private browsing. As Sonny Ordell mentioned, I'm also not sure that you can distinguish private browsing from the ad hoc use of various privace-enhancing features (e.g. manually clearing history or cookies).
Let's assume you operate a web application, and you want to detect when one of your users (with an account) switches to private browsing. I'm specifying that the user has an account, because this strategy relies on tracking various bits of behavior data. The aspects of private browsing are (at least in Firefox): history, form/search entries, passwords, downloads, cookies, cache, DOM storage. I'm not sure how to probe for downloads, but I think the others can be probed. If you get a positive detection on all of them, it seems more likely that your user is private browsing.

In the trivial case, you keep track of (IP, user-agent) for each user. When you get a cookie-less request for a matching (IP, UA) record, you might infer that the corresponding user is private browsing. This method fails (no detection) if:

He uses something like ProxySwitchy or TorButton to activate Tor during private browsing, thus changing IP.
He switches to a different browser (e.g. usually uses FF and switches to Chrome for Incognito mode).
The switch to private browsing is not immediate and his ISP has issued a new IP (e.g. on Friday he was 10.1.2.3, he didn't use your app over the weekend, and on Monday he is 10.1.4.5).

As mentioned in Sonny Ordell's answer, if another person uses the same browser in private browsing mode to access a separate account on your site, you will get a detection -- but this is a slightly different case than if the "normal" user simply switches to private browsing mode.
You'll get a false-positive if the user simply clears his cookies for your site, or uses a secondary profile (e.g. I keep a few different Firefox profiles with different sets of plugins for certain testing and/or to avoid tracking, though I'd guess this is very uncommon).

As a more complex check, you could use something like EFF's panopticlick and maintain a browser fingerprint (or collection of fingerprints) instead of just the UA for each user. This fails in situation 2 mentioned above (e.g. if the user exclusively uses FF for identifiable browsing and Chrome for incognito). The fingerprint will be much more generic (and thus much less useful) if the user has javascript disabled. The fingerprint will change if the user selectively enables javascript in different sessions (e.g. NoScript with temporarily allowed sites).

You may be able to defeat issue 1 (Tor) by detecting access via a Tor exit node, and combining this with fingerprinting. This seems like it would only be helpful in a narrow range of cases.

Instead of just cookies for the checks above, test localStorage. If it's typically enabled, and your key isn't in the storage for this visit, and the fingerprint matches, then this is probably private browsing. Obviously, if the user normally has storage disabled, then you can't use it. The failure modes are similar to those described above for cookies.

I haven't tested or developed the idea, but I suppose you could play games with Cache-Control. (A quick search reveals that this isn't an original idea -- that project has what looks like proof-of-concept code.) This strategy fails if the user goes through a shared caching proxy -- the meantime page mentions anonymizer.com. Firefox, at least, doesn't use the cache in private browsing mode. (See this site for a demo of cache-based tracking.) So you could combine this with the UA/fingerprinting mentioned above: if your cache tracker indicates this is a first visit, then you can guess that the user is private browsing. This fails with a false positive if the user cleans his cache; combine with other techniques to get a better guess.

You could detect and track, for each user, whether the browser autofills a certain form element. If you detect that a given user doesn't get autofill on that form element, you might infer private browsing. This is brittle -- perhaps the user is not using his "primary" computer, but you could combine it with fingerprinting as mentioned above for a more reliable guess.

Side-channel timing attack: detect and track the typical time it takes for each user to log into your app. There will be variations, but I'm guessing that you could get an accurate guess about whether someone is using password autofill. If a user normally uses password autofill (i.e. fast transition through the login page), and then for a given visit (with a matching fingerprint) is not using autofill, you can infer private browsing. Again this is brittle; combine with other techniques for a better guess. You'll also want to detect and correct for network latency on a given page load (e.g. perhaps the user's network is just slow on a given day, and a slow login page transition is just latency and not a lack of autofill). You can be slightly evil and auto-logout the user (give them a bogus error message, "please try again") to get a second data point if you're willing to annoy your users a bit.

Combine this with what you mentioned in the question about detecting if the user is logged in to other services (e.g. Facebook), and you can have more confidence in your guess.

If you're really motivated, you could play games with DNS and tracking page load times. A quick test of FF 3.6 and Chrome 15 seems to indicate that neither browser clears the DNS cache in private browsing mode. And the browser has absolutely no control over the local system's DNS cache. If you use a side-channel DNS timing attack to perform user tracking as an alternative (or in addition to) fingerprinting, you may get a more reliable guess. I'm not sure how reliable tracking via DNS timing will be.

Detection of "anonymous" users in private browsing mode will be much harder, since you haven't had the opportunity to accumulate data on their "typical" behavior. And, since most of the features only kick in when they end the browser session, you don't really know if they're ever going to be back.
With that said, here's an idea to detect private browsing by anonymous users, if you're willing to be evil, and you had some resource for which you knew a user was willing to give your site a second chance, and you can force the user to enable javascript. Track fingerprint, set a persistent cookie, localStorage, cache -- whatever you can do to track the user. If it's a first visit according to your fingerprint, crash/hang the browser via javascript (or flash, or whatever evil tricks you know). Suck up tons of memory, or get stuck in a loop, or whatever it takes so that the user closes the browser. Then when they return, you see (from the fingerprint) that it's a second visit. If the cookie/storage/cache/etc aren't set, then you can infer that the first session was private browsing, and I suppose you might infer that the second session is probably also private browsing. This obviously fails if the user doesn't come back, or if you can't crash / convince them to kill the browser window. As a bonus, if you send them to a custom URL, and they're in non-private-mode and restore the browsing session then you can guess they aren't in private browsing mode (unless they bookmarked the URL).
Everything above is full of holes -- plenty of room for false positives or negatives. You'll probably never know if I'm using private browsing, or if I'm running a browser in a VM with no persistent storage. (What's the difference?)
The worst part is probably that if you do get an answer with a reliable method for detecting private browsing is that it seems unlikely to remain viable for very long as browsers either "fix" it or users find workarounds to avoid detection.


Background checking company requesting sensitive documents via email

First thought that comes to mind is whether it is even legal to require all those documents. Passport makes sense (what happens if you don't have a current passport?), but demanding bank statements is a bit skeezy. Common, but skeezy (just because many companies insist on something, doesn't make it legal). That said, this is an issue to ask a local lawyer, as these things are different between countries.

Furthermore, even if it is legal, the question is are you comfortable sending these documents to them (especially bills and statements). In my opinion, you should never agree to this type of thing - however, if you are committed to getting this job, you might have to comply with whatever they insist. You could still try discussing it with them - explain that you're not comfortable with it, and ask the employer (NOT the specialist company) if it is absolutely necessary (it usually isn't, but they ask anyway), and only if they still insist go along with it.

However, all the above is a Workplace.SE type of answer, not a SECURITY answer... so here are some options for you (assuming you want to be sending these documents to them):

Ask them for their public key (PGP or S/MIME, whatever your flavour) and simply send it to them encrypted;
Zip up all the documents and encrypt the archive, send them the password out of band (e.g. call and tell them verbally). Of course, strong passphrase, etc.
Ask if they have a secure service to upload files to, via their website / file safe / etc.

You should probably also ask for some assurance that your documents will be adequately protected once they've received the files (though don't be TOO optimistic about this being forthcoming (i.e. I doubt it)).


How can I intercept localhost traffic to/from WebGoat with ZED attack proxy?

Setting the proxy host and port and clearing the 'No proxy for' field is all you should need to do.
Have you tried refreshing the relevant WebGoat page (Ctrl-Shift-R)?

I use ZAP to proxy to local applications all the time on Linux, Windows and Macs with no problem.

Btw ZAP is not the new name for WebScarab, its a completely different product ;) But WebScarab is no longer maintained while ZAP most definitely is :)


How does Client-Side-Exploitation get the System-level-shell in Metasploit?

To understand how browser based exploits work, you should understand how browsers work. I have found a nice detailed article about it. How Browsers Work.

The summary point that you can get from the article related to the browser exploits is that browsers have javascript engines which translate javascript instructors into machine code. So the browser engines are translators between the browser and to your machine. Firefox's SpiderMonkey is an example for that. It is written in C/C++ as almost all browser engines.
Since each browsers have its own engines, the browser based vulnerabilities are specific to the browser( also even Operating system specific ) . An exploit code for Internet Explorer 6 probably will not work for Google Chrome, for example. In addition, if you search for more browser vulnerabilities, you will find out that the vulnerability platforms are changing. There are exploits work in only some Android versions for example. You can check out several vulnerabilities of Google Chrome as example; Google Chrome List of Vulnerability
.

Most of the browser exploits are rely on the classic buffer overflow attacks which is also used in Aurora exploit. Therefore, any vulnerability in these engines might be exploited by causing a buffer overflow by using javascript or html dom objects.

In short, Javascript or html can not lead to "Remote Code Execution" by any buffer overflow attack. itself. However, the vulnerability is exploited in the browser engine, not in the browser itself. Javascript or HTML are just used as a tool to exploit the vulnerability in the engines.  You can read more about Auroa vulnerability :
Rapid7 MS10-002 Microsoft Internet Explorer "Aurora" Memory Corruption and
also from here: CVE-2010-0249

EDIT:
I have found out an article about Microsoft Edge's Javascript Engine, it also describes well the principles of browsers' workflow; Microsoft Edge’s JavaScript engine to go open-source

Extra Reading: Understanding How the Chrome V8 Engine Translates JavaScript into Machine Code


Is having a hidden directory under /etc safe?

Yes, that's safe. There's nothing inherently insecure about having a hidden directory under /etc. The only reason rkhunter flags it is that it's uncommon for legitimate programs to do it, and when malware does it, it makes it less likely that you'd otherwise notice it.


entropy of FIPS-181 automated password generator

Note that FIPS 181 is from 1993, which is ancient, in computer security terms.
The paper doesn't say how much entropy the passwords have.  It does say:

  Approximately 18 million 6-character, 5.7 billion 8-character, and 1.6 trillion 10-character passwords can be created by the program.

The question is whether those passwords are all equally likely.  And indeed
the answer is no according to A New Attack on Random Pronounceable Password Generators.

But what that does give us is an upper bound on the entropy.  log2(1.6e12) is 40.5, so the best you could hope for is about 40 bits of entropy with a 10-character FIPS 181 password.  Stephen's calculation of 64 bits for 16 characters seems right, since this estimate amounts to about 4 bits of possible entropy per character, though again that would be an upper bound.  20 characters would max out at 80 bits of entropy.

It would be better to use something like the apg program, which include upper case, digits and special characters by default and you can ask for pronounceable passwords or not.

I looked at NIST SP 800-63-2 Electronic Authentication Guideline (Aug 2013) and didn't see anything like "NIST recommends 80-bits for the most secure passwords".  It does set out lots of scenarios and conditions.  I suggest reading it and applying it to your threat model.

RFC 4086 - Randomness Requirements for Security presents some example threat models and how to calculate the entropy desired for each one.  The answers vary between 29 bits and 128 bits of entropy needed.

See also
How Secure is a Pronounceable Password? In means of entropy - Cryptography Stack Exchange


Why is Message Labs sending mail in plaintext?

TLS is initiated by the sending server. MessageLabs (or Symantec.cloud as they are now known) provide email scanning services for anti-virus, spam, etc and support TLS at two levels:
    - Opportunistic i.e. if the original mail server initiates a TLS session with the MessageLabs infrastructure it will scan the email and then attempt delivery over TLS.
    - Enforced - the enforcement is usually configured at the domain level and the message must be received and delivered over TLS.

I suspect in the instance you are showing the original email was not received over TLS so the delivery was completed using SMTP.

I'm not sure about the reference to DNS but MessageLabs has a global infrastructure with data centres in the EU, US and APJ which includes DNS servers. Customers are generally configured on their local infrastructure i.e. EU customers are configured on EU infrastructure, US customers on US infrastructure, etc. Multinational customers maybe configured on both EU and US infrastructure.

Hope this helps.


If you connect through a website via a proxy, and the proxy doesn't save information, can you still be linked back?

It is technically possible in some cases, it depends on what exactly you are doing.

Some packets you send out, and this is more common on some protocols than others, contain identifying information in the packet itself. If you are using HTTPS (as one example) and you don't log in or out or significantly use cookies, it is very unlikely you can be traced. Same goes for all other protocols designed with privacy in mind. However, if you are using, say, an email server (SMTP) over the connection, your email address will be in quite a few packets, and it is very hard to encrypt the actual address and still get the mail to where it is meant to go, for obvious reasons.


Linux forensics questions (ssh config, user activity)

Welcome to the Wild and Wonderful World of Forensics! So you have your images. Before you do anything else make sure you get a checksum of the disk images and also make a copy of them. The copy means you can work on it instead of the original, allowing you to roll back to the original state if you accidentally change anything on the system. The hash will allow you to validate your working copy against the original. For this purpose, just about any hashing algorithm should be sufficient.

In order to really understand what's going on, or went on, in a system you must first figure out what it was. It is obvious that you're looking at some form of UNIX derivative, probably a Linux, but you should attempt to determine which family it belongs to. Is it a RedHat, a Debian, a BSD, Solaris, or even something completely off kilter like AIX or HP-UX?

The type of system you're inspecting will determine exactly what log files you need to browse and how you determine where configs are stored. The advice to start in /var/log is pretty good, that is the default log location for Linux systems. Depending on the specific flavor you may also find useful information in /var/log/audit from the auditing subsystems (if installed) or the RBAC/MAC systems like SELinux or AppArmor.

Answering your specific config questions, account information is stored in a number of files: /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow. The construction of each is well understood and easily researched. For other services the specific config files, and their construction, will require both research as well as experience based understanding on your part.

Performing a proper post-incident investigation requires that one have a deep understanding of the system you are analyzing. You will not only have to understand what files to look at, but also what files imply what, how different configurations can interact with each other, and (when carving) how a filesystem is actually constructed. Having been thrown into the deep end, as it were, will be tricksome, but can be gratifying. It's not without merit that the mantra of the Offensive Security team is Try Harder™. While this isn't exactly offensive work the principles definitely apply here.


Is the original IV mandatory to decrypt an encrypted message?

For AES-CBC, if you have the key, but not the IV, then you can still decrypt the entire message, except for the first block.  See https://crypto.stackexchange.com/questions/1129/can-cbc-ciphertext-be-decrypted-if-the-key-is-known-but-the-iv-not for more information.


When is it worthwhile to pursue a hacker?

is it at reasonable to pursue the attacker by contacting the
  IP-owner's ISP?

Most likely not. Any moderately skilled attacker would simply steal someone else's wifi or use a proxy. You can then contact that proxy's ISP which is probably located somewhere in Togo and you will never get a reply. If the attacker sets up servers for backdoors and alike, they will be either temporarily or also hosted abroad.

  Is there a damage/cost threshold that would make pursuit worthwhile?

Yes but that threshold is really high. Even when the damage is staggering, pursuing someone over the internet is neither really effective nor is there any hope to get for example stolen assets back. One big reason why cybercrime is so profit-yielding is the fact that it's hard to track down the attackers.

If the source of the attack is from another country (Russia, China), you have absolutely no chance to catch the attacker. Of course, the same applies many other countries.

  Is there a relatively standard or productive manner in which companies
  (or individuals) deal with attacks on a legal level?

Yes, at least in Germany. This is highly depending on the respective national framework of course. Here, critical infrastructures have a central office to report cyber crimes to and get external help, but pursuing the attacker is usually beyond the scope of the investigation. Companies even have to report certain attacks to the police.

As a private individual however, you will most likely only be able to complain to the police. And the police is completely incompetent in that regard.

Almost all methods against cybercriminals are mitigation and prevention, since tracking someone down who attacked from abroad is borderline impossible.


What will happen to my Windows PC if I visit a site from a network marked as malicious by google safebrowsing

If the entire network block is marked as malicious by Google, a lot of innocent sites will end up marked as malicious, as you have seen.

If you are sure that the site you want to visit is not malicious, you can navigate to them and nothing bad will happen. That message is just a warning. Your web filtering software (if installed and updated) can protect you.


How to monitor password protected web page

You could use something like Pingdoms Transaction Monitor (https://www.pingdom.com/product/transaction-monitoring/), but be aware that you are giving credentials to a public service.

You could also use powershell script or similar to do the same.
See this question on stackoverflow:
https://stackoverflow.com/questions/12282842/how-to-login-to-website-with-basic-authentication-using-powershell


Is checking for reputation of a URL a good approach?

Checking the reputation of a URL is a useful approach but of course does not cover every malware or phishing URL. URL based filtering is very fast when compared to the analysis of the response payload. This allows for an early and cheap blocking of the access to potential malicious resources and thus might also preserve more resources to deeper analysis of yet unknown sites.

Reputation is commonly not done based on a specific URL but on the site, i.e. if there is a single definite malware infection on this site then the whole site (or sometimes even the IP address) gets a bad reputation. This makes sense because if the attacker manages to have one URL on the site deliver malware then chances are high that the attacker is able to control more than this one URL.

Reputation services can also not simply be tricked by letting somebody like virustotal check the URL or a even the whole site. Instead these reputation services scan the web themselves and also get user input or information about bad sites from analyzing phishing or spam mails. They also include historical information about domains, i.e. how old the domain is, how often the IP addresses have changed in the past etc. One widely used reputation service is Google Safe Browsing which is enabled by default in Chrome and Firefox.

This does not mean that attackers don't try to work around these reputation services because they actually hamper their business. One way is to hack sites with a good reputation and use these for malware distribution. For example Jamie Olivers website was hacked multiple times in 2015 and used to spread malware.


I'm currently receiving a targeted attack

Just to add to @Polynomial's (what seems to me to be correct) answer (upvoted), when you talk to your friend, don't approach him/her as if it's a confrontation. I've seen many folk (after being hacked) react so badly because they felt they were confronted.

I think you can quickly confirm if it is a phish by asking if he's aware of the situation or if any of his other friends have received such emails? If his account was hacked as Polynomial rightly suggested then I doubt you're alone in receiving such a spam/phish, unless for some (rare) reason you're being specifically targeted. I receive similar emails around once per month from some friend, whose webmail password has been compromised (it's interesting when it happens to a security mailing list).

Looking at the mail headers, the X-Spam-Status:   No, score=-0.1 headers show that everything on the mail was well-constructed, no content appearing like a spam mail, most likely a low SPF rating on the sending mail server and the websites referenced have no prior in terms of being a phishing or compromised URL. Taken with the results below, this would seem to indicate freshly compromised sites.

I also checked the reputation of the two sites (I regularly do this on such occasions and notify the vendors and the local CERT of such sites, I'd recommend doing so). I used to volunteer at a CSIRT and such notifications are invaluable.

kaosbolaclothing.com

Google Safe Browsing - no previous hosting of malware
McAfee - "fashion & beauty" & deemed to be clean
Senderbase - unknown

www.sidat.com.mx

Google Safe Browsing - no previous hosting of malware either
McAfee - uncategorised & deemed to be clean
Senderbase - unknown

From experience, I've found the Websense Lookup Tool to be the best but I no longer have a login there.

I unfortunately don't have time to actually look at the sites to see if they try to exploit anything but I'd be interested to know :)


How would you prevent someone from selling his persistent cookie to someone who is not an institution member and wants to gain access?

Can you prevent someone from selling their password to get similar access?  Do you think you need to?  It's pretty much equivalent.

Do you need to do this?

From my experience being inside/outside academic institutions with journal access, there's always some amount of sharing resources as a favour (e.g. "hey, could you send me a PDF of this paper?").  You'll never be able to stop that, because it is actually being manually accessed by a legitimate user on a correct machine.  However, I have personally never witnessed student/staff trying to make money from this.

Monitoring

Even if they wanted to make money like this, then I don't think sharing cookies is the best way - it's certainly not how I'd do it!  Protections you could add to the cookie system (e.g. fingerprinting the user's browser and checking it stays the same, etc.) won't apply to other methods.

Instead (if this is actually a problem), a reasonable and robust solution is to monitor user's usage patterns.  If they are downloading 100x the resources of anyone else, or if they fetch resources consistently for 250 hours straight (the longest humans can survive without sleep), then there's probably multiple users or an automated system at work.

However, this monitoring solution doesn't have to be included from the beginning, it can be added in later - and until you have evidence that it's actually a problem, I think it should be quite far down your list of things to do.


What is the need and purpose of packet injection within WiFi attacks

Wireless networks work in predefined modes which have specific functionality but also come with strict functional restrictions. Wireless attacks require a higher control over the lower layers of communication in order to send and receive any kind of data.
When you are in the default mode (Station Infrastructure Mode), you have to follow strict rules imposed by that mode, you can't even directly talk to a different client in default mode. So, for more control, you need Monitor mode to listen to any communication in the air. But Monitor mode (if supported by your hardware, chipset, firmware, driver, driver hack and OS wrapper) doesn't standardly allow you to send data. This is where packet injection comes in.
Packet injection means sending data while in Monitor mode because it's a passive-only mode (Source: wireless.kernel.org).
Sending and receiving management and control frames is necessary for impersonating base stations and clients, and for listening to frames that are meant for specific adapters.
The dreadful deauthentication frame, apart from the DoS it can cause, it's the first stage in a multi-stage attack. It can be used to capture the WPA 4-way handshake or to force a user into a malicious AP, or to recover a hidden SSID, and even generate ARP frames for a WEP replay attack.
So, packet injection and monitor mode are two features that provide the much neaded low level control for attacks. And they are missing from some wireless adapters in order to restrict certain layer 2 operations for security reasons, like sniffing and spoofing frames because of poor manufacturer support, lack of open drivers, and people hacking drivers.


How dangerous is it to use CSS styles from an untrusted source?

It is not advisable to use CSS styles from a source you don't trust, without some sort of review.
There are some risks, particularly on older browsers.  Some older browsers provide a way to embed JavaScript inside of CSS, so that the JavaScript will be automatically executed as soon as the browser loads the CSS.  Browsers with this problem include IE6, IE7, as well as later versions of IE in IE7 compatibility mode; also IE Mobile 8.  (In those older browsers, this is supported through CSS constructs like url, expression(...), behavior, -moz-binding, -o-link, and probably more.) This weakness of older browsers allows an attacker who supplies malicious CSS to do anything an XSS attack can do.  Using CSS styles from an attacker is basically a self-inflicted XSS vulnerability.
Fortunately, modern browsers have closed all of these JavaScript pathways.  Unfortunately, some users still use older browsers, so if you use CSS from an untrusted source, you'll be putting those users at risk.
That said, I would recommend taking a risk management perspective.  How great is the risk?  How great is the benefit?  In this case, I suspect the benefits are probably worth taking a slight risk, particularly if you adopt some mitigations to protect yourself.  I would recommend:

Review all of the proposed CSS before loading it into your site.  Make sure you understand it, and it isn't obfuscated.  Make sure it looks clean and well-organized and readable.  Make sure it doesn't load external CSS or other external resources.  See whether it looks reasonable to you.  If you spot it doing stuff you don't understand, maybe don't use it.

Check the source.  Are they a trusted user of your community, who have been spending time on your site for a long time?  Or are they a new user who you have little history of?  There's probably less risk from a trusted member of the site, and more risk from an unknown.

If it were a site I was running, I'd probably do it.  Yes, I'd use the above mitigations to protect myself -- but I wouldn't let security get in the way of having fun things.
Other resources: CSS security, from ha.ckers, Ending expressions, from MSDN


Strange GET requests to my Apache Web Server?

This looks like typical fingerprinting scans. Some tools send out odd requests to determine the type of server and firewalls you might have in place.

Try to replay those requests to see how your site responds and determine if there are changes you need to make to your environment to make it fail gracefully and consistently, if possible.

It is 'just' a probe, but I would put that IP on a watch list for further activity.


Port-forwarding to a web server on Raspberry Pi

The problem is less the open access to a server with some unimportant task. The problem is more that this server is probably located in the same network as more important systems (unless your home router provides network separation, most don't). Thus if an attacker manages to hack into this unimportant server he gets access to your whole important network.

There are several ways to make this harder:

If your home router provides network separation put this server into a network separate from the rest of your system. There are many information online about this.
Limit access to the server by requiring some kind of authentication. This could be plain text authentication with username and password, some secret authentication token or client certificates if HTTPS is used. What you use here depends a lot on how do you need to access the server (web browser from any system, web browser from specific system, mobile app...). In case of IFTTT see here for the possibilities you have.
Make sure that nobody can sniff the traffic and thus capture any plain text authentication or modify the traffic by using HTTPS.
Even if the attacker gets authenticated access to the API make sure he cannot exploit it further by using good programming practices and hardening the setup as described in the following.
No direct invocation of shell commands with arbitrary user controlled parameters, i.e. limit the parameters to specific values in the server (don't trust the client) or sanitize parameters if arbitrary values should be possible.
Don't run the server as root but run it as a user with low privileges. If you need to have root permissions to control the hardware write a separate local service with a small and secured API and let it communicate with your externally reachable web service (see privilege separation).
Ideally add some additional sandboxing, i.e. use containers, chroot, seccomp etc to make it hard to break out of the server. For example containers can also be used to limit network access, so that the attacker cannot access the internal network even when successfully breaking into the web service.
Harden you OS by having only minimal software installed and by keeping this software and kernel up-to-date. Privilege escalation attacks are unfortunately still common in Linux so once the attacker has low-privilege access by breaking into the web service he might be able to get root. Keeping the system up-to-date makes this much harder.


Why can't I share a one use code with anyone else?

They're not being precise because they don't have to, and precise language might confuse some users.

They could say, for example, "You should not share unused codes that are less than an hour old with anyone else and no one from Google will ever ask for this code."

You and I would know what they mean.  My father in law and grandpa won't know why, though. My father in law is a specific example of a person who would see that there are times when he can share codes, and someone scamming him out of his social security check will get access to his email as well. (Yes, most of his inbox is about mind control chemicals added to contrails and how solar flares cause earthquakes, but it might also give someone access to his bank account.)

As has been pointed out in comments, there are other examples of situations that are conditionally dangerous, but people just don't include the exceptions. For example: "Never look down the barrel of a firearm [unless you have cleared the chamber]," or "never stick your finger in a light socket [unless you have turned off the power to that socket]."

Since a used or expired token is useless to everyone, there's no point in keeping it, sharing it, protecting it, deleting it, or adding exceptions to general security advice.

I can tell from personal experience that there are users who will do stupid things when you let them know that there are edge cases and nuances to security.  Knowing that, if I were to write such a warning to my users, I'd make my statement as broad and general as possible.


Does encrypted content in a database need to be signed?

...  they submit sensitive info over HTTPS, which is encrypted and stored in a database,

HTTPS only encrypts data in transit. This means the server as the endpoint of the HTTPS connection is also the endpoint of the encryption done by HTTPS and thus has access to the plain data. It also means that the data in the database are not encrypted due to HTTPS. Instead the plain data need to be encrypted again by a key known to the server. The alternative would be to encrypt the data on the client with a key only known to the client (and kept on the client side) in which case the server would have no access to the data, no matter if HTTPS is used or not.

In any way encrypted data should be protected against manipulation so that decryption should fail if something was changed on the encrypted data instead of returning different data. Some encryption algorithms provide this itself while in others an additional MAC is required. A MAC is not a signature and does not need a private key of the client.

A signature is only needed if you not only want to protect against data manipulation but also need a proof that the data where provided by a specific client. HTTPS does not help here, this signature need to be done instead on the client side with a private key only known to the client. Note that a signature does not need to imply encryption, i.e. it is possible that the server has access to the unencrypted data but gets only a client-generated signature which provides proof of who provided the data.


What password policy should a typical web app have?

Your main three are good, actually the first two are sufficient provided the implementation technique is solid.

Don't allow high speed brute force attempts! Three to five failed attempts in under a minute or two should completely block the IP address for 30-60 minutes. That's short enough for a human to wait out for legitimate errors but long enough to effectively shutdown most brute force attempts. A highly motivated low speed attack over weeks to months is unlikely but even that could be handled with a total error count detection, but realistically this is overkill. Just block high speed.

Make sure you don't create a SQL-injection mechansim. Actually this applies regardless of complexity.

There are other more extreme security measures you could take, but these two address the most common by far attack methods.

The "Best Practice" emphasis on extreme password complexity is misguided in my opinion. Bank ATMs successfully use trivial pins by blocking brute force attempts.


A good general tool to use when testing and learning about pen-testing is Kali Linux. It comes with both test targets and tools. You can use VirtualBox to host it on an existing machine if you don't have another machine to use.


Using ECC for PGP-Master Key in combination with Yubikey

First of all, be aware that the Yubikey does not support ECC keys (but I don't read from your question that you assumed that).

If you use an ECC primary key, others using older implementations of GnuPG not supporting ECC keys (thus, everything before GnuPG 2.1) will not be able to verify your primary key nor signatures issued by you, as it does not understand the new algorithms. So all in all, people running pre-ECC-versions of GnuPG will be able to

sign your key
receive messages encyrpted by you (your key is not involved at all)
send signed messages to you (your key is not involved at all)

but not be able to

verify signatures/certifications issued by you
validate your key (which includes verifying a self-signature)
verify signatures issued by your RSA subkey, as the subkey's binding signature must be validated before
send encrypted messages to an ECC encryption subkey
send encrypted messages to an RSA encryption subkey, as the subkey's binding signature must be validated before

Signing your key is possible, as no cryptography with your public key must be performed, but the signee is just calculating a signature (using his own key) over your key's fingerprint.

PS: I verified those operations between GnuPG 1.4 and 2.1, as I had some expectations, but was not sure whether GnuPG actually meets them.


How victims decide to auto-connect to an Evil twin or not?

First to correct you , for EVIL TWIN you don't need same bssid (MAC) as Target AP

Main Targets for EVIL TWIN are active probing of client device for SSIDs Already in its PNL (preferred network list) , so  of we somehow replace bssid in PNL with out fake AP's bssid , Client will prefer associating with us .

  Do users auto-connect to the new AP?

Out of various AP announcing SSID in our PNL which AP will be in our PNL It Depends on a lot of things few are as below :-

SNR :- AP with highest signal to noise ratio is always prefered

Lowest Delay in probe response :- Among the APs the AP with Lowest

DOT11 authentication :- If Open dot11 its fine but  if shared key dot11 auth is applied , same wep key must be on our fake ap , or we need to allow failed handshake also

DOT1x authentication :- if Dot1x is applied for dynamic keys Management (802.11i) then Protected EAP is not vulnerable to EVEN TWIN if proper root CA  certificates are deployed at client side


The documentation from the source of your citation (sslmate.org) defaults to the use of chained, PEM encoded, certificates. This is a common alternative to PKCS#12, because of its ease of use.

The justification "Since PKCS#12 uses weak encryption primitives" is incorrect in the sense that the alternative does not encrypt its content. However, usually PKCS#12 data is encrypted using a default password for its key, which does not provide more security than PEM encoded data.


How can I verify if a website revoked its old SSL certificate keys?

I find the question useful, because it is actually hard to find out if a certificate got revoked the right way.

If you know who issued the original certificate you can download the CRLs (which contains only the serial numbers and the date of revocation, not the revoked certificate itself). If not you are out of luck.
If you know the serial number of the old certificate you can check if it is in the CRL list. If you don't know the original serial number you have no chance to check the revocation.
If you found out that the certificate got revoked you still don't know if the owner is just reusing its old and probably compromised public/private key pair again with the new certificate. Without having the old certificate you will never know.

So the best thing would be if the owner would make the old certificate (but not the private key) accessible, so that others could verify the correctness of the verification.

At the end it shows again, that the current PKI architecture and not only the TLS implementations are broken. Did you ever wonder why new browser versions got shipped on all the major CA problems (DigiNotar + Comodo 2011, IGC/A 2013)? Because the revocation as originally designed just does not work correctly.


How to make an efficient bruteforce attack on Windows?

It looks like you're performing an "online" attack, in which case the speed at which you can work is limited by how fast your target computer is willing to respond to login attempts.  Since your code isn't (or at least, shouldn't be) the limiting factor, there's nothing you can do to speed up the attack.

If you can acquire the password hashes, you can perform an "offline" attack, in which case the speed with which you can try passwords is limited only by how much computing power you're able to use for the job.


Basically, there are two kinds of protection. First is user - such window prompt makes the user think about what he is doing and if this action was really intended. With UAC it is simpler to guide users in regards to what should be accepted and what must be restricted. Second protection is the system itself - even with administrator rights there are many limitations on running processes.

For those who want to delve into details, here is a link to the blog of renowned security expert Joanna Rutkowska: http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html. In this post she explains UAC and a vulnerability that was found back in 2007.


Since you never know, when new vulnerability will be found, my suggestion for you is to install mod_security on server side.

It's not 100% security, but at least, it will make harder for hacker to perform attacks such as LFI, RFI etc.


What forensics should be collected as part of an incident response plan on Windows 10?

Memory + Hoarder artifacts

Most guides want you to examine processes, network connections, and Event Logs. I don't recommend this.

Others, such as this great guide -- https://unminioncurioso.blogspot.com/2019/03/dfir-first-steps-with-volatility.html -- go into detail about timelines and certain registry hives, such as Amcache, that provide a unique view into what happened.

Perform an analysis using one of these as guest VMs after transferring your artifacts over:

https://www.skadivm.com
https://csilinux.com


Browser session cookies stolen/copied to another PC, why websites not smart enough prevent it?

There is always a balance between usability and security. There are some changes which might be perfectly normal, like visiting the same site from a totally different IP address (mobile users), with a slightly different User-Agent (might be caused by browser update), from a slightly different operating system fingerprint (might be caused by OS update or changes on hardware or restoring system from backup) etc. Getting cookies invalidated in these cases would be more secure but would also be annoying for the user.

But binding sessions to specific environments is also done in practice in cases where the sessions are short-lived so that the environment could be treated as kind of constant or where the data are very sensitive and it is acceptable to login again on any changes to the environment.

On the other hand: what you did is to explicitly copy the cookie from the browser into another browser. This is not what an attacker could do if the site is properly protected (HTTPS, http-only cookies) and the attacker has no physical access to your system. Insofar  binding a cookie to an environment should be more seen as an additional protection layer in case the other layers somehow fail (which they hopefully don't) and not as the single layer which protects against session theft.


Is my developer's home-brew password security right or wrong, and why?

/** Dave's Home-brew Hash^H^H^H^H^Hkinda stupid algorithm */

// user data
$user = '';
$password = '';

// timestamp, "random" #
$time = date('mdYHis'); // known to attackers - totally pointless
// ^ also, as jdm pointed out in the comments, this changes daily. looks broken!

// different hashes for different days? huh? or is this stored as a salt?
$rand = mt_rand().'\n'; // mt_rand is not secure as a random number generator
// ^ it's even less secure if you only ask for a single 31-bit number. and why the \n?

// crypt is good if configured/salted correctly
// ... except you've used crypt on the username? WTF.
$crypt = crypt($user.$time.$rand);

// hash
function hash_it($string1, $string2) {
    $pass = md5($string1); // why are we MD5'ing the same pass when crypt is available?
    $nt = substr($pass,0,8); // <--- BAD BAD BAD - why shuffle an MD5 hash?!?!?
    $th = substr($pass,8,8);
    $ur = substr($pass,16,8);
    $ps = substr($pass,24,8); // seriously. I have no idea. why?
    // ^ shuffling brings _zero_ extra security. it makes _zero_ sense to do this.
    // also, what's up with the variable names?

    // and now we SHA1 it with other junk too? wtf?
    $hash = 'H'.sha1($string2.$ps.$ur.$nt.$th);
    return $hash
}

$hash = hash_it($password, $crypt); // ... please stop. it's hurting my head.

summon_cthulhu();

Dave, you are not a cryptographer. Stop it.

This home-brew method offers no real resistance against brute force attacks, and gives a false impression of "complicated" security. In reality you're doing little more than sha1(md5(pass) + salt) with a possibly-broken and overly complicated hash. You seem to be under the illusion that complicated code gives better security, but it doesn't. A strong cryptosystem is strong regardless of whether the algorithm is known to an attacker - this fact is known as Kerckhoff's principle. I realise that it's fun to re-invent the wheel and do it all your own way, but you're writing code that's going into a business-critical application, which is going to have to protect customer credentials. You have a responsibility to do it correctly.

Stick to tried and tested key derivation algorithms like PBKDF2 or bcrypt, which have undergone years of in-depth analysis and scrutiny from a wide range of professional and hobbyist cryptographers.

If you'd like a good schooling on proper password storage, check out these links:

How to store salt?
Do any security experts recommend bcrypt for password storage?
How to securely store passwords?


Can I use a single permanent session ID for all of a users devices?

TL;DR: No, not secure.

Having a separate ID for each device is important, because if you give them the same one, there is nothing stopping the device from remembering it after the user logs out.

More importantly, only changing the session ID when the users changes password is catastrophically bad. The ID can be stolen much more easily than a password. Sessions should have expiration, otherwise special consideration have to be made, for example allowing users to sign out from devices they no longer have access to.

PS: I also assume your session ids are random. If they are sequential, you also need some sort of token/secret to authenticate, otherwise an attacker may just go through all ids and grab data. Note that using random IDs may be preferable, as attackers still may get some information, like number of registered users, if the IDs are not random. You can use secret in addition to random ID as well, can't hurt and may help, so why not?


Stateless Firewall configuration and random port number from server

You have a misunderstanding of the communication. The server is not assigning the high port (it’s not actually random), the client is the one doing the high port selection which in turn establishes the firewall permissions for that high port.

Nor does the server assign a new port to get off of 80 (or whatever). It continues listening on 80.

A “connection” is a quad of:

    Server IP
    Server Port (80)
    Client IP
    Client High-Port  (Dynamic)

The server listens on 80 and talks on the client defined High Port, the Client does the reverse.

There’s a whole bunch of handlers and threads involved for efficiency, but this is the essence.


TLS private key storage for embedded systems. Are there any best practices?

I was hoping there were best practices available from some reputable source.
Lacking that, I am posting this as a suggestion, and welcome any input on it.

Methods for secure key storage in embedded devices depends on the threat scenario.

Threat scenario 1:
Both remote and physical attacks.

Threat scenario 2:
Only remote attacks.

------------

The best solution in both scenarios

Single-chip MCU with built-in cryptoprocessor and secure key storage, such as PUF-RAM or tamper-resistant write-only flash accessible only by the dedicated cryptoprocessor.
Any firmware loaded from off-chip must be signed.
Ideally no external RAM.
Use MPU to restrict access to crypto functions to privileged sections of the firmware.
Blow the JTAG debug fuse if defense against physical attacks is required

The second-best solution, scenario 1 only

Single-chip MCU, with external security chip.
All communication with external security chip is encrypted using a device-specific key.
Any firmware loaded from off-chip must be signed.
Ideally no external RAM.
Use MPU to restrict access to crypto functions to privileged sections of the firmware.
Key for encrypted communication with external security chip is stored in on-chip flash.
Blow the JTAG debug fuse.

Con: The most complicated to implement, and any bugs in the implementation may compromise security.
Performance may suffer because of the additional encryption.

The second-best solution, scenario 2 only

Single-chip MCU, with external security chip.
Any firmware loaded remotely must be signed.
Use MPU to restrict access to crypto functions to privileged sections of the firmware.
No need to disable JTAG. Greatly simplifies maintenance.

Con: No defense against physical access. The unencrypted interface of the external security chip is wide open to physical attacks

The third-best solution, both scenarios

Single-chip MCU.
All firmware loaded from off-chip must be signed.
Use MPU to restrict access to crypto functions to privileged sections of the firmware.
Private keys stored in on-chip flash.
Blow the JTAG debug fuse if defense against physical attacks is required.
Ideally no external RAM if defense aganst physical attacks is required.

Con: A successful attack yields the plaintext keys, rather than indirect access to keys.

Pro: Ability to add support for new crypto algorithms by firmware update, as security standards evolve.

------------

Explanations

Two lines of defense against remote attacks

The two lines of defense against remote attacks are identical in all four solutions above.

Bug-free monolithic main firmware. Remote attacks are only possible if there are bugs in the firmware.
Bug-free privileged part of main firmware. Even if the main part of the firmware is compromised due to a bug, the MPU provides a partial second layer of protection for the privileged part of the firmware, and the private keys.

This is where your security focus must be, regardless of hardware solution.

External security chips

Dedicated devices with built-in secure key storage and cryptoprocessor capable of performing all required ECC, RSA and AES functions. Typically connected to your MCU using I2C or SPI

These cannot really be said to add any additional lines of defense against attacks. A better description is to say that they change the outcome of a successful attack. Without a security chip, a successful attack yields the plaintext keys. With a security chip, a successful attack yields indirect access to use the keys. The latter is a marginally less damaging outcome.

But ask the cable-TV industry what they think about this kind of protection. Indirect access to keys is sufficient for widespread cable-TV piracy by having the keys indirectly accessible via internet.

Security chips also come with a significant drawback: They expose an easy to access hardware interface to use the keys, actually making physical attacks very easy.
The exception is external security chips with support for encrypted communication with the MCU, and which even over that encrypted interface does not allow reading the private keys. But that creates a new key-storage problem in the MCU.

MCU internal hardware cryptoprocessor and protected key storage

Provides the same advantage as an external security chip, but without the physical attack weakness or performance issues.

Physical attack vectors, and their defenses

Ranked from easiest to hardest attack vector.

Serial interface to external security chip.

Use MCU-internal cryptoprocessor and key storage instead.
Use external security chip with encrypted interface and device-unique encryption key.
Use no security chip, and store private keys directly in MCU-internal flash instead.

JTAG debug interface.

Blow JTAG fuse.

External boot flash.

Verify signature or hash of loaded firmware.

External RAM.

Use only internal RAM.

Silicon probing.

Anti-tampering hardware.
PUF-RAM.


If one HashiCorp Vault Policy allows a capability, and another denies it, how does it decide which Policy to honor?

The short, and unsatisfying partial answer, here, is to just modify the default policy to remove or "comment-out" (I know) the sys/leases/lookup stanza.

#path "sys/leases/lookup" {
#    capabilities = ["update"]
#}

Still doesn't answer the broader question of the nitty gritty details of how one set of Policies' deny capabilities might or might not override capabilities allowed in another Policy, and where.