How much does knowing the zxcvbn password strength help an attacker? On an answer to the question How critical is it to keep your password length secret?, Mike Ounsworth commented that by storing the zxcvbn-calculated entropy of a password you make it easier for an attacker to guess the password:

  You are in effect keeping two "hashes" for each password: the bcrypt hash, and the zxcvbn entropy. Since zxcvbn is much faster to compute than bcrypt, an attacker only has to do the 100,000 (or wtv) salt-and-hash iterations of a candidate password if the zxcvbn scores match exactly. This is a HUGE advantage to the attacker.

For a bcrypt-hashed password, how much of an advantage would this give the attacker? Can this be quantified?

Also, other comments mention that reducing the precision of the entropy reduces the attacker's advantage. Would storing only the score (0, 1, 2, 3, or 4) effectively eliminate the advantage?

I'd be happy to explain my comments further :-)

Unfortunately it's not a simple explanation.

  For a bcrypt-hashed password, how much of an advantage would this give the attacker? Can this be quantified?

Quantifying this will be hard since guessing at the runtime of an algorithm is tough, especially if the attacker is allowed to make specialized chips for the job.

So no fancy math :-( but I can still give an intuition-based answer;

bcrypt is designed for hashing passwords in a way which is robust to offline dictionary attacks, meaning that, among other things, it is slow. Slow means that an attacker who is brute-forcing has to do more computations per guess, and therefore can't make as many guesses per second. Or, in economic terms, the amount of money that an attacker has to spend on processors and electricity in order to crack your password skyrockets when you use a nice slow hash function.

To illustrate the point, this table, taken from a paper by Colin Percival (full reference below), shows the estimated cost of hardware you'd need in order to reliably crack a hash in a year (note that this is the cost for the number of 2002-era processors you'd need, it completely ignores the costs of electricity, power supplies, cooling, etc).

Now that we've established that slow is good, and that good hash functions are slow, let's talk about zxcvbn.

zxcvbn is meant to be a javascript dohicky that runs client-side without lagging up the page, so compared to PBKDF2, bcrypt, and scrypt, it is lightening fast.

To actually answer your question, imagine that I stole a password database where each row looked like this (which is what I believe @ScottArciszewski was describing in his comment here):

username        bcrypt_hash                        bgcypt_salt                zxcvbn_score
happyfish23     IjZAgcfl7p92ldGxad68LJZdL17lhWy    N9qo8uLOickgx2ZMRZoMye     32.827

Typically a brute-force attack will take a password from its dictionary, hash it, and see if the hash matches the one in the stolen database, if it does then I've cracked your password, otherwise I keep trying until I find one that does match. (This can either be done online one-at-a-time as passwords are guessed, or as a pre-computed rainbow table, but either way, slowing this down costs time and money, esp. since you need a different rainbow table for each alg + iteration_count  salt combination)

With access to the above database, I could use the zxcvbn score as a filter; if the zxcvbn scores don't match, then I already know that it's not the right password and there's no point wasting time on the bcrypt calculation. So I only need to compute bcrypt if zxcvbn matches. Since zxcvbn is basically free, compared to bcrypt, it's not unreasonable that a brute-forcer could go from 10 guesses / second to millions of guesses / second using this trick.

As for the second part of your question:

  Also, other comments mention that reducing the precision of the entropy reduces the attacker's advantage. Would storing only the score (0, 1, 2, 3, or 4) effectively eliminate the advantage?

Yes, this would effectively eliminate the advantage. The reason why basically falls out of the explanation above. Let's assume that the original database stores a 5-digit zxcvbn score, and that passwords in the brute-forcing dictionary are uniformly distributed over zxcvbn scores (a terrible assumption, but it makes the logic easy). You would only expect the zxcvbn scores to match 1 / 100,000th of the time, so you only have to compute a bcrypt for every 100,000th guess. But if instead you store a lower-precision version of the score, for example {0,1,2,3,4}, then you'd be forced to compute bcrypt for every 5th guess. You're still giving the attacker a ~5x  speedup, but that's WAAAYY better than a 100,000x speedup.

REFERENCE:

Percival, Colin. "Stronger key derivation via sequential memory-hard functions." Self-published (2009): p. 14 (link to pdf)


Buffer Overflow and Segments I know by overwriting the return address in vulnerable program we can change the offset of next instruction and make it to point to our injected buffer. but this buffer is in stack segment and the offset (ip) is calculated for "code segment" so how is it possible to make the program execute the code in the data segment? (Suppose near call.)

In most (if not all) modern operating systems that run on x86 hardware, segments are ignored. The segment registers are set to begin at address 0 and to extend for the whole 32-bit address space; thus, offsets computed relatively to one segment are valid for all segments, since they all start at the same place and exactly overlap each other. In practice, application code does not fiddle with segment registers at all; it just assumes that they are already set as described above, and forgets about them.

Consequently, in a modern OS, there are no "far calls". All calls, all data accesses are "near". The notion of "modern OS" includes here all Windows versions since Windows 95 (and also the older Windows 3.1 when the "win32s" extensions are installed), and all versions of Linux since day 1.

Some finer details:

When the machine is 64-bit able, and the OS kernel runs in 64-bit mode, then it can still run code in 32-bit mode, but that's only an "emulation". In that emulated mode, segments are really fixed at address 0, and cannot be changed by the kernel. This means that the "let's forget about segment registers" stance has become firmly entrenched in the hardware as well.
Some operating system will make the stack (and other data elements) "non-executable" so as to make life harder for the attacker; this is called Data Execution Prevention. One possible trick for that is, indeed, the use of
segment registers: for instance, the CS segment will cover addresses 0 to 1073741823, and the OS will arrange for non-executable elements (in particular the stack) to be located at an offset above 1073741824. In that case, any attempt at jumping into code that is in the stack will make the CPU try to read opcodes (thus relatively to CS) beyond the limit of that segment, which then triggers an exception. However, data accesses will be made with DS or SS, whose upper limit is kept at 4294967295, and will thus be unhindered.

As a DEP mechanism, segment registers are not very flexible, since they require a clear separation between areas that can be executed, and areas that cannot. JIT compilers, in particular, are not very happy with that, since they need to allocate RAM, write code in it, then make the area executable, which cannot be done if it was not allocated in the "executable space" (the area covered by CS) in the first place. Moreover, as said above, segment-based tricks don't work when the kernel is in 64-bit mode. This is why modern OS, when doing DEP, prefer to do it through the MMU, which allows for allowing or preventing execution on a per-page basis, and to dynamically change execution rights for each page.

(Also, DEP is only an attempt at hindering the attacker, but workarounds exist. For security, it is much better to not allow buffers to be overflown, rather than trying to recover more or less cleanly from an overflown buffer.)
The GS register is special; its base address is not the address 0, and it still works when the kernel is in 64-bit mode. It is used for efficient thread-local storage.


Are there any passwords managers that use a second hidden encryption drive to hide passwords? I've heard that encryption program, Truecrypt can create a hidden encrypted drive within an encrypted drive; and even if an attacker accesses the first encrypted drive he/she cannot prove the hidden drive exists.

I'm not sure what you call this model of encryption security. Are there any password managers for Linux that use this model of security? In other words, are there any password managers that require a password to access and then a second password to access even more top-secret passwords?

AFAIK there is no such functionality.

If you need such two level of password database, you should merely just use two databases. As mentioned by Neil Smithline in his comment, your second database may be on a separate partition protected by deniable encryption.

However, be conscious that deniable encryption proved to be often counter-productive. Initially designed to allow someone to give one key hoping that the "attacker" would not "question" him anymore, it turns out that due to this system the attacker as no way to know when the user as given all his keys so he will continue to "question" him no matter (and by "question", one must often understand "torture"..).


How do you know if the bios has been compromised? To secure my PC I have setup a BIOS password, preventing any access from a live-cd.

Recently I've noticed that when the BIOS asks for my password, I just have to press Enter to boot. It doesn't work if I type just anything, but it works if I type my actual password.

This situation is pretty worrying as it means that my computer is no longer secured.

The question is now, is there a way to check if any bios is affected, and if so how to clean it ?

The BIOS or equivalent firmware is the first thing that runs when the computer is booted, so it could easily start a lightweight hypervisor before loading the OS that will present a clean firmware image if the OS ever asks for it, while still being compromised.

So from the actual machine, there is no reliable way to check if the firmware is malicious. You can however do so from another machine by unsoldering the ROM or flash chip that holds the firmware, putting it in an appropriate reader and reading it from a known good machine (but not executing it, just merely reading) and comparing to a known good image such as one provided by the mainboard manufacturer.


How Web-proxy and Virtual-Hosting are complications for HTTPS? While studying HTTPS and related transport layer security protocols(SSL/TLS), I came to know that HTTPS suffers from two complications - Web-Proxy and Virtual-Hosting.

I can understand how virtual-hosting could be the complication for HTTPS. This is because the underlying transport protocol of HTTPS (SSL or TLS) issues single certificate per IP/PORT combination so hosting multiple sites on single IP would really be an issue while implementing HTTPS.
However, I really don't understand how Web-proxy is an issue or complication with HTTPS ?
Anybody please clear the concept.
Thanks.

Current browsers support SNI (server name indication), which sends the name of the target host inside the initial client hello. Thus it is possible to have different https servers on the same IP and current http servers support this. There are still problems with non-browsers (tools and SSL libraries or SSL interfaces in various languages). Some do use SNI by default, others need to explicitly enable SNI and some don't even support it.

I can see no problems with web proxies: the browser just does a CONNECT tunnel to the target host through the proxy and then the rest is normal https, including SNI.


