Here is a good overall reference http://cwe.mitre.org/data/definitions/79.html

per www.infosecisland.com:

  From Symantec's Candid Wueest:

  "The vulnerability exists in the mobile API version of Facebook due to insufficient JavaScript filtering. It allows any website to include, for example, a maliciously prepared iframe element that contains JavaScript or use the http-equiv attribute’s “refresh” value to redirect the browser to the prepared URL containing the JavaScript."

  "Any user who is logged into Facebook and visits a site that contains such an element will automatically post an arbitrary message to his or her wall. There is no other user interaction required, and there are no tricks involved, like clickjacking."

  "Just visiting an infected website is enough to post a message that the attacker has chosen. Therefore it should be of no surprise that some of those messages are spreading very fast through Facebook. Some are posting links to infected websites, creating XSS worms that spread from user to user."

  Facebook has patched the JavaScript-based XSS vulnerability, and the company says they are now working to undo the damage done by the attack.

So the issue is related to neutralizing data input into web pages.


I kinda solved the problem by reinstalling it from its repository instead of using arch linux package manager. First I uninstalled it then

git clone git://git.savannah.gnu.org/tiger.git
./configure
make
sudo make install

Then it created all the necessary files to run.


HMAC and password hashing solve very different problems. With HMAC the secret is expected to be high quality (ie 128 bits of entropy), whereas passwords are expected to be low quality (30 bits of entropy is optimistic for most people).

A single round of a quick hash function is bad for passwords because it allows attackers to quickly attempt many common passwords, or do a brute force attack on a low entropy password. For HMAC that risk doesn't really exist (as long as the secret is generated by a CSPRNG), so one round is sufficient.

Side note: you didn't specify, but you shouldn't use SHA-256 directly for hashing passwords, even if you use many rounds. It's much easier to use PBKDF2 with SHA-256 from a standard library so you don't run into any pitfalls.


Runlevels determine what services are started on Unix machines. Usually the higher the level, the more distinct processes are executed. As a general rule level 3 does not include GUI and level 5 does.

There is no right or wrong runlevel. It's about compliance.

The problem might arise when you secure your server assuming it's running without a graphical environment (thus for example you don't harden or patch it), but in reality it does (so the attack surface is larger than you assumed).

The checks are there to make sure the machine is running at the level you expect it to run; and that it runs (only) services you expect it to run at the specified level.

  And which level could be undesirable?

Any level different from the policy specified for each individual server is undesirable.

  What can go wrong if I configure the runlevel wrong?

In such case you cannot claim you have a full control over your systems. You don't know what processes they are running, you can't tell if those processes are secure. You can't tell what can go wrong.


... is it theoretically possible for an attacker to obtain the php source-code in plain text by doing things with the url?

There is no inherent feature within a web server or a URL which makes it possible to get the source code of a PHP file from remote.

But, this does not mean that it is impossible in all cases. For example a bad server configuration might unwillingly expose the source code. Or a bug in the web application might allow read access to files on the server, including the PHP files. Or due a bug in some file upload feature an attacker might be able to upload its own PHP script which allows this kind of access. And sometimes none of this is even needed since the source code is available from some badly secured software repository.


iptables: block traffic from OSX hotspot

I think you're falling into the trap of looking for a technical solution to a managerial problem.
This is a case of users circumventing security. Try talking to them; why would they want that hotspot? Does the official Wi-Fi network have shortcomings that they're trying to work around?

As long as this is not addressed they will find ways to work around what you're trying to fix.

Why? Because this is not really something you can fix with a firewall.
These only look at the physical and logical addresses, which aren't much use here.

If you don't know who is doing it, you could try foxhunting them with airodump-ng, or see if your Wi-Fi solution supports rogue AP detection.


as the website service panopticlick puts it "How unique and trackable is your browser?"

there are many things that especially via scripting can be found out about your machine. This uniqueness estimation can include

browser type
browser version
geometrics (screen size)
average cpu usage / calculation power via script trial
fonts (are a especially neat way to test for uniquess)
the operation system as reported by the useragent stuff from the browser


DoS testing as a part of penetration testing

First, I would not rely solely on banner enumeration to determine vulnerability in terms of a penetration test.

Second, it might not be correct to assume these are the only viable DoS attacks. Web applications (particularly ones that are homegrown) are often vulnerable to all kinds of interesting DoS attacks. One example might be an application server that has a connector that interfaces incorrectly with a partnering web server and a series of requests (ie. content discovery with a tool like dirs3arch) for non-existent content will cause the server to fall over.

And for the slowloris style attack, any servers that will keep connections open indefinitely when receiving incomplete requests will be vulnerable. I've found quite a few applications where this is true in real-world penetration tests.


How does Java connect via SSL to a server without me providing any private/public key for the communication?

In "usual" SSL, the public and private key pairs are on the server side, not the client. The client uses the server's public key (as found in the server's certificate, that the server conveniently sends to the client during the first connection steps) but does not need to own a public/private key pair itself(*).

Of course, this implies that while the client obtains from the server's certificate some reasonable guarantee that it is talking to the genuine intended server, the server has no idea whatsoever who the connected client may be. When there is no client certificate, SSL ensures only one-way authentication. If a server wants to authenticate clients, then it is up for the client and server to run some extra authentication protocol within the SSL tunnel. That's exactly what happens with Web browsers and HTTPS servers: the SSL layer convinces the client that it is talking to the right server, and then the client shows the user's password to the server.

(*) If the client and server agree to use a "DHE" cipher suites, then indeed both the client and server create temporary Diffie-Hellman key pairs, that you won't see; the corresponding public keys will not appear as part of certificates either. If the client and server use a more common "RSA" (non-DHE) cipher suite, then the key exchange is really the asymmetric encryption of some random bytes generated by the client, using the server's public key, and there is no public/private key pair on the client side.


Is it dangerous to sync my data with my personal server through unencrypted http?

It depends on what you are worried about.  Transmitting it unsecured means someone could alter it in transit or monitor the connection and make off with your data.  Further, they could access your OwnCloud credentials and take, remove or alter data on your OwnCloud account.  If you are just using it in a read only manner, you are a little better off, but still open to manipulation before it gets to you.  This probably isn't a significant risk for most people, but it is a risk that can be easily mitigated.

You can use a self-signed SSL certificate for this and add your signing certificate as trusted (or simply accept the untrusted connection).  This will still provide encryption for your connection but won't cost you anything.  You only have to pay to get an SSL certificate that is verified by a certificate authority.

If you do decide you want a trusted certificate, they are also pretty cheap.  I get mine from StartSSL for under $60 for a 2 year SSL cert.  I actually use that cert with my OwnCloud instance and it works great.


Can 802.1X, EAP and RADIUS work together?

I don't see any reasons why they can't work together, especially when they are different things?

EAP -- Extensible Authentication Protocol. It is just a PROTOCOL which is used by 802.1x authentication server (RADIUS, for example) and client to authenticate each other.

RADIUS -- Remote Authentication Dial-In User Service. It is SERVICE which use one or more authentication protocols used by clients to authenticate themselves. There are several industrial authentication protocols, which include but not limited to: (from less secure to more secure) PAP, SPAP, CHAP, MS-CHAP, MS-CHAPv2, EAP-TLS.


How to set up OpenSSH to use x509 PKI for authentication?

OpenSSH does not officially support x.509 certificate based authentication:

  The developers have maintained a stance that the complexity of X.509
  certificates introduces an unacceptable attack surface for sshd.
  Instead, they have [recently] implemented an alternative certificate
  format which is much simpler to parse and thus introduces less risk.

...

  OpenSSH just uses the low-level cryptographic algorithms from
  OpenSSL.

However Roumen Petrov publishes OpenSSH builds that do include X.509 support, and you could try with those.

  X.509 certificates can [be] used as "user identity" and/or "host key" in
  SSH "Public Key" and "Host-Based" authentications.

Roumen Petrov's builds can be downloaded via this page.

Here's a Debian how-to for SSH with authentication key instead of password that might also prove useful in setting up your OpenSSH to accept x509 PKI for user authentication.


How to log all resources my site needs from other sites?

If you use Firefox, you can install Firebug, go to the Network tab, and load your site. All the requests will be shown there, so you can host them on your server and change the code for your website.


Credit Card Fraud Prevention - Why Aren't Simple Things Used?

I recently lost my ID at a ski resort. While I was waiting for them to mail it back, I got groceries. If they had asked me to present ID, then I would have had it taken. Plus, there's a burden on the sellers to confiscate/store IDs, and deal with all the people who would absolutely lose their marbles when their CC is confiscated. You'd be really screwing with normal commerce.
That's a ton of data. Plus, a photograph doesn't mean too much if you're prepared for it. Makeup, wigs, and lighting are magical.
Interesting. A two-step auth for credit cards! That's feasible, but vendors are just starting to roll out two step for passwords. That might be a ways off for the general populace, which when faced with technology is only slightly smarter than a bag of hammers.

  Why are the card issuers, banks, and gateways apparently not doing more and just eating the costs of fraud?

Because they can!


Can importing an .ics file be dangerous?

The real risk here would be the application importing the .ics file, the file in itself is harmless. Only if that application would improperly handle parts of the file content you would be at risk. With Google Calendar, I think those chances are very, very slim.


