Verification of certificate trustworthiness (e.g. in JWS and Client Certificate) I am comparing implementation complexity of JWS and Client Certificate and troubleshooting Client Certificate at the same time.
I understand that both methods require to prove that the certificate (x5c in JWS or the actual Client Certificate) is trustworthy (as per https://tools.ietf.org/html/rfc7515#section-10.3). How should this validation process be achieved? Where do I get the root certificate from if I wanted to extract public key from the root?
For JWS I intended to hold a copy of a certificate (or at least its public key) in application memory. Before I validate the signature wih x5c certificate, I would validate the certificate itself. Is this correct approach?
For Client Certificates - the plot thickens, especially in my scenario (*) and it is not transparent to me since it is handled by HTTP server, not by my application, therefore I believe it can differ between server implementations, unless there is some standard? RFC5280 Section 6 on Path Validation cover this? My HTTP server expects me to install a "client certificate" (yes, on the server) and I am curious what the validation procedure would be (what is compared - just the keys or entire certificate, maybe just the root certificate?) and why it cannot use the same certificate that is already used for authenticating the server/domain (since they share the root certificate). In reality, each client has been issued their own certificate (with a shared root), so which client certificate am I expected to provide? Should I provide 1K client certificates for 1K clients?

(*) I am not a CA that self-signed client certificates, but they have issued a server certificate for my subdomain that is intended to handle the traffic. This means that I do not have direct access to private key and the root certificate.

By 'Client Certificate' do you mean in SSL/TLS and (thus) HTTPS? If so, 8446 (for TLS1.3) references 5280 for cert validation, although earlier versions were not explicit, and libraries generally implement this (or at least its predecessors; in OpenSSL for example the cert validation code didn't change much from about 2000 to about 2015). Typically a server wants you to configure one or more trust anchor(s) for the client certificate(s); while (often) this can be (an) individual cert(s), it can also be a cert for the/each CA that issued the child cert(s) (or usually its root) -- as long as you consider that CA reliable, i.e. you trust it adequately ensures the certs it issues (and does not revoke) are legitimate. Often this will even say something like 'tls-client-ca'. But a definite answer depends on the specific server: apache? nginx? haproxy? tomcat? Jboss/Wildfly? Liberty? other (custom) Java? Or C or C++? Or rust, or go, or whatever comes next? Or python, or nodejs, or perl, or ruby?
JWS also specifies 5280, in 7515 4.1.6, but implementations can vary a lot.

Added for comment:
(1) Okay, this is for Azure Gateway. Their documentation is confusing, inconsistent, and bloated, as typical for Microsoft. They use "client certificate", "client CA certificate", and "client CA certificate chain" in various places as if they were the same which they certainly are not. In https://docs.microsoft.com/en-us/azure/application-gateway/mutual-authentication-portal the "Before you begin" links back to its parent page https://docs.microsoft.com/en-us/azure/application-gateway/mutual-authentication-overview#certificates-supported-for-mutual-authentication which actually describes server certs not client, so is useless. However "Configure mutual authentication" step 5 (and the parent page also) says you should use https://docs.microsoft.com/en-us/azure/application-gateway/mutual-authentication-certificate-management
which describes a way (only for Windows) to get the intermediate and root CA certs for the client cert, not including the client cert itself. This is consistent with the option described (at length) on related pages for them to check/require that a client cert is directly issued by a configured CA, e.g. "Verify client certificate issuer's DN" on the portal config page; that direct issuer will usually be an intermediate CA thus for this option to work they need the intermediate not just the root which would be enough for normal validation. (It's not clear if they actually need intermediates other than the first/lowest when multiple intermediates are used; the example doesn't show that case, and they don't really explain or precisely specify. They also don't show the direct-root case, which is rare, although I'd expect/hope submitting only the root works.) Although they give you the procedure only for Windows, the format they show is a sequence-of-PEM, a common standard you can easily create with other systems and programs.
(2) "the origin of a root public key" -- well, the origin is the root CA. But what matters is how you get it onto your system(s) in a way that is trustworthy, so that you are certain it is not tampered or faked.
For public CAs this is normally handled by the root-CA programs of various software suppliers: Microsoft (Windows) and Apple (MacOS and iOS) each has a program to provide (and update) trusted roots as part of their systems (which are secured overall to prevent lots of attacks not just SSL/TLS certs); Mozilla has a program created for and used by Firefox and Thunderbird, which many Linux distros and some other software (e.g. curl) also use; Oracle-formerly-Sun has one used by their builds of Java while other (OpenJDK, IBM, ?) builds can use something different depending on the builder. I don't know what dot-net does on non-Windows platforms. There are undoubtedly others that are less known.
For other CAs it may vary. If you work in a business or organization that has an internal CA they will usually have a process to get you the correct root; for domain-managed Windows systems they can do this automatically so you may not even be aware of it. If you 'join' http://cacert.org (not https!) you are expected to handle these details yourself.
(3) The verify logic described in the OpenSSL man page is basically standard, although it doesn't automatically fetch CRLs or use OCSP (or caIssuer) -- which are not strictly required but very useful and some other software does. The truststore format OpenSSL uses (a file and/or a directory using subject hashes in the names) is an implementation detail and typically (though not necessarily) the same for https servers (and others) that use OpenSSL, but often different on other software or middleware. E.g. Windows used locally has its own 'machine' store or may use/share the domain controller; since Azure is cloud we don't really know what it does internally, only what the input (or output) is like.


Automatic detection of a compromised web server I'm trying to figure out if it is possible to automatically detect the the fact that the HTML or javascript files on a server have been tampered with or changed by an attacker.

Our website, say www.example.com/index.html, when loaded in a browser, also loads https://www.example.com/scripts/example.min.js inside a <script></script> tag. If someone were to somehow hack into my server and swap out the example.min.js file with a modified one, is there any way I can automatically detect said intrusion?

One way to do it would be to run a program on an independent secure server that queried https://example.com every few minutes and compared the SHA of the index.html and example.min.js file to the last known good values.

Question 1:- assuming the polling interval is acceptable, is this a strong enough defense? Could the malicious code fool the polling code?

Question 2:- Is there a better way to reduce the window of risk other than reducing the polling interval, which creates unnecessary traffic.

There are a number of local processes that will watch files and directories for any changes, writes, deletions, and accesses. When these events occur, the process creates an event log through syslog. This can happen in a second.

If the syslog entries are sent to a remote server (as they should be) you will have nearly instant alerting to file changes, without the possibility of "fooling" anything, without any "unnecessary" web traffic.

There are pre-packaged software to do this, or it can also be done using custom scripts (pre-packaged, tested software tends to be better).


Msfvenom meterpreter android architectures Is there any android architecture I can set my meterpreter reverse_http payload to that works on every android phone?

Basically, when I don't set any architecture it defaults to dalvik but that architecture does not seem to be working on every phone I try it on.

The ART runtime/architecture was introduced in android 4.4.

It completely replaced the dalvik runtime in android 5.0.

So maybe you should use this knowledge to help you decide which architecture to target.


Is using a public-key for logging in to SSH any better than saving a password? Using a public/private key pair is fairly convenient for logging in to frequented hosts, but if I'm using a key pair with no password, is that any safer (or less safe) than a password?  The security around my private key file is paramount, but say my magical private key file was just a list of passwords to various hosts, is there a difference?

My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.
First of all, you must understand that user authentication is a different and separate process than the establishment of the secure channel. In laymans terms what this means is that first, the public key of the server is used (if accepted!) to construct the secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication.
After the channel is functional and secure, authentication of the user takes place.
The two usual ways of doing that is by using a password or a public key pair.
The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access.
In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user.  If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model. (In SSHv2 something a bit different but conceptually close is actually used)
As you can imagine, in the first case the password is actually sent to the server (unless SSH would use password challenge response), in the second your private key never leaves the client. In the imaginary scenario that someone intercepts the SSH traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) or has access to the server or client, your password will be known - with public-private key authentication and the challenge response model your private details will never fall in the hand of the attacker.
So even if one server you connect to is compromised, other servers you use the same key for would not be!
There are other advantages of using a public key pair: The private key should not be stored in cleartext in your client pc as you suggest. This of course leaves the private key file open to compromise as an unencrypted password file would do, but it's easier to decrypt (on login) and use the private key. It should be stored encrypted, and need you to provide a usually long passphrase to decrypt it each time it is used.
Of course this means that you will have to provide the long passphrase each time you connect to a server, to unlock your private key – There are ways around that. You can increase the usability of the system by using an authentication agent: This is a piece of software that unlocks your keys for the current session, when you log in to gnome for example or when you first ssh into your client, so you can just type ssh remote-system-ip and log in, without providing a passphrase, and do that multiple times until you log out of your session.
So, to sum up, using public key pairs offers considerably more protection than using passwords or password lists which can be captured if the client, the server or the secure session is compromised. In the case of not using a passphrase (which shouldn't happen), still public key pairs offer protection against compromised sessions and servers.


Why do credit cards not use digital certificates? Asymmetric encryption and digital certificates are used all over in the IT world to verify authenticity and prevent forgeries.  And it works great.

Why do credit cards not use some form of public/private key to verify authenticity?  Is the reason logistical, or is there some other business motive?

Some credit cards using EMV (at least in the UK) do use public key cryptography behind the scenes.  More information about how this protocol works for payment (and what's wrong with it) can be found in a paper by Murdoch et al..  However, this is used to verify the authenticity of the card rather than the card holder.

If you were suggesting that the card holder might be authenticated by holding a private key and having some kind of certificate, there are several practical issues.  The private key has to be held and used by a device, not a person, so for in-person payment you immediately go back to the EMV model mentioned previously.  For online shopping, however, you could potentially store keys and certificates on your PC or phone to authenticate the user.  Unfortunately experience suggests that certificate management has usability issues (see this classic paper) which would make life difficult for the end user.

In practice, public key infrastructures tend to be quite good for authenticating devices but relatively bad for authenticating people.  Exceptions to this rule tend to be in corporate environments where dedicated IT departments exist to support the system and people are required to comply to company policies.


Is it a security hole to have a stored procedure output the key and certificate names? My scenario is this:

(Following the method of opening keys, encrypting, and closing keys, found in Ben Cull's Blog.)

Imagine you have a MS SQL sever with tons of keys for encrypting different fields in different tables which you update every so often, and you use procedures to open the keys and close the keys, BUT in order to reduce the number of procedures and functions you have to update every so often, you eliminate the functions to encrypt the data, and you instead OUTPUT the key and certificate names, so you can just use the regular encrypt function with the key and certificate from the OUTPUT parameters of the OpenKey procedure.

It would look something like this:

CREATE PROC [dbo].[sproc_OpenKey_10]
    (
        @Key CHAR(10) OUTPUT
        ,@Cert CHAR(10) OUTPUT
    )
AS
BEGIN

    IF CONVERT(DATE,GETDATE())  < '1/1/2017'
        BEGIN
            OPEN SYMMETRIC KEY AC_16
            DECRYPTION BY CERTIFICATE WebAC16
            Set @Key = 'AC_16'
            Set @Cert = 'WebAC16'
        END
    ELSE
        BEGIN
            OPEN SYMMETRIC KEY AC_17
            DECRYPTION BY CERTIFICATE WebAC17
            Set @Key = 'AC_17'
            Set @Cert = 'WebAC17'
        END
    RETURN
END

And so using the function and encrypting would look like this:

DECLARE @Key10 CHAR(10)
DECLARE @Cert10 CHAR(10)
DECLARE @EncID VARCHAR(100)

EXEC dbo.sproc_Secure_OpenKey_10 @Key = @Key10 OUTPUT, @Cert = @Cert10 OUTPUT
SET @EncID = EncryptByKey(Key_GUID(@Key10), @Custid)

(NOTE: the cert would be stored in the table for decryption later --that is why it would be returned.)

In theory, this would be handy, allowing you to only have to update the OpenKey and CloseKey procedures.

My question is:

Is outputting the Key and Cert names from an OpenKey stored procedure a possible security hole? If so, is there a way to make this secure?

I'll appreciate any input.

Thanks!

So after some time and research, I think I've answered my own question.

When using this method of opening and closing keys, you don't set any permissions, therefore nothing that doesn't already have the appropriate permissions (of its own) can use the stored procedure and receive the outputted Key and Cert names --the OpenKey and CloseKey stored procedures work under the permissions of the calling stored procedure, therefore only the calling stored procedure with the permissions will be able to use and see the Key and Cert names outputted by the OpenKey procedure.

In summary: it seems outputting the Key and Cert names in the OpenKey stored procedure should not create a security hole, provided no permissions are set for it.

I thought I'd share my findings, if perhaps it would help someone else.


Viewing the configuration.php My understanding is that you should never host your configuration.php file within the public_html directory (I am specifically referring to Joomla, but I imagine this is a cross-platform scenario).

My question is: is it at all possible for a user to access/view this configuration file over the internet, or would they first have to exploit the server and then use that exploit to access the config file. In other words, is the best-practice of keeping configuration.php outside of the web root purely to stop a minor exploit from escalating higher, or does the file's existence provide a vulnerability in and of itself?

A configuration file is not publicly viewable over the internet as long as the permissions are setup correctly. Configuration files usually do not output any data directly anyway.

They are able to download a copy of the configuration file if they exploit your server and gain access via methods such as SSH, FTP or through a web-based control panel.

Keeping the configuration.php file outside of the web root directory does increase the level of security, however if an attacker was to compromise your server and gain full access then they are still able to access this file.


Can a hacker install known-vulnerable software on a machine in order to control the PC and elude antivirus? I recently discovered that on one of my PCs the SolarWinds software was installed.
I didn't install this software on my machine.
I also saw that SolarWinds was cracked by Russian hackers and also companies like Microsoft have a lot of data leaks.
Is it possible that I'm a victim of a hacker attack?
And what I can do now in order to secure myself?

Of course it is possible to install weak software in order to get more access to a machine. This is a known approach.
However, if you have access to install something, you tend to have enough access already. SolarWinds provided a backdoor, and if you can install SolarWinds, then you can simply install a backdoor.
If the software gave you more access than you might have (like system-level access) then it becomes a viable approach. But that's not the case with SolarWinds.


Google's view of a web page is corrupted Recently, one of my website has been hacked in a very interesting way.

By doing some researches I've found that I wasn't the only one affected by the hack, but didn't find anything about it.

Note : I am going to describe my website but after looking at other hacked websites, they all have the same behavior and look like the hack has been spreading.

  Few information about the website :

is using wordpress,
is executed by apache

  Information about the hack :

The website hasn't changed of any way. I still have my only page with a clean source code, which hasn't changed at all.

The way I've noticed that something was wrong on the site is that the title and description on Google suddenly became in Japanese, with some keywords like iPhone, Samsung ans other popular brands.

I then tried to domain search it on Google like site:mywebsite.com. This gave me around 12k results (when there should be around 15 maximum), all being pages that redirect me to 404 with title and description in Japanese. All these pages have a cache version with different Japanese content.

When I try to look at the website "like Google" in the search console, I see the website being displayed like the cache version. There is some code in my website that targets Googles bot and create fake urls for it.

This looks like Pharma Hack, but the difference is that they are not trying to make any back-linking. There is absolutely no link that redirects to something else than my website (home or 404). Maybe it is more NSEO ?

I know that WordPress is one of the worse thing security-wise. But my question is more security oriented. Is this a known hack ? How does somebody target google's robot to make him see a totally different website that the one that I made ?

As mentioned in the comments, try this command to see if the malware is not returning different content to browsers and bots (just use your own URL):

curl -H 'User-Agent:Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' \
  -H Pragma:no-cache \
  https://httpbin.org/user-agent

And the attack may have targeted Google for a number of reasons:

turn your page into a SEO backlink farm
attract traffic from specific user agents only (e.g. mobile browsers) and only show infected HTML to them

This also might not be an infection at all, these symptoms could be present in the following cases:

broken virtual host configuration on your web server - e.g. different page returned when accessing it through www.example.com and example.com because on of them is not configured explicitly to return your page and returns a default web server contents, which happens to be someone else's website (e.g. on shared server)
broken DNS configuration, resulting in Google bot speaking to a different server than you think it's speaking to

You might try to use some cloud-based web site scanners  to see how your website is rendered from the outside world - e.g. scan it on WebCookies.org and see if the title and description matches your website.


How can I determine if a CA Cert can be used for DPI-SSL I would like to know if a CA Cert I installed can be used to perform DPI-SSL decryption without my knowledge. Would there be any indication? Can you look at the cert properties to determine if it can be used for this purpose?

DPI-SSL works by doing a man in the middle attack: it frames the right server by dynamically generating a fake certificate for that server. This works only if the corresponding CA (the one which issues the fake certificate on-the-fly) is "trusted" by the client. By definition, this CA "looks like" any other CA It is different from the "normal" CA only in that the private key is owned by some system which does the DPI, but this is not written on the certificate itself.

What you can do is compare the certificates that your machine trusts with that from the "root CA" store of a generic desktop system; compare the "thumbprints" (these are the hash values computed over the root certificates themselves). Presumably, the default root CA are not involved in DPI; any extra certificate is then a potential suspect.


Bypass Stack Canary by going past the return address I was testing a simple C program with stack canary protection.
I attempted to bypass the protection by overwriting past the function's return address and overwriting main's address. I am overwriting it with the address of a function within the target program. I get the following result which leads me to believe an attack is possible:

It detected the smash, but it looks like it attempted to jump into the target function, which is "yo". I attempted to manipulate whatever address it was attempting to access, but no luck.

My question is, is further exploitation possible? Is it terminating as a result of SIGSEGV (i.e. accessing 0x1010...) or the canary detection?

The idea came from this article

The program:

It's terminating as a result of the canary detection.  Just because GDB shows the stack frames including your other return address does not mean code execution would have ever gotten there -- GDB is just reading the addresses up the stack ("unwinding the stack") to display the information to you.  You would only have gotten to yo if you had successfully returned from all of those functions, but since __stack_chk_fail results in the program dying without returning, that would not happen.

To bypass stack canaries, you pretty much need to leak, guess, or brute force the canary value, find an arbitrary write (e.g., write over EIP without overwriting the canary), or find an exploitable bug in the stack canary handler.


What is Greasemonkey/Userscripts and how does it relate to IT Security? I came across http://userscripts.org/ and learned that it is popular among web-users to install something called "Greasemonkey" to allow client side scripts to run.

What are the benefits of Greasemonkey to the IT Security Professional?

Should IT Security be concerned about the growing use of Greasemonkey and related browser add ons?  What mitigations are there?

Greasemonkey allows you to basically have a scriptable API into website/data/view manipulation using JavaScript.

It is beneficial in IT security to use to automate some things or even to give yourself a more usable view for output you may be receiving

You can't really mitigate anything GreaseMonkey does directly persay, but preventing automation of anything you have would (possibly) inherently stop it


Is it true that argon2i is "preferred for password hashing and key derivation"? I was looking at the wiki for the node-argon2 package in npm, when I came around this justification for using argon2i as the default mode:

  The variant of the hash function. Argon2 has several variants with
  different aims:

argon2d is faster and highly resistant against GPU attacks, which is useful for cryptocurrency
argon2i is slower and resistant against tradeoff attacks, which is preferred for password hashing and key derivation
argon2id is a hybrid combination of the above, being resistant against GPU and tradeoff attacks

This security.stackexchange post suggests that side channel attacks are not a big concern on server(which I assume is the application here), and that argon2id or argon2d would be better choices.

Additionally the claim that argon2i is better for password hashing because its slower seem dubious, since the number of iterations can be adjusted for any mode

Is there any truth to the statement "argon2i is slower and resistant against tradeoff attacks, which is preferred for password hashing and key derivation"?

If you are verifying passwords, your first choice is Argon2id in all cases.

In the incredibly unlikely event that you can't use Argon2id, then the tradeoffs between Argon2i and Argon2d matter.

Argon2i is intended to prevent side-channel attacks.  That is, if you have an unprivileged malicious process on your server, it could use CPU vulnerabilities like Specter to tease out enough details to reverse engineer the password.  By randomizing its memory layout a bit, the malicious processes are far less likely to be able to listen in.

This is very important on servers; especially virtual servers running in cloud environments.

Argon2d, however, is intended to prevent optimizing parallel processing in memory constrained environments like on GPUs, FPGAs, and ASICs.  The tradeoff here is that general purpose CPU cores tend to have access to a lot of memory, and multiple banks of memory can be mapped at the same time.  GPUs have several programmable lanes (not exactly a CPU core; there's less branching allowed) that have access to far less memory at any given time. Switching the mapping of memory banks takes time and makes using a GPU less desirable.  A password hashed by Argon2d is far more resistant to offline brute force attacks, because it is designed so that there should be no shortcuts that an attacker can take to run faster than a general purpose CPU.

If you know that you have physical security over your server (only you can touch it), and you have audited every piece of software on that server (not possible with a modern OS due to the vast amount of software on even the most barebones systems), then you can ignore Argon2i.

If you know that your user database will never be leaked, or you are working with cryptocurrencies where nobody knows which inputs will generate the desired output, you can ignore Argon2d.  If you're a cryptocurrency designer who still thinks that proof-of-stake means proof-of-work, then you want the memory hardness of Argon2i, to disincentivize the GPU/FPGA/ASIC arms races that only serve to put money into the pockets of those who are already rich.  (And the pockets of your electric company...)

If you are like 99.999% of site owners, use Argon2id.


Are there any risks from cloning a LUKS encrypted partition? I'm using an installation of Ubuntu server  on disk, with some extra packages installed and configuration carried out, on disk as a kind of base image for repeatedly creating other systems. I clone this to a new disk, alter a bit of configuration and have a new working system in very little time. I understand that some sort of automated provisioning system such as Ansible may be a better way to go, but this is my current workflow.

However, I have one partition that's a LUKS container, managed with cryptsetup. This only has a single keyslot in use in the LUKS header. My approach is to alter the passphrase interactively with cryptsetup luksChangeKey.

I've considered also changing the UUID of the LUKS device. Although I'm not sure if that's adding anything, it will at least differentiate the partitions on different systems.

Am I creating an opportunity for attack by doing this?

Per the cryptsetup wiki,

Note: this section pertains to backups specifically, but I feel like it applies to your situation.

  6.7 Does a backup compromise security?

  Depends on how you do it...There are risks introduced by backups.
  For example if you change/disable a key-slot in LUKS, a binary backup of the partition
  will still have the old key-slot. To deal with this, you have to be
  able to change the key-slot on the backup as well, securely erase the
  backup or do a filesystem-level backup instead of a binary one.

To clarify, one should ensure that the old key-slot is removed in the cloned partition.

  In both cases, there is an additional (usually small) risk with
  binary backups: An attacker can see how many sectors and which ones
  have been changed since the backup.  To prevent this, use a
  filesystem level backup method that encrypts the whole backup in one
  go, e.g.  as described above with tar and GnuPG.

To reiterate, one could simply back up the partition by creating an archive and encrypting it, and then moving it to a newly encrypted partition on the new machine and extracting it.

  I've considered also changing the UUID of the LUKS device. Although I'm not sure if that's adding anything, it will at least differentiate the partitions on different systems.

I would recommend this.

  6.15 Can I clone a LUKS container?

  You can, but IT BREAKS SECURITY, because the cloned container has the
  same header and hence the same master key.  You cannot change the
  master key on a LUKS container, even if you change the passphrase(s),
  the master key stays the same.  That means whoever has access to one
  of the clones can decrypt them all, completely bypassing the
  passphrases.

  The right way to do this is to first luksFormat the target container,
  then to clone the contents of the source container, with both
  containers mapped, i.e.  decrypted.  You can clone the decrypted
  contents of a LUKS container in binary mode, although you may run
  into secondary issues with GUIDs in filesystems, partition tables,
  RAID-components and the like.  These are just the normal problems
  binary cloning causes.

  Note that if you need to ship (e.g.) cloned LUKS containers with a
  default passphrase, that is fine as long as each container was
  individually created (and hence has its own master key).  In this
  case, changing the default passphrase will make it secure again.


Security implications of using an algorithm to lengthen and salt passwords before using them? I have created a JavaScript bookmarklet which, among other things, base64 encodes my plain-text passwords combined with information from the site's domain name. The idea is that base64 output is significantly longer than its source, and the domain info keeps the same password from generating the same output if reused on a different site. You could also salt this with your own personal key, should multiple people be using the same algorithm. As long as it has predictable output the idea is that you could use it to make human readable passwords the length of a strong computer generated one. I don't see any downsides to doing this, but I'm not a security expert and I have a feeling that I'm not seeing something here that could actually weaken a good password's inherent security. Am I? If so, what is it and can it be fixed?

For your consideration here's a simplified version of the script I'm using that shows the basic idea:

(function() {
    var pwelements = document.querySelectorAll("input[type='password']");
    for (var i in pwelements) {
        var pw = btoa(pwelements[i].value + window.location.hostname.replace('www.', '').substring(0, 10));
        pwelements[i].value = pw;
    }
    return false;
})();

Using this script with the word "test" on https://password.kaspersky.com/ takes the estimated crack time from 1 second to "10000+ Centuries" (or 98 centuries if using a super computer). Obviously these sorts of password checkers are inherently flawed, but it serves to illustrate the difference I'm hoping to achieve with this. The encoded results of "test" passed through this algorithm is "dGVzdHBhc3N3b3JkLms=". Real passwords typically produce much longer output.

If this sort of thing is a good idea, is it possible to create a version of this which could be fully open-source but not compromise the security of passwords using it? Right now this is all reversible if you know the algorithm and know the output, the only saving grace is that if user specific salt was used then, once hashed server side it shouldn't be possible to just run an attack through this algorithm to brute force using the plain-text version (without knowing the salt)... I think? I think that the salt would serve as a form of two-factor authentication, but I am unsure of how effective this would be. As far as I can tell this is at least no worse than using the original password normally.

I'm convinced there is a reason this is a bad idea, but I don't know what it is.

I'd say that it doesn't add much. Base64 is just an encoding, it doesn't add any entropy to your password.

It's also quick to compute so it won't slow down a brute-force attack.

The only thing it can prevent is an attack against an universal rainbow table that didn't take into account the base64, but maybe some rainbow table out there did take this into account. It wouldn't be more complicated to compute that a standard rainbow table. The only good way to prevent a rainbow table attack is to use a salt.

Also, always assume that the salt is known. The purpose is to prevent rainbow tables not brute-force attack. The best way to prevent brute-force attack is to use a slow hashing process like bcrypt.


How to see (EC)DHE length in a browser? If you check a site's TLS encryption in a browser, you'll see somethng like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. You can see there AES and SHA length. You can see RSA/EC length if you inspect the certificate. But where can I find (EC)DHE length?

The answer will of course depend on which browser you're using. Here are the two that I have available:

Chrome

This is easy to get; open Developer Tools (F12) > Security tab.

I can see that my browser negotiated curve X25519 (which if you look upis a 256-bit curve offering 128-bits of security) when I connect to security.stackexchange.com:

Good question whether the key length for traditional DHE would show here also, I don't know of a site that's still using DHE on which I could test...

Firefox

The Dev Tools (F12) doesn't have a Security tab, and clicking More Information on the green lock tells me the cipher suite was negotiated, but not which curve:

A few minutes of googling did not find me a way to get the (EC)DHE info. I'm actually surprised that I can't find a firefox add-on to do it either. You've got me stumped there.

Other browsers

You'll have to play around in the dev tools and see if it's exposed.

The upcoming TLS1.3 is trying to simplify cipher suited by moving more information out of the cipher suite string and into extensions field the same way the size of elliptic curve is negotiated today. So I expect that once Firefox starts using TLS1.3 by default, they will have to add some sort of viewer for this data.


Block spam that looks like it is coming from actual humans, and not bots? I work for an educational institution, and we are seeing entries from our admissions application that amount to spam. Currently I only have one honeypot applied to thwart the spam bots, but these entries looks like input from actual people. There is no garbled text in input fields, no crazy links, just regular names, social security numbers that are all very similar if not duplicates, phone numbers that are very similar, and they may or may not leave an email address. Cities do not match the states. Addresses are non-existent.

It is an online form, using SQL Server and C#, ASP.NET. However, the application submissions go directly to another server. We don't store anything in SQL. I'm not sure what other kind of details to enter.

How can I guard against this type of spam, if possible?

A captcha is the best way. If you are worried about usability, there are other things you can do, but everything can be bypassed.

You can use javascript to perform some type of calculation. For example, taking into account the time the form is loaded and when it is submitted and send that value back to the server. Then on the server you can do a check to see if it makes sense and filter out the ones that dont.
You can do a lot of things with javascript which will filter out a lot of bots since most dont interpret javascript.

None of this is fullproof because a sophisticated bot could be using something like phantomjs, and there is also a chance you can be denying legitimate traffic.

Alternatively, you can use a Cheap waf and create custom rules to filter out certain types of traffic too if you can find any similarities in the traffic, which you usually can. That can turn into a game of wack-a-mole though.

Blocking bots is an industry in itself because of the difficulty involed.
The most effective solution would be a decent captcha that isnt difficult to read.


What software commonly generates RSA keys with public exponent 0x23 (35)? Reviewing the SSH keys of hosts that I connect to (as gathered by PuTTY in registry key HKEY_CURRENT_USER\SoftWare\SimonTatham\PuTTY\SshHostKeys), I find that they all start with 0x10001 (65537) or 0x23 (35), most often followed by 2048-bit composite values with no small factor. I conclude they are RSA keys, and that 0x23 (35) is the second most common public exponent in my sampling.

What software commonly generates RSA keys with that public exponent 0x23 (35)? Why that value, which is not prime, and thus slightly complicates the selection of the factors of the public modulus?

Versions of OpenSSH up to 5.3 AFAICT then they switched to F4=65537. I don't recall seeing an explanation for why they used 35, but I haven't read every line of everything.


How do I secure "Data at Rest" only allowing Service API to access it from a mobile application How do I secure data at rest from unauthorized access, but still allowing my application to access the data using user authentication over HTTPS?

My scenario is as follows:

Login to application using ID and password (password is hashed using MD5)
After authentication from the server, user uploads data to the server
User can retrieve that data using the application
All data transfer is based on HTTPS
Data on the server is not encrypted

My questions are:

If I encrypt the data at the location on the server, how do I retrieve it using my client application?
Is there any algorithm which allows data to be encrypted and the encrypted data to only be decrypted and retrieved when my application is trying to retrieve data?
How do I keep that data secure from getting hacked if someone gets access to the server?

You could:

Encrypt/decrypt data in the client, then the server is just storing an opaque blob.
Have the client transmit a key that the server uses for encryption/decryption.

Any encryption algorithm provides what you want, what matters is key management.  Additionally, if your server is compromised, then encryption at rest only protects against adversaries not able to tamper with your operating environment.  If they can modify the server (which they usually are able to do, except for access to backups, etc.) then they can capture the data coming and going.  In that case, only client-side encryption will help.

And seriously, don't use md5 for passwords.  If you're using MD5 for password hashes, you've already put user's data at risk.  Leaked, unsalted, MD5s are basically as good as plaintext these days.  scrypt and bcrypt are considered the state of the art in password hash storage, but even salted SHA-2 will buy you a lot compared to MD5.


How whoer.net is able to get your TCP/IP's operation system&modem and its version When running test on https://whoer.net/#extended

On the OS section, TCP/IP column, I get Windows NT kernel [generic] (Ethernet or modem, MTU: 1500)

The question would be how do they do that and is it possible to spoof it?

Most importantly, does this happen on client side javascript or it is completely server side and there is no way to spoof it?

Thank you!

As it says, it's TCP/IP and this information is based on your TCP/IP headers. You send the MTU with every TCP packet and also other details from which it is easy to conclude operating system type.

MTU size is sometimes rewritten by some home routers, they lower the value either as needed or to some preconfigured size like 1480.


How to make this script run from image? I'm testing my application for security vulnerabilities. I've inserted javascript in a gif and uploaded it into the application. The application loads the image in <img> tag. The script gets executed only if the image is given as source in <script>. Is there any other way to load the script in the image?

Historically, it has been possible, such as the GIFAR malware case from over a decade ago.

But as of now with modern web browsers, there is no way. It has been patched to prevent polyglot images from being executed at will. <img> will only read and output the image as an image, regardless of the Content-Type of the page itself (it used to take precedence).

However, you might want to know that it might be possible to do an XML injection using an svg file. XSS will not be possible as long as you stick to the <img> tag, but XXE can occur.


I'm conducting a study involving passwords, and need a method that assigns a numerical value to the complexity of a password I'm currently a student and am conducting a science fair project for my high school. The study involves collecting human-generated passwords and testing them for complexity, or "crack-ability," to determine which password requirements/criteria best encourage users to generate secure passwords.

I need some system that rates each password for how secure it is. I considered using NIST's formula for calculating data entropy, but later realized how unrealistic entropy is for measuring crack-ability. I have also read some of Matthew Weir's studies and would like to, if possible, use his system, PCFG Generator. I've found the download and instructions here, but as a student, I'm still unable to figure out how to use it exactly.

Any reliable system for predicting the guessability of a password would be very helpful, so long as it considers common cracking tools (dictionary attacks, like JtR). Any help would be greatly appreciated.

Thanks!

In short there is no reliable way to do this. Your program would have to implement a set of rules. Humans then work around these. I.e. requiring a number makes 99% of average users passwords no more secure - they just add a 1 at the end of the existing password. The same with symbols.

"p@55w0rd!" would score highly on a lot of prior attempts at rating passwords. As would "This is my password!". Meanwhile "lbvgjnwhha" (randomly generated)  would score poorly because its a fairly short string of all lowercase letters.

Instead I would consider a different approach. This page, for example can check a password against hundreds of millions of known to be leaked passwords. This should defeat most non-targeted (i.e. personal attributes like surname, date of birth etc.) dictionary attacks. You could demonstrate this (or download the full password hash lists and write a tool to calculate the hash for an entered password and check it against the list) while explaining password best practices & the benefits of two factor authentication.


Does username length/complexity/uniqueness positively impact security? Is having a longer/more complex username considered more secure than using a shorter/basic one? Would the uniqueness of a username positively impact security?

This is assuming that adversaries aren't aware of what the username may be, eg. a remote terminal login.

A harder to guess username adds to the security if it's kept secret.

The problems are

Usernames are often not kept especially secret. On most systems allowing multiple users to log in, any user can view the list of valid users. On systems that run mailservers, the mailserver can effectively be used to check if a username might be valid as most mailservers will accept mail for any local user. Various programs may include your username by default in outgoing traffic when they connect to servers. New user signup forms or password recovery forms may allow an attacker to check if a username is taken.
Usernames are often harder to change than passwords.

So when adding additional complexity to your login credentials, it's best to get into the habit of putting that extra complexity in the password rather than the username.


Protecting yourself against DNS spoofing? Are there any things which the user can do, on their own machine, to protect against DNS spoofing? I was just thinking when I was at the airport last and I wanted to check my email I used a hotspot access point, paid for the access using my paypal and that could probably have been intercepted. What could I have done from my end to maximize my protection?

I would usually suggest vpn, or ssl but this isn't something the user can decide, thats something for the network owner to implement?

Technically that could have been an ARP cache poisoning attack which is much more likely to occur. I'd suggest using SSL (Secure Socket Layers) and TLS (Transport Layer Security) as well as only connecting to the sites with "HTTPS://" addresses to encrypt your connection. Using a proxy or VPN protects your IP address from users on the other side of the modem, but not people within the network you're using.


How to ensure an email address is not free webmail or ISP address? I notice security companies such as Rapid 7 prevent people signing up with either free email accounts, or accounts provided by ISPs:

https://www.rapid7.com/products/metasploit/metasploit-pro-registration.jsp

  To prevent software license abuse, this field requires an email address from a domain you or your employer owns, such as a company, university, or personal domain. Email addresses from internet service providers or free mail providers are not accepted

Now I imagine that this could be accomplished by a blacklist of ISPs and free email address providers but I also notice that it does not work with some of the temporary email address services so these must be catered for somehow. My other guess was that it did some sort of DNS lookup to validate the company, but this would not work if I had set up a domain using my own company solely for temporary email addresses that the general public could use.

My question is how does the form validation work to ensure that your email is not any form of temporary address?

The above page validates the email on lost focus, so you do not have to actually submit the whole form to test this (as I would not advocate spam).

It's most likely blacklist-based. You wrote

  I also notice that it does not work with some of the temporary email address services

-- these are, for obvious reasons, a prime target for blacklists, so them being blocked is not a reason why it shouldn't be blacklist-based. Of course, blacklists are never complete, but there are services that provide such blacklists as an API and I'd guess they are pretty comprehensive.

Indeed, they query an online service to validate the address, which will most likely check against a blacklist and appears to perform other checks (e.g. existence of domain, but not if the domain even has a MX record).


What impact does an installed extension have on the browser fingerprint (uniqueness)? Motivation
I want to develop a custom, local Firefox extension and investigate, if its installation has any impact on the browser fingerprint.
Background
Some time (years?) ago, there were articles advising against installing too many browser extensions,
as they would make the browser client more identifiable and trackable by leveraging more unique fingerprints (if  I remember correctly).
Today I gained more experience with JavaScript and its APIs in general, though still lacking knowledge about Firefox web extensions API to approve or falsify the mentioned articles' statement. After a bit of research, I cannot find any JavaScript API that would allow websites to read a list of my installed extensions or similar. amiunique.org also does not provide this information. Hence I would like to comprehend possible reasons for this advise (can't remember the source, sorry).
I guess, Mozilla in the meanwhile also had hardened its extensions API (was it v60?), which might make statements not comparable to status quo.
Questions

As of today, is there any JavaScript API that allows reading the list of used/installed extensions, so websites could use this information to create a more unique fingerprint of my browser client?

Does using a custom, locally developed (or more in general any) extension have an impact on the browser fingerprint?

Have browser APIs been more "generous" in terms of querying installed extensions, so that this advice has made sense in the past?

There are no explicit APIs to enumerate the browser extensions. But this does not mean they are not detectable or that they cannot be included in the fingerprint even if the specific extension is not detected.
Browser extensions usually serve a purpose and this purpose can cause side effects, like manipulating the DOM (remove ads, change visual representation, enrich content with more additional information ...) or change the timing of operations. These side effects can be measured and can be included in the browser fingerprint. This can be done even if the specific extension is not known, i.e even the effect of private extensions can be included in the fingerprint.
Apart from that it might be possible to detect the existence of specific extension by probing their internal resources, see How to Detect Browser Extensions for details.


The site includes HTTP resources. but I did not find the http resource My website is https://blogviets.com but the https is not green. Chrome said "The site includes HTTP resources." but I have view the source of website and search for http:// and there is not resource such as image, css, js use http://

Could you please check and help me fix to make https green color?

Thanks

If you follow the details offered in the message you get in the console:

  Mixed Content: The page at 'https://blogviets.com/' was loaded over a secure connection, but contains a form which targets an insecure endpoint 'http://canthomoi.us10.list-manage1.com/subscribe/post'. This endpoint should be made available over a secure connection.

And it even points you to the line 90 where this problem happens:

<form class="thesis_email_form feat-box-mchimp" method="post" action="http://canthomoi.us10.list-manage1.com/subscribe/post">


About generating Exe files from Metasploit scripts I'm a newbie to Metasploit framework. I want to create a standalone application (an exe file) exploiting MS08-067 vulnerability. Is that possible for me to have the application generated from Metasploit Exploit Scripts?

I've read an article at http://www.offensive-security.com/metasploit-unleashed/Backdooring_EXE_Files but it seemingly apply payloads only.

I think the simplest way is to find the MS08-067 exploit code, which is available in exploit-db. Its written in several programming languages, compile the C code to standalone EXE then execute the msfpayload and msfencode to obfuscate the code from AV (change the putty.exe to your exe file).

by the way, you need to add the exe file in metasploit root directory and shell directory

BUT.. this code can be executed remotely so you don't need to use it with the example above. The backdoor method is useful for exploits that has to be executed locally (then follow the method above) or to open up a connection from the system to connect back to the hacker.


Is ssh tunneling to remote server Php admin secure? I have not been able to find an answer online so I thought I would ask here. I have setup an Amazon Lightsail instance to act as a development platform for my website. I have setup SSH for accessing administrative tools such as PHPMyAdmin. Would this be sufficent in terms of being able to securly access PHPMYAdmin and upload files or should I be using SSL aswell?

Would this be sufficent in terms of being able to securly access
  PHPMYAdmin and upload files or should I be using SSL aswell?

I am guessing you are talking about Secure socket tunneling to run the localhost on the remote server as given here.

The secure socket tunneling protocol already does SSL/TLS provides transport-level security with key negotiation, encryption and traffic integrity checking.wiki
That should be sufficient.


"Yea, I can hear them" I just heard this from my computer speakers Randomly I heard a man's voice from our home Mac, "yea, I can hear them"

There were no internet windows open. We cover our camera with a sticker, call us paranoid but are we really? NO!

Does anyone know how I can find out how, why, where, who is listening in on me?!?!?!?

Install Little Snitch for Mac and reboot. You can use the filter to limit external communications to just those that you explicitly authorize. If it's an ongoing thing, just disconnect for a while to see if it persists.

If you're really worried about it and don't want to monitor network connections, you could always block the microphone. On my MacBook, I used a few layers of electrical tape to cover the microphone (didn't fall off until a while after I stopped being paranoid). To find the microphone(s) on your machine, you can open QuickTime Player, click File > New Audio Recording, turn the volume up, and tap around the chassis. Use headphones to eliminate reverb loops while testing.

Really doubt an eavesdropper would use a two-way stream.


Why is RFC4255 (SSHFP) not used for https? I had this idea a few hours ago, but of course it already exists and there is even an RFC...
Why don't we publish the fingerprint for the SSL/TLS certificate via DNS? We need DNSSEC to make sure the answer is legit and we need to make sure the nameservers are in a secure environment, but besides that I see no issues that SSL/TLS doesn't already have.

This change would move the authority for securing all our encrypted traffic from certificate authorities (CAs) to DNS nameservers. This could be an issue because in that case, all DNS providers (that have DNSSEC) should become very high-security environments like CAs are now. But shouldn't all nameservers already be this? The majority of the websites use plain http for sensitive traffic and most people would not notice if there is no padlock when logging in to Google. I'd say they have a huge responsibility already.

If we don't trust the domain's nameservers, we could include fingerprints in root servers instead, but I'm not sure how much extra load that would be.

Another issue is that DNSSEC is not that widely implemented yet. But the reason for my asking is because the IETF is considering to support encryption in http/2.0 without requiring certificate verification "to make it easier to deploy".

In my opinion, security should either be done correctly or not at all. Don't give people a false sense of security. But if we're going to change protocols anyway (upgrade all webservers), we might as well implement DNSSEC and do this the right (authenticated) way.

The issues/changes in short:

we need to trust (root?) nameservers instead of a ton of CAs;
we need to add a dns record type or extend the use of the sshfp record; and
we need to support dnssec more widely.

Am I missing something? Why are we paying top dollar for SSL/TLS certificates when all we need to do is publish the certificate's fingerprint over some authenticated channel?

The point of unauthenticated encryption in http 2.0 is to encourage enabling it without having to modify any other config at all. I'm against this because it's needlessly slow (another roundtrip for the key exchange, which is especially bad overseas or with any packet loss) and hardly adds any security. It might even provide a false sense of security. On the good side, it obfuscates traffic.

This proposal to use DNS makes it somewhat more work to implement encryption on webservers, but makes it (at least nearly) as secure as normal SSL/TLS while still keeping widespread availability of encryption very high (I don't expect they'll keep up the ridiculously high prices for a sshfp/httpfp/tlsfp-enabled nameserver like they do with certificates). Unauthenticated encryption might still be a last resort when all other options (signed cert; stored cert; securely published fingerprint) are unavailable (though it should not be shown to the user because it provides a completely false sense of security), but I'm not sure it's even worth the slowdown.

If it's not possible to use the root servers for this, we could also use the domain's nameservers as "reasonably secure envionments" (normal padlock) and use a CA-signed certificate for EV (green bar). Then tell people to look for the green bar when they're doing online banking. Nameservers already have a rather big responsibility so it might be safe enough even if we can't expect them to be as secure as a CA. At least it'd be a much more flexible system; I'm restricted to my domain and one subdomain for any reasonably priced certificates (and the subdomain is already occupied by "www.").

My question again in short: Is there any reason why we don't use an SSHFP-like system for https, if DNSSEC were widely available?

There is a RFC for that. It is part of what DNSSEC is meant to do.

Now don't get too hopeful about "top dollar" or reduction thereof. The need to "certify" in some way public keys with regards to server names is not magically removed by switching to DNSSEC. The "CA" role is just moved around, and the associated costs are still there. It can be predicted that if the registrars must assume these costs, then their prices will rise. Sooner or later, someone will have to pay for it, and I have a strong suspicion that it will be the SSL server owner.

Philosophically, it is unclear whether merging the certification structure (the PKI) and the naming structure (the DNS) is a good idea. The merge would sure simplify the communications between DNS and PKI when dealing with the specific case of issuing certificates bound to host names; but it also means that the two responsibilities become intertwined. It takes a substantial dose of wishful thinking to believe that whoever is a good registrar would also be a good CA; the two kinds of activities are vaguely similar, but not identical.

Also, certificates are supposed to have a scope beyond HTTPS servers; they should be usable in contexts which have no relation whatsoever with the DNS and host names, for instance when signing software (application, drivers...).

Economically, it would not change much. Among the commercial CA, the most used is VeriSign, aka Symantec. Switching to DNSSEC means that the ultimate certification authority will no longer be VeriSign, but whoever manages most of the root DNS, i.e... VeriSign. Now THAT would be change, wouldn't it ?

Politically, there would be trouble with "state CA". Many of the dozens of CA which are trusted by default by a Windows system are "vanity CA" sponsored or even operated by various governments. The same governments have no intention to operate DNS-related infrastructures which require a lot more bandwidth and availability; and they would resent seeing their precioouuusss certificates becoming "second-class citizens".

For security, this is mostly a non-issue. Fake certificate events are very rare; we hear about one such occurrence per year. The bulk of Internet-related frauds and phishing and other attacks does not rely on fooling existing CA. In other words, the current CA system works. Don't fix that which is not broken. Yeah, the CA system looks brittle and prone to failures, but despite much publicity about the occasional breaches, the raw fact is that it survives.

Summary: the standards are ready, the RFC are published, the software is written. Now all that lacks is a reason to switch from a "commercial CA X.509" world to a "commercial registrar DNSSEC" world. It is hard to see what good it would actually do.


Risks of explicitly trusting SSL certificate vs relying on certificate chain for validation? I'm working with a client that is manually importing our (publically signed and issued by a well known intermediate CA) SSL certificate onto their client systems.  I believe they are doing this because they do not update the list of trusted root CA certificates on older Microsoft Windows 7 systems.

This inevitably causes problems each time our SSL certificate is renewed or changes for any reason. I'd like to understand some reasons (advantages) that would motivate an organization to manage their systems in this way.

Specifically:

What are the risks of not relying on the certificate chain for SSL certificate validation and instead manually importing the certificate as trusted?
What additional risks, if any, are there for not keeping the list of trusted root CAs updated?

What are the risks of not relying on the certificate chain for SSL certificate validation and instead manually importing the certificate as trusted?

One is related to the fact the chain of validation typically includes a CRL and/or OCSP service to query for invalidated, but otherwise legitimate, certs.
In other words, a cert may be technically valid, but have been invalidated because its private key was compromised - CRL and OCSP are standardised ways of dealing with revocation, which is not generally the case of manual certificate management.

I would also tend to think this is a waste of resources: why expend additional effort on meeting a need that has a better, and more to the point, standardised, solution?

Especially at any scale, surely this is also inefficient: versus the one root (or e.g. 5 root + intermediate CAs) you might want to trust, you would need to distribute X end-entity certificates, and additionally, would be bound to the issuing CA's lifecycle for certs in terms of needing to re-distribute new certificates.

  What additional risks, if any, are there for not keeping the list of trusted root CAs updated?

As mentioned, revocation is one area that springs to mind: absent an effective revocation mechanism, a trusted CA merely indicates that something was, at some point, trusted. It has no clear significance for whether this same 'something' is now trusted.

Without maintaining your trusted roots, I would tend to think you are rendering much of the purpose of x509 moot: trust is a transitive property, and any assumptions to the contrary have tended to be exploited for malicious purposes.


Bot detecting by considering request inter-arrival time If there are some chances to detect a bot by considering the users page viewing time, is it possible to measure this time?

When a user request for a page (page request), browser request for several other components within that page (inline requests), i.e. images, CSSs, JSs, ...

By just sniffing the traffic, is it possible to find the time interval between user's page requests (page viewing time) by discarding inline requests? There is a need to differentiate page request and inline requests. Is it possible?

Here at Incapsula we actually use some of these methods for bot detection (i.e. JS and Cookie challenges) but I`m not sure about the page-view-time metric.

For one thing, you want to detect and block malicious bots as quickly as possible and there are better things you can do then to wait around, even if it's just for a short while.

I also have to agree (+1) with @yfeldblum about the Expire headers and their ability to interrupt resource-load based tests. Having said that, CND and Multiple servers are not an issue if the challenges are performed by the CDN provider himself.

I also wanted to contribute few other ideas for bot detection:

Behavior (i.e. early access to robots.txt)
HTTP Header order/missing parameters

Also, I would like to suggest not to rely exclusivity on any of these methods because this will lead to false positive identification. Instead, try to combine them into a step-by-step cross verification process.
(i.e. JS challenge -if failed-> Cookie challenge -if failed->Robots.txt access and so on....)

Finally, at some point you'll have to start collecting and relying on signatures to minimize redundancy.

After all, you can't keep testing Baidu bot every time it visits, this is just one step away from a self-inflicted DDoS. :)


Security drawbacks for using short-lived access token in javascript client side I intend to build a front end site entirely in javascript (NodeJS) and i would like to do ajax calls to a REST WS which is on another domain on client side.

I intend to use oauth2 and SSL to secure my REST back end, perform the access token asking on front end server side, but as i want to be able to do ajax calls, i have to use the obtained access token on client side.

My question is : what is the dangers to use a short-lived access token on client side in order to perform cross domain ajax calls ? Isn't it as secure as using cookies ? I know that passing by a proxy should be more secure but is it really worth ?

Thanks a lot.

With any API over HTTP you have to worry about Cross-Site Request Forgery attacks.  JSON+REST CSRF is possible.  This isn't taking JSONP or CORS into consideration because the request isn't being performed with an XHR.

Enabling CORS causes huge problems trying to protect your API.  CORS in effect revokes your rights to protect your website with the Same Origin Policy,  it is very similar to having an XSS vulnerability on your website.

A really good method of preventing CSRF is including a random token with each request.  Unfortunately this isn't very RESTful,  but it is secure.  In some cases an attacker maybe able to obtain this CSRF token by abusing JSON(http://jeremiahgrossman.blogspot.com/2007/01/gmail-xsrf-json-call-back-hackery.html), and there are ways of preventing this.  If you are serving this token with a CORS enabled REST api,  then there is no way to prevent an attacker from obtaining this token,  and there for you cannot prevent CSRF.


Wireshark as a network scanner I have been playing with nmap lately, trying out arp-ping scanning and using idle hosts, etc...

Looking at Wireshark, there is always some suspicious activity when performing scans. The thing is, I do have to scan to find idle hosts to use and whichever type of scan I use is never 100% silent. There is always suspicious traffic and/or logs in the target machines.

So I had this idea: why not use Wireshark as a scanner? Instead of actively scanning machines I could just start Wireshark or a similar sniffing program and watch how machines interact with one another in the network with the data being stored in a database.

My question is, is there any program or Wireshark mode/module/etc that already does that?

The process you are talking about is a form of passive scanning. Frankly, you don't even need Wireshark to do exactly what you want and without a database: you just need to manage the pcaps.

There are tons of tools that can query pcaps for data, Wireshark is only one of them.

If you are wanting to use Wireshark, in the "Analysis" and "Statistics" portion of Wireshark, there is a summary of the hosts, and even the ports that are used. As far as I can tell, that's what you are looking for.


Passing Data between Mobile / Web Apps We have a third party mobile app that will link to a dashboard in our web app. The user id needs to be passed from the mobile app to the web app in this interaction so that we can retrieve the user's data in the web app. The user is logged in in the mobile app and we need to sign them into the web dashboard without prompting again for credentials. I'm considering using Encrypt-Then-Mac approach to pass the user id on the url as a query parameter OR a pseudo SSO approach where the mobile app retrieves a one time token by calling a background API and passes that along with the user id to the web app.

Can you comment on the pros/cons of these approaches or suggest a better one?

Authenticating to the API and then receiving a token is a far better approach. This ensures that the user is authenticated and the token is the representation of that authentication. You can use a framework like JWT to make such tokens.

Encrypting the User-ID is not a good idea. What this "authenticates" is that the request comes from the mobile App, which an attacker can reverse engineer to gain access to the keys. An attacker can then freely create "authentication tokens" for arbitrary user IDs.

In general, OAuth 2 may be a worthwhile thing to look into.


Is there benefit to an Anti-forgery cookie with sameSite:none? We have a form that is using asp.net core AntiForgery validation.
Recently encountered an issue with a form on the site hosted on www.domain.ie not being able to POST to the API at api.domain.co.uk due to AntiForgery validation.
The recommendation from the team who implemented this is to set sameSite=none on the AntiForgery token cookie.
I'm not familiar with Antiforgery validation but this seems like it would negate the purpose of using it. Is that the case?

No, it won't negate the purpose of using it since the framework's Antiforgery validation mechanism will remain the same. The samesite attribute should not replace having a CSRF Token. Instead, it should co-exist with that token in order to protect the user in a more robust way (cf. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#samesite-cookie-attribute).
What you should keep in mind though, is:

Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context/HTTPS).
Chrome 85 doesn't allow insecure SameSite=None cookies


AMD K8 processors may not be vulnerable to Spectre? I've been chewing on this for a week or so. Thought I'd ask if it could be validated. My thoughts are based on reading the Spectre whitepaper and research on the AMD K8 microarchitecture, and haven't been able to find any AMD K8 specific Spectre related info on the web. I'm also not a computer science dude... So here it goes:

AMD K8 processors are possibly not vulnerable to Spectre variant 1 (exploiting conditional branches) as although the processor does have an out-of-order execution paradigm, memory operations are executed in-order; memory access cannot be reordered. So if a memory read gets stuck, it would stall all subsequent memory reads or writes, thus eliminating the attack.

The AMD K8 processors are also possibly not vulnerable to Spectre variant 2 (exploiting indirect branches) as although the processor does have branch predictors, it doesn't have indirect branch predictors. Meaning, that the processor will just go to the same target/branch as it did the previous time. Therefore, the processor cannot be trained to make a misprediction nor mistrained, thus eliminating the attack.

Thanks to all the responses.

You were right, and now there is some confirmation from AMD.

In this whitepaper that describes possible mitigation techniques, the AMD family 10h (= AMD K10), as well as the AMD family 0Fh (= AMD K8) are mentioned.


How to implement end to end encryption in multi platform messengers AFAIK, end to end encryption (E2EE) initiates on one device (one platform e.g. android), message reaches the destination and decrypts there. So other devices of mine (like iOS or web client) don't have keys to decrypt the message.

But some IM applications like Wire provide multi platform E2EE instant messaging storing chat history.

1 . The question is: How do different devices decrypt a message that is end to end encrypted on a different device? How do iOS and Android and web and desktop client sync messages?!
If they share private keys, how can we trust the server not to save the key?!

2 . Any idea on how Wire messenger syncs messages?

I will try and answer what I - at the point of writing - understand is your questions:

Cryptography is platform independent, so it does not matter which platform is sending of receiving an encrypted message as long as the sender and receiver do adhere to the same protocol.

As to the key exchange: Let's say, you have devices A and B, both belonging to the same identity, I. Now, I is supposed to have access to messages through A and B. That either means each message is to be encrypted with key(A) and key(B) - or that key(A) = key(B).

In the first case, you cannot trust the server to not transparently add a third device under their control to the list of keys for I, i.e. key(C). This might raise some eyebrows with the sender, but as they are in control of the UI and for that - nevermind.

In the second case, you can share the keys by establishing a secure communications channel to transmit the key - for example by displaying a QR-Code on A and scanning it with B in a secure environment.

In both cases, as the UI and logic might me closed source or you might not be running the binary you have sources for (could be patched before delivery), you cannot be sure that either A nor B transmit all keys known to them to the server while you're texting away.

It boils down to: key exchange is a solvable problem for this scenario - trusting software isn't. You either do or don't and use your own software under your control, adhering to the same protocol.

As to you asking for the implementation and design details for a specific product: I don't know; it might not be disclosed. And if it were, if you're distrusting the supplier, why trust what They say?


SSH key auth, but still need password for sudo? SSH with public-private key authentication comes enabled by default with most Linux distributions. This is great because when I create accounts for remote users I don't have to email them sensitive info(passwords).

However, this process becomes useless when these users need to run sudo -- the server is still asking for their passwords. That means I still need to generate passwords for these users and figure out how to securely get it to them.

I know about sudoers file and NOPASSWORD parameter. However, I feel uneasy enabling it. I would still want some sort of authentication before users can run sudo commands.

While doing some research on this topic I found pam_ssh_agent_auth project, which from my understanding enables the same private/public key authentication as used for ssh connections but for sudo command.

It seems like with this module in place we can have completely passwordless accounts.

Why is this module or similar process is not part of standard Linux distro configs? Is there some security caveat I'm missing why this is not more widely adopted? Why passworded sudo is considered to be more secure than public/private key sudo?

I am trying a different approach that doesn't require creating and managing passwords: I set up key-based authentication with the user's public key, disabled password-based authenticon for ssh and set up the user accounts with an empty but expired password  (passwd -de). That way users get prompted on their first login and can choose their own passwords.

I am feeling a bit uneasy about the empty password but as far as I can tell, it's fine as long as password authentication for ssh is disabled and there are no other services running that require authentication (IMAP or something). Any opinions on this?


Is it possible to catch a virus on my LAN without clicking on anything? My unpatched PC running Windows is connected to a network which contains other "infected" computers, can I get infected by viruses without any interaction on my part?

Absofrickenlutely.

All the other infected PC(s) have to do is find a vulnerability in an unpatched application visible on the network on your PC and exploit it with vulnerabilities they know about.

This doesn't just apply to Windows either. Any OS that is network facing and has exploitable vulnerabilities can be attacked this way.


Insecure local Fritzbox login? I’m a newbie to this area of security, but I’ve been reading up on best practices and have been checking out the Fritzbox 3490. As I understand it when accessing the admin page locally it should always be done with https via the browser. The problem is that the Fritzbox only allows https when setting up a remote access account with them.

I’ve read though the manual and it claims that the firewall isolates the box when locally accessing the admin. I’m not sure this sounds secure, so I need advice - is this an easy way for an attacker to take over the router if there is no encryption on the local admin? Should I search for another brand of router?

First of all, there are different attacker scenarios, lets start with some theoretics:

First, you might be concerned about attackers from the Internet. Here the firewall is a rather important thing. It primary separates local traffic within your LAN from getting into the Internet and prevents unwanted traffic from the Internet entering your LAN.

Especially, if you did not set up remote access, the latter means nobody from the Internet can access your local admin page. While the former means if you send locally your admin credentials to your router, that message never leaves your LAN and therefor can't be sniffed by someone out in the Internet.

Secondly, you might assume that the attacker has direct access to your LAN. Either because you just mistrust your fellow LAN users or because someone from the Internet already hacked one of the devices within your LAN. In this case it might be possible for the attacker to read your password while you transmit it to the router via HTTP. So your indeed should prefer HTTPS.

About your more practical issue:

  The problem is that the Fritzbox only allows https when setting up a remote access account with them.

Where did you get this?
I actually found:

  "For the following MyFRITZ! activities the HTTPS security protocol is used:
  - setting up a MyFRITZ! account [...]"

and

  "The FRITZ!Box generates its own HTTPS certificate. Because
  this certificate does not come from a certification authority
  preconfigured in common browsers, you have to confirm in
  your web browser or in the My
  FRITZ!App that the connection
  should be established nevertheless."

  From Fritzbox manual

It rather states (as I read it) that for the listed activities HTTPS is default/required. But, it also indicates that your router is quite capable of HTTPS. So you could just type the "https://" in front of your admin page URL and test it.
However you will get a warning about the not certifiably connection, but this still encrypts your traffic (as long as there is no Man-in-the-middle).
With my Fritzbox 7360 I'm capable of using the HTTPS protocol this way.


What is the purpose of derivation of encryption and authorization keys from master key? We're using AES-CBC and HMAC to encrypt and authenticate our messages (using encrypt-then-authenticate method).

Sometimes I see solutions (like this one) which are deriving encryption and authorization keys from single AES master key:

Kenc = AES(Kmaster, P + "1")

Kauth = AES(Kmaster, P + "2")

Questions

Is it somehow improves security (in case if P and derivation algorithm is know to attacker)? If so, does deriving Kenc from Kmaster is really a necessary step?

Using the same key for two distinct algorithms incurs the risk of interactions. An extreme example is when you use both AES/CBC for encryption and CBC-MAC as MAC algorithm: if you use the same key for both, then it is pretty obvious that the MAC can be trivially worked around. For AES/CBC + HMAC, the gut feeling of most cryptographers is that the two algorithms are sufficiently "different" from each other that these interactions do not occur, but putting a precise, mathematical definition under that term looks challenging.

Basically, this is untrodden territory, so don't do it. Deriving an encryption key and a MAC key from a given master key, using a Key Derivation Function, is the cautious and safe method: it ensures that no deadly interaction may occur. Since you have some HMAC code, use HKDF for such derivation: it is easy to implement, and has received the blessing of many cryptographers.

Alternatively, you may want to ditch both CBC and HMAC, and instead use an authenticated encryption mode which combines encryption and MAC with the same key. These are specialized modes where interactions have been thoroughly analysed, and all nasty details worked out. GCM and EAX are usable without legal hassle, and are fine; GCM is also a NIST standard and is beginning to be widely used (e.g. as part of SSL/TLS).


Website is under attack, how to deal with the constant requests When i logged on cpanel this morning, i noticed tens of thousands of requests for pages that don't exist coming from a few IPs.

links such as : /cgi-bin/1998, /cgi-bin/1999, /cgi-bin/2000 etc..

What are they trying to do and how to protect myself against it ?

They're still scanning the site as we speak.

Setup Fail2Ban, or it's equivalent, to automatically block the IP addresses scanning you. They may try again from other IP addresses but this will radically slow them down. It will also make their efforts more expensive labor-wise and in most cases, it will stop them quickly.

Fail2Ban is easy to setup quickly. Once you have more time look into tools like mod_security and integrate that into your Fail2Ban setup.


Effect of "decrypting" clear-text then "re-encrypting" it I have a (unique) situation where I receive data that is a combination of encrypted (with AES-CBC) and clear-text blocks and I cannot tell which blocks are encrypted. I plan to decrypt all of the data, including the clear-text, I receive and store it locally. Before retransmitting the data, I will encrypt it again. I need the blocks that were originally in clear-text to be in their original clear-text form for the retransmission.

If I decrypt the entire original message, even the blocks that were in clear-text, and then re-encrypt it with AES-CBC and the same key used for decryption, will the originally clear-text blocks be the same after re-encryption as they were when they were received.

Always encrypting the same text to the same value leads to data leakage, violating semantic security. To prevent this, CBC mode uses an initialization vector (IV). The IV is just a random string of bits equal to the block size of the cipher. This is XORed with the first block of clear-text to be encrypted. This makes the first encrypted block random. Each successive clear-text block is XORed with the cipher text of the previous block so that each block after the first is also random. From the Wikipedia:

The IV is then stored beside the encrypted text to allow decryption when the process is reversed:

This use of the IV ensures that encrypting the same message twice will not produce the same encrypted text. CBC mode even protects against repetition in a single cipher string. So repeating bytes in the clear-text message will not encrypt to the same byte sequence.

Note that a poorly implemented CBC encryption might reuse IVs and therefore produce the same encrypted text for the same message. See this answer for more information.


NMAP to scan ip and ports from file I want to scan IP and port from a file as below:

192.168.1.2 443
192.168.2.100 8443
192.168.3.99 80
192.168.4.11 443

How can I do that? I know there is option to take IP from a file using -iL but how can do with IP and port as for each IP there is a specific port.

As of Nmap 7.70, this is not a feature that the Nmap development team is interested in developing. Full discussion can be found in Issue #1217, but the current best practice is to scan all desired ports against all targets.

EDIT: To everyone doing some big shell script to scan each port and host individually, you'll be here all day waiting for that to finish. Accumulate all the unique ports and targets and scan them in one go. You'll end up scanning a few ports on some systems that you didn't intend, but overall it won't take that long. And like everything else, it fits into one line of Perl:

perl -lanE'END{$,="\n";open$i,">ips";say$i keys%h;exec"nmap -iL ips -p".join(",",keys%p)}$h{$F[0]}=$p{$F[1]}=1' input.txt


How dangerous is referencing a variable out of its lifetime I understand that referencing a variable out of its lifetime is a dangerous practice, and can enable someone to seriously circumvent the program logic.
However the CERT C Programming Language Secure Coding Standard (last edited in 2007) references this as a level 3 vulnerability in terms of severity, which means it can lead to the user running arbitrary code. I would like an illustration of how this could be possible, or a reference to an article explaining it.

The issue of using of using memory outside its lifetime is that its content might have changed in an unexpected way.

Consider a dynamically allocated structure with a function pointer as field. If this memory is somehow freed, it is possible that the next memory allocation request points to this memory. An attacker controlling this memory might put data in it which is then interpreted as a function pointer to malicious code. This is an example of arbitrary code execution.


How similar are bots regarding their HTTP GET request? Lets assume a botnet is attacking a website by HTTP GET flooding. To find the bots, the only way seems to be finding the similarities of the HTTP GET requests considering the URL and header fields, since the requests are sent by some script. Is this true? The URL could be crafted by the bot to contain some parameter with random fields. The headers are: HOST, Referer, User-Agent, Accept, ...

Does this idea of similarity measure work?

If the requests generated by the botnet have a distinguishable pattern from legitimate traffic, then you can manually write rules in the firewall or web server to block these requests. A more advanced product could figure out those patterns and block them automatically.

http://code.google.com/p/mod-dosblock/ is an Apache module that helps against denial of service by allowing you to write rules about the HTTP headers and about the rate those requests come in.

The quality of the denial of service tool, meaning how well it simulates legitimate traffic, would make the detection easier or impossible.


Smartphone motherboard - Does it hold any data? I recently went for a smartphone repair and got its motherboard replaced. However, it didn't occur to me to ask for the damaged motherboard back. I had confidential credentials and data stored. No doubt there is a chance the phone's storage might get copied during the repair, I'm more concerned whether the motherboard could contain any data?

(phone (Samsung note 2) had a basic password but not encrypted - should have been though)

It really depends on the device itself - without any specifics, I don't think we can really give a definite answer. I'm assuming the phone is Android, as iOS would probably be encrypted. The only real concern is any storage chips that might exist on the device.

It probably contains flash memory. Yes, unless you wiped it, confidential data will still exist on it. Usually, the operating system of the device, along with its core configuration files are stored here. This could contain anything from Wi-Fi SSIDs and passwords to SMS data.

The baseband chip is also rather likely to have cached information from the SIM card. Why? Because basebands (almost always) run proprietary software, which, in theory, could keep a copy of phone logs and SIM card information like IMSI and your phone number. However, because of the design of SIM cards, it is not possible for the baseband software (and hence an attacker) to extract the shared secrets from the SIM and clone it.

Overall, the chance of anything happening as a result is low, but it's probably worth changing your passwords. Ask the repair technician what they did with the old motherboard, and if you can get it back, dispose of it properly using thermite.


SSH Tunnelling: How can I stop users being able to access services bound to localhost via port forwarding? I want to be able to offer ssh accounts on my linux server for people to be able to use for SSH tunnelling. All accounts will be locked down with no interactive shell, for tunnelling / port forwarding purposes only. My problem is that I don't want them to be able to access services that are bound to localhost only by doing port forwards like the following:

ssh account@server -L 9999:127.0.0.1:3306 && telnet localhost 9999

Would give access to the default mysql database port.. How can I stop this?

I see options in the configuration file for OpenSSH to allow specific ports/hosts, but not to block them. Any help would be greatly appreciated :)

Port forwarding by the SSH daemon is done by a non-privileged child process of the ssh daemon.

ssh jeff@localhost -R 9999:localhost:22
sudo lsof -i
sshd      4856  jeff   10u  IPv4  21933      0t0  TCP localhost:9999 (LISTEN)

Thus we can see that the SSH process responsible for forwarding ports is owned by the user. There are fancy ways to go about tagging packets for custom handling, but I think the easiest is this:

iptables -A OUTPUT -m owner --gid-owner 1000 -d 127.0.0.0/8 -j REJECT --reject-with icmp-admin-prohibited

Put all your users into the same group, put that group in the rule, and put that rule at the top of your list before any allow rules. Note that I used 127.0.0.0/8 -- anything in the 127 netblock will get you to the local host, so don't just block 127.0.0.1.

Also, consider adding a similar rule to block access to your external interface IP. It is a crafty way to bypass the firewall rules.


How does a third party file encryption get along with OS native file encryption? I sort of understand what is meant by no security level beyond "cannot break it" but I have a much more involved question about having more than one form of encryption on a computer at once.

Suppose your using Windows 7 and as we all know Anyone can encrypt and decrypt right within the explorer menu when clicking on any file or folders.

But now lets say you want to install for example a separate encryption program (something like TrueCrypt) and you've already encrypted many of your files using Windows.

Would a program like TrueCrypt simply encrypt these (already encrypted by Windows) files or would a user need to decrypt them in Windows first before they could run a program like TrueCrypt?

Hopefully this isn't too confusing a question but I still think its a good one considering this topic of discussion.

TrueCrypt
TrueCrypt creates a disk object by inserting itself as a translation layer above an existing container - typically a partition or an entire disk, sometimes a file which will therefore contain a disk image. You then format that disk created by TrueCrypt using NTFS or FAT or EXT4 or whatever you want. TrueCrypt neither knows nor cares about the files on the disk[1], it just encrypts the disk raw. Used space, free space, deleted files.. everything. It's the disk that's encrypted, and therefore any files on it are by extension also encrypted because they're in an encrypted container.

NTFS
Windows built-in encryption is based on NTFS -- the filesystem used by Windows. NTFS takes an existing disk and decides where on it to store files. It keeps track of used blocks, file names, the location of file contents, file fragmentation, all of that. It's the set of rules used to decide where on the disk a given file goes.

Built in to the NTFS spec is the idea of encryption. Key handling is done through windows, but the important point is that the encryption happens transparently when the file is stored to disk. If the file is marked as encrypted, then NTFS will transparently encrypt/decrypt the file as it's reading or writing from the disk.

Together
You can create a TrueCrypt container and format it with NTFS. In that sense, the entire filesystem will be encrypted, but Windows won't know that. All Windows sees is the disk object exposed by TrueCrypt. It doesn't know (nor does it have to know) that TrueCrypt is transparently encrypting that data before writing it to disk. But it is.

Within that NTFS filesystem in the TrueCrypt container, you an also instruct Windows to encrypt the file. It tells the NTFS filesystem that this file is encrypted, and NTFS will dutifully encrypt the file.

Now the file appears to be in plain text to the user, but actually when it's stored to disk, the filesystem is transparently encrypting it. And then again when those encrypted bits are actually written to the physical disk, TrueCrypt is getting in there and encrypting those data blocks again, so the file is encrypted, and the disk that the file is on is encrypted.

Both are done transparently, and the whole process just works. Obviously you'll need both keys to get to the actual file data. The TrueCrypt key is your TrueCrypt password, while the Windows NTFS key is typically an x.509 private key encrypted with your Windows login password.

[1]:  Not entirely accurate, but accurate enough for this discussion.