How can access to settings of a public router be (mis)used? I've noticed that, in the local café, Wi-Fi router credentials are simply user: admin pass: admin (as default). Upon this discovery, I was intrigued and I wanted to know more about what possibilities do you have when you have the access to router settings. Not that I would want to anything serious, I just want to know more about router security (to protect myself also)... mind that the router is not aftermarket one, but the cheap one you get with your contract, so it doesn't have many advanced options...

Just a brief list of some fun possibilities:

Hog all off the WiFi Connection by kicking everyone off. Kick everyone else off in a number of ways, changing password to WiFi and to the router to prevent wired users, then block everyone but your MAC address. I wouldn't suggest this though because the owners may notice a lack of wireless internet and go and reset it.
Provide a captive portal page that looks like Google to steal credentials
Provide a captive portal page that take you to a drive by or provides a hook
Set all DNS traffic to a DNS server you control to point all bank traffic to spoofed banks to harvest credentials.
If a remote firmware update is available then have malicious firmware updated to allow a whole set of Man in the Middle attacks to happen
Logging all packets coming in and through, pick up unencrypted traffic*

These are just a few I can think of off the top of my head
*Probably can't be done without flashing firmware or a more advanced router


Hijacking stale DNS entry to point to your own website Context and system configuration:

AWS EC2 instance with a public IP address
AWS Route53-managed DNS with a somesubdomain.somedomain.io pointing to the above IP address
Above AWS EC2 instance was not running all the time, it was stopped most of the time with only occasional periods of running
Every time the EC2 instance was started, DNS entries were updated to point at its new IP address - EC2 instances are not retaining their public IP addresses when they are not running, they are getting new public IP address on startup
DNS entries were left as-is when the instance was stopped
The reason behind this bit unusual setup is cost saving, while being able to use static domain names for connecting to the instance when running

Attack:

One day I noticed there was a website under the somesubdomain.somedomain.io mentioned above, despite my EC2 instance being down
This website had my domain name in its banner/logo, so this couldn't have been a coincidence

Analysis:

I did not carry out as much analysis as I could at that time. In fact I just wanted to solve the problem. Now I just delete DNS entries when shutting down the instance.
I realised there is a problem with a DNS entry under my domain pointing at the past public IP address of my EC2 instance. When the instance was last shut down, the IP address got back to available pool and could be re-assigned to a completely different instance

Questions:

Does this attack have a common name?
What would be the primary benefits for the attacker?

This is a subdomain takeover.
They typically happen in one of 2 ways:

You have an A record pointing to an IP address that no longer exists and an attacker can gain control of the IP address in question
You have a CNAME record pointing to a domain that no longer exists, and the attacker can register the domain.

The reasons can vary depending on the circumstances. To pick two:

Impersonation is much easier if you can control an "official" domain. This can lead to phising, social engineering attacks, and more.
If the main domain has cookies which are valid for sub domains, then the attacker will be able to steal all cookies from the main site if a victim visits their subdomain.

And yes, there are ways to scan for such misconfigurations and attackers can and will find them.
Solution:
The simplest and most effective way to stop subdomain takeovers is to always cleanup you DNS records - don't leave an A or CNAME record pointing to non-existent resources/domains.
In your case though you have another option. You can reserve an elastic IP address to your account and attach/detach it from your EC2 instance as needed. By reserving the IP you will make sure it does not return to AWS' pool for someone else to use. This solution has a slight advantage that you don't have to update DNS or worry about DNS propagation, but it has a slight disadvantage in that you will pay a nominal hourly fee while the IP address is not in use.


Is it a good practice to show 403 unauthorized access error to user? Whenever we see a 403 forbidden access error page we think we have got to a place where some secret or private data is present. Now at this point bad guys know that this might be of interest and start to see if they can do something to get access to this secret data.

So is it good to show this error or just redirect to some other place?

Edit

I am thinking of dealing with error is to redirect to separate login page to access that particular resourse. But in this case also what if I simply don't want any one (may be even admin) to have access to these resource via my application.
Offcourse admin can access the same resource by some other mean at the backend.

In production environment, you usually want to disclose as little information as possible. For that purpose, it's preferable to show generic error codes:

Error 400 for client-related errors: Bad request, authentication needed, etc.
Error 500 for server-related errors: Database down, site down for maintenance, etc.

Ideally, you shouldn't opt for the default error pages provided by your webserver. You either make your own error pages, or edit the default error pages in a way that hides any information that could be used by an attacker. For example, here's an error from one of our servers when accessing a password-protected URL:

Beyond that, it's a pure usability issue and it's greatly case-dependant. Shouldn't you redirect users to the homepage? Are those areas password-protected? Should you view a login form? Or do you simply want to show the generic error message with your site's style?

Here's an example of an error page on our site (Security.StackExchange)


Can you set up 2FA with a USB drive? I want to set up two factor authentication for some of my online accounts. I don't want to install an app, and I don't like using my phone as the physical medium anyway, because it's more likely to get stolen and it's also more vulnerable than a static object that I just carry around.

I'm attracted to the idea of Yubikey, but they're a little pricey and I don't see what they're charging for. I don't know exactly what is going on under the hood in 2FA, but I can't see any reason that you couldn't use any old USB (with the appropriate software around it).

So, my question is: can you use a USB flash drive to generate 2FA codes?

This may or may not answer my question, but I did some digging after asking the question and I've got a solution that's working for me at the moment. I'll outline it below.

First of all, there is a useful command line tool called oathtool. You can use it to generate the 6 digit codes for 2fa using your 2fa key. The steps are outlined here.

So one solution that addresses my convenience complaint is that I could store my 2fa key in my password manager, and write a script to generate the 6 digit code from that.

However, this removes the "something you have" aspect of 2fa, which I would like to keep. To address this, I did the following:

Store the 2fa key in an encrypted file, and store that file on a flash drive.
When I plug in my flash drive, mount the folder containing the (possibly many) 2fa keys into a folder my password manager can see. I use pass, so this is very easy to do. At the moment I do this manually, but I may try to automate it.
The interface is something you can customise, but I wrote the following bash script, called 2fa:

pass 2fa/$1 | xargs -d '\n' oathtool -b --totp

The net consequence of this (with my naming system) is that I can write 2fa gitlab and get the 6-digit code at my terminal. I have another script that writes it to my clipboard, and prompts me with a list of names (the same interface as my password manager).

Of course, none of this works without the USB drive, which makes it a bona-fide "something you have" solution. However, it will only work if you can decrypt the gpg files, which requires my private key. I only use 2fa on a few trusted machines at the moment, so this is okay for me. If I needed it to be more versatile then I may reconsider using a phone or Yubikey.

I welcome criticism or ideas for improvement, especially if there are any obvious vulnerabilities to this system that I've missed.


PCI DSS requirement 8.3.1 I have a question regarding this requirement, does even the non-CHD system need to use 2FA?

Ex: When accessing CHD server it asks for 2FA, but do we need the system that accessing from to have 2FA as well?

The first problem I seem to encounter revolves around the difference between systems/devices that process/store/transmit cardholder data (aka Category 1 systems/devices) versus those systems/devices that are connected to those Category 1 systems/devices (aka Category 2 systems/devices).  The guidance here is that if a Category 2 system has the ability to effect the security of a Category 1 system (i.e., the Category 2 system/device has inbound access to the CDE system(s)/device(s)), then administrators should also use MFA to access those Category 2 systems/devices.

Curled from https://pciguru.wordpress.com/2017/01/07/getting-ready-for-8-3-1/Chris


Verify digital signature without key public key in signature When receiving emails, I sometimes see the following:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I found an integer overflow in PHP, in the conversation of dates to "Julian Day Count" function.

The commit, with a PoC can be found here: https://github.com/MegaManSec/php-src/commit/a538d2f5605798422f2746636 ecdc300f8ebcaa1
Use CVE-2015-1353.

CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington
Road, Bedford, MA 01730 USA [ PGP key available through
http://cve.mitre.org/cve/request_id.html ]

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJUw/LpAAoJEKllVAevmvmsiYoH/Ag+n/8x+blfJyccUhjt39bp
nRxsuZw2MIx7COJcoufIxeycu2YGnm1O9RxZBA9lKmVYjb0wjMi9yHogcWkT8UOo
i93ARMw7V6UFp1nV+2Kv5BgVh2EcwEBXyDkKkcaN2l68Dm3nRoApMB4i4m7G67BC
K2T1L4eq1orQCNaR7n4hup2155pHZbLqZQRMAYn5EGQPr/+zPjgq+PQKes631US5
SXrnthRKOAfZk9QVIlxf5t1JfVvC3Cta0HgETTaXJ8TbqEAA5AXw8hl+RmhWgFnI
Cto73LM+iiA1tyxDXdXnfdRqV/uxmqK+FCgO6asyCuT7EYOpBZ74Wmq1z+RVJRc=
=VLR4
-----END PGP SIGNATURE-----

From what I understand a digital signature works in the following way:

The content of the message is hashed to provide a fixed length output of the entire content.
The hash which is generated is then encrypted with the senders private key (PS: I thought public key was used to encrypt things, different context?)
The process above creates a digital signature which is transmitted with the original message
The receiver uses the public key to decrypt the ciphertext to return the hash and then hashes the message them-self to see if its the same

The problem I cant understand is the public key part, in the example above from Mitre, there is no public key sent for me to decrypt the signature. So how do I go about verifying this signature? I can see that they have provided a link "PGP key available throught" but this link contains the key ID. What is this key ID and is it what I need to find the public key?

Finding CVE's PGP/KEY

This article explains how to search for a GPG key, and specifically the CVE site's public key.  There are instructions on how to import it there, and I've provided basic importation instructions below.

Typical GPG/PGP

In PGP/GPG when a user generates a key there is a key ID also associated with it.  You'll notice, in the link that you provided, that the last 4 bytes of the fingerprint are also the key ID.

Generally, the user will upload their public key to a key server.  The key ID is what the key server uses to look up keys within its database.  Other users can search the key server for the key ID associated with the data they're trying to decrypt or verify.  GPG uses your keychain to perform all of its operations.  On a Linux box you can install GPG.

Debian:

sudo apt-get install pgpgpg

You can then import keys into your keychain with a given key ID from a keyserver:

gpg --recv-keys 0x<key_id> --keyserver 'http://key-server.org'

Or if you have the keyfile:

gpg --import <keyfile>

There are a few ways that a document can be signed.  One way by creating a detached signature file.  In this case you can do the following:

gpg --verify file-1.2.3.tar.sig file-1.2.3.tar

However, in your case you have both the message and the signature in the same file.  You can tell because you have both -----BEGIN PGP SIGNED MESSAGE----- and -----BEGIN PGP SIGNATURE----- within the message.  In this case you can just do the following:

gpg --output your-file.txt --decrypt my-file.gpg

For each of these verify commands GPG will attempt to look in your keychain for the key used to sign the message.  If it can't find it then it will print an error message.

You mentioned that you see this in emails.  If you're using Thunderbird there is an extension called Enigmail that will allow you to set keyservers, import GPG/PGP keys, and encrypt/decrypt/verify email signatures for you.

To answer your questions on how public keys and private keys relate I would read through Thomas Pornin's Answer here.


Without using SSL, what's the most secure way to make an AJAX request to a PHP page? It was suggested over at stackoverflow that I try my question here. This is it verbatim:

So, it's impossible to do AJAX requests securely without using SSL. I get it. You can either view-source the data that's being sent via Javascript, or you can directly access the PHP page by spoofing headers, yada yada.

But let's say this web app doesn't particularly require true security, and instead it's just a sort of game to keep most reverse-engineers at bay. What sort of hurdles should I employ?

I'm not looking for some ridiculously over-the-top Javascript implementation of an encryption algorithm. I want simplicity as well as mild security... if that isn't contradictory by nature. So, what would you guys recommend?

For example, I'm running a contest where if a user clicks an image successfully (jQuery), it passes their userid and a timestamp to a PHP page, both MD5 salted by random data and then encoded with MIME. The PHP page then validates this userid and timestamp, then returns a winning "code" in the form of another salted MD5 hash. I'm also employing multiple header checks to help ensure the request is from a valid location. Am I missing anything, or is that about all I can do? It seems like someone could just fire the jQuery click event and ruin the whole thing, but I don't see how I can prevent that.

I'll be awarding the answer to anyone who comes up with an ingenious faux-security mechanism! Or... just whomever tells me why I'm stupid this time.

Specifically, what are you trying to be secure against?

Eavesdroppers recording or intercepting messages between the client and host?  You basically need SSL to ensure no one can eavesdrop, or create your own encryption protocol (say as a browser extension or javascript on the page), though I strongly recommend against the create-your-own encryption method (will be slower/weaker and almost undoubtedly have major flaws if you do not have it examined by several crypto experts).  Granted if your users only have computers on separate networks from each other (and the host machine) and do not control intermediate networks (e.g., work at one of your ISPs), they won't be able to eavesdrop.

I'm not sure what the point of your game is:

  For example, I'm running a contest where if a user clicks an image successfully (jQuery), it passes their userid and a timestamp to a PHP page, both MD5 salted by random data and then encoded with MIME. The PHP page then validates this userid and timestamp, then returns a winning "code" in the form of another salted MD5 hash. I'm also employing multiple header checks to help ensure the request is from a valid location. Am I missing anything, or is that about all I can do? It seems like someone could just fire the jQuery click event and ruin the whole thing, but I don't see how I can prevent that.

Are there multiple images and only one image is correct and they are only allowed to guess once?  I'd suggest having them use a server-issue token of some sort.

A correct process would be (a) they use their secret credentials (username, password) to request a one-time guess token (a unique random string) from the server.  They then make their guess (by clicking an image) which submits the username, guess token, and the image they chose.  The server records the image if the submitted guess token was valid and has not been previously used; otherwise it says token not valid and throws out their answer.  This still let's an eavesdropper figure out the correct answer.


Man in the middle attack on loopback We made a client/server program that runs at localhost. Is it possible to execute a man in the middle attack on the loopback between the client and server?

Depending on how the programs know each other it might be possible.

Assuming you are running a server that only listens on 127.0.0.1 and a client that tries to connect to it. What port does the server listen on? What happens when the port is ocuppied? How does a client know it's a correct port?

Assuming that the port is not hardcoded in both server and client, but is somehow configured, one could setup a MITM on a different port and trick a client to connect to that modified port.

Poor man's example - assuming you have SSH server on your local box

socat TCP-LISTEN:1234 TCP:127.0.0.1:22

In the other console do

ssh 127.0.0.1 -p 1234

You'll see that you connect to your own SSH. Kill the socat in the first console and you see connection breaks. The socat is your MITM.

Edit: After you've specified your target (modifying a packet en-route and watching HMAC break it), I'd guess you'll need a second server, that normally only forwards packets from one socket to other, but after somehow notifying it (10% of the time, a specific file exists, a signal is received, 10s after startup...) it modifies the received packet before forwarding.


Best practices communicating links in email Our communication department recently asked us (the security team) a question. They send out a lot of mail, especially mails like 'your password is set to expire' are hot topics here. The question was: Should we write out the links? We have 'domain.com/passwordreset'. Should we add 'www'? Should we add 'https'? Should we just make it a link of text 'Click here'?

I checked some email I personally got from banks and noticed that it is usually a string that then contains a link, but those companies do that because they want to track who clicks the links and the links are thus really long. The URLs our communication department is trying to communicate are short URLs that they would love for people to remember outside of the email as well.

I looked around, but could not find any practical experience with this online. So my question is: What would be the 'best' option and why?

A policy I've seen used by some banks and government agencies in the Netherlands is never to include any links in mails, but just to refer to "our website" or "our webportal".

The main idea here is that they're explicitly telling customers never to click on any links in emails (supposedly) coming from them. This way they hope to reduce the chance of people visiting links mentioned in phishing mails and entering their credentials there.

People are always forced to enter the URL of the webpage in their browser (or use bookmarks), which can be a bit of a drawback looking at it from an UX perspective, but it can work as a security measure.

Unfortunately, I have no idea how effective this is, and thus if it's a useful strategy.


Does posting the technique I used to encrypt my Linux system make the encryption inherently less secure? I recently encrypted my laptop, but I also wrote notes on how I did it and posted those notes online. The configuration is fairly complicated and, from what I can tell, also fairly unique. I did not put any private information in it (such as UUID's, checksums, or passwords). Does releasing general information about how my system is set up make it inherently less secure?

Side question: this is my first time encrypting a system. Are there any vital flaws or security holes that I overlooked?

Yes, it does make your system less secure, since it exposes internals to the world, and the next time an exploit is detected for a service you use, you can be an early target.

That being said, it may still be a good idea. Sunlight is the best disinfectant and by Kerkchoff's principle, secrecy of your implementation should not be a precondition for security. Since it is your first implementation, and you haven't revealed how to trivially find your system, a public review can only help.

This related post concludes that security through obscurity isn't bad, as long as you are not relying only on it.
Only counting on obscurity is bad. You want your system to be secure with the attacker knowing it's complete workings apart from specifically controllable secret information So I still suggest modifying everything in a few days/weeks (adding some obscurity)


Using IPTables over a network I recently found out how to "block" an IP address from your computer, with this command:

sudo iptables -A INPUT -s 210.1.193.49 -j DROP #Blocks 210.1.193.49 from your computer

I was wondering, how could I do this for ALL hosts on the network, not only my machine.

I am running Kali Linux.

SCENARIO:
Lets say my "Internet Cafe" is suffering from a DoS attack. If I want to block the IP address that is sending me packets, how would I do so?

BREAKDOWN:
Attacker is using Low Orbit Ion Cannon to DoS my Network, using my PUBLIC IP address (Attacker is from outside the network)
I want to block the attackers IP address from reaching my network

If you want to block traffic to a whole network you have to do it at the network border. In the simplest case of a network with a single connection to the Internet (typical home network) this would be the Internet router. Most home routers have a GUI allowing you to add this kind of rules, often under the heading "Firewall".

Alternatively you can perform the iptables command you quoted (or its equivalent for other operating systems) on every host in the network. This may prove impractical or impossible depending on the number and types of hosts in your network.


Is Chrome completely secure against Reflected XSS? I notice that Chrome does not execute scrips that are part of the web request,

http://vulnerable_site?pageTitle=<script>alert('xss')</script>

With such links since the script is as part of the web request, Chrome does not execute the script. Does that prevent all kinds of Reflected XSS attacks with Chrome browser ?

Edit:
I've already read this thread; although the title seems similar, the contents are different.

No, because the XSS filter only looks whether it sees XSS code in the input back in the HTML outputted by your server.

For example, if Chrome sees your web page is accessed with an URL that contains the following:

?q=

and if the HTML returned by the server contains this:

You have searched for

it knows that this code is most likely the result of it being included in the request, and neutralizes it.

However, if the code is not found in the request, for example if the application accepts input that is encoded in some way, the filter may not be able to figure out that the code is the result of some XSS code embedded in the request.

As seen in the commit log for WebKit, until it was forked recently  the rendering engine in Chrome, they are trying to address the most common bypasses, where the XSS-code in the URL and the resulting XSS-code in the HTML look slightly different.

If none of these rules for special cases apply, the XSS will be left through. For example, if they aren't decoding Base64-encoded data in the URL, if the web application were to accept input encoded with Base64, it may be possible to XSS a web application.

An example:

?q=PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+

(PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+ is  encoded in Base-64), if not filtered, would result in response HTML like this:

You have searched for

Additionally, it won't stop XSS occurring with data that is not embedded in the HTML unencoded, but is treated in an unsafe way by JavaScript.

For example, consider a page which contains the following JavaScript:

eval(location.hash.substring(1))

This will execute any code trailing the # in the URL, but it is not filtered out by Chrome.

↪ You can see this example in action here

↪ Another example, which uses Base64


Encryption key exchange for Tor I've been studying how Tor works - including the great QA "Why can a Tor exit node decrypt data, but not the entry node?".

I understand the concept of onion routing and multiple layers of encryption. My question is specifically how are the keys exchanged securely so the circuits can be built? This is touched on in that question but not actually answered.

It seems that you wouldn't want a bridge node to pass back the public key for an exit node since it would be easy to fake and break the anonymity.

Can you just assume that the public keys and IPs are listed in a directory and that they are picked from there? When I get privacy related questions like this I really don't want to hand wave away the details.

Per the Wiki (emphasis mine):

  To create and transmit an onion, the following steps are taken:

  The originator picks nodes from a list provided by a special node called the directory node (traffic between the originator and the
  directory node may also be encrypted or otherwise anonymised or
  decentralised); the chosen nodes are ordered to provide a path through
  which the message may be transmitted; this ordering of the nodes is
  called a chain or a circuit. No node within the circuit, except for
  the exit node, can infer where in the chain it is located, and no node
  can tell whether the node before it is the originator or how many
  nodes are in the circuit.
  Using asymmetric key cryptography, the originator uses the public key (obtained from the directory) of the first node in the circuit,
  known as the entry node, to send it an encrypted message, called a
  create cell,

The rest of the article appears to omit how the public keys for relay nodes are obtained. However, since the selection of all nodes for a given chain is done from the directory node, I'm pretty sure all public keys are taken from the directory node. Therefore the directory node (and your connection to it) must be trusted if you are to trust the public keys of any of the nodes in your Tor chain.


Securely embedding a widget submitting forms to our servers on third party websites? I would like to build a javascript widget that third party developers inject on their page by adding:

<script type="text/javascript" src="https://test.com/widget.js" async></script>

The script injects the email collection form widget into a div tag on the developer website. When a user submits the form, it makes a POST request to an endpoint hosted on our server. We use recaptcha to validate all requests.

There are some security implicatons:

Bad actor can spam the endpoint with bad email addresses.
Since the widget is embedded on the developer page, they can use the widget for nefarious purposes and have our name on it.

How can I address the security issues that comes with an embeddable widget? All requests go through HTTPS. Recaptcha is used to help against spam/abuse. Maybe I can use a site key/referrer header to validate that the request is coming from a trusted website?

Another option is to use an iframe hosted on my website to show the widget.

The fact that you are embedding this as a widget is not all that relevant for most security aspects. Most attacks would be directed right at the endpoint, bypassing the form, widget and browser alltogether. For instance, you would need the captcha no matter if you make a widget or not, because spam is sent with automated scripts and not done through browsers.

You can, however, limit what origins can send requests to your endpoints from a browser. This would be done using CORS, only allowing some origins in your Access-Control-Allow-Origin header.

The trick to make this work is that the request must not be "simple", i.e. it must trigger a preflight. An ordinary form POST is simple, so that will not do it. You would have to change the verb, or require a specific header to be present in the request or something like that. See the link above for what is considered "simple" and what is not.

Do note, however, that it is the browser that enforces CORS policy. An attacker can still send whatever requests they want using e.g. CURL. Also note that even if you do not make a widget, anyone can just create a form that posts to your endpoint on their own webpage.


www-data is sending rogue mails through sendmail. How do I find the source? So I have a Ubuntu server hosting a PHP-based web site for me. Some of the services rely on sendmail being configured. I have set it up to send through my GMail account.

As of yesterday ~19:00 CET, my GMail "sent mail" folder suddenly got overwhelmed with Returned mail delivery reports from Mail Delivery Subsystem. I could see that someone is attempting to send outgoing emails (spam) from my system using the www-data. Luckily for me, they were also attempting to alter the From-field, which was denied by (AFAIK) Google. Here is a (sensored) transcript from mail.log:

Feb  4 18:58:10 ip-xxxxx sendmail[740]: s14IwAHQ000740: Authentication-Warning: ip-xxxxx.ec2.internal: www-data set sender to thelma_combs@mydomain.com using -f
Feb  4 18:58:10 ip-xxxxx sendmail[740]: s14IwAHQ000740: from=thelma_combs@mydomain.com, size=464, class=0, nrcpts=1, msgid=<201402041858.s14IwAHQ000740@ip-xxxxx.ec2.internal>, relay=www-data@localhost

I've "shut down" sendmail by chmod'ing the executable to 000.

So the thing is I'd like to get sendmail up and running again while closing the security hole. I'm a bit of a loss of where to start. I'm not a Linux expert although I've managed to set this system up.

I'm running a total of 5 web sites (Virtual hosts) on the system, and I'm pretty confident that one of them, and which one of them, is compromised. In the log above, I've swapped the real domain of one of my 5 sites with "mydomain.com". So I'm pretty sure it's that particular domain which is attacked. I can't find any suspicious activity in the apache access log though. Where do I go from here?

edit1: Anyone got any tips on how I can find out whether or not a user got full control of my www-data account, or if it goes through HTTP calls to a PHP file?

Edit2: Found this nugget of a file when searching for PHP files modified the last 48 hours (I had personally modified zero).

System:

Ubuntu 12.04 LTS running at Amazon EC2
PHP version: 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:19:58)
Apache2 version: 2.2.22
Website running PHP Fusion CMS system v7.01.01

From your update I'd guess that PHP fusion is the problem here.  It looks like there's wide range of vulnerabilites for newer versions than that including SQL Injection and other pretty high risk stuff  (sample info here), so it's reasonable to assume that the one you're using is vulnerable too...

So it would be likely that your attackers have got access to your server that way with at least the privileges of the web server user.

At this point really you need to look at rebuilding the server as it's very hard to effectively clean someone off your system without knowing exactly what they've done (e.g. put rootkits on the system)

If you have backups from before the problem started you could work from that, although it could be tricky to tell exactly when they got access.

Key point would be to ensure that you have fully updated versions of all the software you use and make sure to keep the CMS updated as they can be common points of attack.

Also looks like there's some advice on the php fusion pages (here) on recovering from this kind of attack


Is it possible to secure a web app without HTTPS? Possible Duplicate:
  Can you secure a web app from FireSheep without using SSL?

Think of a typical web application where the users log in, and then the session is kept with a session key. Is it possible to protect it from all kinds of sniffing-based attacks without HTTPS or its equivalent?

Let's say I'm not worried about data transfer, only password or session theft.

No.

Even assuming you're only referring to leakage of user passwords and/or session ids (btw "secure" includes a lot more than that)...

There is simply no secure way to send a user password over the Internet in the clear, without benefit of a proper encryption protocol. Without using TLS/SSL, you'd be forced to implement this yourself - which, at best, would be insecure.

Likewise, the user's session identifier would be equally exposed, if not restricted to HTTPS only.

That said, the above all assumes a website on the public internet.
There are certain other situations which can be secured without TLS/SSL:

Internal (e.g. corporate) website, that is protected using IPsec.
A local website, on the same machine that the user is browsing from, accessible over the loopback interface only (and dependant on the machine being in use by a single user, not e.g. a shared terminal server).


What's the best way to secure inter-server communication for cloud servers? I'm looking for best-practices or suggestions to secure inter-server communications between VPSs.

Should I just run all traffic through SSH?
What about HTTP Traffic via something like mongo?  Reverse proxy it on the same machine to https with nginx?
What about setting up a VPN?  My concern here is both 100% reliability and overhead.  If this is a way to go, OpenVPN?

Thanks for any insight :)