Why does Authenticated Encryption not decrease confidentiality?

Instead, only the MAC will be checked, which should be considerably faster.

Not so. In fact, it can be the opposite.

For Encrypt then MAC, you'd have to MAC the entire ciphertext to test a MAC key
For both Encrypt and MAC and MAC then Encrypt you'd have to decrypt the entire ciphertext and then MAC the entire plaintext to test an encryption+MAC key
If the ciphertext starts with a known plaintext block, you can decrypt the first block and see if it matches to test an encryption key

The fastest of those options is the 3rd, and ciphers should still be secure against that. With a 128 bit or larger key there are just too many possibilities to guess (as long as the key is random).


E-voting: receipt-free, verifiable, and anonymous

Being anonymous, verifiable and reciept-free at the same time is impossible. Of course, there will be kept some records and logs for verification purposes. You have to be seen(logged) for maintaining the rights of one person one vote. If it really is completely anonymous, anyone from anywhere in the network can vote any amount of times without getting caught. Being logged is a price you have to pay.

But still, if you don't want that, there is a darker way.


Strange requests coming from EA4350 Linksys routers

Your router may be scanning for vulnerabilities other routers, it certainly does not appear to be expected behaviour.

POST /JNAP/ is likely an attempt to exploit CVE-2014-8244
GET /HNAP1/ is likely the vulnerability used by the moon worm
I wasn't able to pinpoint the rest urls to a specific vulnerability with a quick search.

According to the CERT advisory I linked to for the JNAP vulnerability you should be using a much newer version of the firmware.


You're simply hitting the maximum number of allowed keys in an answer.  For example searching my username:

$ gpg --keyserver pool.sks-keyservers.net --batch --search-keys "grochmal"
gpg: data source: http://mira.cbaines.net:11371
(1) Michal Grochmal <REDACTED>
    Michal Grochmal <REDACTED>
    Michal Grochmal <REDACTED>
      2048 bit RSA key 040E2771C840C4F6, created: 2014-08-21
Keys 1-1 of 1 for "grochmal".  gpg: Sorry, we are in batchmode - can't get input

But searching a common name would give a huge amount of keys, and the server will refuse to answer:

$ gpg --keyserver pool.sks-keyservers.net --batch --search-keys "mike"
gpg: error searching keyserver: No data
gpg: keyserver search failed: No data

In the Bitcoin case all that the server is telling you is that you exceeded the maximum number of allowed keys with your search for "Bitcoin", and you should try a more specific term (which "Bitcoin Core", or even simply "Bitcoin Co" turns to be).

The maximum number of returned keys that can be returned has been 1000 in the past (on pgp.subkeys.net).  But that is information from 10 years ago, I may be wrong, and the number is probably different now.


Is it secure to use CORS to implement SSO?

Over and above the advantage of only having to deal with one user database, there are 2 important security benefits of using SSO:

1) The application should never see the credentials - thus removing some of the attack surface

2) since the browser redirects to the SSO site, the user can easily verify that they are supplying their password to the appropriate system under appropriate controls (TLS, HSTS).

What you propose seems to directly undermine 2, and, since the client will be pointed to the SSO by the application, your proposal indirectly undermines the first benefit.


As a general rule, every security application that performs monitoring or blocking will have a place for you to review any alerts. If it doesn't have that, then it's either useless or a complete fraud.

In your case, there is a detailed view.

Thie picture below was taken from McAfee Knowledge Center article TS102852. You can find the same article by searching "TS102852".

The button is blue in the picture below. This may be due to UI focus, so your button may be the same color as the "Got It" button.


Why would some Windows executables not have a "Digital Signatures" tab?

Executable's are not required by Microsoft to be signed. However, drivers are.

  Starting with 64-bit versions of Windows Vista and later versions of
  Windows, driver code signing policy requires that all driver code have
  a digital signature. In addition, certain configurations of 32-bit
  versions of Windows Vista and later versions of Windows also require
  driver code to be digitally-signed in order to access next generation
  premium content that is controlled by the content protection policy.
  Windows Vista and later versions of Windows rely on digital signatures
  of these components to increase the safety and stability of the
  Microsoft Windows platform and enable new customer experiences with
  next generation premium content.

Ref: https://msdn.microsoft.com/en-us/library/windows/hardware/ff548231(v=vs.85).aspx


Protected Client Server communication advice

If you see only the ACK, SYN+ACK, ACK and FIN packets, then you are seeing the shell of a TCP connection, but no data. If the FIN is from the client, then the client apparently decides that it has nothing to say. So this points at a configuration issue on the client: when the client should begin the SSL/TLS conversation (by sending the ClientHello message), it just gives up. In any case, at that point, the role of the server is to wait for the ClientHello, so its own SSL-level configuration has not been exercised yet.

Now some general comments:

