How to protect against injection into a 3rd party REST API?

In general the answer is: you can't.

The best way to protect against injection attack is to separate data and commands.  When talking with an SQL database, this means using prepared queries.  When updating the DOM, this means using javascript methods that tell the browser "this is data to display and should not be interpreted as HTML".

Unfortunately this is one particular "backend" for which that simply is not possible, since you only have one communication channel.  You definitely can and should use proper URL encoding so that an attacker can't use your system to feed extra parameters to the third party but, for instance, there is no great way to stop an SQLi payload from moving through your system.

Certainly you could do what some do and implement a WAF.  I.e. if you see SELECT, 1=1, or other common SQLi payloads then you can refuse to pass along the request.  In general though blacklisting is not an effective security measure (there are plenty of questions on this site about bypassing WAFs) and it also tends to get in the way for regular users through false positives.  As a result I don't really recommend it.  Indeed, you don't even necessarily know what technology they use on the backend.  You might assume an SQL variant and try to detect SQLi payloads, when they are really operating a NoSQL database with a completely different syntax and vulnerabilities.  Therefore you may end up protecting against the completely wrong "kinds" of things.

All that to say: you really have no choice except to trust that the third party is practicing proper security themselves.  Which is really the only answer anyway, since as a general rule of thumb you have no control over the security of someone else.


Is using my phone number as a pin for a phone a security risk?

Your phone number is documented in a large number of places - your friends, your family, your employer, maybe even your Facebook profile and G+ profiles. Many of these people know your phone number. Some of them may even know it from memory.

The equivalent would be writing your password down in an email and sending it to your contacts list - you're not advertising the fact that it is your password but the information is out there and significantly easier to find than a password or PIN that you have memorized (which would require intimidation or  torture to get it out of you, or brute force/exploiting a vulnerability to bypass).


Password Managers: Which passwords to still remember?

I think it depends on your threat model, how you use your devices, what services you need to use, and some other details. Personally I would not enter my passwords on someone else's device (a stranger on the street?), so I would not do what you suggested in case my phone was stolen. I'd just hope my screen lock prevented the thief from accessing anything, at least until I got home on my computer to track or lock the device. If my screen was not locked, well, uhm, let's say my mitigation of this threat is still in progress.

Anyway, here's a list of passwords that I think should be remembered in general:

Password for the password manager (master password)
Password for full disk encryption of your computer
Passwords for full disk encryption of your backups (external HDDs, USB sticks, etc.)
Password for logging in or unlocking the screen of your computer
Password to unlock the screen of your phone
Passwords to access the most important services (at least your main email account from which you could reset the passwords of most of the other services)

Note that most of the above passwords won't be difficult to remember, because you are forced to use them every day (to unlock the phone, boot your computer, etc). Also, if you use an online password manager, you don't really need to worry about remembering the passwords for your backups, because if your computer blows up you can always log in to your password manager from anywhere and retrieve the passwords. But in my case, since I use a local password manager, if my computer blows up I'll have to rely on my backups and be able to access them.

So as you can see, it depends. If your threat model requires you to be able to access a certain service quickly without using your password manager, then yes, consider learning that password (or change it to a passphrase you can learn and remember more easily).