It depends on the traffic. If it's commands and file transfer, then SSH is sufficient (since you'd be using SSH anyway). You'll be relying on strict host key checking, so make sure you don't suppress that.

Otherwise, VPN it. OpenVPN is simple enough. Requires some setup, but not tons.

IPSec was actually designed specifically for this purpose. It's a disaster of Design-By-Committee bloat to the extent that it's, unfortunately, almost completely unusable. A bit of a shame, because it's otherwise a simple solution to a very common problem. But if you can get IPSec to work, the overhead is theoretically negligible.


What tools exist to manage large scale firewall rulesets? For an enterprise firewall you may have over 50 thousand rules. With typical errors in firewall rules including things like mistyped network masks you couldn't hope to manually review the release.

So what tools are available? Free or otherwise.

Tufin and Firemon are the major players here.  I do not have experience with Firemon, but Tufin makes a solid product.  (I do not hold financial interest in Tufin, but am a customer).


Frameworks or any Solutions for authentications/security/ login management in Java Web Applications I am looking for a framework/solution for authentication/ user-login management/ security  in java web application that can make the naive developer's job easier/faster and make the application relatively more secured against potential threats.

P.S. :  I'm using JSF 2.0 as the front-end development framework in my web application.

Check out OWASP's ESAPI (Enterprise Security API).

  ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development.

While it is ported to several languages and frameworks, it started as a Java EE project. It's a very large and flexible framework, should meet most of your needs.

And as far as authentication and user management goes, strongly consider using OpenID (or something like that), so you dont have to manage it at all. Depending on your usecases and userbase, this can be a huge benefit, to you AND your users.