In SSL/TLS, the server should have a private/public key pair, the public key being wrapped in a certificate. The client may also have a private/public key pair -- but not the same one ! The whole point of asymmetric cryptography is to avoid having to share private elements between different entities. In fact, you should strive never to let private keys travel between systems: the more a key journeys, the more exposed it gets, thus the less private it becomes.
Cipher suites select the set of cryptographic algorithms which will be used. In the three suites you talk, RSA will be used for the initial key exchange (so the server's public key should be of type RSA), and SHA-1 for integrity protection. The symmetric encryption will use, respectively, nothing at all, 3DES, or AES. If unsure, use AES. If you are thinking about using the "NULL" encryption, then think again.
If you want to use SSL/TLS, and, even more, if you want to debug some SSL-related issues and have begun launching Wireshark (that's a good thing), then you will need to understand how SSL works. You could do worse than reading this answer for some explanations on that.


Do you need to validate compensating controls of a certified organization?

You should be able to link to an existing certification from your own documentation. Referencing, and providing links to, their existing certification as a compensating control in your documentation should serve as validation. In effect you are chaining the documentation sources together which in many cases will make it easier for the 3rd Party Auditor/Assessor as they can verify the existing certification rather than wading through your reproduction/validation of already existing documentation. However, you should ascertain whether the certification itself meets the requirements and is valid to the best of your ability before adding it as a compensating control.


How I can get following cipher list support in openssl to test

By using OpenSSL version 1.1.0 or higher:

$ openssl-1.1.0c ciphers -V 'PSK'
0x00,0xAB - DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(256) Mac=AEAD
0x00,0xA8 - PSK-AES128-GCM-SHA256   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(128) Mac=AEAD
0x00,0xB7 - RSA-PSK-AES256-CBC-SHA384 TLSv1 Kx=RSAPSK   Au=RSA  Enc=AES(256)  Mac=SHA384
0xC0,0x38 - ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(256)  Mac=SHA384
...


It is very, very unlikely that they could recover data from the hard drive after even a single wipe.
But I would be more concerned about the data that is not on the drive, like your company cloud storage, email, backups, etc.


How (if at all) can an attacker manipulate an already established SSL/TLS Connection?

Pretty much any active attacks leads to an aborted connection. This includes disrupting the TCP connection as you suggest, or manipulating the payload, triggering a MAC failure, which in turn aborts the connection.

TCP disruptions have happened in practice. While this was against bittorrent, and not SSL protected connections, SSL over TCP can't prevent this kind of attack.

  According to independent testing, Comcast injected reset packets into peer-to-peer connections, which effectively caused a certain limited number of outbound connections to immediately terminate. This method of network management was described in the IEEE Communications, May 2000 article "Nonintrusive TCP Connection Admission Control for Bandwidth Management of an Internet Access Link"

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

It's important to note, that the software using TLS is able to distinguish aborted connections from connections that were closed gracefully, because a gracefully closed connection ends with a TLS "BYE" message, which cannot be faked by an attacker.

DTLS over UDP might be more robust since you can't just disrupt the TCP connection. But of course an attacker can simply swallow all messages preventing the connection from continuing.


Are all SSL domain validation basically the same technically speaking?

"If there is no real difference then why not go with the free ones provided by cPanel?"

  Use this interface to install an SSL certificate on a domain, subdomain, or addon domain. Before you can use this feature, you must create or purchase a certificate, and you must possess the certificate's key.

Directly from cPanel's website it looks like you MUST either purchase a cert, or you can use one cPanel provides, but that MAY be a self-signed certificate. Without seeing what is offered by cPanel, I have no way of guaranteeing what cPanel is offering is a CA signed certificate.

If you choose the free certificate from cPanel, it will tell you if it is of the self-signed variety:

  When you install a certificate, this interface indicates whether your certificate is self-signed. Self-signed certificates are easy targets for attackers and generate security warnings in your users’ web browsers. Only install a self-signed certificate temporarily, until you can replace the certificate with a certificate from a valid certificate authority (CA).

You can actually look at the certificate you are provided and determine if it is "technically" the same as another.

If you want to decode a cert on your computer use the following:

openssl x509 -in certificate.crt -text -noout

If you don't mind providing your certificate to a website to be "read" (this is the same thing that happens when the cert is read while in use):

https://www.sslshopper.com/certificate-decoder.html

Usually you select a modulus value (2048 or 4096, anything less is weak), the PKI encryption type (ECC or RSA, either is safe for common use), symmetric encryption type (AES 128 is safe for common use) and any hashes (SHA-256 is common, I prefer SHA-384 because more bits). If you compare two RSA 2048, AES-128, SHA-256 certs they are technically the same regardless of how much they cost.

In March of 2020 most browsers will no longer accept SSL (any version), TLS 1.0, or TLS 1.1. If you have the option, ensure that you are using a TLS 1.2 certificate, at minimum.


What is the best practice for giving Oracle DB credentials to a Java Application?

The standard that I've seen is simply use file system permissions - to do so, you need to ensure that the application is running as a dedicated user - that no other application uses that user; that access to that user is restricted similarly; and that the appropriate config files that contain secrets are restricted to just that user - no group or other permissions at all.

Beyond hardware based authentication storage systems, most other schemes simply end up moving the secret that needs to be stored (example, some people suggest encrypting the information - the secret that then needs to be protected becomes the encryption key/initialization vector).  Ultimately, SOMETHING needs to grant the access - and there's nothing fundamentally wrong with OS file system permissions.


Does WhatsApp "end-to-end" encryption protect against a compromised router?

What you describe as your wifi in being controlled let fear a Man In The Middle attack. The encryption of Whatsapp message is more than enough to be protected from that. Someone just eavesdropping what is exchange over the Wifi network will only see encrypted messages and will not have access to the actual content.
Now if your question does using Whatsapp guarantee that nobody else but the recipient will ever see the messages, the answer is quite different. The protocol used by Whatsapp is indeed secure, but it looks like the implementation willingy choosed ease of use over security. It has been discussed at Whatsapp security, and a comment gave a link to the Guardian explaining that

A security vulnerability that can be used to allow Facebook and others to intercept and read encrypted messages has been found within its WhatsApp messaging service...
However, WhatsApp has the ability to force the generation of new encryption keys for offline users, unbeknown to the sender and recipient of the messages, and to make the sender re-encrypt messages with new keys and send them again for any messages that have not been marked as delivered.
The recipient is not made aware of this change in encryption, while the sender is only notified if they have opted-in to encryption warnings in settings, and only after the messages have been re-sent. This re-encryption and rebroadcasting of previously undelivered messages effectively allows WhatsApp to intercept and read some users’ messages.
[Whatsapp justifies that to cope when] a contact’s security code has changed. We know the most common reasons this happens are because someone has switched phones or reinstalled WhatsApp. This is because in many parts of the world, people frequently change devices and Sim cards. In these situations, we want to make sure people’s messages are delivered, not lost in transit.

So Whatsapp main design is useability and not security. Full stop. For most usages it is fine, but if you really need a high Confidentiality level, choose a tool dedicated to security like PGP or S/MIME encrypted mail. Not as sexy but far more secure.


Number of AES-256 operations per second on a maximized Cray XE6

The cores in a Cray XE6 are AMD Opteron -- that's the kind of thing you find in a basic PC. You could expect that each core could compute one AES block in a bit more than 300 clock cycles; but if the cores know the AES-NI opcodes, then this can drop to 30 clock cycles per AES-256 instance. Assuming that the whole thing runs at 3 GHz, you can then hope for up to 108 AES-256 operations per second. With one million cores, that's 1014.

Note that:

A full CPU is something quite huge if you just need an AES implementation. In particular, the floating-point operations that Cray boasts about are totally useless for attacking the AES.
Most of the price of a Cray XE6 is about the interconnection of the CPU: bunches of helper bus and controllers, which are not used for AES cracking.
Even at 1014 operations per seconds, you would still need more time than the lifetime of the Universe to actually crack a key.

Buying a Cray XE6 to crack AES would be a huge waste of money.


Sudo password when authenticating via passwordless SSH

The reason you're not being prompted for a sudo password is because your user (or usergroup) has NOPASSWD enabled in /etc/sudoers. You can edit this file with visudo as root.

Regarding passwordless authentication, you are correct that public key authentication is a preferred method for authenticating to servers. If there is no password to guess, then no brute force attempt can succeed.

The fact that you have no root password at all violates some best practices, but as you correctly stated, if a key is required to get into the box, it is probably alright. Having a root password might encourage you to use SSH to login as root, which should be disabled in your sshd_config.

The only question I have relates to one of your last paragraphs:

  Also, for the record: I did try to set a password by logging in via SSH and then running passwd, but it threw an error. I don't remember the exact phrasing, but it was something about a "token". Either way, the password didn't stick, which makes me think I'm misunderstanding something at a fundamental level here.

You were unable to set a password while sudo'd to root? Or just as a regular user? Having public key authentication in place shouldn't stop you from setting a userspace password, nor a root password. It looks like you might be encountering this problem, discussed on SuperUser, so hopefully that will help a bit.

I hope I answered the security side of your question; feel free to add a comment or followup if you need more information!


What is the difference between misuse and abuse cases in security?

The nuance is subtle and not well-defined, but if you really want to make a distinction between misuse and abuse, then I'd say that abuse is "misuse with malicious intent".

E.g. running while carrying a powered chainsaw is misuse; doing so on purpose in a crowded mall is abuse.


Is hashing the concatenation of my password and account type secure?

The idea is, broadly, secure. In fact, it's been implemented several times before. There are a few problems that any such approach (and a few more than an approach as simple as this) will run into, though. In no particular order:

Multiple accounts per site. The scheme, as described, provides no way to differentiate between accounts for the same site. You'd need to stick a username in there somewhere.
Password rotations (mandatory, or due to compromise). You can't change the generated password without changing the master password. While mandatory password rotations are becoming less common, they do still exist in some places.
Password complexity rules. Sites tend to have a wide-ranging (and often very bad) list of complexity rules, some of which are mutually incompatible (e.g. one site insists on "special characters", another forbids anything non-alphanumeric). This tool has no way to meet constraints like that.

Speaking of which, how exactly do you plan to encode the hash digest? 256 bits is 32 bytes is 44 (if you keep the terminating =) base64 characters or 64 hex characters... None of these are the 40 characters you mention (are you thinking of SHA1 - a 160-bit digest - in hex encoding?)

Master password can't be rotated. With normal password managers, you can change the master password (if, for example, you fear somebody may have keylogged it), and while it's a good idea to then also change all the passwords it was protecting you probably have some time to do so. With this scheme, you have to update the passwords on all your sites if you want to change the master password.
Lacks brute-forcing protection. While the master password you chose is long enough to probably be safe (assuming you use something of similar entropy), most people are going to pick more predictable passwords than that. A single round of any fast hash (including all members of the SHA family) salted with nothing but a predictable string provides very little protection against brute-forcing, these days; a decent graphics card can compute billions of hashes per second (and specialized hardware can do much more than that) trying to find the original password. You need, at a minimum, to use a few thousand rounds of hashing to slow down the search; you could also use one of the newer algorithms (like scrypt or argon2) that is specifically designed for password hashing.
Passwords are hard to transcribe. If you need to enter a password into anything that doesn't let you copy-paste it, you're in for a lot of very careful typing.
No way to look up stored accounts. While this can be a plus in the event of your system getting compromised, it's more often a minus. If you don't know whether you have an account for some service, or don't know what the "salt" for the account is (is it "bankofamerica", "BankOfAmerica", "Bank of America", "BOA", "boa", "BofA", ...?) you might spend a while trying wrong passwords without knowing for sure.
No way to store associated secrets. For example, a password manager lets you store things like multi-factor backup codes or "secret question" answers; this system doesn't support the first at all and the second only clumsily (by basically using the question itself as a site/username/salt/whatever).
No support for changing cryptographic primitives or work factors. If SHA-256 gets broken and everybody is told to move to the SHA3 family, you have to change all your passwords. If in two years you want to double the number of iterations you do to account for Moore's Law, you have to change all your passwords.

Anyhow, not saying such a scheme is actually insecure (though you might want to harden the hashing function a bit, at a minimum) but it does have a lot of limitations and potential pitfalls.


Port-knocking is often used in 'closed' designs to assure network integrity. In the meantime it evolved into single-packet authentication.

Check here for the source of sources on the topic :)

http://www.cipherdyne.org/fwknop/docs/SPA.html


I would try injecting a backslash at the end of the username.  Depending on how the language/system works (I'm not familiar with ASP) you may need to inject a double-backslash.  Also don't forget that your payload will probably need to be URL encoded.  i.e.:

http://example.com?username=admin%5C

You'll end up with this fragment in your query:

WHERE USER='admin\'

In most systems this will turn the single quote that was supposed to end the string into a single quote inside the string.  This would break the query, except that the opening single quote around the password parameter will end the user search string, and then whatever your password is will be injected directly into the query.  So you would use a payload like:

http://example.com?username=admin%5C&password=%20OR%201%3D1--

You'll then end up with this query:

WHERE USER='admin\' AND PASS=' OR 1=1--'

Just to be clear, AND PASS= has now become part of the search term on the USER column and there is no longer a search on the PASS column.  The comment is needed to make the final closing single quote disappear and avoid an SQL error.  The search on the USER column won't match anything but the OR 1=1 obviously will, and you'll (potentially) end up logged in as the first user in the system (probably an admin).  You could also try to target someone by replacing OR 1=1 with OR ID=SOMENUMBER to try to login as a particular user.


When using a recovery disk, like AVGs boot-able CD, to scan for viruses, malware etc... what are the limitations?

The core difference a boot disk gives you is the ability to scan the applications through a 'known good' fliesystem, as opposed to a potentially rootkitted filesystem, which may hide any/all malware from a scanner.

The basic problem is that if malware has compromised your system, it could be configured to return anything the author wants when a scan of a file is run, to make it appear the system is clean.

By booting from a CD or other read-only material, as long as you have a clean boot disk it will not be able to be compromised by malware and should give correct results. The assumption here is that you have a clean download.

Aside from that, the usage is the same as a version running on the normal OS - scanning for known patterns, or code which meets certain suspicious indicators.


Burp Suite - Although my configurations are correct, still Chrome doesn't allows me to access HTTPS sites and throws an error!

This is probably due to a change in Chrome 58 which now requires SAN:

  Remove support for commonName matching in certificates

  RFC 2818 describes two methods to match a domain name against a
  certificate: using the available names within the
  subjectAlternativeName extension, or, in the absence of a SAN
  extension, falling back to the commonName. The fallback to the
  commonName was deprecated in RFC 2818 (published in 2000), but support
  remains in a number of TLS clients, often incorrectly.

  The use of the subjectAlternativeName fields leaves it unambiguous
  whether a certificate is expressing a binding to an IP address or a
  domain name, and is fully defined in terms of its interaction with
  Name Constraints. However, the commonName is ambiguous, and because of
  this, support for it has been a source of security bugs in Chrome, the
  libraries it uses, and within the TLS ecosystem at large.

  The compatibility risk for removing commonName is low. RFC 2818 has
  deprecated this for nearly two decades, and the baseline requirements
  (which all publicly trusted certificate authorities must abide by) has
  required the presence of a subjectAltName since 2012. Firefox already
  requires the subjectAltName for any newly issued publicly trusted
  certificates since Firefox 48.

The solution to this is to regenerate the certificate on the server showing the error, or as in your case - the Burp cert.


Thought I would jump in here.

"A few blog comments had some cautious remarks about CF's system being too aggressive and flagging even site owners"

We use a variety of data sources that indicate potential threats, which can lead to some false positives in data. If you're concerned about too many visitors getting challenged, you can do the following:

-Adjust your CloudFlare security settings to low or medium (high is fairly restrictive). This can be done by going to: settings->CloudFlare settings->Basic Security->Change to low or medium.

-You also have the option of whitelisting IPs, IP ranges & countries in your 'Threat Control' panel.

"Also they talk about caching content on multiple servers... What if your content is not static?"
We wouldn't impact dynamic content at all (those changes would appear immediately).

"perhaps from SEO stand point?"

CloudFlare should be good for SEO because we help speed up delivery of your pages (our IPs are also whitelisted with Google).

There are tons of tips and things to consider on our blog as well.


Certificate management: private key distribution with Netflix Lemur framework

Yup, that's how I would read that too.

I assume that for a large cloud-based company like Netflix, the Lemur server would be part of their virtualized prod environment cluster and therefore held to the same level of network security as everything else in the prod environment. For example, if the deployment target is actually a cluster of VM hosts behind a load-balancer (or the load-balancer itself is terminating the TLS connections) then some amount of private key copying will be happening anyways and they'll have infrastructure to handle that properly. Adding a Lemur server to the cluster doesn't open any additional attack surface beyond what's already inherent to a large cloud deployment.

For smaller deployments where your prod server is a single machine, then I think your concerns are justified and it's worth asking some questions about additional copies of the private key floating around.


You're reading the proposal slightly wrong. This is not intended as a safeguard to detect an intrusion to already compromised system, but as means of detecting compromised system's database. This is a whole different scenario, where the attacker wouldn't already have gained access to the system by knowing any end user password, but somehow (improperly discarded backup, physical break-in,...) got his hands on a leaked user database that stores hashed passwords.

The assumption is, that the attacker wouldn't know which brute-forced hash matches the true password of an individual user, and might trigger the alarm by using the honeyword password instead. It's quite a sane method as much as I read about it so far, but have yet to see any real-life implementations (the computational overhead is substantial on proper hashing using slow algorithms). It's also slightly questionable because of the limited abilities of the honeypot itself to prevent additional login attempts by other IPs the attacker might use once the previous IP used was already blacklisted (this is trivial to do to a would-be attacker), but the detection mechanism is sound nonetheless.

Question is, what should happen next, after such attempt is detected. The most obvious solution is to disable the user account in question (the one that the attacker tried to hack into), but what happens when a true user himself enters one of such honeywords by mistake? These words should be substantially different to what user himself chose as a password, and there are other constraints such as where in the database to position the real password in relation to honeyword ones?

Still, these questions might be trivial to address properly, and cheap in comparison to what would happen without such safeguards in place. This said, the answer to your question is - yes, definitely.


Best practices for operating a Bitcoin-Qt client regarding netwok privacy?

It might do. Running traffic through tor helps to protect your privacy but there are quite some pitfalls.

Read the tor warning page for some basic ideas. In essence your biggest risks are:

human error: eg. if you created this stackexchange account without tor, or you ever used it without tor, or in some other questions you reveal information about yourself -> in this case certain people/police might know that you have a milion dollar bitcoin wallet (or at least know/prove that you claim so) or you buy services that might lead to you using your wallet (this is probably the biggest risk because there are only so many useful things that are completely anonymous (you can't change to real money anonymously easily, you can't buy a car or a house or something that will be send to you by mail, etc).
software bypassing tor: if your bitcoin client uses some sneaky way to obtain your real ip address and it communicates it over the net, tor won't help you
software uses unencrypted data transfer. Note that tor exit nodes can read whatever is passing under their nose, unless you encrypt end to end, like ssh or https. They shouldn't be able to get your real ip address, but they can read and change content (say if your bitcoin client had a buffer overflow vulnerability, they could run arbitrary code on your computer) Note that running a tor exit node is quite easy for anyone to do, whereas the government might be able to spy your internet connection with help of your ISP, but for a random individual that is more difficult.
time analysis: If you are a suspect and both your internet connection and that of the bitcoin service you use are under surveillance, a network packet of a specific size leaving from your computer and a packet of the same size arriving shortly after at the server, or the other way round might establish a suspicion that you are communicating with that service.

Note that their are services to help anonymize bitcoins.


How to carry out a CSRF in a stealthful manner

The easiest way is probably a tiny or hidden iFrame.

Embed an iFrame on your page with a src of your other page containing the CSRF code. The iFrame will get redirected but the user is unlikely to notice because they won't be able to see it.


What are the odds of an RSA private key collision?

First, what matters is not having two identical private keys, if either of the prime numbers is the same in the modulus (which is part of the public key), it is easy to quickly recover the full private key.

(Aside -- Brief RSA primer: In RSA for an n-bit private key, the public key is composed of an exponent, typically e=65537 and a modulus, N, which is the product of two n/2-bit prime numbers.  The private key consists of the private exponent d (calculated by d = e-1 mod (p-1)(q-1) which is efficiently found using the extended Euclidean algorithm) and the modulus, N.  The public pair allows encryption of a message, m, into a ciphertext, c, via modular exponentiation: c = me mod N, and the private key allows decryption via m = cd mod N.  This all works due to a fundamental part of number theory -- Euler's theorem and how to calculate totients).

If two moduli share a factor, then you can take the greatest common divisor of the two moduli efficiently (using Euclid's algorithm) and find the shared factor.  Let, the two moduli share a prime factor q, so N1 = p1 q and N2 = p2 q, then gcd(N1, N2) = q.  With the found prime factor, it is trivial to find the other prime factor (p1 = N1/q) and to recreate the private exponent.  A 2012 study looked at 4.7 million distinct RSA moduli and found shared factors in 12720 of them (that is 0.3% of the 4.7 million RSA keys trawled from the web are broken from their analysis).  (The paper also found several other problems with RSA in practice, like shared keys used on seemingly different entities.)

Now, choosing identical prime numbers is extremely low probability if your machine has a high amount of initial entropy and there is no flaw in the random number generation.  Both of these assumptions aren't always true; see the Debian OpenSSL problem keys from 2006-2008 and note that many people create keys for systems on brand new (virtual) machines that haven't had enough time to establish a lot of entropy.

Roughly, the strength of a 1024-bit key relies on the choice of the two 512-bit prime numbers that comprise the modulus.  By the prime number theorem there are roughly (2512/ln 2512 - 2511/ln 2511) ~ 10151 distinct 512 bit prime numbers.  From the birthday paradox, you should expect to have a collision of a prime number showing up more than once with about 50% probability, after generating sqrt(10151) ~ 1075 distinct prime numbers.  That is if some government generated a billion 512-bit prime numbers per second per computer and used a billion computers and had this run for a billion years they would only have generated about 1034 prime numbers, and the probability of a collision with some external key would be essentially zero, the same chance as playing powerball exactly 10 times on consecutive weeks and buying exactly one ticket and winning the jackpot every single time without cheating.  (It doesn't get significant chance of a single prime collision until nearly 1040 = 10000000000000000000000000000000000000000 times more prime numbers are generated).

However, as the 2012 paper shows, this is not true in the real world as RSA keys are generated by flawed methods in practice at a rate of at least 0.3%.


How do cookies work together with token binding?

As far as I understand it, token binding can be used to identify user using a certificate without need of PKI. How it works:

Client generates a key-pair, certificate locally, without need of signing server. Then once it connect to the HTTPS server it signs the tls_unique value (sent by server during tls handshake) using the generated private key then it "builds" the token consisting of the signed tls_unique and the public key. This information is added to HTTP request as Token-Binding header. Additionally, for the first time, the HTTP request includes some kind of another authentication info such as username/password. This bunch of data is sent to the server. Server validates the credentials passed and if it is correct it stores the token binding (mainly the certificate) locally for further authentication. Additionally, it generates the token which can store whatever info but it also stores the public key which's private key was used to sign the binding request. This token is bound to the given certificate and uniquely identifies given user. And this token is delivered back to client using a cookie.

During other requests, no credentials are need as server already has the user certificate bound to the token generated. Client sends the token together with another signed tls_unique value, server checks the token in cookie together with the Binding-Token info and if it knows the user (token is valid) and the certificate presented is the same as previous the authentication is done.

In this case, I would say the token is sent by cookie just because it is well known mechanism which can be done completely automatically and the cookie is quiet well protected. But please note, the token can be delivered to both sides in any other way, i.e. in GET request (http://service.domain/?token=...). This is used especially for federation services because passing cookies cross domain would not work.

What about sessions?. Although this token can also be used to identify the session I would not mix it up. The token is primarily used for authentication while session is used to keep some information about the stateless session during some amount of time. I would use separate session ID for every new session the user would open. This is just my personal feeling and I can't exactly explain why. Definitely, it is not necessary to store authentication info in session anymore as it will be passed with every new request separately in headers (Token-Binding/Cookie) pair ;)

Just to finish it. I would not say the cookie, but rather the token (it can be sent by cookie or by GET/POST request / or data) really servers as client certificate used to authenticate you, moreover without need of PKI. Because you pass your certificate in token together with a data encrypted (signed) using your private-key server. Then server uses it to authenticate you.


Where to draw the line with password managers?

When you use a password manager, you are creating a single point of failure. If you store all of your passwords in one system and that system is compromised, then all of your passwords are exposed. This is the same problem as with single-sign on. However, you can store different sets of passwords in different master databases to provide some segregation where possible. You could also store less frequently used or more secure passwords off-line on a USB disk.

Also, as a point of clarification, you want to make sure you are using an encrypted password manager (e.g., KeePass not just something built into the manager. I am also skeptical of web service based password managers because you don't know if you can trust your browser for the entry, your network for the transmission, or the provider for secure storage. There is also a much more limited risk if you sync your database using something like dropbox, but only because its in more places - though that does prevent the risk of a self-inflicted DoS if you loose your only copy of your password database.

With most encrypted password managers, you can further limit exposure by setting timeouts which lock the database after a time frame, when your screen saver goes on, or when you manually lock your system. You can also apply multi-facotor authentication such as certificates, smart cards, biometrics <- depending on software compatibility. You also want to ensure that the encryption is strong and has been implemented correctly. You should keep tabs on your password manager developer's website for any security updates, etc.

Of course, if someone were to use something like a browser's storage or somehting with no or weak encryption (password protected excel file), you are more or less storing the passwords in a plaintext file.


There is only one bullet proof way to protect from sniffing which doesn't involve trust in other authorities, it is end-to-end encryption. In short this means that the encryption and the decryption must be done client side, on the device of the sender/recipient.

There are services which claim to implement such end-to-end encryption, WhatsApp for example adopted the protocol of Signal, a secure messenger with a good reputation, others did as well. If we can trust in their implementation, you get a safe communication, without the possibility to eaves-drop, even if enforced. What you cannot hide though, are the contacts you are communicating with.

So no it is not a conspiracy theory, most communication is observed at this very moment. If my live would depend on it, I would setup an email client with client-to-client encryption. The problem is that your contact must do the same, or you can trust in services that offer this kind of encryption.


Per the documentation, $_SERVER['HTTP_HOST'] is populated based on the Host header sent by the client.  You should probably start worrying at this point, as it's never a great idea to trust data that may be provided by a malicious client.

There is also SERVER_NAME, which provides a similar but slightly different result.  You can find some good discussion about these two and the appropriate ways to use them in this Stack Overflow question.

Now, what attacks could someone perform via manipulation of your hostname?  That depends on your app.  Perhaps you're caching a rendered page and serving it up to another user, and that page was generated with Host: mymaliciousserver.com, so now your second user is clicking links to the attacker's server, where they phish out account details.  There are any number of possible vulnerabilities, and rather than trying to patch them all, I'd rather just avoid the problem entirely.

It's also somewhat questionable code anyways - it adds a lot of complexity for something that doesn't change often.  If it's your own custom app, just set the hostname once and be done with it; if it's a distributable app, have the customer set the hostname once and be done with it.  You're adding moving parts and magic, and those tend to have security issues as well as performing poorly in environments you haven't explicitly designed for (e.g. sites behind a reverse proxy, sites hosted on a non-standard port, sites run in a multi-site environment, etc.).


Log in with email is more secure than a username?

Give them a choice. For example, my e-mail address is fairly long whilst I usually pick short usernames; you can develop your login form to accept both.

Usernames aren't for securing accounts, passwords are. It isn't for no reason that the username is visible when entered in the browser, whilst the password is hidden. Also, users often re-use usernames, which, in contrast with password re-use, should not be a problem. And, of course, e-mail addresses were and are never meant not to be shared with anyone.

But the main problem: you don't store usernames or e-mail addresses hashed / encrypted, because you want to use them for other purposes than logging in. If someone steals the database with your hashed passwords, they will also have the usernames and e-mail-addresses. Gone is the “security benefit”!

So, forcing users to log in using only the e-mail address (and the password) or only the username (and the password) makes no sense.

Your defense should be enforcing strong passwords, and making sure you encrypt them with a strong password hashing function. Don't forget to set the cost high enough.

Additionally, to prevent an attacker that did not steal your database from renting a bot net and brute-forcing weak user passwords, restrict the number of login attempts per hour per IP address. Also, if you encounter a lot of login attempts for an acccount, block login attempts from any IP address from which no successful login for the account has been done in the past.


Cmd shuts down computer immediately after windows boots up and logs into the default account/user

Since it's not detected by antivirus software:

https://www.virustotal.com/#/file/27e26e77578466a1f93f1a33332893393e176960a5f9fd4295d4515d473a0195/detectionthe

The script runs the command shutdown -s -t 0, this is the usual command to shut down the computer after 0 seconds.

In order to remove, remove the following if found:

 User Startup: `
C:\Users\(username)\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\explorer.lnk`
C:\Users\(username)\AppData\Roaming\Tempo\DOC001.exe

HKLM\..\ShellIconOverlayIdentifiers\00asw: (no name) - {472083B0-C522-11CF-8763-00608CC02F24} - (no file)

Task: 7king hacker suck - C:\Windows\system32\cmd.exe /c shutdown -s -t 0


I don't believe there can be an objective answer to that question. So, here is a subjective answer: the Coursera course is by Dan Boneh, so it cannot be bad.

Note: cryptography is a rather advanced topic. To really get the hang of it, you need to know a bit of maths, especially linear algebra and some probabilities.


Avoid being implicated in criminal activity when using Tor

I think the author is referring to people running exit nodes, not those who run middle or entry nodes. By design, the Tor protocol doesn't allow the entry or middle nodes to decipher what is being received or sent (assuming the keys for the nodes are not compromised by some other fashion), only the inbound and outbound nodes are known. Therefore, it should be safe to say that running an entry node or middle node is okay (in most cases) as you do not know what is going through.

Essentially, you can cooperate with your local law enforcement by saying that you have little evidence of wrongdoing to give. You can even give them your node logs and private keys for the node if they request for it (not that you should without a court warrant), and if your log settings are default they would at most be able to determine which nodes you've been talking to, not the contents of your traffic.

However, there are certain countries that frown upon citizens making their own Tor nodes, as they believe that the Tor network is mainly used for criminal activity. Even if you run a Tor middle node, they might put you in greater surveillance as you are deemed "suspicious" by them. Most consumer level ISPs also do not like their customers running servers (which by definition a Tor node is) unless you upgrade to their business plans.

My advice: do so, but understand more about your country's laws and your ISPs restrictions to avoid getting into trouble.


Can the use of GPS devices leak personal identifiable information?

There are several ways to perform and log location of a person. When using a phone it and the GPS is turned on, an application can access your GPS location (if the app has permissions to do that) and send it through the internet to a remote location. He can also store this in a database and send it after a sucessful connection.

GPS is certainly not the only way of doing this, a more interesting way is to track the cell tower identifiers (in Android you can actually create and subscribe to a broadcast that notifies you when the celltower changes) and keep these in a database. From there you can send the data to a remote location once the device is connected to the internet and match the cell tower identifiers to their geographical location. This will allow you to make an approximation of where the person was walking.

The only way to try to prevent this is by checking the permissions (access) your application wants/needs and just not install software that wants to access your cellular network or GPS location.


Is rel="noopener" any different from rel="noopener"?

If you look at the HTML output, the HTML for the tooltip is inside the title attribute of the the element the tooltip is applied to. That means that quotes and tags has to be HTML-encoded. If they were not, they could not be contained within a HTML attribute.
If you look at the picture, the content of the title attribute has somehow been turned into a real part of the page, and not just a title text. That magic is probably done by some JavaScript from the Wordpress plugin. I can't say for sure what that plugin does, but I am fairly certain that if you use the inspector in the development console to take a look at the link inside the tooltip it will indeed have rel="noopener".
So I don't think there is anything to be worried about here.


Should we change risk appetite when we go on a digital transformation journey?

Risk Appetite is about how much risk you are willing to take on in order to achieve your mission. Your quotes of the different positions are both talking about only one side of the issue and not actually about Risk Appetite.

"Going digital means increased risk" (a higher likelihood of more and bigger negative impacts). I cannot be sure without more detail, but let's assume so.
"Going digital means increased opportunity". Again, let's assume so.

Great. Neither of these statements is about Risk Appetite.

The question that needs to be asked is if the increased opportunities are worth the increased risk. Will the extra risk impact the company in ways that it cannot or does not want to recover? Will the costs of treating the increased risks be greater than the company can afford? Will the loss of the opportunity negatively affect the company?

Those questions are more in line with Risk Appetite.

And you cannot look at Risk Appetite in isolation to these individual projects and not look at the aggregate risk to the entire company.

So, I find it odd that the Information Security team is trying to assign what the organisation should set as its risk appetite. They are not the correct people to be making this decision. By all means, define and analyse the risks, but I'm not sure that the team is properly placed to assess the opportunities or the more holistic organisational risks in context. That's the job of the business.

As for the "industry approaches" that you ask for, the wiki link you provided gives you the basics:

  Derived correctly the risk appetite is a consequence of a rigorous
  risk management analysis not a precursor. Simple risk management
  techniques deal with the impact of hazardous events, but this ignores
  the possibility of collateral effects of a bad outcome, such as for
  example becoming technically bankrupt. The quantity that can be put at
  risk depends on the cover available should there be a loss, and a
  proper analysis takes this into account. The "appetite" follows
  logically from this analysis. For example an organization should be
  "hungry for risk" if it has more than ample cover compared with its
  competitors and should therefore be able to gain greater returns in
  the market from high risk ventures.

What are the risks?
What are the risk costs?
What are the opportunities?
What are the opportunity costs?
What are the risks, opportunities, and costs in the holistic context?
What are the impacts of doing something vs. doing nothing?
What should our approach be to reducing those risks and pursuing those opportunities?


What is the key when facial recognition is used as a password?

Most biometric authentication methods, including face recognition, need to allow for variations in the biometric. Due to this the biometric authentication process doesn't have a precise value that could simply be used as an encryption key.

To solve this problem Juels and Sudan invented the concept of a Fuzzy Vault (PDF). With a fuzzy vault:

  A player Alice may place a secret value K in a fuzzy vault and "lock" it using a set A of elements from some public universe U. If Bob tries to "unlock" the vault using a set B of similar length, he obtains K only if B is close to A, i.e., only if A and B overlap substantially.

A fuzzy vault scheme for face recognition is presented in this paper by Wang and Plataniotis (PDF). I don't know if currently available face recognition software implement such a fuzzy vault scheme.


Am I supposed to find non-wifi devices in 802.11 frames of WPA2 encrypted wifi?

It depends on the isolation mode of your WIFI AP.

It is not uncommon for consumer-oriented products to treat their wired and wireless ports as part of the same subnet in order to facilitate device discovery.


What is the risk of running VPN on VPS?

The main risk is that all traffic inside the VPN can be passively sniffed by the entity hosting the server.

Basically it is similar to giving someone physical access to a physical server. Actually the risk is a bit higher, because VPS could be passively replicated, so it's more like giving someone an unprotected, unlimited access to a real-time replica of a physical server.

All the secrets required to set up a VPN connection are stored on the VPS itself and the traffic can be easily captured, so whoever has access to the underlying virtualisation platform can utilise them to monitor the communication in real time or afterwards.

By extension, you also open your own (connecting) network to the party hosting the VPS. So if you were targeted, they could utilise this connection to get into your internal network, behind your perimeter defenses.

This of course should be addressed separately, regardless whether you were connecting to a hosted VPS or not, but the risk might be considered higher with VPS in comparison to a VPN on a device which you fully control.

The bottom line is: if you don't trust the company, don't do it. You are storing more vital information with VPN than if you used the VPS for other purposes.


Are there any situations when one can only mount a passive MITM?

Passive-only attack scenarios tend to be rather specialized. Mostly, they involve radio links; the attacker can play with a homemade reception antenna, but is not rich enough to build an emitter which can drown out the genuine signal. This rarely applies to the Internet; this is more relevant to military on-field communications.

It could be argued that defeating passive attackers forces said attackers to go active, making them potentially easier to detect and retaliate upon. That's a rather weak argument, though. There again, it more applies to spy networks than to Internet business.


I'll have a shot at addressing this one.

Is this acceptable, first of everything, from a security standard (i.e. accepting an unsigned software)?
Accepting unsigned software that is trusted for some other reason in itself isn't an issue. Accepting ActiveX isn't considered acceptable at all. I'd suggest running the browser that uses ActiveX within its own virtual machine with some fairly harsh isolation settings.

Does the fact that none of our users have admin privileges on their machines mitigate the risks of running unsigned software?
Not really, anything accessible to the user level will still be fair game. The lack of admin rights just means that a few things will stay out of reach unless an avenue for privesc can be found.

Is it possible to allow the unsigned ActiveX only for that software, but not for everything else?
Yes, you can whitelist ActiveX for that one particular domain if you so desire. I would really suggest running it inside the aforementioned virtual environment though. ActiveX is not something you want touching your systems in any way that you can avoid.

Does 'being signed' really mean more secure? I mean, it's signed, so what?
Not really. Anyone can buy a code signing certificate with minimal scrutiny. The cheapest I could find is $70 and promises to be issued within 20 minutes.


What should I do when I found a strange email on my phone?

Go to the google account security page and check what devices has accessed your account recently. Then change your password and remove the device. You should probably enable two step authentication and look over your app passwords too.

You should probably wipe/reflash your phone if there is a chance that it contains bad software with root privileges.


Is pinning global root CA almost same as not having any certificate pinning at all?

Pinning a Root CA can prevent risks posed by other trusted Root CAs in the default certificate store. As mentioned in the link you shared (thank you), it's a deployment decision as to how high (or low) in the chain you would pin the certificate.

Check out this Security.SE post for more information for the underlying threat and some mitigations.


Is storing authorization tokens on Android 's AccountManager secure?

To answer from the security standpoint, and according to the linked answer from SO, the real risk is that a root user can actually exfiltrate the JWT.
Android is hardened enough to that processes do not interfere each other. But if the user running the device has root capabilities, and given that your application can't detect root for sure, there is the possibility that any app running as root, voluntarily by the device owner, or maliciously, can exfitrate the token

This database can be found at /data/system/users/0/accounts.db, where 0 is user's ID.

And is not encrypted.


For a simple purpose, a simple httpd server is more secure?

All other things being equal, simplicity is good for security. But let's not reverse the paradigm. Software is secure because it is maintained. Complex software is harder to maintain, but, on the other hand, Apache and Nginx have a huge market share, are very active project, and thus benefit from about the best level of maintenance that can be hoped for. Python's SimpleHTTPServer cannot (yet) boast as much. Therefore, while SimpleHTTPServer is certainly easier to maintain for security issues, and has less room for nasty bugs, it is unclear whether it really is "more secure" than Apache and Nginx.

Another facet of the issue is system administration: even the most secure and maintained software can fail if the sysadmin does not do his job properly; and anything custom, not-mainstream, makes the sysadmin job harder. So using an alternate HTTP server is all fine and dandy as long as the sysadmin masters its fine configuration issues and details. Said otherwise, if the local sysadmin is a god of Apache, then let him use Apache; that's what will be most secure in practice.


XML External Entity injection within the body of a document

You should be OK, if the XML parser is compliant. Per the XML 1.1 spec,

  The document type declaration MUST appear before the first element in the document.

However, it wouldn't be unheard of for an XML parser to fail to enforce this restriction. An XML doc with a <!DOCTYPE tag following the first element would not be well-formed, but might still be treated as though it were by some parsers, in the same way that malformed HTML is often tolerated by browsers.

Additionally, an attacker could close the entire XML document, and start a new one. The new one would not have any elements in it yet, so the doctype could be put in its correct location. The question then would be, what does your parser do with two (well-formed) documents when it only expected one?


What are the core differences between Airodump-ng, Wireshark, and TCPdump?

Airdump-ng is for capturing 802.11 frames, so you use this tool exclusively for wireless networks.

Wireshark and TCPdump are similar but Wireshark is more complex, also has a GUI. E.g. you can set many filters and perform more advanced analysis. TCPdump is more lightweight.

Which one is best to use is a broad question and is up to you, depending on what you need. You don't have to limit yourself to one if you think you need several different sniffers.


Why is ARP poisoning killing all network activity?

ARP spoofing usually works by fooling all the clients into thinking that you're the router, by faking the ARP responses that translate IP addresses to MAC addresses. When clients receive the ARP response, they remember the MAC that was associated with the IP.

Once you stop the application that's handling the man-in-the-middle part of the operation, the clients keep sending to your MAC address, instead of the router's. Since you're no longer handling such packets, the traffic is blackholed and the whole network goes down. Resetting the router causes it to send an ARP broadcast (e.g. "Hi, I'm 192.168.1.1 at 12:34:56:78:90:AB") along with a DHCP broadcast, allowing clients to re-sync with the real router.

It may be possible for your ARP poisoning software to send out an ARP broadcast when it closes, with the real MAC address of the router, in order to prevent this. This may be a bug, or it may just not be implemented yet.


EC private key, RSA certificate. Is this realisable?

The simple answer is no you can't have an RSA cert which has a ECC public key.  By definition an RSA cert is a cert which has an RSA public key.  The CA could sign your ECC cert with their RSA key but that wouldn't make it a RSA cert it would make it a ECC cert signed with an RSA key.  Likewise a CA could sign a RSA cert with their ECC key but that wouldn't make it an ECC cert it would make it a RSA cert signed by a ECC key.

Do you need an RSA cert or do you just need some digital cert signed by your CA?  If you must have a RSA cert why are you generating ECC keypairs?  Generate an RSA keypair, a CSR and have the CA create a cert from that.


That section of the spec is referring to Cross-document messaging, not Server Sent Events. It appears html5rocks.com has misquoted.

You are correct: If the SSE listener is not set for that domain in the page script, then there is no threat.


Would multiple exposed bcrypt hashes of the same UUID v4 with random generated salt be too insecure?

You don't need bcrypt here.

Bcrypt and other similar password hashing functions use salts and iterations in order to cope with the inherent weakness of passwords, which is their vulnerability to exhaustive search. The space of possible passwords, the one which most users will choose and be able to remember, is simply too small for comfort. We use iterations so that the attacker's task is slowed down. We use salts so that the attacker may not make economies of scale when trying to break several passwords. But all of this makes sense only because breaking one password is feasible.

When the data which is to be hashed (for ulterior verification) is a strong random key, chosen uniformly from a space large enough to defeat exhaustive search, then salts and slow hashing are not necessary. This is the case for your "private UUID". A "v4" UUID is supposed to contain 122 bits generated from a cryptographically strong PRNG. This is way beyond that which is amenable to exhaustive search. This "private UUID" is a key in the true sense of the term.

So, in a given protocol where you hash these "private UUID" with bcrypt, you can replace bcrypt with a simple hash function (e.g. SHA-256) and forget about the salts. In your case, the server stores h(UUID) for some hash function h, linked to a user, and the user has to show the UUID itself to be granted access. This is the simple "password" model but with a really strong password, which does not require the tools developed to tolerate human-remembered passwords (which are not strong). Of course you would want to run the whole protocol under the protection of some layer which ensures that the client talks to the right server, and the transfers are protected from eavesdropping and alterations (basically, SSL).


How can I identify / discover files hidden with ADS?

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


Paypal Account created using my gmail account

A couple of clues that comes in my mind:

Is the account active? If yes you should receive payment information from Paypal regularly. This activity would be a good sign to see whether it is your account (you could have forgot) or another person, or a person trying to harm you.
Maybe there is a person with the same name as yours and he accidentally typed your email instead of his?

By the way, contacting PayPal is indeed the good thing to do. They would normally try to be sure that :

They understand the situation and are aware of possible mischief
You own the email address
You are the same/a different person than the other account

You want to :

Check you did not have any money theft
Someone is not trying to impersonate you somewhere (difficult to assess in my opinion)


Key store is used for private keys. Those can be used for applications that use cryptography features such as public or private key encryption.

These types of keys are supported:

Diffie-Hellman public and private keys
Digital Signature Algorithm (DSA, FIPS 186-2) public and private keys
Elliptic Curve Cryptography public and private keys
RSA (PKCS #1) public and private keys
Several legacy (CryptoAPI) public and private keys

Certificate Stores is a storage location that stores certificates locally on the computer. It can store:

Local Machine and Current User Certificate Stores (local to a user account on the computer)
Trusted Publishers Certificate Store (Authenticode (signing) certificates of trusted publishers that are installed on a computer)
Trusted Root Certification Authorities Certificate Store


Will session_regenerate_id() without true parameter improves security? Should I use it right before login?

The solution to avoid the session fixation is simple changing session ID.

bool session_regenerate_id([bool $delOldSession = false]) will replace the current session id with a new one, and keep the current session information. Adding parameter true: session_regenerate_id(true) deletes old esssion. If you don't delete old sessions, then your web-application is vulnerable to session hijacking. You leave old, but still valid sessions inside the /tmp directory. This means:

on the shared web-hosting servers some people could still have access to them
you give more chance to guess any of your valid session ID

You should always destroy old sessions with session_regenerate_id(true) or session_destroy().

However, you should be aware of session_regenerate_id(true) performance. The bare minimum is to use it, when you change user's priviledges (like login, logout). When you use it too often, you will notice "strange" things with your sessions. PHP has restriction in access to the session for only one running task. Multiple requests get into queue. If you send requests to fast, then:

The first request changes session ID and deletes the old session.
The second request (still) has the old session ID and it tries to do some operations on it.
As this old session ID doesn't exist, the new session is being created - which leads to user logout.


You can't find anything about PCI for checks, because it doesn't cover them.  PCI stands for "Payment Card Industry" - aka, credit cards (and debit cards with a cardbrand logo).  The PCI Council (who set the standards) couldn't care less about securing any other form of payment (cash, checks, money orders, etc).  Even credit-card-like systems (gift cards, store-issued charge cards, etc) aren't officially covered, even if they have a magstripe.

That said, it's good practice to follow PCI standards for other forms of payment, since they're designed for security. If you accidentally leak your customers' payment information, who do you think they're going to blame?

Instead of PCI, the ACH industry is covered by the NACHA Operating Rules, which you can also fund summarized here.  From what I can tell, the relevant sections are 1.6 (Security Requirements) and 1.7 (Secure transmission of ACH Information via Unsecured Electronic Networks).  Together, they comprise less than one page of text.  I can't copy them here, but 1.6 basically says "You have to have policies in place to protect this data." without specifying any specific requirements.

All in all, the client's request may be perfectly valid in a way that it wouldn't be for card data.  It doesn't make it a good idea, but it's valid.


Given your previous question it looks like you are talking about an IoT environment, i.e. IoT devices which communicate with a server via mutual TLS. In this environment you very likely don't use certificates issued by a public CA but instead use a private CA.

The limit of 2 years you mention is only enforced by public CA. If you run your own CA and have full control over the communication peers you can use any validation time you want, also longer than two years.  Still, it is not recommended to use a certificate forever since attacks against the used algorithms improve with the time and also the chance of a compromised private key increases.


Welcome to Information Security Stack exchange!  This is an interesting idea you are proposing, and here are some thoughts I have on it.  Overall, I believe it would provide you personally with an added layer of security if the admin permits it.  You could get into trouble if the idea violates their system security policy though, so be sure to check before you do it.  Here are my thoughts:

USB sticks are bad for security of the host systems (but may work for your situation):

I know many admins do not allow USB because they are a "good way" for malware to spread.  For example, malware could be spread by USB in the following ways:

The USB stick manufacturer could pre-install malware on the USB stick.
A hacker can transfer malware to a system over a USB stick.
The unsuspecting user can transfer malware that has unknowingly infected their USB stick.

It will probably help your own security, if it is permitted:

If your admin is okay with using USB sticks, you might gain some security with your method.  Because of the malware threat with USB sticks, unfortunately, your idea probably would not be a good "overall" security standard solution. Your idea will probably add some to your own security if it is permitted.

The comment posted by @user2313067 is a very good point, that it will not provide full security because the host machine can read what is on your USB stick.  However, I believe the admin would have to be fairly determined to get to your information to go through the measures described in the comment.  I believe it is unlikely (but not impossible) that the admin would be after your info though, and would be this determined to get it.

Potential for trouble:

This could violate system security policies that are already in place too (e.g. a good admin would not want a potential attacker to be able to run any arbitrary software off their USB stick).  To avoid getting into trouble, you will probably need to ask the admin if you can do it.

Keeping up to date:

One thing to be on the lookout for is that the FireFox browser (and probably all other browsers) have vulnerabilities that are sometimes discovered.  Because of this, it is important to keep your browser up to date (as the vendor releases new updates to fix discovered vulnerabilities).

Further input:

I am pretty sure I have not thought up all the pros and cons of his / her idea, and I look forward to seeing further thought on it.


DNSSEC ZSK compromisation (man-in-the-middle attack)

The split ZSK/KSK main benefit is to be able to change the ZSKs very often, as they are under your control completely, while for the KSKs, if you change it, you need to update the associated DS record in your parent zone, which is not always something 100% automated. This is why KSKs have typically 1 or 2 years of validity, where ZSKs are more like 1 month.

In your case, if the ZSK is compromised, you need to remove it immediately from your zone, add a new one which will sign everything else, and make sure it is signed itself by your KSKs.

If your ZSKs is compromised because, for example, it was on an HSM and you have the KSKs at the same place, then if you are paranoid you should suspect that everything may be compromised, which means changing all your keys in emergency, contacting your parent zone, trying to ask major DNS resolvers to flush their cache after your new setup, etc…
Of course same thing if it was a "SoftHSM" setup.

But if only the ZSK is compromised, resolvers will detect it if it used to sign records because your KSK would not sign this ZSK anymore, hence breaking the DNSSEC chain of trust.


Let´s assume an normal guy who likes convenience like everyone else and is very worried where this goes (i.e.: air-gapped PC´s or not using a Smartphone are not convenient)

Yeah, that's not going to work in today's world. It's that laziness that lets government agencies get away with things like this. Smartphones in particular are one of the biggest misnomers foisted on society, in that they're smart alright-- they do nothing but feed intelligence back to everybody but the user. We just keep scratching our heads, our only concern being why they become unusably slow every 18 months.

It sucks, but sometimes to gain security, you do have to give up something in return. You can have convenience or security, but not both.

Even so you'd have to go to some rather schizophrenic levels to be truly off the grid these days, but I'll address the rest of these topics as though I have unlimited time and resources to counter these measures:

Spyware for the Police

You need counter-intelligence. A good cellular-based home security system that alerts you when doors and windows are compromised. Hidden CCTV recording throughout. You'll know who's been in there tinkering with your stuff and how. Spooks are trained in how to look for and detect these things so you have to be comprehensive and sporadic. Dummy cameras that activate randomly and may or may not feed anywhere. Make them waste enough time chasing false leads that they miss a few real cameras.

Audit logs on the computer are likely to be useless and/or compromised. BIOS case-opened alerts are also useless. It sounds counter-intuitive but this is actually a physical security problem.

This honestly is one point I believe will ever only get used for terrorism cases, or child porn distributors/producers. It takes a lot of technical expertise that they're not going to want to waste on some kid torrenting copies of "Baby Driver."

Blocking of Websites

Use a VPN, or set up an EC2 instance in America and tunnel everything over ssh. Or Tor. The nature of the internet is such that when you encounter an obstacle, you route around it.

Most domestic pirates and internet users in developing nations figured this much out a long time ago. It's how they get Netflix in Nigeria.

More Video Surveillance and the connection of all state Organisations and willing private Video Cameras

This is nothing new. If you're in a public place these days, chances are someone is recording video of something around you on their phone and uploading it to YouTube. Facial recognition algorithms are surely scanning these videos. You're part of the social intelligence machine whether you like it or not.

Outside of your own home, everything is already watching you. If not traffic cameras, public CCTV or private CCTV, your phone is being tracked and so are its movements. They always know where you are and only need to issue a few subpoenas, then dial into localized CCTV feeds to see what you've been up to. Pretty soon even cars will be cellular-equipped and report their own geolocation metrics. We're already there with some models.

If you want to stay off the grid, first-- do not carry a phone. At all. Or cycle them out for disposable new ones every month or two, paying cash for them each time.

Second, you have to defeat facial recognition patterns. Wear a dust mask like they do in Asian countries, not a bandana like a hooligan. Cover your eyes if possible. Many FR algorithms depend on triangulating distance between eyes, lips and nostrils, or some combination thereof. Obscure these features as best you can (without coming across like the Unabomber) and you should be clear of most of what they're trying to do with these systems.

There was some hoopla a few years back where some ISIS militant on a beheading tape was identified through his full-facial hijab but I'm pretty sure they used his voice as a second data point and got him that way.

Either data retention or "Quick freeze" of the suspects data

Full-disk encryption. Use a strong password and don't ever leave your computer decrypted and unattended. The Alphabay guy just got busted because of this.

But there's currently a US child porn suspect rotting in prison on contempt charges because he refuses to unlock his drives for investigators to use as evidence in his CP trial. So they'll get you one way or another, even with countermeasures.

Surveillance of all cars on all High-ways

This has always been the case. LPRs aren't going anywhere, and you can't legally obscure your plate. Ride a bicycle.

In the country, some people with a habit of running from the law would make it a point to sling as much mud across the front and rear bumpers as they could in an effort to obscure the plates. You will get cited for this (and ruin your paint) but at least you can try to play innocent when it happens (as opposed to a license plate cover).

On motorcycles, the same thing, except they would bend the plate slightly into the wheelwell. The plate can be completely obscured (facing down) by popping a wheelie.

Surveillance of suspects inside of cars (not specified how)

FLIR, most likely. Not much you can do about this. Using IR techniques was controversial in the US some time ago (cops used it to bust a grow house without a warrant); I don't know where it stands now but this is likely what they're going to do to you people.

Lining your car with tinfoil won't do anything about the windows.

Surveillance through IMSI-Catchers and Silent SMS

Don't carry a phone, or use a burner. Nothing attributable to you. If they start requiring registration for burners, just don't carry a phone. Seriously, you don't actually need one. You can play games with "always make sure it's off" or "always take out the battery" (less possible with modern phones) but we've seen bulletins about certain overseas manufacturers who installed secondary batteries in laptops that keep the thing on even when you think it's off. For what purposes, and by who, take a wild guess. Your first answer will be correct.

If it's attributable to you, or you haven't audited the hardware personally, don't carry it.

Registration of Prepaid Cards (Full name, age, residence, etc)

Every time I've bought them in the US I just give fake information. Perhaps that's still an option if they don't verify. Aside from that, don't buy things online if you can avoid it (leaves a digital footprint anyway), or buy pre-registered cards second-hand.

Identity card requirement to buy bus and train tickets

Not much you can do about this. Ride a bicycle.

Of course the secret service will keep the data secure and sound on their Systems (hahah).

Feed them as much bad intel as you can. Their database gets hacked and all you've given them is fragments of activity across a handful of mobile devices, FR hasn't picked you up on any cameras, you don't drive so LPR isn't catching your plates moving across town, you pay cash for everything and buy (plausibly deniable) laundered gift cards off eBay using other laundered cards and have them sent to a dead drop. If you do it right, for all they know you're 42 different people. Just be careful who you talk to-- you may create a common denominator across your "identities."

Congratulations, you're a ghost!


What causes "High Risk Website Blocked" on Chrome?

Typically a site gets blocked because it either contains malicious code or, more often, links to another site that contains malicious code.

Google has several sources for this information; stopbadware.org is their primary partner in this, and of course they get most of their direct knowledge through their GoogleBot indexing.

Chrome has a built-in feature that checks Google's "is this site malicious" database for all new domains you visit and will display an alert if you access a site that is. You'll get a similar result from any browser if you click on a Google search link.

To find out more about what they found, go register your site with Google Webmaster Tools so that they know you're the owner, and they'll tell you there what they know about your site, including anything malicious they found.

To get removed from the list, the first thing you have to do is find and remove the malware. Of course that's not enough: you also have to find and fix the hole that the hacker used to get in, or he'll just come back. And that's not enough either, because in nearly 100% of cases, the hacker will install multiple backdoors to ensure he has access even if you patch the hole. So you have to identify, find and remove those as well. (Not a trivial task.)

In the end, it's a whole lot safer to just nuke the whole thing and restore from a known-good backup. And then install any necessary patches after that but before you go live.

And once your site is clean, THEN you notify Google through the webmaster tools panel, and they'll re-scan your site.


What are some ways to anonymize your writing style?

There is a program written in Java called Anonymouth which assists with this:

  Anonymouth is a Java-based application that aims to give users to tools and knowledge needed to begin anonymizing documents they have written. It does this by firing up JStylo libraries (an author detection application also develped by PSAL) to detect stylometric patterns and determine features (like word length, bigrams, trigrams, etc.) that the user should remove/add to help obsure their style and identity.

On its own, Anonymouth is only of limited value. Anonymizing your writeprint analysis requires a basic understanding of linguistics and stylometry. Basic stylometry involves the so-called 5-feature analysis, where five major writing style features are analyzed (paraphrased from Wikipedia):

lexical features - The analysis of the lexicon, the author's choice of vocabulary. Different people use different words at different rates, which can make them quite unique. I, for example, tend to use the word tend a lot. I would need to avoid that if I wanted to hide my writeprint. Using simple, short, and common words can reduce the potential of this feature.
syntactic features - The analysis of the author's writing style and sentence structure, such as: punctuation, use of passive voice, and sentence complexity. Using sentences that are as simple as possible with a standard writing style can help weaken this feature.
structural features - The analysis of the author's organization of the work. These include paragraph length, spacing, indentation, use of oxford commas, etc. Just as with making the 2nd feature less useful, making this feature less useful can be done by following standard writing styles rather than using one that naturally evolved with you.
content-specific features - The analysis of the language that is contextually significant to subject of the written work. Examples include the use of slang or acronyms that may be shibboleths. E.g. a set of botnet owners can easily be divided into those who say "C&C", "CnC", and "C2".
idiosyncratic features - The analysis of errors and other ungrammatical elements that may be unique to the author. This is by far one of the most damning features and has lead to numerous people being deanonymized by their writing style. Small mistakes made on one non-anonymous identity can carry on to anonymous identities, potentially linking them.

Many of these features can be anonymized by using standard English with completely proper grammar and spelling, and short, simple sentences. Idioms and the like should be avoided. It's also possible to emulate other authors in order to fool analysis. If all else fails, simply waiting can help. A person's writing style drifts over the years, so it's unlikely that a document authored by you several years ago will be easy to tie to what you write now. This does not mean it is impossible, just harder.