Let x be the maximum bandwidth possible on the network using the protocall without beeing detected (using the whole bandwidth of a network just for ICMP isn't really covert, is it?). Calculate y=(size usable for data in a packet)/(whole size of a packet). (Bandwidth of the covert channel) = x*y.


This is a the classic problem. I've been interested in this for some time now and I'm not aware of any standard model that really solves it out of the box (yet).

RBAC can be adapted to work for your situation by introducing parameters. There are several names that these adaptions go by, the most common is parameterized RBAC (pRBAC). I've also seen names such as Context Aware RBAC, Object Aware RBAC and relational RBAC, which are different incarnations of the same basic idea. Unfortunately, some of these terms, because there is no standardization or consensus, also refer to other access models.

There are several pRBAC concepts floating around, which all differ in detail but are still largely the same idea.
You could take a look at the papers A Design for Parameterized Roles by Mei Ge and Sylvia L. Osborn. A formal model has been described by Ali E. Abdallah and Etienne J. Khayat in their paper A Formal Model for Parameterized Role-Based Access Control.

Just as in standard RBAC, in pRBAC, a subject is assigned a role. The role consists of one or more permissions, each permission consists of an operation, object pair.
In extension to RBAC, pRBAC allows objects to have parameters and users to be initialized for a certain role with parameter values for an object they have a permission on in that role.

So, for example, the object studentCourseResult would be assigned the parameter studentId. Instead of have a role named Teacher you would define the role TeacherOf with parameter values studentId = {1, 2, 7, 9, 11}.
If the parameter value for the object is within the set of parameter values assigned to a subject for this role, access is granted.

Note that it is an easy step from here to not only allow the = operator for parameter constraints, but also allow >, <, <=, etc.

Other than pRBAC you could take a look at Attribute Based Access Control (ABAC), which is quite fashionable at the moment (but it is solving a different problem and creating new ones) and authoriZation Based Access Control (ZBAC) which is definitely a very interesting concept, but likely an overkill for the use case you describe, as it mostly (and very neatly) solves the problem of cross domain authorization.


Do I transmit a plaintext password to my PostgreSQL server?

If you don't have access to read the server configuration, the easiest way to check is to require the use of TLS on your client and see if you're able to connect successfully.  This is done through the sslmode parameter key word.  For example:
$ psql "host=12.34.56.78 port=5432 dbname=mydb sslmode=require"

After you have verified that TLS is available, you can also check to see if plaintext mode has been disabled by setting sslmode to disable.
Sidenote: The $ is not part of the command; it's to show that the line should be ran from a terminal, and does not need to be a superuser account.


Is it possible to use SSH agent for generic data encryption?

No, it is not at least with OpenSSH -- there are no options to operate in this mode.  It is for authenticating with remote servers (validating identity) and then encrypting the network traffic between ssh client application and the remote sshd server.

You could try compiling a library from OpenSSH that uses its encryption modes and create an executable based on that to use encryption, but the authors of OpenSSH did not try to do that.   Here's a github repo that took openssh and tried converting it into a library that other applications can use.

OpenSSH uses well-known protocols that are implemented in OpenSSL; e.g., my ssh connection right now uses aes128-ctr to encrypt with hmac-md5 to verify integrity (the combination).  Granted if you actually trace through to see where aes128-ctr comes from, you'll find it ultimately is taken from the OpenSSL library.  (That is in libopenssh/cipher.c tells aes128_ctr to use EVP_aes_128_ctr which is going through the header file  #include "cipher.h" (libOpenSSH which includes #include <openssl/evp.h> (note OpenSSL) which defines EVP_aes_128_ctr that ultimately traces back to being implemented (after some wrappers to deal with different modes/sizes) in openssl/crypto/aes/aes_core.c.

EDIT:

Sorry wasn't clear to me  you were talking about ssh-agent.

As to using the private keys loaded into ssh-agent to encrypt or decrypt messages, no that is not possible.  The entire purpose of the ssh-agent is to limit use of the private key to only the one acceptable function (authentication in ssh).

Look at the source code of ssh-agent and the description of the functionality in PROTOCOL.agent.  For security, ssh-agent provides a very limited interface to using the stored ssh private keys.

For ssh2, the only use of the private key is to sign requests using your private key.  With ssh1 there's also process authentication challenges, but you really shouldn't use ssh1 anymore.  The other functions don't use the private key, but deal with key management.

Key challenges in SSH1 worked as fellows.  First, the remote end sends a challenge -- a random bit-string encrypted with the user's public key (known from authorized_keys file).  The user sends the challenge to ssh-agent, which uses the private key to decrypt the challenge message.  Then, ssh-agent takes the random bit-string and calculates a cryptographic hash of it, and sends back the cryptographic hash.  This verifies that the user was in possession of the private key, and only leaks the hash of the decrypted message -- but not the actual decrypted message.

Key challenges in SSH2 now work by sending signing requests.  Again, the remote server sends a random bit-string to the user.  Then ssh-agent takes that random-bit-string and uses their private key to cryptographically sign that message -- no decryption is performed.  The signature is sent back and the server verifies the signature by using the public key to validate it.

In the context of RSA, the public key is (N = p*q, e) and the private key (N, d), where d is constructed so d*e ≡ 1 (mod (p-1)(q-1)) (d can be calculated efficiently knowing e, p and q via Euclid's extended algorithm).  Then the method of signing is to hash (with SHA1) the random message h = sha1(r) and then raise the hash to a power with the private key S = h^d (mod N).  Then the server validates the signature S with the user's public key by calculating S^e (mod N) which due to Euler's totient theorem will be the hash of the sent message, which it will compare it against S^e ≡ (h^d)^e ≡ h^(d*e) ≡ h^(1 + (q-1)(p-1)) ≡ h (mod N).


Rename important files to any file type to protect from ransomware

De facto, many ransomware variants target specific file types that promise to be valuable to the owner (text documents, images, etc.). This way the ransomware can operate more efficiently and doesn't risk the stability of the host system by accidentally encrypting system files. Hence, it's plausible that randomly renaming the extensions of important files could eventually leave them unencrypted in case of an attack.

But I'd advise against doing that because it's basically a security by obscurity pattern: You focus on an obscure hiding technique instead of preventing malware infections in the first place. Ransomware developers can take other approaches to determine the real file type (content sniffing) and not all ransomware encrypts solely based on extensions. Instead, your time is best spent at making sure your run a fully patched system and do regular backups.

You can find many ransomware threads with great advice on the site, e.g.:

Techniques to detect & mitigate Crypto-ransomware?
How does ransomware get on people's computers?
What is a good backup strategy against ransomware?


Break out of JavaScript data context to perform XSS when backslash and quotes are replaced?

How about

</script><script>alert('xss');</script><script>/*

?

JS parser will find the close script, and assume the original code is malformed. HTML parser will see the open script and start a new script block. The rest is just to make the rest of the block ignored.

Note that it doesn't contain any of the characters you're escaping - it shouldn't be affected by your sanitising code.


Is it bad practice to reuse private EC key as a shared secret for a symmetric algorithm?

Yes, it's bad practice to use a key for two different purposes. This can have obvious or subtle problems.

In this specific case, I don't see an obvious security problem. Rfc2898DeriveBytes implements PBKDF2, which is a key derivation function. Given the output, it's impossible to reconstruct the input except by guessing. Since a private key has enough entropy to be unguessable, it's impossible to find privateKeyBytes from k and deriveSalt.

Nonetheless there are several problems in your mechanism.

Don't use the EC private key as input. If you need to derive everything from a single key due to extremely limited storage, have a single root secret key and derive everything from that, including your EC private key(s). Derive each key with a different salt.
Rfc2898DeriveBytes is not the right kind of function to use here. It's a password-based key derivation function, but you don't have a low-entropy secret such as a password, you have a high-entropy secret. Use an “ordinary” key derivation function such as HKDF or a function from SP 800-108.
The salt for derivation does not need to be random. Use a constant salt, with a different value for each key that you derive from the same root. Since you can use the same salt value for a given key on every device running the same code, you can hard-code the salt values in your code.
Don't make up randomness by downloading it or other unholy made-up methods. Use your operating system's randomness source, via your cryptography library's random generation API.


Do non-browser clients work around Gmail's 2-factor authentication?

Application-specific passwords are the only workaround currently provided for applications which don't support two-factor authentication to Google. This does effectively bypass two-factor authentication, but only to a certain degree.

Obviously, the primary risk is that a compromised application-specific password can be used to access your account without requiring a second factor for authentication. Google provides a certain amount of mitigation to this risk by making the passwords much stronger than the typical user-generated password, and also by only displaying a given app-specific password once.

You should also be mitigating this by ensuring security of the environment where the app-specific password is displayed and stored, only using a given app-specific password once, and never copying an app-specific password to any location except in the password field for the application that needs it. Also, as always, don't use the application on networks that you don't trust.

You should also take advantage of the mechanisms Google provides for managing and monitoring app-specific passwords. Particularly:

Google alerts you to whenever a new app-specific password is created. Pay attention to these.
You can create custom names for app-specific passwords. Give them names that make sense to you.

Under "Select app" or "Select device" choose "Other (Custom Name)".

You can see when the last time was that an app-specific password was used. For applications that are constantly checking in, this may not be very useful information. However, if you happen to know a device has been offline for awhile and you see recent use, this can still be an indicator of trouble.
You can, and should, revoke app-specific passwords that are no longer in use or which show signs of abuse.

In the end, creation of an app-specific password effectively requires that you accept the risk of allowing that application to have permissions to your account without a second authentication factor.


Information Security and Financial Risks

This is certainly security related and if the transactions involved are done by electronic means, then it is certainly part of estimating risk and determining appropriate security measures that should be taken.  Information Security doesn't exist in a vacuum.  It is dependent on all the surrounding factors, all the way down to physical security of the building that the computers are located in.

Fraud is a type of security incident from misuse of your system, having systems to limit the risk of such incidents is well within the bounds of Information Security documentation, though the exact acceptable level of risk likely needs to come from finance or management.

Many technical measures (such as identity and/or credit checks) may also come in to place to prevent fraudulent activity as well, so Information Security needs to be specifically involved in the process rather than being brought in at the last minute.

I don't think that it is necessary to expect an Information Security person to have in-depth knowledge of particular financial fraud risks (that is why there is a finance department) but it is important to get how systems and policies should respond to those threat documented in a consistent response plan for the entire organization.


Basically, there is not difference between local IP and public IP. By convention, the last available IP of a network always is the broadcast address. However we can imagine the ISP responsible of the network would reject any packet sent to the broadcast address, or at least limit it in order to avoid spamming.

Just test it :

foo@Bar:~$ host security.stackexchange.com
security.stackexchange.com has address 198.252.206.16
foo@Bar:~$ whois 198.252.206.16
# ...
# Some stuff
# ...
NetRange:       198.252.206.0 - 198.252.206.255
CIDR:           198.252.206.0/24
# ...
# Still some stuff
# ...
foo@Bar:~$ ping 198.252.206.255 -c5
PING 198.252.206.255 (198.252.206.255) 56(84) bytes of data.

--- 198.252.206.255 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4003ms

Here we can see that the ping was dropped. Otherwise it would have return IP addresses of some machines upon the network 198.252.206.0/24.


Sending sensitive data over HTTPS and not sensitive data over HTTP?

This is a bad idea.

Unencrypted data can not only be read by a man in the middle. It can also be modified. So if just a tiny part of your HTML is unencrypted, an attacker can insert malicious JavaScript that reads the sensitive data once it is decrypted in the browser. Boom, the entire encryption is defeated.

This is also, by the way, why you need to serve your whole site and not just the login page over HTTPS.

As for your second idea, it doesn't really help anything with performance but have the same kind of troubling implications for security as your first idea. The content as a whole is not safer than the weakest link.

So why doesn't it help with performance? The main reason crypto can hurt performance is that it complicates cashing. Weaker crypto would not solve that. There might be some algorithm that is slightly faster than say AES-128 but less secure, but that would be a very marginal gain in performance that you pay for in terms of security.

And I haven't even mentioned all the work you would have to go through to separate the "sensitive" data from the "unsensitive"...

Edit: One should not be categorical... If you are e.g. programming a game you might want to send the realtime game data (who shoots what where) over something fast like unencrypted TCP, while you have a separate HTTPS connection for e.g. sending username and password to the server. But that is quite far from the HTTP webpage use case.


SSH Key vs Complex Password with Fail2Ban & Two Factor Authentication

There are 2 awnser. They differ on the attack vector under consideration .

Password based login. Is more secure when the machine that would have held the ssh-key is not protected against access to the key. (Use password protected keys always to defeat this weakness and agents for convenience).
keys are more secure when transmission matters. The ssh-keys influence the way the initial key exchange is in such a way that it is already partly encrypted with the private key.  Similar to how client side certificates work.

The difference is minor and the specific threats you want more protection against determines what choice is better here.


I have been hacked and im not sure how -- Ubuntu 14 VPS, crypto wallet

To recap:

You changed application server
You changed network parameters
You changed database server

Still to no avail. What's logically left, then is:

Your application
The load balancer

I assume the HA load balancer doesn't do much and is part of Cloudflare's services. Therefore, looks like your web application is the vulnerable point.

Have you considered getting it pentested?
Do you have multiple users/passwords?
Are you the only person with access to that server, or do you share admin credentials with other people?
Are you sure you're not rounding off values in whatever software you use? Did you check the blockchain against a third party to verify that small amounts are actually being transferred from your wallet?

If everything else fails start auditing your own computer or access methods: perhaps, as one of the comments suggest, your computer is compromised.


First of all, what are you trying to do? You are explaining how you are doing it but not what is your ultimate goal. Consider revising your question to add more detail on this.

That said, for the rest of this answer I'll assume that you're doing some sort of proxying (?) to mirror GIT repositories. Which sounds like a problem already solved, e.g. using git hooks.

Nevertheless, addressing your specific questions in order:

  Is spreading the scripts in various places playing against security ? (Harder to grasp what is going on)

Yes. At the moment you have the following "moving parts":

A PHP script that parses what seems to be the repository URL sent via a HTTP request
A shell script that calls other binaries (git)
All wrapped in sudo
Spread on many servers, as you said

An error in any of the above could result in a system compromise.

Furthermore, a problem might creep up at a later stage: what happens if you find a bug in one copy of the script and forget to replicate it on the other servers? What if git returns an obscure error you can't parse and you end up with a corruption of user data (which is then backed up corrupted)? How are errors reported? Is there a centralised log system and - more importantly - is there someone monitoring it?

  Do you see something else wrong ?

Yes and no. Your PHP script checks if there's a 'url' key in the JSON input, and if there isn't any it sets a 'return' to 'bad value'. Then it continues. This is bad practice: not a bug per se at the moment, but a bug waiting to happen. Rather than continuing, you should stop the program workflow here and return an error.

For example, what happens if in a few months somebody else adds some code like:

/* previous code */
if(preg_match('/^git@bitbucket.org:TEAM\/[a-zA-Z0-9\.-]+\.git$/',$bitBucketUrl)){
    exec(escapeshellcmd('sudo -u webadmin /home/webadmin/scripts/git-deploy.sh '.escapeshellarg($bitBucketUrl)),$results);
    $result=$results;
}else{
    $result=$bitBucketUrl;
}

/* new code */
[...]
exec('sudo -u webadmin /home/webadmin/scripts/new-stuff.sh', $bitBucketURL);

The code I added has two bugs: can you spot them?

One might think that the script new-stuff.sh is executed only if bitBucketURL contains valid data. Instead, it is executed regardless of what happens beforehand as you don't bail out in the else branches.
There's no escapeshellarg

If it took you more than a few seconds to spot the bugs, imagine someone who never saw your code before.

I purposefully omitted the escape from my code example for a reason: you should sanitize your input once and for all and keep using it rather than having to call the escape family of functions every time you need to use the user's input. It's too easy to forget a call to escapeshellargs, especially if it requires more effort (=typing). Instead, try to make the correct use of your code the path of least resistance. For example,

$bitBucketUrl=json_decode($request->getContent(),true);

could become:

$unsafe_user_input=json_decode($request->getContent(),true);
$safe_user_input = escapeshellarg($bitBucketUrl);
[...]
res = do_stuff(safe_user_input);
if (check_error(res))
{
    stop_with_error_message(message);

This way it is obvious what unsafe_user_input and safe_user_input are.

There might be other problems with your approach; the idea of executing code with the least privilege is good, but it's over-engineered here and can have nasty side-effects.


Incident Response and when to consider an incident resolved

My reluctance here is that this will impact SOC performance metrics.

So, your process of resolving an incident has 2 distinct stakeholders:

the SOC team to measure "Time to Resolution"
the infosec team to ensure "Lessons Learned" are properly actioned

Those 2 stakeholders are at odds with each other. And you're trying to get clever at satisfying both parties.
I wouldn't take a NIST or even an infosec approach to trying to address this. This is a pure process design issue.
The resolution date belongs to the SOC. The ticket is theirs and their responsibility comes to an end long before the various projects end. The infosec team needs to find another tool to track the projects it wants to generate and stop leveraging the ticketing tools as its project management tool.
If that doesn't work, add a new date to the ticketing system to reflect when the Response phase ends, and use that for your SOC performance metrics.


New SSL certificate not being trusted on all clients

Run Windows Update. I think you might have missed one of the regular Microsoft root certificate program updates.
Edit: Windows downloads CAs on demand, too
Windows has a mechanism that will check and add new CAs to the trust store upon contact.
Combined with the limitations on web access I imagine this might be responsible for the admin/nonadmin difference.


How to handle OAuth2 refresh_token for sessionless login?

If you want to guarantee they will remain logged in for 30 days then that is the most secure way to do it. And yes, it's not secure at all. It's a usability / security decision you will have to make depending on the risk. You can do something like encrypt it but you would have to store the key in local storage too so it's not any safer.


Should I be worried if somebody uses my email to sign up for accounts?

I would have performed the same actions.  Confirm the validity of the website, and request the account be removed.

I don't believe you've exposed yourself to more risk at all by contacting these services.  The key to performing the above is to not actually click the link in the email.   Go to the service's webpage separately where you can verify the certificate, and if everything checks out email their support team about the fraudulent account.  This allows you to do your homework first without clicking on possible phishing links within emails.

You should always remove accounts that are linked to your email.  Even if your account isn't compromised malicious actors could be using the appearance of your email to gain the trust of others.

As far as a compromised account; if you're worried then I would change your password for the account, and ensure it's a good one.  16 characters will various symbols and numbers.  I would also turn on 2 Factor Authentication if your email service provides it.  This will lock down the account, and help you manage who is logging in.


How Wifi prevent hacking in the same network?

Security for WPA PSK effectively revolves around the secrecy of the key. Anybody who has the key is allowed to connect to the network, and can also decrypt the traffic in the correct circumstances. As long as the key is strong and not shared with the entire world, it is considered reasonably secure for many use cases.
Even if you couldn't decrypt the wireless traffic passively, being able to connect to the network is even more beneficial for an attacker, since a variety of attacks can be launched from there to accomplish the same and more (albeit more noisily). So it could be said that passive decryption with knowledge of the PSK is not a vulnerability since you already have the keys to the kingdom at that point.
If this issue is unacceptable for your threat model, you can use WPA2/WPA3 enterprise instead, which removes the issue of shared keys entirely.


The SSL protocol specifies the way a server sends its certificate to the client. The client should then "obtain" the server public key by validating the certificate. The SSL specification does not describe certificate validation; for that, you must look at X.509, in which you will see that it is a much more complex process than what is described in the document you link to.

Checking revocation status is part of certificate validation. The client is actually free to do it in any way it sees fit; many web browsers "check" revocation status by a process which goes like "mmhh... it is probably not revoked anyway, no need to check anything". In the X.509 world, revocation status can be ascertained by downloading and validating CRL (Certificate Revocation Lists) or obtaining OCSP responses from OCSP responders (an OCSP response is a kind of CRL reduced to a single target certificate). Theoretically, revocation status should be obtained for all certificates, i.e. the server certificate but also the intermediate CA certificates used to validate the server certificates, and all other certificates used to validate CRL and OCSP responses (this can become highly recursive). The aggregate cost (especially in download time) can become prohibitive, which is why many client rely on a weaker but faster model (e.g. checking status only for the server certificate itself, not the intermediate CA; or checking no status at all).

Anyway, validation is how the server public key is obtained, so it occurs during the SSL handshake, right before the ClientKeyExchange message is sent by the client.


How applications are installed in TEE and REE

The installation of TEE application purely depends on the TEE that you choose. There are so many TEE vendors in the market. General methods of TEE application installation are

Build the TEE application statically in the TEE itself.
Install the TEE application from the REE file system. There are commands available to install these applications to secure memory from TEE


I can't explain it as anything beyond legacy madness, or lazily copying username restrictions to password restrictions without forethought.

Any block of data, printable or otherwise, should be acceptable if you're hashing your passwords. The only restrictions should be a minimum complexity and a "sanity" maximum length so somebody doesn't soak up 1MB of bandwidth (and the corresponding CPU time to hash the input because you use a slow algorithm, right?) every time they login.


This depends on how savvy the programmer of the malicious binary decides to be.

If it's a simple binary I would suggest first downloading Strings for Windows.  It's a version of the Linux programs of the same name.  It runs through and prints out all strings in a binary.  If the binary isn't encoded or packed this should give you what you want to know.  Once installed:

Bring up a command prompt: WindowsKey + r, type cmd and hit ENTER
cd <directory/of/binary>
strings <binary_name>.exe

A lot of output will be printed to the screen.   You can use strings <binary_name>.exe > output.txt to write it to a file.

If the binary is packed or encoded the easiest way to analyze a Windows binary for these things is a tool called PE Insider or CFF Explorer. PE Insider allows you to quickly look at the Portable Executable's headers, performs quick decompilation, and simple analysis.  CFF Explorer allows you to decode and unpack other resources within the binary.

The links provided should give you enough resources on how to use those tools.  For more information on malware analysis you can checkout How to Analyze a Piece of Malware, and Topics to Know When Analyzing Malware.


Can public keys in digital certificates be used to verify name of certificate holder?

You are mostly correct.

The public key of a certificate is not used to proof any information in the certificate itself. The public key of the issuer CA instead can be used to verify the certificate signature which encompasses both the certificates public key, subject, expiration, usage, extensions etc.

But even with the issuers key the name of the certificate holder cannot be verified. It can only be verified that the issuer CA has signed the certificate. Only if one believes that the issuer has properly verified that the name in the certificate actually belongs to the entity who submitted the certificate request one can assume that this is the name of the certificate holder. In other words: issuer key is not enough, but issuer key combined with trust in issuer is needed.


Is it safe to run virus (infected executable) inside VirtualBox?

Your question differs from the one stated in your post. Is it safer? Yes, it is safer to execute programs in a virtual machine but it is not complete safe (then again, what is?). You can escape a virtual machine a vulnerability is used, in this case within VirtualBox.

You also have to keep in mind that setting up the virtual machine poorly will allow malicious code to escape the virtual machine. This all depends on you.

It depends on the malware itself what they can cause. It can vary from using your computer or virtual machine in a botnet to destroying all files on the computer.

Edit It was brought to my attention this question is a duplicate, see this answer for a more detailed answer to your question.


If you just want to block a specific IP:

iptables -A INPUT -s 1.2.3.4 -j DROP

You can't reject a TCP connection which has the later intent of visiting a particular URL, because the TCP connection has to be made before that information can be transferred.

To be honest, I wouldn't worry about it. It's probably a drive-by attack against a random plugin or CMS that you don't have. If your server is responding with a 404, there's not much you can do in response. There's no real security threat to mitigate here.

That being said, you could look into installing mod_security to provide some generic blanket security protection against drive-by attacks.


If you wanna run in Pcap live mode then you should turn-ff AF_PACKET mode from suricata configuration file: suricata.yaml.

# Linux high speed capture support
af-packet:
  - interface: lo

you got error because of af-packet packet capturing mode, probably not configure properly.

7/9/2018 -- 19:32:29 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn't init AF_PACKET socket, fatal error


You state that "I guess one should now consider that all chips over a given complexity are possibly back-doored in this way or in hardware" and then ask "what kind of chips can be safe?" The Arduino or Raspberry Pi, although less complex than PC chips, are still much more complex than the room-sized supercomputers of old.

Additionally, you make the assumption that hardware may be backdoored but the OS may not.  I think that contradicts the premise of your question: how we keep digital communications from being snooped upon?

I'm going to steal from @Hector above.  Based upon the question, I can really only see one possible technical solution: air-gap the devices and only allow specific USB disks between the two communicating devices.  No other USB disks would be allowed, and the message disk would only be allowed in the communicating devices.  Then, to encrypt that communication, use only a one-time cipher based on something random and then padded with a list of names from the Prague phone book.  (czech names would make a frequency distribution crack more difficult due to the way that names are spelled).  Also the drive in transit would need to be kept secure in a container that cannot be opened without destroying the USB disk, where only the sender and recipient have keys which vary from day to day.

That trades the security desired with usability, however.  The users of that system would find it a huge pain in the Mikta.


In Ephemeral Diffie Hellman Key Exchange - what is actually ephemeral?

A & B are called the ephemerals that Alice and Bob exchange. It's not more complicated than that. There are other ways to use Diffie Hellman, for example DSA - Digital Signing Algorithm in which the term ephemeral does not appear.

Also, usually, (P,g) are fixed not only for a website, but for much of the internet (via RFCs) which is related to the recent revelation about the Logjam attacks and NSA likely hackings. Here's my write up on that. In any event, (P,g) are complicated to create, so most people use the ones that are already out there. Therefore, they don't change much. Given the recent exposures, it looks like we need to use bigger ones or you can compute your own (should be a big P).

(a,b) are not recomputed periodically except by policy for some network security protocol or, in the case of TLS, cipher suite configuration. I'm not familiar enough with TLS cipher suite config to answer that question. Generally, for improved security a network session should recompute session keys on a periodic basis. This is usually 8 hours, although it can be shorter or longer. Nothing in math requires the recomputation, it's only advised.


what is the role of RADiUS server and Active Directory to increase the security in wireless networks?

No, because the accountability is too low and chances are high your WPA2 password would leak out. When using RADIUS all users have their own password and usernames to authenticate to the AP.

Chances of users sharing the WPA2 password to the wifi network is larger than them sharing their own personal username and passwords. This increases security in two ways:

not everyone will leak passwords
If you want you can track your users and see who's done what

The last part is not possible when using WPA2 with a shared password between  the users.


How to correctly escape a string from an input field, preventing XSS attacks in JavaScript

I'm quite new to coding so I copy/pasted it to my JavaScript function and doesn't appear to be working.

It might not be working because ESAPI is a library you have to reference in an HTML script tag; it isn't part of core javascript that comes with the browser. ESAPI seems to be available from github, which also contains a README.md file that explains how to load it in HTML. May you missed that part? Your question doesn't say.

Also, note that it should be

var safe = ....

not just

safe = ....

This is important in javascript. You don't want to create global variables and pollute the global namespace if you can help it.

  Valid characters for my applications are only the numbers [0-9] and a dot (.).

In that case, I'd suggest you use a javascript regular expression to see if your input matches these characters, and show an error message if it doesn't. ESAPI seems to be overkill for that. Validating "known good" input is much safer than trying to think of all problematic inputs and removing/transforming that via a sanitation routine. Do something like that:

var validationRegex = new RegExp('^[0-9.]+$');
var text = document.getElementById("this").value;
if (text.match(validationRegex)) { }; // do something when text matches

I don't have all that much javascript experience, so you might want to read up on how regular expressions work in javascript to doublecheck that code. Take care with the dot character - outside of [ ], it stands for "any character except newline" in regular expressions.

Finally, if you're sending your extracted input field data to a server (I'm cleverly assuming that you don't just want to output the data via alert(safe) - in which case you wouldn't need to sanitize it in the first place), it would be much better to sanitize the data on the server, because there you can trust the sanitation. If you sanitize on the client, a malicious user might still send your server unsanitized data.


I almost searched my password, but didn't press enter. Is my password at risk, because of autocomplete or anything else?

I highly doubt it.

You didn't press enter but Google will sometimes send the information to quickly present your results. This is forced over HTTPS. Your information was likely encrypted and not exposed.
According to most sources Google processes on average 3.5 billion searches per day. There is no additional information to prove your query is a password. Nor is there any public way for a person to get the search queries of a particular Google user. So they would have to be an actual employee of Google. The likelihood of a internal Google employee to trying your search queries as passwords to your account is highly unlikely. It might not even be possible for most standard Google employees to get such identifying information. But if so, the possibility of one with such access purposely targeting you is astronomical.
Again, there is no additional context to prove it is your password. Nor is your user information submitted with your query. So in the event of a MITM attack where they can read your traffic I would still factor it as real low as they would also have to have your username.

I am going to flat out say there 99.9% chance you have nothing to worry about. If you are wearing a tin foil hat or still have a nervous tick then change your password. If you don't use this password elsewhere then you're golden since it isn't like they could log in with an old password. Otherwise I would move on and not worry about it.

Edit: @reirab made a point it could make it pop up in features that use your search history. I don't believe this happens if you don't press submit. But if you want to be sure clear your search history with Google. I can't be sure this clears it from Google's servers but it should prevent them from popping up in the auto-complete.


How do I secure a nonce value within app whose source code is public?

I'm one of the core maintainers of Nylas N1. I think the other answer is good general advice, but here are a couple more tips specific to N1:

If you want to secure a process or algorithm, you can write it in a native node module which is distributed in binary form. We don't currently do this, but many other JavaScript based apps do (Spotify's DRM is in a C++ library they distribute alongside the JS.)
If you want to authenticate the client with a service, use 3-legged OAuth. With 3-legged OAuth you distribute the Application ID but not the Application Secret in the client. When the user signs in, a Code is returned, and you hand that Code to your own server (the third leg), where the Application Secret is used to exchange the code for a token, which is sent back to the client. This process is a pain to implement, but ensures that the only sensitive tokens the client ever has are for accounts the user authenticated.
If you want to store tokens, user API keys, etc. client-side, we suggest using node-keytar. It's already available in N1 via require('keytar'). It provides a simple API for storing secrets in the user's keychain on Mac, Windows, and Linux. We currently use it to store N1 API tokens.

Hope that helps! Feel free to reach out to me or other Nylas engineers on our community slack channel at http://slack-invite.nylas.com/


Using sqlmap and testing parameters inside SEF URL alias

AFAIK it should work out of the box as sqlmap keeps the values, however, on the chance that it doesn't work, here are some easy work arounds that come to mind:

You could tweak the url by appending an injection to be more sql injection friendly to begin with, ie: http://example.com/alias-text-22565-(case when 1=1* then 1)/description as described here: http://pentestmonkey.net/blog/exploiting-a-tricky-sql-injection-with-sqlmap. This is the method I usually use, but it does require you to have some knowledge of sql injections.
You could feed sqlmap through an intercepting proxy such as burp or zap and add a replace rule to replace 22565 with alias-text-22565 and invoke sqlmap with the url http://example.com/22565*/description
You could write a quick tamper script that would prepend alias-text- to the url and invoke sqlmap with the url http://example.com/22565*/description


Best practices for Tor use, in light of released NSA slides

As a very long time Tor user, the most surprising part of the NSA documents for me was how little progress they have made against Tor. Despite its known weaknesses, it's still the best thing we have, provided it's used properly and you make no mistakes.

Since you want security of "the greatest degree technically feasible", I'm going to assume that your threat is a well-funded government with significant visibility or control of the Internet, as it is for many Tor users (despite the warnings that Tor alone is not sufficient to protect you from such an actor).

Consider whether you truly need this level of protection. If having your activity discovered does not put your life or liberty at risk, then you probably do not need to go to all of this trouble. But if it does, then you absolutely must be vigilant if you wish to remain alive and free.

I won't repeat Tor Project's own warnings here, but I will note that they are only a beginning, and are not adequate to protect you from such threats. When it comes to advanced persistent threats such as state actors, you are almost certainly not paranoid enough.

Your Computer

To date the NSA's and FBI's primary attacks on Tor have been MITM attacks (NSA) and hidden service web server compromises and malware delivery (FBI) which either sent tracking data from the Tor user's computer, compromised it, or both. Thus you need a reasonably secure system from which you can use Tor and reduce your risk of being tracked or compromised.

Don't use Windows. Just don't. This also means don't use the Tor Browser Bundle on Windows. Vulnerabilities in the software in TBB figure prominently in both the NSA slides and FBI's recent takedown of Freedom Hosting. It has also been shown that malicious Tor exit nodes are binary patching unsigned Windows packages in order to distribute malware. Whatever operating system you use, install only signed packages obtained over a secure connection.
If you can't construct your own workstation capable of running Linux and carefully configured to run the latest available versions of Tor, a proxy such as Privoxy, and the Tor Browser, with all outgoing clearnet access firewalled, consider using Tails or Whonix instead, where most of this work is done for you. It's absolutely critical that outgoing access be firewalled so that third party applications or malware cannot accidentally or intentionally leak data about your location. If you must use something other than Tails or Whonix, then only use the Tor Browser (and only for as long as it takes to download one of the above). Other browsers can leak your actual IP address even when using Tor, through various methods which the Tor Browser disables.
If you are using persistent storage of any kind, ensure that it is encrypted. Current versions of LUKS are reasonably safe, and major Linux distributions will offer to set it up for you during their installation. TrueCrypt is not currently known to be safe. BitLocker might be safe, though you still shouldn't be running Windows. Even if you are in a country where rubber hosing is legal, such as the UK, encrypting your data protects you from a variety of other threats.
Remember that your computer must be kept up to date. Whether you use Tails or build your own workstation from scratch or with Whonix, update frequently to ensure you are protected from the latest security vulnerabilities. Ideally you should update each time you begin a session, or at least daily. Tails will notify you at startup if an update is available.
Be very reluctant to compromise on JavaScript, Flash and Java. Disable them all by default. The FBI has used tools which exploit all three in order to identify Tor users. If a site requires any of these, visit somewhere else. Enable scripting only as a last resort, only temporarily, and only to the minimum extent necessary to gain functionality of a web site that you have no alternative for.
Viciously drop cookies and local data that sites send you. Neither TBB nor Tails do this well enough for my tastes; consider using an addon such as Self-Destructing Cookies to keep your cookies to a minimum. Of zero.
Your workstation must be a laptop; it must be portable enough to be carried with you and quickly disposed of or destroyed.
Don't use Google to search the Internet. A good alternative is Startpage; this is the default search engine for TBB, Tails and Whonix. Another good option is DuckDuckGo.

Your Environment

Tor contains weaknesses which can only be mitigated through actions in the physical world. An attacker who can view both your local Internet connection, and the connection of the site you are visiting, can use statistical analysis to correlate them.

Never use Tor from home, or near home. Never work on anything sensitive enough to require Tor from home, even if you remain offline. Computers have a funny habit of liking to be connected... This also applies to anywhere you are staying temporarily, such as a hotel. Never performing these activities at home
helps to ensure that they cannot be tied to those locations. (Note that this applies to people facing advanced persistent threats. Running Tor from home is reasonable and useful for others, especially people who aren't doing anything themselves but wish to help by running an exit node, relay or bridge.)
Limit the amount of time you spend using Tor at any single location. While these correlation attacks do take some time, they can in theory be completed in as little as a day. (And if you are already under surveillance, it can be done instantly; this is done to confirm or refute that a person under suspicion is the right person.) While the jackboots are very unlikely to show up the same day you fire up Tor at Starbucks, they might show up the next day. I recommend for the truly concerned to never use Tor more than 24 hours at any single physical location; after that, consider it burned and go elsewhere. This will help you even if the jackboots show up six months later; it's much easier to remember a regular customer than someone who showed up one day and never came back. This does mean you will have to travel farther afield, especially if you don't live in a large city, but it will help to preserve your ability to travel freely.
Avoid being electronically tracked. Pay cash for fuel for your car or for public transit. For instance, on the London Underground, use a separate Travelcard purchased with cash instead of your regular Oyster card or contactless payment. Pay cash for everything else, too; avoid using your normal credit and debit cards, even at ATMs. If you need cash when going out, use an ATM close to home that you already frequently use. If you drive, try to avoid number plate readers by avoiding major bridges, tunnels, motorways, toll roads and primary arterial roads and traveling on secondary roads. If the information is publicly available, learn where these readers are installed in your area.
When you go out to perform these activities, leave your mobile phone turned on and at home. If you need to make and receive phone calls, purchase an anonymous prepaid phone for the purpose. This is difficult in some countries, but it can be done if you are creative enough. Pay cash; never use a debit or credit card to buy the phone or top-ups. Never insert its battery or turn it on if you are within 10 miles (16 km) of your home, nor use a phone from which the battery cannot be removed. Never place a SIM card previously used in one phone into another phone, as this will irrevocably link the phones. Never give its number or even admit its existence to anyone who knows you by your real identity. This may need to include your family members.

Your Mindset

Many Tor users get caught because they made a mistake, such as using their real email address in association with their activities, or allowing a hostile adversary to reach a high level of trust. You must avoid this as much as possible, and the only way to do so is with careful mental discipline.

Think of your Tor activity as pseudonymous, and create in your mind a virtual identity to correspond with the activity. This virtual person does not know you and will never meet you, and wouldn't even like you if he knew you. He must be kept strictly mentally separated. Consider using multiple pseudonyms, but if you do, you must be extraordinarily vigilant to ensure that you do not reveal details which could correlate them.
If you must use public Internet services, create completely new accounts for this pseudonym. Never mix them; for instance do not browse Facebook with your real email address after having used Twitter with your pseudonym's email on the same computer. Wait until you get home.
By the same token, never perform actions related to your pseudonymous activity without using Tor, unless you have no other choice (e.g. to sign up for a service which blocks signup via Tor). Take extra precautions regarding your identity and location if you must do this.

Hidden Services

These have been big in the news, with the takedown of high-profile hidden services such as Silk Road and Freedom Hosting in 2013, and Silk Road 2.0 and dozens of other services in 2014.

The bad news is, hidden services are much weaker than they could or should be. The Tor Project has not been able to devote much development to hidden services due to the lack of funding and developer interest (if you're able to do so, consider contributing in one of these ways).

Further, it is suspected that the FBI is using traffic confirmation attacks to locate hidden services en masse, and an early 2014 attack on the Tor network was actually an FBI operation.

The good news is, the NSA doesn't seem to have done much with them (though the NSA slides mention a GCHQ program named ONIONBREATH which focuses on hidden services, nothing else is yet known about it).

Since hidden services must often run under someone else's physical control, they are vulnerable to being compromised via that other party. Thus it's even more important to protect the anonymity of the service, as once it is compromised in this manner, it's pretty much game over.

The advice given above is sufficient if you are merely visiting a hidden service. If you need to run a hidden service, do all of the above, and in addition do the following. Note that these tasks require an experienced system administrator who is also experienced with Tor; performing them without the relevant experience will be difficult or impossible, or may result in your arrest. The operator of both the original Silk Road and Silk Road 2.0 were developers who, like most developers, were inexperienced in IT operations.

Do not run a hidden service in a virtual machine unless you also control the physical host. Designs in which Tor and a service run in firewalled virtual machines on a firewalled physical host are OK, provided it is the physical host which you are in control of, and you are not merely leasing cloud space. It is trivial for a cloud provider to take an image of your virtual machine's RAM, which contains all of your encryption keys and many other secrets. This attack is far more difficult on a physical machine.
Another design for a Tor hidden service consists of two physical hosts, leased from two different providers though they may be in the same datacenter. On the first physical host, a single virtual machine runs with Tor. Both the host and VM are firewalled to prevent outgoing traffic other than Tor traffic and traffic to the second physical host. The second physical host will then contain a VM with the actual hidden service. Again, these will be firewalled in both directions. The connection between them should be secured with a VPN which is not known to be insecure, such as OpenVPN. If it is suspected that either of the two hosts may be compromised, the service may be immediately moved (by copying the virtual machine images) and both servers decommissioned.

Both of these designs can be implemented fairly easily with Whonix.
Hosts leased from third parties are convenient but especially vulnerable to attacks where the service provider takes a copy of the hard drives. If the server is virtual, or it is physical but uses RAID storage, this can be done without taking the server offline. Again, do not lease cloud space, and carefully monitor the hardware of the physical host. If the RAID array shows as degraded, or if the server is inexplicably down for more than a few moments, the server should be considered compromised, since there is no way to distinguish between a simple hardware failure and a compromise of this nature.
Ensure that your hosting provider offers 24x7 access to a remote console (in the hosting industry this is often called a KVM though it's usually implemented via IPMI) which can also install the operating system. Use temporary passwords/passphrases during the installation, and change them all after you have Tor up and running (see below). Use only such a tool which is accessible via a secured (https) connection, such as Dell iDRAC or HP iLO. If possible, change the SSL certificate on the iDRAC/iLO to one you generate yourself, as the default certificates and private keys are well known.

The remote console also allows you to run a fully encrypted physical host, reducing the risk of data loss through physical compromise; however, in this case the passphrase must be changed every time you reboot the system (even this does not mitigate all possible attacks, but it does buy you time).

If the system was rebooted without your knowledge or explicit intent, consider it compromised and do not attempt to decrypt it in this manner. Silk Road 2.0 apparently failed to encrypt its hard drives, and also failed to move service when it went down in May 2014, when it was taken offline by law enforcement to be copied.
Your initial setup of the hosts which will run the service must be in part over clearnet (via a Tor exit node), albeit via ssh and https; however, to reiterate, they must not be done from home or from a location you have ever visited before. As we have seen, it is not sufficient to simply use a VPN. This may cause you issues with actually signing up for the service due to fraud protection that such providers may use. How to deal with this is outside the scope of this answer, though.
Once you have Tor up and running, never connect to any of the servers or virtual machines via clearnet again. Configure hidden services which connect via ssh to each host and each of the virtual machines, and always use them. If you run multiple servers, do not allow them to talk to each other over the clearnet; have them access each other via unique Tor hidden services. If you must connect via clearnet to resolve a problem, again, do so from a location you will never visit again. Pretty much any situation which would require you to connect via clearnet indicates a possible compromise; consider abandoning it and moving service instead.
Hidden services must be moved occasionally, even if compromise is not suspected. A 2013 paper described an attack which can locate a hidden service in just a few months for around $10,000 in cloud compute charges, which is well within the budget of even some individuals. As noted earlier, a similar attack took place in early 2014 and may have been involved in the November 2014 compromise of dozens of hidden services. How often is best to physically move the hidden service is an open question; it may be anywhere from a few days to a few weeks. My best guess right now is that the sweet spot will be somewhere between 30 to 60 days. While this is an extremely inconvenient timeframe, it is much less inconvenient than a prison cell. Note that it will take approximately an hour for the Tor network to recognize the new location of a moved hidden service.

Conclusion

Anonymity is hard. Technology alone, no matter how good it is, will never be enough. It requires a clear mind and careful attention to detail, as well as real-world actions to mitigate weaknesses that cannot be addressed through technology alone. As has been so frequently mentioned, the attackers can be bumbling fools who only have sheer luck to rely on, but you only have to make one mistake to be ruined.

The guidelines I have given above are intended to make it harder, more time-consuming and more expensive for attackers to locate you or your service, and whenever possible to give you warning that you or your service may be under attack.

We call them "advanced persistent threats" because, in part, they are persistent. As the US attorney Preet Bharara said announcing the Silk Road 2.0 raid, "We don't get tired." They won't give up, and you must not.

Further reading

Chatting in Secret While We're All Being Watched
Mostly good advice from one of the journalists who communicated with Edward Snowden. The only part I can really disagree with is the possibility of using your existing operating system or smartphone for communication. As we've seen already, this cannot be done safely, and you must prepare a computer with something like Whonix or Tails.
Selected Papers in Anonymity An extensive collection of anonymity-related research, some of which has been presented here. Go through this to get a feel for just how difficult remaining anonymous really is.


How does Memory Corruption apply to Android?

Most of the Android applications are written in Java. As long as you don't use native code, it's not possible to cause buffer overflow or memory corruptions. In android it's possible to use native code and compile them using Android NDK. Applications like Firefox and Chrome are using native codes.

Many opensource libraries can be compiled for android e.g. libpng. So a vulnerability in libpng for linux is also applicable for libpng in Android.


Why is it a bad idea to store my ethereum keyfile in my Google Drive / Dropbox etc

This question comes down to how much you really trust service providers like google and dropbox to properly secure your data. If you trust google to keep your information secure and safe, then by all means store it with them.

You ask:

  Overall, since my key file is protected by password, what use is it hiding its location? Doesn't that just increase the risk of me losing it?

This is why most people store their "private key" to their crypto wallets in a secure location (like a lockbox at a bank). The private key isn't password protected, it is usually a string of 12 words that can be used to restore a wallet.


This is not possible. The configuration interface of a router is running HTTP, which uses TCP at layer 4. For TCP connection to be succesful to start talking HTTP at layer 7, you would need to have the following handshake:

The problem with IP spoofing in regards to TCP is that this is not possible. With just IP filtering you will be able to send the first SYN past the firewall, but your router will respond to the person having the actual IP with SYN-ACK, meaning you will never be able to send ACK. This means there is no handshake possible and thus you will not be able to talk HTTP to your router.


Under which conditions wouldn't a script tag run

You can find the answer if you peak at the source code.

The


How can I decrypt a Word document that I know the password to without opening it in a word processor?

This one decrypts password-protected DOCX documents and has no dependencies apart from Python crypto library https://github.com/nolze/ms-offcrypto-tool


Cryptographic Security of Dynamically Generated, Non-Random Salts

You are somewhat mistaken about the role of the salt. It is not meant to be "unguessable by the attacker". If it was meant to be unguessable, it would be a piece of confidential data, and we would call it a "key", not a "salt".

The salt is there to make the password derivation process unique, in order to prevent an attacker from making economies of scale when attacking several passwords. If the attacker tries to guess three passwords, it must cost him three times as much as attacking one. One big fat example of "economy of scale" is a big table of precomputed hashes for common passwords (or its evil offspring, the rainbow table, which is just an enormous precomputed table with a trick to keep it merely huge). In the presence of a salt, there is not one hash function, but one per salt value; or, said otherwise, a precomputed table would be specific to a given salt (the one used during the computation) and worthless for attacking any password which does not use that salt.

Of course, if an attacker could get a copy of the hashed passwords but not the corresponding salts, his task becomes very hard indeed. But this is not a plausible scenario: if you have a storage area where you can put the salts out of reach of the attacker, then why did you not store the hashed passwords there too ? So the security analysis assumes that the salts are known to the attacker. Their usefulness stems from their uniqueness: no two distinct hashed passwords, on the same or different systems, at the same or different times, have the same salt value (not even two successive passwords for the same user: when you change the password, you also change the salt).

You can generate and store salts in any way that you see fit, even with a "dynamic generator", as long as the probability of reusing a salt value is negligible. This is so precisely because they are supposed to be public and need not be "unguessable" by the attacker -- unguessable things require heavy artillery.

There is a slightly related concept which has sometimes been called "pepper": a secret key which is also inserted into the hashing process (see this previous question). That key is shared system-wide. The idea would be that a unique key is easier to keep confidential than a whole database of hashed passwords, at least in some configurations (e.g. you keep it in a private configuration file, not the SQL database). The "pepper" concept implies a more complex management (one more thing to backup and not lose, or share between front-end servers) and is worth anything only in the fringe scenario where an attacker can dump the user database but not the complete host system. In any case, the "pepper" does not realize the uniqueness property that the salt provides, so the pepper must not replace the salt -- only possibly complement it.


PSExec not working against windows XP (metasploit)

Try setting the SMBDomain to a single dot "." or the system name rather than WORKGROUP and see what happens.


Why can I still receive email at my old domain after someone else bought it?

Are my email accounts still working simply due to the new registrant not changing the MX records?

Most likely.

As an aside; how is it possible for me to manage DNS for a domain I don't own?

If your registrar is minimally professional, no.

Why am I able to put up a website on a domain that is no longer
registered to me?

You can put up a domain for nasa.gov if you want. Just create a VirtualHost on Apache, a couple HTML pages saying you are NASA, and you are done.
Easy, right? But don't expect anyone to type www.nasa.gov and end up accessing your server.
Now, on your issue: the new owner of your domain may have acquired the domain and never bothered to change anything: MX records, CNAME, A and AAAA records. So if you create a page and put on the previous server, it will still work, because all addresses are pointing to your original server. But this is not permanent: as soon as the new owner changes the records, your site is not accessible at this domain anymore.


Is e-mailed cryptic download link considered secure?

Depends on your definition of secure.

For something to be secure, it should have the following three components of C.I.A (at minimum):

Confidentiality
Integrity
Availability

Does this link meet C.I.A requirements?

Having a download link like this: https://example.com/de2e1ecd-d5ee-42a7-8980-969961a4f397 meets the definition of confidential in and of itself because it is computationally infeasible  to find this file on purpose without prior knowledge of where it is. Brute forcing the site and trying every possible combination would take millennia.

The example uses SSL (TLS) so it is protected in-transit as well.

This does not meet the integrity requirement. We have no way of knowing if this document was altered by a MiTM attack, was changed by a bad actor at the server, etc... The file just is sitting on the server.

This file link does meet the availability requirement. Navigate to the URL, get the data. Doesn't get more available than that.

Where does the security break down?

The security of this link breaks down when you start to transmit the link to people to make it available.

Transmitting the link in plain text via email breaks any security that the GUID-named file ever gave you because unauthorized people can get access to the plain text URL.

In order to maintain the security, you would need to use a method of communication that used both encryption and authentication. Encryption protects the URL in-transit, and authentication ensures the person reading it is the correct person, and allows them to ensure the person who sent it really was you. (This adds even more complexity because computers cannot really guarantee the person reading the message is the intended recipient. An unattended, unlocked iPhone, the recipient held at gunpoint and forced to open the message, etc... could all be possibilities on how the message could be read by unauthorized personnel.)

This link never had integrity, so it can't be broken.

This link's availability is still maintained here.

How can you improve the security of the link?

Add a password for access to the system. A good on. 16+ characters, which are randomly generated from a password generator. This opens up yet another issue of password security, but for now, just use random passwords at a minimum length of 16. This adds a second factor, and secures the link against eves droppers. Of course, you can easily break this as well if you send the password in the same email as the link. The password must at minimum be sent out-of-band. (Email link, call and tell them the password). NextCloud and ownCloud offer this obfuscated link + password option, for example.
Use GPG / PGP to send the information to the recipient. This allows you to encrypt the message and sign it prior to sending it to the recipient. The recipient also has to have their password to decrypt the message. In this scenario, the information is properly and safely transmitted to a recipient, which maintains the integrity of the GUID link. Alternatively, you can use Signal or WhatsApp, which make this same process transparent and have widely accepted security standards and protocols.
Use public key cryptography to sign the document. Signing the document at the download location allows remote users to verify the document is in its exact, intended state and has not been tampered with since the original author authored it.

How much is too much?

You have to decide what your threat model is. What problems could you have if this file "gets loose?" If it's pricing for a customer, which may be different on a per-customer basis, and you don't want the customer to be able to guess another account to shop you, just the link is probably sufficient. If you're transferring confidential secrets that you don't want the company IT guy to find if he's bored, you're going to have to step it up a notch. If you're transmitting government secrets... well ... you get the point. Figure out what you are worried about first, then define the security parameters that need to be met within that context.

References

Information Security - Basic Principles


Security Alert - Office File Validation - how to decide whether to proceed?

If the document comes from a trusted source delivered to you in a secure manner, I would proceed with opening the document. In this scenario, I would consider the chance of it being a false positive to be high enough to warrant proceeding with getting your work done.

However, if the document comes from an untrusted source, or is delivered through a manner that might have the potential for a malicious attacker to modify the file, I would try to work out a solution with the party that provided the document, or just not open the file.

There is also a chance that the source, although trusted, might have been infected with malware that is trying to propogate via the document. Thanks @Polynomial for pointing that out.

A way to check if the document is really malicious would be to execute the document in a sandboxed environment like a virtual machine, which should prevent malware from spreading into your host operating system, if any is present. This is quite troublesome though, and involves highly technical skills such as malware analysis - which the average user does not have.

A lot of it comes down to your risk appetite. How much do you trust the person who provided the document? How much do you trust the delivery mechanism?

In your case - I would proceed, but it is difficult to provide a general answer as different situation requires different actions.


Am I legally required to give passwords or keys for encypted data during an criminal investigation?

This depends on the jurisdiction and local laws.

In some countries, you may be detained or fined for refusing to surrender encryption key or to decrypt encrypted data. This is called either key disclosure or mandatory decryption laws. In most civilized countries, enacting such laws requires warrants or court orders and may not be enacted with just probable cause. On others, even customs officer may be able to force you to decrypt data.


No,  there is no way to know who deleted the file by looking at the USB stick alone.  Even if there was a way it would be very easy to modify the content of the USB stick to mask this behavior.  If you have access to the machine then you can configure windows to log file deletion events.  However, even windows log files can be modified.


What are the chances of a database being hacked?

Even if such a statistic existed, it would be meaningless because these attacks don't occur as a result of random chance.

Your chances of being "hacked" rise dramatically if:

You don't secure the application properly (SQL Injection being the most obvious, and sadly still commonplace vulnerability; others include plain-text passwords, XSS/XSRF, and not validating form/query string inputs);
You don't secure the site properly (e.g. you allow directory listings, allow anonymous FTP access, don't chroot the FTP, etc.)
You don't secure the network properly (e.g. you run services under privileged accounts, don't set up proper ACLs or firewall rules, etc.), which would make it far easier for an attacker to scan for vulnerabilities and find some means of privilege elevation.
You have a large and/or poorly-trained staff working on the system, increasing the odds of a random social engineering attack being successful.
Your site is high-traffic, high-revenue, high-sensitivity, or otherwise represents a high value to attackers, which implies a greater likelihood of a targeted social engineering or similar attack (i.e. espionage).

If you secure your environment and your applications properly, you have very little to worry about as long as you don't paint a big target sign on your back.  Once you get to that size, you should be hiring a full-time IT security consultant who will ensure that the odds of you being "hacked" are very close to zero, and/or that the actual business implications of such an occurrence would be minimal.


You have a misconception:
With SHA3/Keccak, being a bit strange compared to previous hash functions, output size is not comparable to security. A certain security level requires a minimum output size, but the output can be made longer without increasing the security as hash.

The minimum hash size (of Keccak in general, not of the standardized subset called SHA3) is 1 bit:

In the sponge construction the value of the sum c+r is restricted, but how much of it is c and how much r is freely choosable. Make r=1 and do only one iteration in the squeezing part (after the vertical line), then the hash output z0 has exactly 1 bit.


The phone line is not considered a secure end-to-end medium. It is possible the tap into a phone line. The parties who are most interested in tapping your phone aren't interested in having your SSN or Credit Card number (government agencies).

People who are really interested in harvesting SSN and credit card numbers have other means which tend to yield a lot more credit card and social security numbers. You can imagine the incentive it would take to tap on every single phone line across the globe. It's a lot more interesting to use other scams to get to this data, not mentioning the detection rate.

So to conclude, the risk versus effort versus yield is not interesting enough for people to tap into your phone line to get your CC and SSN. People who will do phone tapping are not interested at all in your SSN or CC.


Should we store personally identifiable information on google drive?

Google Drive is no more or less safe than any other web-based service with a single logon. Your company must decide for itself whether it is willing to put the data online (albeit behind Google's authentication)

At the very least, I'd recommend that

2-factor authentication is used
Any data travelling outside the organisation is encrypted.

Google Drive is presumably fairly secure, but as we saw with iCloud, people can (and do) sometimes get access to systems they shouldn't be able to access.

One piece of advice a tutor at university gave me was:

  Treat anything that isn't behind your firewall as though it was on a USB pen you'd just left on a train

Meaning: assume that it may fall into the wrong hands, and ensure that you've taken sufficient precautions to make it useless to them.

(In fact, I'm a fan of treating things that are behind my firewall the same...)

Edit

To add to the "liability" question:

This is mostly a matter of what is stated in the contracts, agreements (EULA or ToS etc) etc between you and Google, and potentially you and any third parties who the data belongs to. Note that this doesn't just include clients/customers, it also includes your staff, if you are storing their personally identifiable information in the cloud - so this could not only cause financial issues, but also destroy employee trust if there is a breach! Your bank may also refuse to reimburse any money lost if bank details are stored in the cloud, as this could be considered negligence.

In general, though: unless specifically stated, at least some liability will always remain with you. Some liability may or may not fall upon Google for data breaches etc, but this will depend on the agreement. You will still be liable for any third party data, however, in as much as you have chosen to entrust it to a third party.

If there was a data breach, it would then become a (likely very long and drawn out!) legal question, and would revolve around whether either Google or yourself were negligent, the nature of your agreement, and whether you both took any and all reasonable steps to protect that data.

I think the crux of your question is "Will Google take responsibility for the security of data on Google Drive" to which the answer is "No, probably not". But I am not a lawyer, nor do I play one on TV.


Encrypting user data using password and forgot my password

The standard way of doing this is as follows:

Create an authentication hash using a salted key derivation algorithm such as PBKDF2 or bcrypt.
Generate a random surrogate key for data encryption. Encrypt all data with this key.
Generate a "locking" key from the password using a different salt, but still using a strong KDF.
Xor the surrogate key with the locking key and store that value. This makes the master key unknown unless the password is unknown.
On login, generate the locking key and xor it with the stored surrogate key, which gives you the real surrogate key.

The benefit of this system is that it allows for easy password changes - just use the old password to decrypt the surrogate key, then generate a new locking key from the new password.

When using such a mechanism, the only way to decrypt the data is to have the password, unless you create a second encrypted copy of the surrogate key using another secret.

Here's how I'd do it:

Ask the user to provide you with 3 secret answers. Convert the answers to uppercase and concatenate them. Run that value through a KDF to create a secondary locking key.
Xor the surrogate key with the secondary locking key and store that as a backup key.
When the user forgets their password, ask them for their secret answers and generate the secondary locking key, then use that to compute the surrogate key.

The secret answers option is the easiest, but it's possible to do this with any secret value.


When gpg encrypt is called from the command line, how is a key chosen to do the encryption?

Often, whenever you provide a filter to a parameter which matches multiple keys, it uses  all of them (e.g. --list-keys or --export). I was expecting it to do the same here. However, a basic check shows that it is not encrypting to all of them, but only to a single key, which is the one imported earliest to the keyring (the selection changes if imported in the other order). The command --delete-keys acts in the same way as -r, choosing just the first one present in the keyring.

You may see to which keys it was encrypted (other than by attempting a decrypt) by parsing the actual packets:

echo Hello world | gpg -e -r jdoe  | gpg --list-packets

And, as noted by CBHacking, you can use key ids everywhere. Using the textual user ids are actually simplifications for better usability.


Can Symantec Trial Certificate be used for easy man in the middle attacks?

The SSL certificate issued using this process is not trusted by default by any software and thus cannot do any harm as long as the software is doing proper validation of certificates. And if the software is not doing proper validation there is no hope for this software anyway, i.e. you don't need this trial certificate but can create your own.

From the documentation:

  In order to test the use of a Symantec SSL Trial certificate, you must install a special Symantec Trial Intermediate and Symantec Trial Root CA on the server. The Trial Root must also be installed in each browser that will be used during the testing phase. This is a special step that Symantec has implemented to prevent fraudulent use of trial certificates. When purchasing a production SSL certificate, these additional steps are not necessary.


Interesting problem.  I wonder if a solution to this problem may be to force your users' web browsers to solve a cryptographic problem (using javascript running in their web browser) that is 'hard' to solve, but 'easy' for your site to verify.  By 'hard' to solve, I mean a problem that would take ~10 seconds to solve with the resources of a typical desktop or laptop.  A problem akin to the problem that bitcoin miners solve when new blocks are mined, but of course on a much simpler scale.

Your legitimate users would not notice the difference, as the script churns away while they fill out the form on your site.  But, it would slow down the abusers considerably, and force them to allocate a lot more resources, and force them to re-work whatever tool they are using to automate these posts to your site.


How much can we trust open source implementations of crypto (security) libraries?

Much better than closed source implementation.

When it comes to security that really matters, you have to follow the principle "trust but verify". Trust that popular open source implementations are more likely to get it correct and enough eyeballs to spot mistakes, but verify/audit the code yourself if it really matters to you.

With open source implementation, you can actually verify it yourself if it really matters for you. With closed source implementation, you only have the vendor's word for it.

If anything, distrust over open source security libraries is a good thing; it makes some people to start auditing them before using, rather than just blindly trusting an implementation because they are popular.


In general certificate based authentication consists of two main parts:

A presents a certificate to B and somehow proves to B that it has access to the private key to the certificate.
B verifies that the contents of the certificate matches the expectations. These expectations are typically a trusted issuer known to B, a specific subject, that the certificate is not expired or revoked etc. But it might also be that B already knows the exact certificate to expect and just compares the certificate or its fingerprint against the known one.

These parts could be attacked within an MITM attack as follows:

The MITM attacker presents the original certificate of A to B. This should only be doable if the attacker has a matching private key. Assuming that the certificate does not use a weak key in the first place then the attacker needs to somehow steal the original private key, for example by hacking A. But it might also be that the prove that the peer has the private key for the certificate is wrong. Usually this prove is done by signing a challenge which is (at least in part) based on random data generated by the server. If the check of private key ownership is implemented wrong at B it might be possible for the attacker to replay a prove previously sent by A.
The MITM attacker presents its own certificate (where he has the private key) to B. In this case  B must somehow be tricked into believing that this certificate is valid for A. Typically this works if the certificate is insufficiently validated in the first place, for example by not validating it at all. It might also be possible that the attacker is able to get a valid certificate from a CA trusted by B as issuer for the certificate.

In other words, if implemented correctly no MITM is possible. But there are various ways it might have been implemented incorrectly.


What do speculative execution patches protect me from?

I'll bite...

Firstly let's handle meltdown (Google: P3). As you probably know, your system has multiple privilege levels for code known on Intel/x86 as ring 0 (supervisor code) and ring 3 (user mode), which are the CPL bitfield choices in your segment selectors. Code is either running using one segment selector or the other (the selectors cover the whole address space) and this determines what privilege the code can execute with.

In parallel, there is virtual memory, controlled by page tables in the CR3 register. Paging allows for a virtual address space of a certain size regardless of the actual amount of backing storage (physical memory) and allows operating system developers to do things like write pages to swap (windows: pagefile) to evict them when tasks are using memory, but have not accessed it for some time and physical RAM is in demand. Page tables also have a user bit, which controls whether code can be seen by code executing at cpl 3. If the bit is set, user mode code can see the page, otherwise not.

Now there are two key points to understand. Firstly, on x86 (and many other architectures), hardware level tasking does not exist. A process, then, (linux task, windows process) is entirely a concept in software. This works by allocating each process its own virtual address space and when processes switch, the relevant pages are switched, "plugging in" the new process into the virtual address space and removing the old one (or unmapping it, even if not evicted from physical RAM) temporarily.

The second thing to understand is that this is a relatively expensive processes, so operating system designers came up with a "higher half kernel": in each process' address space, the kernel is mapped into the higher half of memory completely. This brings us an important advantage: if the kernel needs to handle an interrupt, or perform some IO, we can jump into the kernel space via a system call or interrupt handler and we don't need to switch address spaces of the process. If the task doesn't require us to switch address spaces for any other reason (this is slightly different to a context switch, which is the save of register state, which we can still avoid using the higher half design in some cases) this is nice and efficient: the kernel does its work and returns to user mode as fast as possible.

Unfortunately it turns out that speculative execution occurs across privilege levels on Intel CPUs, specifically that code running as CPL 3 can speculatively load pages with a cleared user bit (so, supervisor/ring 0-2 only). Meltdown exploits this by referencing memory from the higher half on a page-by-page basis through instructions that are only executed speculatively. However, the processor pulls those pages into the higher caches, resulting in a cache based timing side channel.

KPTI and equivalent patches in macOS and Windows protect against this by not using a higher half design. Only the bare minimum needed to enter the kernel address space is mapped into every process; the rest of the kernel lives in its own virtual address space like a separate process. This has two main effects:

Any entry to the kernel implies a switch of address spaces. This is more expensive than the higher half design, hence the quotes of a 5%-30% slowdown. The reason for the "it depends on your workload" explanations is because it does depend on how many times you need to enter the kernel.
However, now, there is only a small amount of kernel space left in the same virtual address space as the process and most of it is an uninteresting interrupt handler. You can leak it, but, it's a smaller target and its location can be randomized as well. There's simply no valid references any more to things like disk encryption keys and so on, as they exist in a separate virtual address space, which requires a switch to the kernel process first.

This is obviously bad news. The same issue issue can occur for some kinds of hypervisor designs. Containers are a kernel construct entirely and thus are affected, just like processes.

Spectre (Google: P1, P2) works similarly, except it allows the attacker to induce a target to perform some kind of speculative execution in its address space and leak that via a side channel. A critical difference from the Spectre paper is:

  Spectre attacks only assume that speculatively executed instructions
  can read from memory that the victim
  process could access normally, e.g., without triggering a
  page fault or exception. For example, if a processor prevents speculative execution of instructions in user processes from accessing kernel memory,
  the attack will still work. [12]. As a result, Spectre is orthogonal to Meltdown [27]

In other words, you cannot use Spectre to read kernel memory from an unprivilged process directly - or any memory in a higher privilege level.

In order to fix these issues there are a number of possible resolutions:

XEN XSA-254's FAQ suggests that Intel, AMD etc are preparing microcode updates that will flush branch prediction logic on entry to the hypervisor, to ensure any attempt at poisoning across this boundary is removed.
It also mentions (and this applies elsewhere) applying indirect jumps in code, in such a way that speculative execution does not occur. This defence is to effectively defeat the CPU's optimizer and requires that the software in question is recompiled. It is this defence that is being added to GCC, Clang as mentioned in other answers.

Now, to answer the actual questions you asked:

  For example, if I am on a Windows OS, running Firefox and Chrome, where the OS is patched, but not any of the browsers, what does that buy me? Is speculative execution to read kernel memory via javascript still possible in that case?

If you have the KPTI patch series or equivalent, the answer is no, you cannot. Or more precisely, you can, but you can only find uninteresting things like kernel code for switching address spaces.

  As a bonus, I've read that Mozilla and Microsoft have temporarily mitigated the attack via browser, by purposely making some the javascript timing mechanisms inaccurate/less-precise. Isn't it theoretically possible to bundle your own time measuring libraries to bypass that?

Theoretically, if a method of measurement exists that is accurate to the required degree in browsers already, yes. However, bundling your own measurement essentially requires extending the browser. It isn't as simple as loading some javascript as, underneath, javascript in the browser is using entirely browser-provided APIs. So theoretically, if there is some code path that allows measurement that has not been closed off, yes, otherwise, no.

I would go with no for all practical purposes, as a result.

Summary:

KPTI series patches explicitly protect against Meltdown, i.e. full kernel address space reads, on Intel CPUs.
Spectre is harder to protect against as this allows for the same speculative execution, but targeting a different victim process across address spaces. KPTI does not fix it. Individual software packages must deploy mitigations. By contrast, Spectre cannot cross the ring 3-ring 0 privilege boundary (but I believe it can across ring 0 - ring 0 (or "-1" the hypervisor) and hence the Xen comments.


Prevention against De-Auth Attack for Handshake Capturing

It would most certainly work, and rob whoever is doing it of both handshake and 'for-the-lulz'.

You can disable it on most platforms - I am not so sure about Android.

If you are interested in keeping things separate, get a pcengines alix/apu or soekris, connect wan to port1, lan to port2, and wlan on port3. don't let lan and wlan interact, restrict wlan to what you need.

Both PFSense (browser 'GUI' setup) and OpenBSD are straightforward and well-documented.

Edit: pfSense works much more reliably as an AP than OpenBSD. Using the latter, you would have to use the exact right minipci card. The rum driver (a USB dongle) for example creates an annoying kernel panic after a while in HostAP mode.

Trivia: Using WPA enterprise you can prevent anyone without the cert from connecting to your wifi. They could still sniff a bit, but most important stuff uses HTTPS/similar now, and the attacker cannot use MitM like sslstrip2/dnsproxy against your clients.


How can I secure encryption keys in the code?

You are right to be suspicious of this process. Android apps are super easy to decompile, so you should assume that any keys that are embedded in the app might as well be posted in a public blog.

Without more information on why you need to encrypt the data files it's hard to give detailed advice. A usual way to solve similar problems is to use public-key encryption. Each client app generates its own public key, and when it requests the data from the server, the server encrypts it specifically for that client, using their public key.

Unless there's details that make your problem more complex, you could probably accomplish this by using standard PGP libraries to generate client keys, and to encrypt / decrypt the files.


The script is executing the shell builtin instead of /bin/bash.


Is there any benefit in having CNNIC certificates installed, if you're not in China?

If you don't use Chinese websites and internet-based products, you won't need to worry about removing them; you are unlikely to experience problems with legitimate websites by removing these dodgy certificates.

I used to live in China, and I never used any of CNNIC's certs outside of a virtual environment.

Legitimate browsers - Firefox and Chrome for example - are excluding these certificates as a result of fraud. Get rid of them.