Writing malware in java? To me, it seemed like malware could never be written in java. Those who taught me java said it was "secure" and did not allow "low-level access" like c,c++.

But, I discovered that it can be done - http://blog.trendmicro.com/trendlabs-security-intelligence/jacksbot-has-some-dirty-tricks-up-its-sleeves/

notes on the same thing - http://www.darknet.org.uk/2011/01/java-based-cross-platform-malware-trojan-maclinuxwindows/

Here is my question -
Can we use java to perform ALL the "bad things/tasks needed by malware" which c, c++,  can do ?
If that is the case, then can we say that java is also good for malware writing ? After all, most criminals would want their malware to be multi-platform.

Java code can invoke native code (e.g. code written in C or whatever, and compiled to a sequence of CPU opcodes) through a standard interface. Java can actually write a DLL file somewhere (as a bunch of bytes) and load that, so everything native code can do, so can Java.

Java also features a rich standard library which allows it to read and write files in arbitrary ways.

The hard parts for Java-based malware are:

A Java VM is needed. Java is not installed by default in many modern operating systems.
The Java VM tends to sandbox Java applets. To run native code or access arbitrary files, a Java applet must ask for permission, which entails digital signatures and certificates which may be tracked back to the perpetrator. Or a specific sandbox escape bug must be exploited; such bugs are discovered regularly, but they are also patched with commendable alacrity.
The existing Java VM implementations are fat. They are optimized for big applications which will use lots of RAM anyway, so any Java code has a large minimal memory footprint. Malware usually prefers inconspicuousness.
Java VM implementations come with extensive debugging tools which allow plugging into a running VM and inspecting what happens in it. This may help in cleansing a Java-based malware infestation.

These are reasons why Java will not look as the best language ever to malware writers. Also, even if Java is nominally portable, cross-platform malware is an elusive goal, because malware tends to do things at a quite low level -- that is, a level which is very OS-specific. Modifying the /etc/passwd file is a very naughty thing to do on a Unix-like system; but it would have no impact at all on Windows, which does not have an /etc/passwd file. Thus, there is little incentive for malware authors to use Java.

(All of this would apply almost unchanged to a question about writing malware in C#/.NET + SilverLight.)


Does Docker provide the same security as a vm Does Docker provide the same level of security/isolation as a virtual machine running over a hypervisor? If not, how can that be achieved?

Theoretically, the isolation of Docker is not quite as strong, because parts of the system are shared (kernel is shared, container has a chroot of the original filesystem, etc). However, for most purposes it's good enough. With chroot, cgroups, etc, and the ability to run containers under an unprivileged account (so root in the container is still limited on the host), you can lock down the container sufficiently for most uses.

If you really want VM-level isolation, then use a VM. Depending on the use case, you could start and stop Docker containers within a VM.


Is XSS dangerous on web without login/sensitive user's data? Is XSS dangerous when the web application doesn't have a login/register function, the user isn't logged in or when the website doesn't store any sensitive user information?

Of course!
False information could be inserted into a webpage with XSS. Imagine if Microsoft had a giant banner on their front page stating they would shut down the whole company, their shares could drop significantly, just because of a XSS attack, without anyone logging in.


How secure is BitLocker with a USB key on the motherboard I've been reading a bit about using BitLocker without a TPM chip and I've seen here and there that some people advise to use a USB stick for ease, and plug it into an internal USB header converter and configure BitLocker to require it present every startup.

Which leaves me wondering, is that really secure? If someone gets physical access to your computer (which, as far as I know, is the only reason you'd want to have disk encryption anyway) would a USB key that is permanently attached be just as secure as a TPM chip? (in both cases assuming you don't have to enter any passwords to boot windows but do need a password to log into your account)

I haven't been able to find anyone saying anything on this and I'm really curious.

An USB stick is even less secure than a TPM. The latter at least tries to check whether the system is in a trusted state before giving away the key, but the former doesn't even care and has no way to do so.

TPM attacks exist but still require some effort to pull off, and possibly some hardware (soldering wires to the LPC bus to talk to the TPM chip directly). USB "attacks" would simply involve unplugging the stick and copy/pasting the keyfile that's inside, or just booting the machine off a Linux disc and reading the keyfile from there without even touching the actual USB.


What is the risk of data being recovered from SAN storage after logical deletion? The specific scenario involves Linux servers on VMware hosts with SAN storage.  If files containing sensitive data are deleted by Linux, can they be recovered by a low level tool similar to what might be done with local storage?  I think there are a number of scenarios that probably have different answers:

"Shortly" after deletion.  The Linux instance has not been rebooted since the deletion and no explicit relocation of the VMware workload has occurred.  The rest of the environnemnt has been stable during the intervening time
"Long" after deletion.  The Linux instance has not been rebooted since the deletion and no explicit relocation of the VMware workload has occurred.  Normal operations have occured around the instance that might have included relocation of other workloads and reallocation of SAN storage for other workloads.
An OS level restart has been performed, such as to force re-initialization of an updated service.
A full OS shutdown was performed and some time later the image was restarted.  [What if the image is moved to a different host before restart?]
Workload was shifted to new VMware host without OS shutdown.

There are a few other cases I can imagine, but you get the idea.  So, can data be recovered from within the OS in various scenarios?  How about from the virtual host or SAN management console?  From the media?  How difficult are these vectors to exploit?  What protection is there against recovery of deleted data in a SAN based virtual environment?

Each layer of indirection makes this more difficult to answer.

NetApp SANs for example have the explicit policy to always do Copy-On-Write. This means that data is NEVER updated in place. Nothing is ever overwritten directly. Instead a new RAID stripe is written, this new stripe's data is mapped to the old stripe's address and the old stripe's data is marked as available for overwriting. This is completely unknown to the VM running on top of it. If I recall correctly the stripes were something like 4k. So if your private key was inside that stripe and you thought the Linux "shred" command actually overwrote it on disk, then no, this is not what happened down on the hardware level.

And there is no real telling exactly when that old stripe data once marked as reusable will actually really be reused. So depending on free space percentage on the SAN and throughput you may give some probability for overwrite. But only probabilities.

And every layer makes this harder to predict:

What about tiered storage?
What about the file system on the Linux VM itself? Will it actually release that space for overwrite? Will it forward the SATA "trim" command to the storage layer at all?

So in closing: so good way to tell. If you worry about remnants of deleted data consider full-disk-encryption.


Security of pronounceable passwords Some random password generators support the generation of pronounceable words of any given length n. Assuming that words are derived using 26 lowercase letters, the number of possible words of length n is 26^n. Not all of these words are pronounceable. My question is how many pronounceable words are possible of any given length n?

The count of pronounceable words of length n is obviously less than 26^n and therefore the search space for the attacker is less than 26^n. If there is no exact answer is there any upper bound on the count? Is setting a pronounceable word as a password is secure or is this just a fancy feature of password generators? What should be the minimum length?

In the context of pass-phrase, i think it as special case of pronounceable words formed by concatenation of more than one common English words. Assuming that n len words are derived using 26 lowercase letters.

Number of n len words (26^n) > Number of n len pronounceable words > Number of n len pass-phrases > Number of n len English words.

Am I correct?

Note : I have read the argument of setting long pass-phrase "horsecorrectbatterstaple" as password and don't want to start it again:)

Pronounceable words are more-or-less sequences of syllables. What constitutes a syllable depends on the language, including the language variant (British, Scottish, American, Indian... versions of English are not rigorously identical). So we will make some approximations.

Let's suppose that we want two-letter syllables, always a consonant followed by a vowel. We also want to avoid ambiguous syllables: there shall be an injective mapping from pronounced syllables to letters; thus, we will not use "c" or "q", relying only on "k" and "s". We end up with:

18 consonants: b, d, f, g, h, j, k, l, m, n, p, r, s, t, v, w, x, z
6 vowels: a, e, i, o, u, y

Not that this entails pronouncing "hi" as in hit, not high; "ge" as in get, not gel; and so on.

We then end up with 18×6=108 unambiguous two-letter syllables. The number of possible passwords of length n is then 108n/2, i.e. about 10.39n. If you want 10-letter passwords:

Sequences of 10 random letters: 141167095653376 choices
Sequences of 5 random syllables: 14693280768 choices

Compare this with the total number of possible English words, which has been estimated to about 470000 (only). For passphrases, the number of passphrases of a given length or up to a given length is necessarily greater than the number of words of the same length, since a single word is a kind of passphrase. However, your inference is correct: for a given length in characters, independent random letters provide the most room for entropy, followed by random syllables, followed by sequences of random words ("passphrases"), followed by single words.

The story does not stop there, though. The whole notion of passwords revolves around scarce resources. Namely:

The password must be remembered.
The password must be typed.

Thinking in terms of "number of letters" relates mostly to the second resource: more letters imply more typing efforts. Not that the character kind matters: if the user must use his smartphone, then he will much prefer a sequence of lowercase letters than a password which mixes letters and digits or distinct casings.

Using "pronounceable" passwords is a trade-off: we accept to use more letters, so that we may use a password that better fits our echoic memory. Note that the number of possible "syllabic passwords" of length n is 10.39n, very close to the number of digits-only passwords of length n (10n); but many people will find it much easier to remember a random syllable than a random two-digit integer.

Whether echoic memory is the best compromise depends on the subject. Some people work better with pictures than sound (that's called iconic memory). There are even some people who are most at ease with numbers, and would prefer n random digits over n/2 random syllables. One of the main points of the famous comic is that most people really remember stories, and sequences of meaningful words are the substance stories are made of. We may add the following points:

What is the best fit for a given user is not necessarily the optimal trade-off for another. Thus the need for several password generation methods, so that each user may use a method that works best with his brain and fingers.
Users themselves are bad at making such decisions, because they tend to think that a password that "looks complex" is more secure. In fact, "password complexity rules" such as requiring letters, digits, mixed cases and punctuation signs siphon out the scarce resources of memory and typing very fast, and don't provide that much entropy. These rules are often a bad bargain, but many security professional love them, and parrot the received dogmas about their necessity, because the rules make for visible security (they give a lot more feeling of security than actual security).
All such analysis relies on independent, random and uniform selection of the password components. Letters, syllables, words in a passphrase... must be generated with a computer (or dice or some other physical device), not with a human mind. Humans cannot do good randomness. The password must be generated, then the story built on the result, and not the other way round. There must be random generation that the users accept. This is the trickiest point.

Last but not least, there is a disadvantage to pronounceable passwords: they may be pronounced. Users must be made well aware that though the password can be uttered, it must not be actually spoken, since it may then fall in malicious ears. The whole idea of pronounceable passwords is that users speak them in their heads. If a password is easy to pronounce, then it is also easy to share orally (e.g. with some co-workers), which is, in all generality, a rather bad thing.

User education, as usual, is what matters most. Regardless of how passwords are generated, security won't be achieved if the users are not informed about how passwords shall be used, and what they should not do with them.


Can I avoid DNS spoofing by typing the IP address? The question is in the title. I have been reading about DNS spoofing. What if I were to save the IP addresses of websites I consider sensitive and then just enter the IP address when I am using a suspicious connection to prevent myself from DNS spoofing attack? Will it work? Why or why not?

This won't work for many websites. Many websites use virtual hosts where they host websites for multiple domains from a single webserver. In this case, the only way they know what site you're coming from is by the hostname your browser sends in the Host header of the HTTP request.

The way to do this would be to specifically add these entries into your /etc/hosts (or on Windows, \Windows\System32\drivers\etc\hosts) file and continue to type the domain out as usual.

Unfortunately, even this can be impractical. Not only can you disable features like DNS-based load balancing and location-based DNS results (should you travel), but you could also open yourself up to attack should a site change IP addresses. It wouldn't be unreasonable for an attacker to consider trying to acquire the IP addresses large sites may have relinquished.

TL;DR this

is inconvenient as hell,
can disable useful DNS-based features
doesn't really add much practical security, and
introduces as many new attack vectors as it closes


Putty settings - Protocols and Algorithms to warn about I specify "Putty" as otherwise I feel the question would be too broad.

What are the algorithm (as of March 2016) that one needs to be warned about (ie, those that no longer are considered safe enough) when logging on a ssh server...

For Putty, I want to talk about the "SSH" and "SSH-Kex" sections of the config, ie the Encryption Cipher and the Key exchange algorithms. (and any other relevant config you may want to add)

Common choices for "SSH" "Encryption cipher selection policy" :

AES (SSH-2 only)
Blowfish
3DES
Arcfour (SSH-2 only)
DES

And for SSH - Kex (Key Exchange)

Diffie-Hellman group exchange
Diffie-Hellman group 14
Diffie-Hellman group 1
RSA-based key exchange

Putty allows one to move a "warn below here" setting, but I wonder where to place it at nowadays... Pointers welcomed!

A simple search was not enough for me... And we could also date each answer to ensure they give an hint as to their relevance [and [any?]one could then update them when things change, to keep the info as current as possible]

In SSH, for all algorithm classes (encryption, MAC, key exchange and public-key authentication), the client and the server send to each other their lists of supported algorithms; the client lists are ordered by preference, and that preference is honoured: the protocol is such defined that the chosen algorithms will be the first in each client list that also appears in the corresponding server list.

I recall that point because it highlights what this "warn below here" option really means. It means that there are some algorithms that the human user would really prefer not to use -- but, for some reason, he included them in its list of supported algorithms. So what will the human user actually do if he gets the warning ? Will he click on "OK, I got it" and proceed with the connection ? Or will he bail out ? In the first case, the algorithms are thus functionally supported, while in the second they are not. Does it really make sense to have a warning popup under these conditions ? If the user does nothing else about the warning than deciding whether to keep connecting or abort, then the warning is meaningless; it would be simpler and safer to simply omit from the list all algorithms that the user is not ready to use.

The warning is useful when the user (on the client side) can, at some point, alter the configuration of the server. It can then serve as a indicator for a misconfigured server, that the user may then fix himself at a later point.

All of that being said, there are reasons why some algorithms are preferable to others. In no particular order:

Protocol version should be SSH2 only. SSH1 has flaws, and if the server you are trying to talk to supports only SSH1 then it is very old software which is probably riddled with unfixed but known vulnerabilities, so you do not really want to connect to that server at all.
DES uses a 56-bit key (officially 64 bits, but 8 bits are ignored in the process, so effectively 56 bits). This is in range of exhaustive search by attackers with a bit of budget (in the thousands of dollars, not in the millions) so you really want to avoid that.
RC4 has known biases. SSH can support some variants that discard the first 1536 bytes of RC4 output, which removes the biggest biases, but not all. While there not has been any published practical exploitation of RC4 biases in the context of SSH yet, this is still a worry and it is recommended not to use RC4.
Blowfish and 3DES are 64-bit block ciphers. In SSH, they are used in CBC mode, which means that they begin to run into trouble after encrypting about 232 blocks (of 8 bytes each), i.e. about 32 gigabytes. If you occasionally transfer gigabytes of data over a single connection, then you will want to avoid 64-bit block ciphers, and concentrate on 128-bit block ciphers like AES.
3DES is slow in software. This may matter if you have a fast network (gigabit ethernet) or very slow hardware (not a PC).
If you have the choice, prefer "modern" encryption modes like GCM or CTR instead of CBC. The mode describes how the block cipher will be used.
For key exchange, you may want to avoid the "group 1" which uses a 1024-bit modulus. Breaking Diffie-Hellman modulo a 1024-bit prime has never been done in a public demonstration (current record is a 596-bit modulus) but it is within technological reach of mankind (projected budget would then be in the dozens or hundreds of millions of dollars). The "group 14" is a 2048-bit modulus, which is fine.
"Diffie-Hellman group exchange" is DH in server-chosen parameters, and normal servers will take care to select parameters that at least match the strength of their authentication public key. So this is safe as long as the server (or its administrator) does not do anything stupid.
RSA key exchange is pretty rare, because it involves generating an ephemeral RSA key pair on the server side, which is relatively expensive. Usual servers do not do that.

So my advice would be: remove all symmetric ciphers that are not AES; keep only DH group 14 and the "DH group exchange"; don't bother with the "warn me" limit; instead, use the failure to connect as a warning. If you cannot connect to a given server with sane parameters, then something is amiss and you should pause and think -- a forced abort is more likely to make you think than a simple warning popup. Maybe the lack of AES support for a given server is normal, but this requires an explicit decision, not a popup that is to easy to ignore.


Firewall Blocking IP Spoofing I was studying firewalls and I came to think of this. I have a firewall configured as follows:

packet filter rule table to allow users of a corporate network
to surf the web via HTTP and HTTPS

Now what happens if an attacker from the “outside” spoofs an
IP address from the “inside” as their source address?

Could they then connect to a machine inside the corporate network? Why/not?

Typically, a protected internal network relies on more than just an IP address to determine whether something belongs on the network. This could include, but is not limited to, some sort of software (a la MS NAC/NAP), or physical controls (i.e. are you connected to an approved device). Moreover, typically the edge devices that do routing to your internal network will behave as described by korockinout13, and drop any traffic coming from outside that looks like it is coming from non-routable (i.e. internal) addresses.


Is it secure to send personal data via HTTPS? On the website of some company, it is possible to send personal data using a form. The browser I'm using says that the connection is secure.
Is it completely secure to send personal data via the form?
Is there any possibility that an attacker can grab the data, or maybe the data could be stored anywhere between my PC and the company's server?
The website is accessed using the HTTPS protocol, so the data should be encrypted, shouldn't it?

No system is 100% secure. But encryption provides a high level of security for data in motion. But it doesn't mean that your data is 100% secured or impossible to break.
Especially you may be trying to access a phishing website. Even though HTTPS is secure, you are sending data to a malicious website.
In addition, the certificate key may be compromised but the certificate is not revoked yet. Or, Forward Secrecy can provide enhanced security of HTTPS but most sites do not enable this feature.
If the site has HTTPS properly configured, you can trust it up to a certain level, because if someone collects data from a middle point, it is impossible to read. If the key is not compromised.


how to make socat ignore client certificate? I'm trying to set up a listener to check if an application checks the server's certificate (I'm strongly assuming it is not). So I've created a self-signed certificate fake.pem for a listener and am trying to connect to it from the application.

socat openssl-listen:443,reuseaddr,cert=./fake.pem echo

The packets I capture in Wireshark are

Client (C) -> Server(S): SYN
S->C: SYN-ACK
C->S: ACK
C->S: sClient Hello
S->C: ACK
S->C: Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
C->S: Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
S->C: Alert (Level: Fatal, Description: handshake Failure)
S->C: RST ACK`

I thought that socat only checks against the option cafile (at least that's what it says in the manpage). Does it perform additional checks I could disable?

Could there be other good reasons why the server side would complain besides not a valid certificate from the client?

The problem was the certificate request part. The client application didn't send any certificate and if option verify=0 is added to the socat listener it works fine. verify is set to True by default.


Pen testing - How to use credentials without remote desktop? I'm a junior penetration tester, working in a place that does not give much guidance and I kind of just had to dive in. I'm pretty good, in that I can normally still obtain domain admin on networks I audit, as well as numerous other vulnerabilities. There is still a lot I don't know, that I am trying to learn to be a better tester.

One thing in particular is, what good are user credentials if I can't log on to other machines via remote desktop?

I had thought logging on to other machines to try and get local admin to access hashes and other such stuff is a big part of the process. But if remote desktop is not enabled or logins restricted to certain users, how can you use user credentials to still do this?

In addition to remote desktop (and PowerShell remoting, as @JoeM mentioned), credentials can be used for lots of things.

Accessing network shares or other resources over SMB
Access other services that are protected by Windows authentication (for example, internal web apps, SharePoint, etc.)
Logging into a user's mailbox (for example, on Exchange) to access the user's email and messaging
Using Windows remote management apps (may Windows command-line apps, such as schtasks.exe will accept a machine name and credentials)
Using Management Console snapins (many of the "Computer Management" tools can connect to remote machines)
Using Sysinternals psexec.exe tool
Using WMI (Windows Management Infrastructure)
Using SSH (if it has been enabled)
Logging into a VPN (if only Windows creds are required or you can access the other creds needed)


Use client SSL certificates as web application authentication I'm working on a web application with simple API needing authentication. For my application nature, users have two RSA keys, for signing and encrypting messages.  My protocol works based on it. The web application has access to public keys.

One solution to achieve authentication and kill MITM is to build SSL over the application API and build an authentication method using user's keys. Simple messages passing. But I'm thinking about another method... Make authentication based on SSL client certification. I'd used client certificates for previous projects but I've some problems deciding whether to use it for this project:

Is it bad idea to use one of user RSA keys to generate certificate for it?
Is there any web-server (as SSL wrapper) that can allow me to extend functionalities during SSL negotiation with external program? I mean when user sends SSL request, I look for his certificate in a database (a) and if found insert a record to a database as session ID and the web application use this (b). This means not just give access to some users, but finding out which user is logged in. ANSWER: At-least nginx supports passing received client certificate to the web application. I went by this.
Analysis about performance. I doubt about large number of users and this certificate based authentication performance, but authentication is some part in my application that should be done and SSL is too.  What extra load and latency can I expect when using client and server certificates compared to just using server certificates? ANSWER: See MadHatter's answer.

Thanks for your suggestions and sorry for my bad English.

The normal method of doing client certificate validation is to create your own Certification Authority (CA), and use that CA to mint client certificates, which are distributed to the clients.  The server then only has to check that a client certificate has a valid signature from the pre-configured CA, or has a valid chain of trust leading back to that CA, to know that the client certificate is good.
See above.
Very little extra overhead, at least when done as above.  All clients have certificates (public keys) anyway, they're just (usually) self-signed and are used only for encryption rather than encryption and authentication; if a client uses a certificate with a valid signature on it instead, having the server validate that certificate is a very small extra overhead.


problem upgrading openssl on ubuntu servers I'm running Ubuntu x86_64, and want to upgrade to OpenSSL 1.0.1.f.

wget <openssl latest>
tar -xzvf openssl.tar.gz
cd <openssl dir>
./configure --prefix=/usr
make

In the console output, I get the following error:

collect2: error: ld returned 1 exit status

Besides the fact that this topic is not security related, but related to Ubuntu administration, you should really use a package manager, like apt-get or aptitude.


Getting a log of computers that have remotely accessed a Windows server I have suspicions that someone other than people on my team have obtained the credentials to remotely access a Windows 2008 Server. I need to get some evidence before I start pointing fingers or get everyone alerted that someone might be hacking our servers.

Can I get a log of all the computers that have remotely accessed my server (by remote access I mean using the remote desktop features of Windows server). Ideally there should be some information about each computer, at least their public IP address.

Any help would be appreciated.

Once someone has access to your server it's not your server anymore. Meaning that logs could be tampered with as well as binaries.

There is a security log in Windows which allows you (if configured correctly) to:

Account logon events
Account management
Directory service access
Logon events
Object access
Policy change
Privilege use
Process tracking
System events

There is just a catch here. Any administrator will be able (as mentioned before) to tamper with the logs. If you are unsure it is best to place a sniffer between your server and the network. That way you can monitor all incoming and outgoing connections and determine if the IPs accessing the machine are indeed legitimate.


Is storing a user id in JWT enough to verify the identity? I have been thinking to try out JWT as an alternative to the old session based authentication for performance reasons (i.e. no additional SQL lookup for session id in database just to get the user id for each and every HTTP request) and usability reasons (JWT is gonna be used in HTTP headers instead of cookies so that my app can be used as RESTFUL API and accessed by non-browser clients like mobile apps, also adding JWT in HTTP headers eliminates the danger of CSRF). Since the payload is signed with a secure HMAC like SHA256, it's nearly impossible to forge the payload. Additionally, the user id itslef isn't really a secret and is used publicly by the app.

I am thinking of using a payload that is something like this:

{
  id: "1234abcd",
  iat: 1522779638
}

where iat is a unix timestamp at which the JWT was created and this can be used to expire the JWT message and also harden the security by randomizing the hash for the same id.

My question is, assuming that I am going to apply strict HTTPS connection for my app in production, is using this unencrypted payload secure enough to verify user's identity and initiate unsafe methods like POST methods (e.g. follow a user, unfollow a user, etc...) that's as secure as the session based authentication? Do I need to encrypt the payload using something like AES-192 or AES-256 just to be more sure?

This seems as being enough to authenticate the user and secure the token in transit. However, the problem could be that with this system, you would not have a good way to revoke such a token. So if the token is stolen, it can be used forever. You may want to have a way for user to revoke these tokens. There are many scenarios where token could be stolen, from malware through stolen phone to logging in on insecure PC let's say in an internet cafe.

One possibility would just be to add a single "not-before" column to the users table and refuse tokens with iat lower then that. So the user could revoke all previously issued tokens by setting this column to the current timestamp. This would require access to the database, but only to the users table using ID which you will probably want to do anyway.


Disclose to user if account exists? Someone told me it shouldn't be possible for someone to detect if a certain email address is used by a registered user on a website. So, for instance, when the user asks to reset his password, you should say "Password sent" whether the email exists in the database or not. If not, people can use this function to check who is a member and also check validity of spam lists, etc.

But I noticed that Facebook says "E-mail already registered" if you try to register the same e-mail twice. Does this mean that conventions have changed; that informing the user is more important than revealing accounts?

It is a rather old tradition not to tell people whether specific logins exist or not. This is why Unix or Windows systems, when asking for user credentials, will respond to any error with a generic "wrong username or password" message. The idea comes from a rather old-fashioned vision of attacks: envision a bad guy who wants to enter a mainframe, and succeeds in getting his hands on a serial terminal plugged to the system, or maybe a telnet interface over a modem line. This attacker will be in a position of an online dictionary attack: he will try to guess a pair login+password which grants access. The administrative login names like "root" were usually better protected than normal user accounts (the "root" user was better at selecting strong passwords, or at least so it was surmised) so attackers would try to find normal user accounts, and, in particular, normal user account names.

Watching the movie War Games (from 1983) gives you a good idea of how things were.

Note the critical point: in the attack scenario above, the attacker wants to obtain at least an account, but could not get one under normal conditions, or even know who has an account.

It is now 2013, three decades after that movie. We have servers where everybody can register for free, and get an account. Obtaining one account is thus no longer an attacker's goal. Instead, the attacker will want to access specific accounts, with known identities. This is not the same situation. The context has changed. Therefore, old lore is not necessarily applicable.

Anyway, when a user tries to register on Facebook, he expects the process to work. At that point, the process may fail for only one plausible reason, which is an email address already used. It would be difficult to hide that fact from the user...

If we want to "protect" user email addresses, then the registration process must go thus:

User enters his alleged email.
An email is sent to that address, containing a one-time registration link; however, if the email is already registered, then an email is sent explaining that fact. No clue is written on the response Web page as to whether the email already existed in the system or not.
The user registers by following the link from the email.

Such a process would double as an email verification process, so that's kind of good. However, it has some latency (user must get out of the Web site, open his email reader, and wait for the incoming email), so this can be problematic for shopping sites (users are not patient, and they are prone to go shop elsewhere if they find the checkout process too cumbersome). Also, there must be some guardrails to avoid this registration system to be abused into a spamming machine.

I think it can be said that, for Facebook maintainers, making the registration process as smooth and quick as possible is more important than the user's privacy. Really, who would that surprise ?


Why check to see if a password is already used by another user? This is coming from a joke originally in French:

  Enter your password.

  carrot

  Sorry, your password must be more than 8 characters.

  carottegéante
  (giant carrot)

  Sorry, your password must contain a number

  1carottegéante
  (1 giant carrot)

  Sorry, your password must not contain accented characters

  50putaindecarottesgeantes
  (50 damn giant carrots)

  Sorry, your password must contain at least one capital letter

  50PUTAINdecarottesgeantes
  (50 DAMN giant carrots)

  Sorry, your password must not contain two consecutive capital letters

  5OPutainDeCarottesGeantesQueJeVaisTeMettreAuCulSiTuNeMedonnesPasImmediatementUnAcces!
  (50 Damn Giant Carrots That I Will Put In Your Ass If You Do Not Immediately Give Me Access!)

  Sorry, your password must not contain punctuation characters

  AttentionMaintenantJeVaisAllerTeTrouverEtTeMettreVraimentLes50CarottesGeantesSiTuContinues
  (Caution Now, I'll Go Find You And Really Put 50 Giant Carrots If This Continues)

  Sorry, this password is already in use.

But speaking around with a friend:

I said:

  This is a built joke only: there is a typo on 3th answer: ne soit pas.. and at all, I don't know any user creation engine that do check for already used passwords.

My friend answer:

  You're right, it's a joke, but you could configure PAM to do such a check:
     password required pam_pwcheck.so nullok remember=N

Well, I don't understand!

Any unauthorized person could check if a password is used by simply create a new (fake) account!

What could be the goal of this kind of check?

You misunderstand what remember does for pam_pwcheck; see the man page:

remember=XX
Remember the last XX passwords and do not allow the user to reuse any of these for the next XX password changes. XX is a number between 1 and 400.

With this option, pam_pwcheck will reject attempts at reusing a password which was previously used by the same user. It does not do anything cross-users; it will not warn you about whether your password of choice is used by anybody else or not.
In fact, such a check would be expensive to implement if proper password hashing is in place (with salts and many iterations for slowness, it would take several minutes to "try" the putative password for thousands of other users). As you say, warning users about how a potential password is already used by another user would be, by itself, a serious security issue; but it would also mean that the passwords are not stored properly, and that is another serious security issue.


With 2-factor authentication, is a backup email address or phone a good recovery option? A lot of sites offer 5 or 10 recovery codes as the backup mechanism if the user loses access to their primary 2FA (usually a phone number). Can we just simply use a backup email address instead, or a backup phone number? After verifying their primary email and password, we would email/text their backup with a code that they have to verify. What are the pros and cons of this recovery method?

The whole point of 2FA is to require the second factor to login. Usually - password+token, in recovery situation - password+recovery key. Something you know + something you physically have.

If you can use secondary email as a recovery option for 2FA, the user account is protected by their password + the recovery email password, thereby defeating the goal of 2FA. The attacker will just go through the easier route.


How to properly invalidate JWT tokens and sessions in this use case? I am building a web app, which is made of a Node.js Backend and Angular (NOT AngularJS!!! I only used the tag, because Angular was not available..) Frontend.
How do I properly secure this app? I already have an idea to use JWT tokens (I already implemented this) with a set expiration date, which will be way longer than the Frontend timer. The frontend timer should be like 15 minutes of inactivity. But how do I secure this Frontend timer against RAM modification with tools like Cheat Engine and also JavaScript modification/injection/editing? Are there any flaws in this logic? Any suggestions?
I was thinking of renewing JWT tokens, but that's apparently not possible. I am sure there's something wrong with my logic but I can't put my finger on it. Maybe I am lacking general sessions and their management?

You can't rely on the client code
General rule of thumb: once you send code down to the client to run on the user's machine, it's not your code anymore. The only security you can count on is security that's enforced by the server.
Stateful vs stateless
When designing a JWT mechanism you have to choose whether you want the server to track sessions in some sort of cache or not
Pros of stateless:

JWT is entirely self-contained; everything the server needs to know about the user and session is contained in the JWT (either a signed JWS if the contents are non-sensitive, or an encrypted JWE if the contents are sensitive).
Low server memory footprint (no cache) and latency (no db lookups).
High horizontal scalability because there is no cache to syncronize.

Cons of stateless:

No way to revoke a token -- the JWT will be valid until it expires (for example, no way to robustly do a logout mechanism).

Hybrid solution: short-lived JWT with Refresh token
The best-of-both-worlds solution that I like is to issue sort-lived stateless JWTs (expires in 5 - 15 mins), and also issue a long-lived stateful Refresh token (expires in weeks - months). That way the flood of API requests that happen on page load are using the high-performance stateless token, but you get to enforce logout every 5 - 15 mins when the client needs to trade in its Refresh token for a fresh JWT and Refresh token.
Auth0 has a nice writeup of this solution here:

https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/


How to Stop Email Spoofing Apart from SPF, what else can be done to stop hackers from spoofing your company's email addresses?

Set up Domain Keys Identified Mail on your own domain.  That will digitally sign legitimate outgoing from your domain.  More and more email providers are rejecting or flagging spoofed email where legit email is identified with a Domain Key signature.

Your question says, "apart from SPF..." and that's what I answered.  However, for others who might use this answer, SPF is another deterrent.  It is easy to set up, but has some limitations that should be considered carefully.  You probably want to start with a SOFTFAIL policy.


Is it secure to rely on websocket connection? In a client-server communication scenario over secure websocket, client is authorized securely and from there on, I have two choices:

Assign a unique random ID (session) and check that on subsequent
communications.
rely on socket connectivity and keep a handle to the socket object (which internally use it's own session).

For sure the first choice is secure if has been implemented properly. My question is, if the second one is secure.
If someone be able to intercept websocket connection in such a way that connection is not dropped, this choice could not be considered secure. Should I worry about that?

If the webSocket connection is using SSL/TLS, then it cannot be "intercepted" or "hijacked" after it was connected. This is one of the fundamental protections of SSL/TLS.

Part of establishing such a connection is that the endpoints securely end up with encryption keys (created via the public key/private key technology) and one intercepting the connection (a so-called man-in-the-middle-attack) will not have appropriate encryption keys and thus will not be able to either read data being sent or inject data onto the connection.  They can't read because data is encrypted with keys they don't have.  They can't send data because they don't have the proper keys to encrypt data that will pass incoming security tests.


What security measures does Chrome have in place to sandbox different user accounts? Google Chrome has a feature that allows different users to use Chrome on the same computer in a completely separate space.

The support page is quite light on information. Is there information available about the security of this particular feature? What sort of measures are in place to prevent attacks against a particular user account from affecting another user account?

It is not a true sandbox. It is more a way to keep several "profiles" in a way similar to what Mozilla/Firefox have always done: basically, each such "user" will have his own set of cookies and browsing history, but, at the OS level, there is just one Chrome and one user account. The normal Chrome "sandboxing" is active in the following sense: code within one page shall not escape the browser and mess with the user's files (or, for that matter, with other pages or tabs). However, if malicious code does succeed in escaping that sandbox, then nothing will prevent it from altering the profiles of all "Chrome users" because the protection at that level is from the OS, and the OS is oblivious to this separation into multiple "Chrome users".

Chrome has long resisted adding such a feature, claiming that it was better to use several OS-level accounts. They were theoretically right, but it seems that market pressure trumps theory every time; and then they yielded.


How can I identify / discover files hidden with ADS? ADS, or alternate data streams, were added in to Windows in 1993 (First Windows NT version) as a feature of the new NTFS file system to help support some features of the Mac OS at the time. I like to read about security stuff, and I recently read about how viruses, trojans, keyloggers, etc. like to hide using ADS because the file is invisible - not like a hidden file, but completely invisible to Windows Explorer, and even the dir command in Command Prompt. Basically it's like the Anne Frank for computer viruses, it hides there and no one knows it, which is why it could be a threat to computer users.

Is there a way to detect these ADS files without the use of a specialized program, and if not what would be a progrm / method to detect these files?

In a command-line environment, dir /R includes ADSes in the directory listing. Its other options work as usual, so dir can list a single file, wildcards, or (default) the entire directory; and optionally all subdirectories.
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>dir /?
Displays a list of files and subdirectories in a directory.

DIR [drive:][path][filename] [/A[[:]attributes]] [/B] [/C] [/D] [/L] [/N]
  [/O[[:]sortorder]] [/P] [/Q] [/R] [/S] [/T[[:]timefield]] [/W] [/X] [/4]

  [drive:][path][filename]
              Specifies drive, directory, and/or files to list.

  /A          Displays files with specified attributes.
  attributes   D  Directories                R  Read-only files
               H  Hidden files               A  Files ready for archiving
               S  System files               I  Not content indexed files
               L  Reparse Points             -  Prefix meaning not
  /B          Uses bare format (no heading information or summary).
  /C          Display the thousand separator in file sizes.  This is the
              default.  Use /-C to disable display of separator.
  /D          Same as wide but files are list sorted by column.
  /L          Uses lowercase.
  /N          New long list format where filenames are on the far right.
  /O          List by files in sorted order.
  sortorder    N  By name (alphabetic)       S  By size (smallest first)
               E  By extension (alphabetic)  D  By date/time (oldest first)
               G  Group directories first    -  Prefix to reverse order
  /P          Pauses after each screenful of information.
  /Q          Display the owner of the file.

  /R          Display alternate data streams of the file.

  /S          Displays files in specified directory and all subdirectories.
  /T          Controls which time field displayed or used for sorting
  timefield   C  Creation
              A  Last Access
              W  Last Written
  /W          Uses wide list format.
  /X          This displays the short names generated for non-8dot3 file
              names.  The format is that of /N with the short name inserted
              before the long name. If no short name is present, blanks are
              displayed in its place.
  /4          Displays four-digit years

Switches may be preset in the DIRCMD environment variable.  Override
preset switches by prefixing any switch with - (hyphen)--for example, /-W.

dir has no option to list only files that have ADSes. See also https://stackoverflow.com/questions/16333782/how-to-display-only-files-that-have-alternate-data-streams-in-command-prompt


Why is it easy to detect network layer DDoS attacks? I have seen numerous research papers that claim it is "easy to detect network layer DDoS attacks" without saying why. Usually these research papers focus on detection or prevention of application layer attacks, which is why they don't go into detail about network layer attacks. Why is it easy to detect network layer attacks? One of the papers I am looking at says "In network-layer DDoS attacks, attackers send a large number of bogus packets (packets with bogus payload and invalid SYN and ACK number)". Why not just open up a large number of "new connections" with valid data, other than a spoofed IP address? Yes, I suppose it would be easy to detect when you've just received a packet with an invalid packet header. But what about when you receive a lot of packets with valid headers, that are nonetheless from spoofed IPs?

Network-layer DDoS attacks typically involve a lot of very similar traffic; it follows a discernable pattern, it appears in statistically unusual quantities, and it looks very different from the surrounding "normal" traffic.

That's what makes it easy to identify.