Research about entropy of human randomness?

This is what I could find in 30 minutes on Google Scholar.

Lots of papers on the entropy of human movement and walking gait. Lots of papers on measuring the entropy of passwords (for the purposes of displaying a strength meter). Some papers talking about the amount of entropy a human can memorize.

This paper is pretty close and probably contains some partial answers:

Password Generation and Search Space Reduction [Link to PDF]

If I am reading Table 1 correctly, then they found that when allowed to make 8 - 10 character passwords, people tend to select passwords from a roughly 240 password space. This is kinda a measure of entropy, I guess.

Here are other papers I found that are close-ish to the spirit of your question:

Entropy quantification of human brain [EEG]
Comparing User-Generated Passwords on 3x3 vs. 4x4 Grid Sizes for Android's Pattern Unlock

So within the powers of 30 minutes of my Google-Fu, I am going to say Lots of research has been done on the average entropy of passwords found in database leaks (hint: it's real low).

But as to "what's the best a human brain can do?" It looks like: No, this research has not been done.


The request was aborted: Could not create SSL/TLS secure channel Exception

X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine);

You're using the LocalMachine store.  Either put your certificates are 'Machine Certificates' in mmc, (elevated MMC -> certificate snap-in -> Computer Account), or use the CurrentUser store.

Also this might be a better question for StackExchange since it's C#/Programming related.


What is wrong with physically exchanging certificates instead of handshake?

Organization XYZ prefers not to trust any CA but only itself.... All
  inside Browsers are set to trust this Enterprise CA. So, naturally,
  all other web sites (like Google) are not trustworthy which is
  indicated by browser.

  What is wrong with this picture?

What's wrong is that Organization XYZ is using the wrong enforcement point.

If they don't trust the outside world, then they should remove outbound web proxies and ensure firewall rules disallow all access outbound on ports 80/443.

Or they could implement a draconian proxy with TLS MITM which limits access to only those external sites they consider legitimate.  (And if they do that, of course, they should again trust the outside certificate authorities, as access to approved sites is being enforced by the proxy, not at the TLS certificate layer.)

If Organization XYZ isn't willing to take these - admittedly quite drastic - steps, then they need to seriously reconsider why they're stigmatizing what is - by their own admission - acceptable access.  Because by distrusting all other CAs, they're placing Extended Validation certificates on the same level as Self-Signed Snakeoil certificates.  If you're going to throw that away, you should just block everythi.... oh, wait, that was step 1.


OSSEC, what is it telling me about port changes?

For what it is worth, and for others arriving at this page looking for an answer, I've been seeing similar behaviour. I've been getting regular, and frankly irritating, Level 7 notifications from OSSEC about rule 533.

I think it is being triggered because of the runlevel where OSSEC is starting and establishing the current list of listening ports, takes place before most of the services that will be listening on 127.0.0.1 have started.

To get around this, I have moved ossec from K20ossed to K98ossec in /etc/rc0.d. IT seems to have stopped the alerts.


Methods to work with offline primary keys

I have found a way to link an offline primary key. Still, inspired by a blog Using an offline GnuPG master key, I realised that --keyring adds a file to a list of keyrings, whereas I needed to specify exactly one file. Therefore, the missing option was --no-default-keyring. I am not an expert but this is what worked for me:

1) Mount USB stick. The folder will something like /run/media/username/CORSAIR in Linux.

2) Create directory for a ram disk

mkdir ~/ram

3) Mount the ram disk:

sudo mount -t tmpfs -o size=64M tmpfs ~/ram

4) Create a temporary directory for gpg: mkdir ~/ram/gpgtmp.

5) Import private keys from a USB to a temp gpg , e.g.

gpg --homedir ~/ram/gpgtmp --import /run/media/username/CORSAIR/gpg-archive/primary-keys.asc

After importing private keys to ram disk, USB stick is no longer needed.

6) Run GPG editor:

gpg --homedir ~/ram/gpgtmp/ --keyring ~/.gnupg/pubring.kbx --no-default-keyring -u <ID1> --edit-key <ID2>

7) In the editor, use uid n to choose an identity of interest, followed by sign to sign selected identity with a local key .

With a primary key linked to a temp gpg folder, the command should be completed with success. As a side note, after step 5 a USB stick is no longer reuqired and can be dismounted.

EDIT.

In case of error:

gpg: key AAAAAAAAAAAAA: error sending to agent: No such file or directory

try to restart gpg-agent

gpgconf --kill gpg-agent
gpgconf --launch gpg-agent

I also deleted everything in gpgtmp. Even better would be to re-create the folder. After re-launching the gpg-agent, the import was working again. I guess a simple restart system would also work.


What gpg defaults can be improved, when performance is not an issue?

1) password hashing iterations

If you don't care about waiting a little longer, you can use the maximum count value, which is 65011712. This isn't strictly the number of iterations so much as the number of bytes to be hashed. S2K works by repeatedly feeding the password and salt to a hash function for a specific number of bytes. The more bytes, the longer it takes. This is what the s2k-count parameter specifies.

  2) size of asymetric key

The maximum key size that most implementations of GnuPG are capable of generating is 4096 bits for RSA. This is a result of the memory limitations placed upon the software. In order to prevent secrets from being leaked into swap, it has to "lock" memory. The operating system provides a limit as to how much memory a single process is allowed to lock. GnuPG would need to lock more than it is allowed to generate a key larger than 4096 bits. Luckily, 4096 bits is plenty for an RSA key.

  3) algorithm for symetric key

AES256 is already plenty. It's most certainly not going to be your weakest link.

There are other things you can do to further harden your GnuPG implementation, although the complete list is too vast and dependent on your situation to list here. A few improvements would be to add to your gpg.conf file a few settings like with-fingerprint to display fingerprints by default. This doesn't improve security unless you actually verify that the fingerprints match what you expect, of course.

You can also use a stronger digest for signing keys. Avoid using SHA-1. You can use SHA-256, or even SHA-512, although that's a little overkill. This can be set with cert-digest-algo SHA512.


Asymmetric public-key cryptography: can either key be used to encrypt or decrypt?

I think you are mixing terms. Untangling them might help your understanding. (In the order you used them):
Key Exchange is one of a number of methods for taking a symmetric key that you have (say an AES key) and exchanging it with another party such that no eavesdroppers can learn it in the process.
Key exchange and encryption are (almost) unrelated concepts. Key exchange is often accomplished by using asymmetric encryption, but there are key exchange methods that have nothing to do with encryption.
Public key / private key encryption and digital signatures: you are correct in that with encryption, you encrypt for the recipient's public key and then they can decrypt with their private key. With signatures you sign with your private key and then anyone can verify with your public key.

Are public keys and private keys interchangeable?
Trying to generalize it like you have done gets messy really fast because there are many asymmetric (or "public key") cryptographic algorithms (paraphrased from wikipedia):

Examples of well-regarded asymmetric key encryption and key exchange techniques for varied purposes include:

Diffie–Hellman key exchange protocol
ElGamal encryption algorithm
Elliptic curve Diffie-Hellman key exchange
Various password-authenticated key agreement techniques
Paillier cryptosystem
RSA encryption algorithm (PKCS#1)
Cramer–Shoup cryptosystem
YAK authenticated key agreement protocol

Examples of asymmetric key algorithms not widely adopted include:

NTRUEncrypt cryptosystem
McEliece cryptosystem

Examples of notable – yet insecure – asymmetric key algorithms include:

Merkle–Hellman knapsack cryptosystem

There is a similar, but different, list of digital signature algorithms (also from wikipedia):

Some digital signature algorithms

RSA-based signature schemes, such as RSA-PSS
DSA and its elliptic curve variant ECDSA
Edwards-curve Digital Signature Algorithm and its Ed25519 variant.
ElGamal signature scheme as the predecessor to DSA, and variants Schnorr signature and Pointcheval–Stern signature algorithm
Rabin signature algorithm
Pairing-based schemes such as BLS
Undeniable signatures

You'll notice that RSA and ElGamal are the only algorithms that appears on both lists, ie the same algorithm can be used for both encryption and signatures. I'm personally not familiar with the math behind ElGamal, but RSA signatures work the way you describe - that a hash of the message which can be decrypted by the public key. However that description does not work in general for all crypto algorithms, for example DSA which is for signatures and does not have an encryption variant.

Summary
To answer your question "Should I think of asymmetric keys along the lines of one key encrypts and the other decrypts or can either in a pair be used to encrypt or decrypt?", the answer is "It depends which algorithm you are talking about."
What you state in your question is (mostly, slightly simplified) true for RSA, but certainly is not true for any other asymmetric encryption or digital signature algorithm. It's better to think of them as four separate cases:

Encryption public key encrypts
Encryption private key decrypts
Signature private key signs
Signature public key verifies

That's the most specific you can get and still have it apply to all encryption and signature schemes because the details of how the math works varies wildly from one algorithm to the next.


How secure is the "no-password" login scheme?

The protection mechanism in using a password when talking username+password is to provide authentication. Whether it is sufficient is dependent on the threat model.

When using a "no-password scheme" as you describe, you move the initial authentication to the mail account, with which the account was created. Sending a link to the mail account provides possible attack vectors, but if we ignore these and focus solely on the mechanism of using a link with a session token, it can be a valid way to provide authentication. In principle you are using the mail account for federation of identity, which is to say that you as a user put trust in your mail provider and your own awareness on mail usage when using a "no-password scheme".

You pose the question whether the "no-password scheme" is more vulnerable to hijack of the mail account. As the mail account is your sole mean of providing identity and authentication, it is more vulnerable to account hijack through your mail provider than a scheme where you can provide a username+password. However the username+password is not a vulnerable point in the model for the website account.

Your question to whether it is a weakness, is dependent on whether the user supplies a secure means of mail account usage. The focus of the login is removed from the website and the user puts trust in the mail provider and the session establishment via a link with a session token sent in (dependent on threat model and possibilities) an encrypted or secured mail.

Making a scheme like the "no-password scheme" better could be to introduce a two-factor component. If you consider that your link with a session token is one factor, you could introduce an out-of-band validation mechanism, such as Google Authenticator, FIDO U2F, or a similar concept such as printed keys from the website. This could strengthen the security, but would not make the experience more seamless.


Using TOTP instead of passwords for IoT device authentication

If we assume that the keystore is safe and keys can not be copied or extracted but it can perform HMAC-SHA(1) then you might think of using TOTP.

But I would also recommend taking a look at OCRA.
Here you can do real challenge signing. You either realy do only a challenge signing or you can add time or a counter. This way you would have no problems with a clock drift.

But why not use public key crypto? If the keystore can also store an RSA private key - I would probably go with signing the challenge with a private key.

If you are still going with TOTP or OCRA, you might also want to take a look at privacyIDEA, which can help you to manage all the secret keys of your devices.


How to inspect an email attachment without downloading it?

Many email services include a basic virus scanner. I know Gmail does, but that is not an endorsement. One thing you could try is to forward the email to another email service that uses attachment scanning.

If something is found, then you know. But if nothing found, then you cannot be certain.

Another option is to use a webclient for your email (like Gmail) and save the attachment directly to an online file store (like Google Drive). Then you can use VirusTotal's URL scanner to access the file (after you made it public). The file never touches your computer and never gets executed and gets sent to an online service to be scanned.

But the PDF is most certainly infected. What you describe is a very, very common attack. You need to scan the attachment to see how it might have affected your device.


Unknown PHP file in my upload folder, isn't malicious code?

I just google dorked the code here and it looks to some sort of malware/trojan aimed at IP address filtering on a webshell. You may need to translate the page to English.


Best practice, who should be responisble for HTTPS configuration?

One edge case where it might make sense to put responsibility for ssl certificates on the app/app developers:

If your app was reachable through multiple domain names, and these domain names were controlled by the app itself, then it would make sense for the app / app developers to set up a system to automatically extend the certificate to the new list of domains whenever a domain was added.

This might also be relevant for applications which allow users to create their own subdomains, (e.g. john.example.com and jane.example.com), but I think that in that case, what you'd usually do is get a wildcard certificate which would cover *.example.com, and in that case there'd be no need for the app / app developpers to take care of the certificate).

Other than that, I don't see a reason why a third-party consultant should take care of a client's ssl certificates. In fact, I'd see it as a disadvantage, since from a security viewpoint you'd add an additional point of failure - after all, if the consultant took care of getting a certificate for the client's server, he'd also have access to the private key, and this could be a liability for both the client and the consultant:

The client could never be sure of who had access to his encrypted communications with his clients, since he couldn't know whether the consultant who got the ssl certificate for him took all the necessary care to keep the private key secure, and in case there was a breach of privacy with financial (or public) consequences, the consultant might suddenly have to show that it wasn't his fault in order not to be held accountable.

So if I were you, I'd counsel the client against outsourcing certificate acquisition and deployment if at all possible (of course, if they don't have their own tech guys, then there's no way around it).


How secure is this token url for subcontractors with no accounts?

There are several scenarios you have to think about. If you are sending the URL over HTTP you (and your customers) are vulnerable to man-in-the-middle attack (the attacker will have access to the information sent to you by the subcontractors) and even if you are sending it over SSL that will protect your URL only during the transit, and if you are rely on emails to send it then SSL won't protect you from the insecurities of the email that may go through lot of servers before reaching your customer; and before all, it is a weak method to do so in that it is not supported by the merest authentication mechanisms (such as sessions).

Also the fact you need to send the URL subcontractor for each time you require his information, with its validity for 24 hours, expose you to more threats as it enhances the length of the  attack surface. And if the URL is cached by the browser and a subcontractor may use it more than once (you did not specify this through your question) then even SSL is useless for this particular case.

There are other considerations to think about too: what about  any internal routing, server logging?

For your last question:

  What if instead of 24hrs the link lasted for 1 month?

Again, if you enhance the time validity of the URL you are enhancing in the same time the surface attack as the subcontractor email (or the system with which he receives your URL) may be compromised by time.


Does Readdle (Spark) keep my logins/passwords on their own servers?

Here is a reply from support:

  We use server side pushes to send you fast notifications. In order to
  send these push notifications, Spark server needs to check your email
  account — either using Oauth token (for Google, Outlook and yahoo
  account) or via your credentials. Our servers are located in the US,
  so probably yes, these are connections from our servers.

I would preferer to have an option to turn off this notifications. Now I have changed the email client.


zap proxy - modify post to inject a zip file

Ok well is not exactly what I wanted but in zap if you go to the url with the form.. then intercept and instead of injecting I was able to select the post, then use one of the build in scripts in ZAP to convert to curl and from curl I was able to just add the filename and inject..

Scriptname is:
curl_command_generator.js


Possible SQLi with self-made prepared statements and real_escape_string?

if there is anything wrong to escape and process user input like that?

To clarify, there is nothing wrong with escaping per se as long as it is used on purpose - to escape not the arbitrary "user input" but specifically data to be used in the string literals in SQL query. Frankly, as long as the data in SQL query is both quoted and escaped, there should be no harm possible.

The code in question is a special case. Although bulk escaping is used (which is a big red flag as a rule), in this case it should be considered safe as long as only basic printf placeholders are used (i.e. %s, %d, %f etc), without argument swapping and other fancy stuff. As a result every input variable would be either

wrapped in quotes if %s placeholder is used (and thus gets quoted and escaped to satisfy the rule from the above);
or gets formatted as a number in case any other placeholder is used.

So I don't see any possibility for the injection.

The only slight security concern here is to use mysqli::set_charset() to set the connection encoding, to avoid a virtual vulnerability when a peculiar outdated encoding is used.


Fostering an environment where honesty and disclosure are valued

If there is anything we know for certain, it is that people respond to incentives.

It is trivially true that an environment where employees are incentivised to hide mistakes from management does decrease the ability of management to identify and respond to internal failures. It is also trivially true that a company that is internally crippled in such a way that they cannot identify and respond to its failures is inherently less trustworthy than a company that can identify and respond to its own failures.

Internal failures and problems do not, as a rule, disappear by being buried; they instead tend to grow and metastasize more than a disclosed failure would precisely because the people dealing with the problem have fewer options available to them. If I don't want my mistake to become public, then my range of options in dealing with that mistake are severely limited, and I will end up choosing a less-than-optimal option that protects myself at the expense of the company.

So yes, an internal environment of honesty does increase overall security. Problems can be dealt with swiftly and cleanly, and catastrophes can be averted.

And certainly a company that has an internal environment that promotes honesty is more valuable to me as a customer than one that doesn't. But every manager thinks he fosters an environment of honesty; he wouldn't knowingly set out to encourage his subordinates to lie to him. Asking management whether or not their environment encourages honesty would be a pointless affair.

Instead, you have to look at the incentives.

If an employee sees a mistake -- perhaps his own, perhaps his supervisor, perhaps his subordinate, perhaps his coworker -- then what is his incentive to make that mistake known? What is his incentive to keep it quiet? And the person he tells; what it that person's incentive to keep it quiet?

The concept of an economy deals not just with money but rather with incentives. An economy of honesty is therefore an incentive structure that encourages honesty; be that an internal incentive structure or a structure of incentives between organizations.


How to exploit XSS reflected in order to steal cookies

Actually i am facing the same error when i was doing. And that time i came to know about the local hosting have some limitations. We can not directly send data between to machine that are locally.
So if you try to use the remote hosting that will work
And one more thing is that your POC link is expired.

Here i am putting the link of my POC:
https://youtu.be/H4AXL4K_hw8

I hope this will help you:)

Thanking you..


Does bugzilla.mozilla.org's "new" password requirements make sense for that type of account/service?

So my question is: are there any objective reasons for such a complex password for something like BMO? What is the worst thing that can happen if someone cracks an outside users password there?

Remember that the bug tracker may contain information pertaining to 0-days in the software, or other serious security bugs. Not all users have access to this information, but some do.

Such information may impact a large number of users should it become publicly known.

It's easier and better to enforce password policies for all users, and not depending on group. Many password hashing schemes will hide the complexity of the passwords, which means that it is only verifiable when actually changing the password.

  because the password they require won't be easy to memorise

I memorize exactly three passwords: my computer account password, my remote access password and my password manager passphrase. The rest is stored in password managers (Lastpass and KeePass). This is suggested by the user guide you point to. This makes it easy to use unique passwords for each service, and you don't have to remember anything.

In addition, they do allow passphrases, which is easier to memorize. Four random words is certainly possible to remember, if you desire.

  Finally some personal remarks about this issue: personally I am not too found of the thought of a password manager in the cloud (which is was BMO recommends).

They recommend a password manager. They don't mention a specific one, and does not mention cloud based at all. You should probably read the page you linked once more, as you infer things that is not stated there.

In addition it should be noted that Lastpass uses your passphrase as an encryption key for your data, so an attack against a different user may not yield your passwords.


What could this set of IDS alerts be (DDNS deaftone.com darktech.org chatnook.com, ...)?

One idea (though it may or may not be correct) is that malware on your system could be trying to reach out to its creator (e.g. to send out information or to allow for your system to be used in a botnet).  The * is typically used as a "wild card".  For example, the domain www.abc.3d-game.com should be found by the *.3d-game.com query. The domains shown here definitely look suspicious.  I would update your antivirus and run a scan of your system to check for any malware.  Even a clean virus scan does not entirely rule that idea out.

Edit: For a Mac, you may be able to use Apple's file quarantine system, see the question:
Should I get an antivirus for my Mac?


It is hard to conclude without knowing the requests and the responses. However, it is less likely that an IPS blocks your access. Most IPSes block SQLMap immediately by simply looking at the request User-Agent.

From debugging, try to run SQLMap through an intercepting proxy and observe the responses from the server:

sqlmap --proxy=http://localhost:8080 [THE REST OF YOUR PARAMETERS]

Then manually modify the request and send to server using your intercepting proxy. This way it is easier to find out where the problem is.


Unless you've disabled it, Firefox enables WebRTC by default which can expose your local address behind a VPN, depending upon VPN details.
In any case, check your VPN connections at some diagnostic sites like:
ipleak.net
perfect-privacy


Security controls to implement on a private environment

ISO/IEC 27002 lists 114 security controls they feel everyone should at least consider, but I wouldn't recommend starting there; you need to do a risk assessment first so you know what you have to control.

Don't start with a list of controls, otherwise you'll make a horrible mistake like assuming fingerprints readers mean external people can't access your building.

(Who cleans the kitchen? Who fixes the toilet when it breaks? Who delivers parcels? Who checks your smoke alarms? Who would your lowest paid employee let in if I gave them $5,000? Who would your highest paid employee let in if I threatened to tell his wife?)


What is the safest way to use Bitlocker with TPM?

If this is done automatically an attacker can just come to my laptop and start it and my data isn't encrypted

This is the procedure. It isn't secure. For the average person, BitLocker and TPM is more secure than not using full-disk encryption. TPM is a secure microcontroller with cryptographic capabilities designed to provide basic security-related functions involving encryption keys. now the specifics BitLocker seals the master encryption key in the TPM and only allows the key to be released when code measurements have not changed from a previous secure boot. - Trusted Platform Module (TPM) and BitLocker Support

This is done with support from secure boot. Hence, directly booting and circumventing the normal boot procedure is not allowed. However, if you can find a vulnerability within Windows, you can circumvent this, as you do not physically need the decryption master key. E.g. Windows will boot to the lock screen, if you can identify a vulnerability here (when the drive is decrypted) you have access. Windows ’sticky keys’ exploit exploited a vulnerability where startup recovery would print the diagnostics within Notepad.exe with elevated administrator privileges. Notepad could open Windows Explorer and rename a program which would run at the login screen, sticky keys are one example. Renaming cmd.exe to sethc.exe allowed cmd.exe to be run with elevated administrator privileges at the login screen.

  Which is the safest way to use Bitlocker

Use a strong password on BitLocker or setup a USB key. The USB key, will be a USB flash drive, just like TPM. Except you will control the storage mechanism, also you can easily remove the drive. However, both the options I said here can introduce other problems. This is very subjective depending upon your OpSec requirements. Bitlocker: USB Key vs Password?


Low-level encryption, for arbitrary packets, is called a VPN. If your wireless router implements IPsec, you can use that. This will raise a few tricky questions, of course (key management, authentication...).

I doubt many home wireless routers know how to do IPsec natively (peruse the documentation of your own router), but some routers can be reflashed with an alternative firmware who can do it.

If you let hostile people physically plug in your home network, then you may have bigger problems to deal with. For instance wanton degradation by temporarily wiring an ethernet cable with 110V power...

Also, remember that the Internet at large is not a nice place. Encrypting your packets only on your home LAN will protect them against people plugged on that LAN, but only against them. If the data is sensitive, it should benefit from end-to-end protection. In simple words: use only HTTPS Web sites. And if you do, then you don't have to do anything special on the LAN.


"Diffie-Hellman Key Exchange" in plain English

Diffie-Hellman is a way of generating a shared secret between two people in such a way that the secret can't be seen by observing the communication. That's an important distinction: You're not sharing information during the key exchange, you're creating a key together.

This is particularly useful because you can use this technique to create an encryption key with someone, and then start encrypting your traffic with that key. And even if the traffic is recorded and later analyzed, there's absolutely no way to figure out what the key was, even though the exchanges that created it may have been visible. This is where perfect forward secrecy comes from. Nobody analyzing the traffic at a later date can break in because the key was never saved, never transmitted, and never made visible anywhere.

The way it works is reasonably simple. A lot of the math is the same as you see in public key crypto in that a trapdoor function is used. And while the discrete logarithm problem is traditionally used (the xy mod p business), the general process can be modified to use elliptic curve cryptography as well.

But even though it uses the same underlying principles as public key cryptography, this is not asymmetric cryptography because nothing is ever encrypted or decrypted during the exchange. It is, however, an essential building-block, and was in fact the base upon which asymmetric crypto was later built.

The basic idea works like this:

I come up with a prime number p and a number g which is coprime to p-1 and tell you what they are.
You then pick a secret number (a), but you don't tell anyone. Instead you compute ga mod p and send that result back to me. (We'll call that A since it came from a).
I do the same thing, but we'll call my secret number b and the computed number B. So I compute gb mod p and send you the result (called "B")
Now, you take the number I sent you and do the exact same operation with it. So that's Ba mod p.
I do the same operation with the result you sent me, so: Ab mod p.

The "magic" here is that the answer I get at step 5 is the same number you got at step 4. Now it's not really magic, it's just math, and it comes down to a fancy property of modulo exponents. Specifically:

  (ga mod p)b mod p = gab mod p
  (gb mod p)a mod p = gba mod p

Which, if you examine closer, means that you'll get the same answer no matter which order you do the exponentiation in. So I do it in one order, and you do it in the other. I never know what secret number you used to get to the result and you never know what number I used, but we still arrive at the same result.

That result, that number we both stumbled upon in step 4 and 5, is our shared secret key. We can use that as our password for AES or Blowfish, or any other algorithm that uses shared secrets. And we can be certain that nobody else, nobody but us, knows the key that we created together.


Is accepting arbitrary COM pointers over a process boundary safe?

I think I found my answer after more reverse engineering and watching old CON talks. This answer represents my current understanding of the situation.

In theory this operation is safe, But there are a number of caveats. I think I found an improvement in the my server, since I initially did not have specific security settings enabled.

First, what actually happens when I pass an object to the COM server is that the COM subsystem will begin the process to marshal my object and provide a proxy for the server to call.

The COM client (the attacker) can fully control the object, RPC data and marshaled interface.

In the COM server (assuming Out of process servers, as is the case here) the RPC runtime will call CoUnmarshalInterface on the data provided by the client to create a proxy. This function will first determine if the sent object uses custom marshalling. Since I was mainly interested in this functionality I did not verify what happens when a standard object is unmarshalled.

Custom marshalling is used on objects that provide their own serialization and de-serialization routines. The data stream provided by the client will contain the CLSID of an object that can be used to unmarshall the data further.

Before this is done, however, the COM subsystem will check if it has been initialized to allow custom marshalling.

Calling CoInitializeSecurity with dwCapabilities set to EOAC_NO_CUSTOM_MARSHAL will disable this feature.

Supposing that security has been initialized to allow custom marshalling the process continues.

The server will now call VerifyUnmarshalerClsidForRestrictedInternalInterface this function checks if the unmarshal class specified by in OBJREF.u_objref.clsid is restricted in some sense.

A next follows in DetermineEffectiveUnmarshalingPolicyForStream and CheckAllowedByPolicy which will make the final determination if the custom marshaller will be loaded.

The unmarshal clsid specified by the attacker must inherit from IMarshal. The object is then instantiated and it's IMarshall interface by a call to CoCreateInstance. The rest of the function deals with actually unpacking the object with calls to UnmarshalInterface and similar.

I found this talk very helpful in understanding COM more under the hood:
https://vimeo.com/214856542

These documentation pages were also quite helpful:

https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-counmarshalinterface

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dcom/fe6c5e46-adf8-4e34-a8de-3f756c875f31


Managing SSH private keys on a public host

I assume you mean that public_host must contain the public/private keypair of an identity that's allowed to log into Bastion and worker? As mentioned in the comment on your question, it's unlikely you'd have the private keys of those other systems on the client system.

To address your question, there are a few things you can do to reduce risk or as alternatives:

Ensure the client's keys have a passphrase defined. Now, nobody can
use those keys without knowledge of the passphrase, even if they
steal the keys.
Store the keys elsewhere (e.g. on an individual user's system) and use SSH
authentication forwarding. Anyone who has access to public_vm as root while
you're logged in will be able to use those keys (since they're accessed via
a pipe/socket in /tmp that root can read/write), but non-root users won't, and
the keys simply won't be available at all when you're not actively logged in.
On the destination host, configure the SSH server to restrict exactly what
 those keys can do. For example, you can force a particular key to run a
 specific command instead of whatever the user requests, or disallow sftp
 while still allowing ssh. This can reduce the risk to the server if the
 client's key is compromised.


Web-Application with CORS Origin: * using authorization header

Pretty much, yes. The key here is that the browser doesn't pay any attention to the ACAO header for requests to the same domain: therefore you can put anything you like in the ACAO header, and it'll work for your application running on the same domain.

For requests to a different domain, the browser does pay attention to the ACAO header - if the origin is acceptable, it then looks at what other Access-Control headers are included, and takes action based on those (e.g. ignoring authentication headers if there is a wildcard, or no Access-Control-Allow-Credentials: true header)


How to find the DH prime value (if 1024 or 2048) from Internet?

I assume you are trying to check the length of the DH parameter for a TLS-secured service.

If you have access to the server, you can check it's configuration. It is usually configured together with the other TLS parameters of your (web?-)server.

If you don't have accees, you could use sslscan :.

Example:

> **sslscan 192.168.X.X:443**
Version: 1.11.12-static
OpenSSL 1.0.2-chacha (1.0.2g-dev)

Connected to 192.168.X.X

[...]

  Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-384 DHE 384
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 1024 bits
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve P-384 DHE 384

If you are not looking for the length, but the actual content of the parameter, you will require access to the server.


If we cast a value is it still necessary to escape it with mysqli_real_escape_string()?

It's true that casting can mitigate SQL injections, but unless performance is a huge concern for you, I'd use mysqli_real_escape_string() anyway, for two reasons:

Your application might change in the future. Even if your application is only passing integers into your queries right now (via this particular function call or whatever), your code may be modified in the future to accept strings, etc. I'd propose that you're better off planning ahead a bit, and that you should seal off this potential future security vulnerability right now, while it's on your mind.
A less experienced developer might "refactor" away that cast. I can see a junior dev coming through your code at some point and saying, "Why is this cast here? We're only passing IDs into the SQL anyway," and then refactoring away that cast. I'd recommend using mysqli_real_escape_string() even if only to give future developers a heads-up that there's a security issue at stake here.

At the very least, if you're going to rely on a cast to implement security, I'd leave some very conspicious ALL CAPS comments in your code to make it clear that that's what you're doing.


Securely building a local pentest lab in a VM

The core mindset you want is:

Build it as if it were real, not virtual.

What would you want in place? Firewalls, access controls, logging etc

For a lab running virus analysis etc., you would normally segregate that from the rest of your network, so do the same here. I don't know of any malware yet that is specifically designed to break out of a VM in order to compromise the host and spread that way. However, what you'll find is that quite a lot of malware will detect it is in a VM and tailor its activity accordingly, which could hamper analysis.


Would 2FA's second factor be a safe enough way to login?

The obvious problem with this is the same problem with just using a password: as soon as someone has that, they have all the access they need. Assuming you'd use your phone, then if your phone was stolen, then that person can log in.

If you feel that the risks of using this method is acceptable, then it's acceptable. But you have to understand the weaknesses of the approach and accept them as part of the deal.

Let's put it another way in an extreme case: is it "safe" (you haven't defined that) to use a password of "123456"? Sure, it does keep people out of your account, until someone tries to guess your password and tries this very, very common password. Your account is "safe" from people who will not try to guess your password (but unsafe against those who do).

Is using a super-complex random password of 30 characters "safe"? Sure, it is now safe against those who would try to guess your password, but unsafe against those who would try a keylogger, or a password database that stores everything in plaintext, or a super-computer dedicated to cracking your password.

Each layer of complexity increases "safety" and secures your account against certain groups of threats. By only using 1 factor, you reduce the complexity and reduce the number of groups that you are securing against, but perhaps that groups that remain are sufficient for your needs.


No, you don't need CSRF token

Csrf token is used to certify a request is approved by a user. If there is no gain between sending this request by your own and sending this request being another user on the network, Csrf is useless.


Finding a Webshell script in User home directories.

There are many approximations to find for LFI,RFI, Webshells, Password Grabs, Web Scanners so you could do the following :

Start by checking my access logs, it really depends what webserver I'm  using, for this part you could use different tools but if you want to build your own tool you maybe want something to start like the Irongeek's Logwatch Script which is a little old but this will give you some ideas.
Search site folders/directories for suspicious files like the popular backdoors that are readily available on the internet

sploitpattern='r0nin|m0rtix|upl0ad|r57shell|cFaTaLisTiCz_Fx|Tukulesto|99shell|shellbot|phpshell|void.ru|phpremoteview|directmail|bash_history|.ru/|brute*force|multiviews|cwings|vandal|bitchx|eggdrop|guardservices|psybnc|dalnet|undernet|vulnscan|spymeta|raslan58|Webshell'

find ./ ( -regex '.*.php$' -o -regex '.*.cgi$' -o -regex '.*.inc$' ) -print0 | xargs -0 egrep -il "$sploitpattern" | sort >potential_exploits.txt

Search site files for suspicious content with grep/findstr
using grep command line tool because most vulnerable web applications use the shell_exec,or include things like PHP vulnerable functions, so  searching for the shell_exec and inclusions in folders to check for the possible PHP files that are vulnerable to RCE or command injection.

grep -Rn 'shell_exec *(' /var/www
grep -Rn 'include *(' /var/www
grep -Rn 'require *(' /var/www
grep -Rn 'include_once *(' /var/www
grep -Rn 'require_once *(' /var/www
grep -Rn 'base64_decode *(' /var/www


Upgrade to the WebSocket protocol and security

Should we configure the WebSocket protocol in a firewall between a browser and a server?

Can you? It is unclear what specific capabilities your firewall has so it is unknown if you can do any special filtering for the WebSocket protocol at all. If your firewall offers the possibility and there is only WebSocket to expect, then why not restrict it to what you expect.

Or enough to allow only HTTPS between a browser and a server?

Again, nothing is known about your firewall can do in the first place so no recommendations can be done here.

There are some libraries (e.g SockJS) that performs a WebSocket emulation. Is it enough to allow only HTTPS in a firewall between a browser and a server?

SockJS is just HTTP(S). So exactly this should be allowed.

Last, but not least: in all cases we need to protect our application against WebSocket attacks as described in many threads here.

I'm not sure which attacks you refer to since "described in many threads" does not really point out specific attacks. But very likely a generic firewall will not protect against attacks specific to WebSockets.


At what level does session key entropy become a real-world issue?

Well, you said it. It depends on the context. Precisely, it depends on what the attacker has to do to test an hypothesis on the session key.

If the attacker, to test a key, must talk to your server, then this is an online attack and it won't go faster than what your server can do -- moreover, you could apply countermeasures, e.g. stop talking to clients that obviously engage in attackish behaviour. 33 bits ought to be enough for that. This is, after all, the situation of servers that do password-based authentication of clients.

If the attacker can just do computations on his own machines, to ascertain whether a potential session key is the right one or not, then this is an offline attack, limited only by the computing power available to the attacker. In that situation, 33 bits are way too few to be much of a problem for the attacker. Exact threshold depends on the attacker's motivation, his available computing power, his patience, and the amount of computations needed to verify one session key; but 33 bits are really too low for that.

Whether the context is that of an online or offline attack depends on the details of your protocols. If the "session key" is just sent to the server within a SSL tunnel (e.g. a cookie for an HTTPS Web site), then this is an "online attack" context. Just configure your firewall to block clients that connect too many times within a small time frame, and you should be fine (or, at least, finer than your competitors, so attackers will attack them, not you).


Can Facebook collect data on local network?

It's not Facebook that decides on their own to show him a Netflix ad. It works more like this:

Netflix decides they want to advertise to their users on other web and app properties (like Facebook). Netflix says to Facebook- I want to advertise to my users on your platform, so I will provide you with the advertisement, called a creative, and I will provide rules to you so you can identify when my users are visiting your platform. Facebook says- cool, pay me $$, and give me that creative and those rules, and I will show them your ad and give you some statistics on how often it was shown, who clicked on it, etc.

So what rule did Netflix provide to Facebook to allow Facebook to know that your friend was a Netflix user- albeit with a profile under your account?

There are lots of ways, but from what has been provided in the question, the simplest and least sinister is IP address. Your friend visited Netflix from his PS4, which from his home network reaches the internet through his ISP. He also visits Facebook from some other machine on his home network, but which also reaches the internet through his ISP, using the same IP.

Netflix says- I have a user who visited me from IP address X. Facebook says, sure, I have someone who visits from that IP. So the ad gets shown.

(Using a specific IP to target is not allowed under GDPR or- currently- under US law, but is common in other parts of the world.)

Does that help?


Can my G Suite admin see my browsing history if: I am in incognito mode on iPad Chrome?

The answer to this is very simple, and follows from the ten immutable laws of security

  If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore
  A computer is only as secure as the administrator is trustworthy

In your case you have a device someone else administers. If you don't trust your administrator, you cannot trust the device with whatever you are about to do. This universal to absolutely all computer systems.


Why do email server/clients block executable attachments?

Would it not be sufficient to use a big, fat warning

Sure, if they worked. Most people tend to just "click away the annoying" without thinking.

Blocking executables means that attackers can't do something like sending totallylegitfile_really.pdf.exe It's a very basic social engineering defense to block executables.

Attackers have to go through the extra steps like you described, and so does the end user. Those extra steps give the user a little more time to think about whether this whole interaction makes sense. That extra time is key.

If I spoof the HR department's email (or make it look similar) and send out staff_bonuses.pdf.exe and it hits the user's inbox, there is little to protect the user. One click is all it takes. To do the same as an attacker, I would have to upload it somewhere then send the link. That's going to get more than a few people curious about why HR is using some 3rd party file hosting service.

It's a basic defensive measure. It raises the threshold of difficulty for attackers forces them to use 3rd party tools and gives end users a little more time to think.


How to connect to a MariaDB database after collecting data about users and passwords with a SQLI?

Most likely, you can only connect from localhost/127.0.0.1


An alien packet from the switch shut down my ethernet card when using nessus?

From the above, you're not able to run a scan using Nessus when you connect to the EX2200 (ssg as well?) but when you connect directly to the uplink, you can run/complete the scan - is that correct?

Assuming it is, when you say the interface "shuts down," can you confirm at what level the interface shuts down?  For example, is it a physical port down (i.e. link lights go out) or is it logical (l2 or higher)?  In either case, chances are you're on the right path.  The ex220  (or perhaps even the ssg) could disable/shut-down a port if it detects certain policy violations.  Depending on how the port is disabled/shut-down, you could figure out what's causing the behavior.  Assuming you're running JUNOS 12.1, here's a link to a page with documentation for the EX series switch.  EX can run as a UTM (and other security modules) so it's possible that physical shutdown or port disablement is initiated by some module on EX.  In an enterprise, you'd be concerned if some port randomly started to initiate suspicious behavior (ip address spoofing, mac address spoofing, storm control, etc).

I'd recommend checking the security features on the ex2200 first to determine if (or which) security feature is kicking in.  Otherwise, could it be the ssg (the above diagram wasn't clear whether you initiated the scan internal or external to the ssg).


How safe is the 256-bit encryption used in bank transactions?

You can pretty much ignore the statements about 128 and 256 bits.  It is a marketing statement intended to sound impressive, but really it just means that they are using SSL in a not-totally-stupid way.

(It means the symmetric-key cipher is using a 128-bit or 256-bit key.  This ensures that the symmetric cipher is not the weakest link in the chain.  However since the symmetric cipher is not the weakest link in the chain, the risks will be primarily elsewhere, so you shouldn't get too caught up in the meaning of 128- or 256-bit strength.  This just means that they haven't chosen a stupid configuration that makes the symmetric key readily breakable.  It does not mean that the RSA key is 128 bits or 256 bits; as you say, a 128-bit or 256-bit RSA key would be totally insecure.)

There is a lot written about this topic on this site.  I suggest you read Is visiting HTTPS websites on a public hotspot secure?.  Also see the blog entry QotW #3: Does an established SSL connection mean a line is really secure?.
And read Is accessing bank account on the internet really secure? and Does an established ssl connection mean a line is really secure.  Doing a search on this site will find lots of information -- give it a try!


From another post on this site:

  It's the state of the encryption. The pending state includes new
  encryption keys, and initialization vectors. There is a write key for
  sending data, and a read key for receiving data. The state of the keys
  and resulting IVs are the read and write states.

  So when the current read/write state is overwritten with the pending
  read/write state it means that the new encryption keys and IVs are to
  be used for future communication. Until a new Change Cipher Spec
  message is received.

  The significance of these states is that they keep track of the
  cryptographic state as data is being encrypted and decrypted. When a
  new key is negotiated these states are updated to use the new key that
  was negotiated between the peers. Key renegotiation is common among
  most cryptographic protocols.

Not much to add, that answer pretty much covers it.


DoS anomaly-based detection: simplest approach beside simple threshold

I'd think the next best thing to a simple threshold would be to have some more intelligent resets in your threshold counting.  Certainly things like constantly repeating or nonsensical packets should trigger a warning sooner.  Out side of that, a lot depends on if you are worried about DoS or DDoS.  I don't know that you could do much better than a well defined threshold for simple DoS.  DDoS would require actually comparing normal traffic to current traffic and looking for differences in the patterns they fit.  That gets far too complicated for an answer here really quickly though looking in to things like Baysian filtering might be another possibility in addition to the wavelet and kalman filtering you mentioned.


Does client side hashing reduce insider risk?

Almost never.
As others have pointed out, this just replaces "SECRET" with "HASH(SECRET)". To make things worse they log the hash, which is now the password.
This is because the client is authenticated on the basis of the hash it transmits, alone; so, knowing this hash either by intercepting it at the client level or by lifting it off the logs, one can access the service at any future time until the secret is changed.
These two things together negate all logging security and create a problem (you are now logging "data, including personalised security credentials which can be used to carry out fraud", and this impacts your PSD2 compliancy).
Having a different hash on the client (for logging purposes) and on the server (for authentication purposes) would be tricky to implement, since the server guys would have no quick way of verifying that the hash is indeed correct, unless they knew the password (which would have to be stored in the clear somewhere). Using the same hash or a two-level hash might be used, I don't know, to diagnose whether the password was sent correctly (the client sends both the pass and its hash, the second gets logged and is the same as the hash stored in the auth records, or is the hash of that hash just to complicate things) -- but unless things go very wrong, this information is the same as the login status.
A better way to do this would be for the server to send a unique ID plus a timestamp, and for the client to hash together the password, the unique ID and the timestamp. The server could then send ID, timestamp and username to a black-box "oracle" that would only answer yes or no (or "OK", "NO SUCH USER", "BAD PASSWORD", "TIMESTAMP EXPIRED", "UNIQUEID REUSE DETECTED" and so on). This way:

the server does not know the password (the "oracle" does)
the log can safely contain both unique id and timestamp
the hash cannot be reused (the timestamp would go "stale" after some time)
the password never travels in the clear, only the hash does
unique id and timestamp act as salts of each other

You might be interested in looking at thinbus-srp.


Recommendations for documenting security code review

I would recommend the following information be included in a security code review:

Vulnerability Overview - This should include a high level overview of what was the problem that was discovered.  This may also include background information on the type of vulnerability.

Severity - Determine a scale such as High, Medium and Low or something that seems applicable to the software you are reviewing.

Vulnerability Details This should include specific details relating to the vulnerability as it pertains to the software you are testing.  If you have access to to the code and you can document the function in question this would be the place to point that out.

Vulnerability Remediation  This is where you suggest the solution to fix the vulnerability.

Replication Technique This may or may not be optional however you can include how the vulnerability was discovered or how it can be exploited with examples.

Of course I would include a high level summary of the entire report for the management team.


In order do pretend he's Bob, John will not only have to present Bob's certificate, but also prove that he is in possession of the private key corresponding to the public key in said certificate, by encrypting a challenge with it. So copying the certificate alone will not buy John anything.


Are Digital Signatures tuned to become harder as computers become faster?

Suppose you need to check 2^128 = 10^38 keys to brute-force. Suppose your computer checks 10^9 keys/s. In a year this is ~3x10^16 keys. Let's round it up to 10^17. If you have 10^10 computers (more than the Earth population), you would check 10^27 passwords in a year.
CPUs are getting about 20% more powerful each year. If this trend remains for 100 years (which is hard to believe), the performance in 100 years would be 1.2^100 ~= 10^8 higher than now days. Means it would be possible to check 10^27 x 10^8 = 10^35 passwords in a year.
Means, even in 100 years later even when using the whole computer power on the Earth  will not be sufficient to brute-force a 128-bit password.
Thus, there is no need to consider other algorithms because of increasing CPU power.
But one should pay attention to cryptanalysis and what attacks are getting known each year.
How strong should the signature be? It depends on your threats, on your risks, on the benefits that an attacker can get by brute-forcing your signature.


How are biometrics tougher to crack than a pin?

The issue with the biometrics is that the data being generated depends heavily on the sensor used to capture the data. I have biometrics recorded on my iPhone, my Android and my bank. As all three uses different sensors, the data they all have on record is wildly different.

Even if someone steals the data from one of my phones, that data cannot be used to attack my bank, for example. The sensor used on the ATM is different, and the binary data cannot be used to reconstruct my fingerprints. Even if I reuse my fingers on all three services.

On the other hand, if I reuse my PIN on all three, and one leaks, the same PIN can be used for attacking all my phones.

The main vulnerability of biometrics is that they cannot be revoked. If someone manages to grab a high quality picture of my fingerprint, they can make a model of my finger and maybe unlock my devices and my account, and I cannot revoke my fingerprint and issue another.


MD5 was never broken, but it was discovered there could be generated collisions hence weakening it.

I would suggest OSPFv3, it allows SHA or MD5.

OSPF is not as simple as RIP, it is intended for more complex networkings, but IMHO would be a very good choice complexity/authentication security.

This is a sample cisco config using SHA-512 (source)

interface GigabitEthernet 0/0
 ospfv3 1 ipv4 authentication key-chain ospf-1
 router ospfv3 1
  address-family ipv6 unicast vrf vrf1
   area 1 authentication key-chain ospf-1
   area 1 virtual-link 1.1.1.1 authentication key-chain ospf-1
   area 1 sham-link 1.1.1.1 authentication key-chain ospf-1
   authentication mode deployment
!
key chain ospf-1
key 1
   key-string ospf
   cryptographic-algorithm hmac-sha-512
!


How to check if an mp4 file contains malware?

To answer your questions, we have to understand what malware in an mp4 file actually means.

An mp4 file isn't an executable, so it will not run any (malicious) code directly. Therefore, if a mp4 file contains malware that wants to execute instructions, it has to exploit a vulnerability (e.g. a buffer overflow) in the program that plays the file. This can either be a known vulnerability that hasn't been patched or a 0-day.

I will answer your questions inline below:

Is it easy to bypass the google security that is implemented in gmail so that it will not be detected as virus/malware by gmail?

Depends on the malware. If it has a known signature or is easily detectable with heuristic methods, it is very likely that it is caught by a malware detection system at gmail. But if you are dealing with a 0-day, chances drop dramatically.

Once, downloaded the video, how to check whether it contains a malware/virus or not (other methods than using virustotal...)?

If you are not an expert in reverse engineering, your best bet actually are established malware detection systems like virustotal. In case you REALLY need to play the file and are afraid of infection, use a throw-away OS (e.g. in a hardened virtual machine) to play it and wipe the system afterwards.

Is it possible that the malware can infect multiple OS (Windows and Linux: mainly Ubuntu)?

Very unlikely, because the exploit probably uses a memory corruption bug, which is usually platform specific.


In theory, yes.  The Biba integrity matrix is the traditional theoretical description of such an ACL.  Unfortunately it turns out to be rather difficult to describe "integrity" in a way that facilitate development of a Biba based system.  I'm not aware of any real world implementations of Biba, although if I remember correctly, the concept was applied to parts of the Trusted Computing Station.


The issues which are talked about in the article are mostly of the following kind: the applications misuse the protocol, in that they disregard validation errors. They do so because the application developers use SSL as a black box which is just assumed to "add security" by virtue of being there. These developers are not helped at all by the state of the documentation of many SSL libraries, which, when it exists at all, is rarely clear for anybody who has not studied X.509 certificate validation.

Someone who would use his own CA would be someone who is aware of the issue and understands what is going on when a certificate is used. That is the solution: that application designer would not make the mistakes to which the article alludes. A private CA is just the logical solution towards which application designers steer when they know what they are doing. Maintaining a private CA can be complex and expensive, but that's a symptom of certification being, generally speaking, a hard problem. The important point is that application designers must grasp what SSL and certificates do and do not. As long as they do not, no amount of private CA will save them.


How can I protect my saved passwords in Chrome?

This doesnt relate specifically to Chrome, but you could take a look at services like lastpass, or keepass.  I'm not very familiar with Keepass, but I know that Lastpass uses browser plugins to notice when you are creating new accounts or attempting to login and will fill in the username/password for you automatically.  Your credentials are then stored in an encrypted format (AES-256) and only accessible once you enter your master password.  The plugins also have features to automatically log out of the vault after a given time period so that if you forget to close your vault and walk away from the computer, it will close itself.  One of the other features is the ability to require the master password to be re-entered for specific sites even if your vault is open.  This can be used to protect sensitive sites (banking, online tax return, etc) even if you forget to close your vault and the inactivity timer hasnt closed the vault yet.

lastpass is a commercial offering which stores your vault on their servers.  If you are uncomfortable with that I'm sure keepass has very similar or identical features, but does so locally on your machine so that your vault doesnt go anywhere unless you copy it somewhere.


PCI DSS compliance on storing email body in database which contains plain text password

If the user account contains protected data, then storing access to that protected data in the clear in a database would appear to go against the standard.

You might get away with it if the accounts were blank, but I can't see how you would pass a review if the account had data that was regulated by the standard.

Obviously, the best option is to send the email straight away to transfer the risk to the user.

Encryption might work, but you would have to run that past your QSA to be sure.


How can I mitigate the risk of my wifi key being shared with strangers through apps?

If you give a guest a wifi password, they can share that password though obviously you could politely ask them to not share it.  The only way to prevent that is never share one global wifi password with guests you do not trust.

The best practice would be to maintain your home wifi network (secret password, never give to others) and a shareable guest network (still with a strong password), but one you are willing to share and change frequently if your guests are sharing that password inappropriately.

MAC address filtering is probably not worth the effort, as again your MAC address is broadcast to everyone in cleartext every time you send a packet.

If you really need a more permanent solution, you could probably setup a captive portal on your guest network where users need to register their information and set up a username/password.  Then you can flag and shutoff problem accounts (e.g., if more than 2 MAC addresses use the same password then you shut it off, or if it uses more than ~1 GB of downloads, etc.).


Is signing safe from brute force attacks?

From a short look at the module it is using a plain HMAC together with SHA-1 (or SHA-512 in newer versions). This is the same algorithm as used in TLS to detect data manipulation.

But a HMAC can be computed fast. The major costs in the HMAC are the hash computation (i.e. SHA-1 in your case) which is needed twice. This means that if you have a weak secret a brute-force attack is possible. And, while Signer seems to offer the use of a key derivation function to "harden" the key the offered functions are only a single hash or a HMAC (i.e. two hashes), which don't really slow down a brute-force attack.

This means that the security of this approach lies in choosing a good secret key, i.e. some long random string instead of a comparable short password. Unfortunately the documentation does not really show what keys are secure and only makes some recommendations similar to password recommendations:

  Given a key only you know ... So if you keep the key secret and complex, you will be fine.

But from similar password recommendations we all know how secure such keys will be at the end. What you really should use is hidden in the source code in the documentation of derive_key:

  def derive_key(self):
          ...
          Keep in mind that the key derivation in itsdangerous is not intended
          to be used as a security method to make a complex key out of a short
          password.  Instead you should use large random secret keys.

The following would create a secret with 128 random bits which is sufficiently secure against brute-force attacks:

 import os
 secret_key = os.urandom(16)


Looks like there's three questions here:

1)  You should keep your private GPG key secret despite its passphrase.  Your passphrase is a lot easier to crack than the private GPG key, so even having the passphrase-encrypted private key makes it potentially easier for an adversary.
What the passphrase does is apply a layer of symmetric encryption to the keyfile, so the local computer needs that passphrase to open it.

2) If an adversary stole your passphrase-encrypted keyfile, they can try to brute force the passphrase (which is far simpler than brute forcing a 2048 or 4096-bit RSA key, even with a super-complex password); or attempt a password re-use attack (check known dumps for your previous passwords).  A strong, unique passphrase could make these attacks unfeasible.

3)  If you didn't have a passphrase and that private key file was copied from you, that key would be fully compromised and someone could decrypt your previous GPG-encrypted communications (provided they had access to the encrypted copy), et cetera depending what the key was used for.  With a strong and unique passphrase, you have a second line of defense that could potentially stop such a compromise in its tracks.

In conclusion, it's always a best practice to secure your private keys with a strong, unique passphrase.    Any passphrase makes it a lot harder to compromise the private key, and one that is strong and unique might be implausible for an adversary to ever crack.


For the kind of protection, that you want, you need a Digital Rights Management (DRM) scheme. Unfortunately, those are kind of inconvenient, expensive, or both. Also, most commercially available schemes are either broken or can be worked around.

For example if you want to count how many computers are used to open a specific copy of your e-book, those computers need to contact a server of yours. That's inconvenient for your customers, who have to be online to read your book. The will probably be limited to a certain software reader. And they have to be okay with the fact that you can track their reading behaviour. Also, when some time in the future you decide that you do not longer want to maintain the server, they might not be able to read the book any longer.

You can ask a publisher to sort the details out for you -- Amazon is not the only one offering that kind of service. That will free you of the burden to run a DRM-Server, and probably will give your customers a larger degree of compatibility as well.

If you expect to have a limited audience, a Traitor Capturing Scheme like the one mentioned in your last paragraph might be a better idea: You can for example compile a personal edition of your e-book, with the name of your customer (if it's a present, the presentee's Name) and a short text explaining that it's pretty uncool to copy this book. Watermarking, encrypting or digitally signing might be a good idea to make sure, the name stays there.


Performing AES multiple times is not useful. Breaking AES would take infinity if you use a proper key. What KeePass is doing here is making the key derivation from password slower so that a bruteforce attack would take a very long time because for each password the key needs to be re-computed (it's what PBKDF2, Scrypt and Bcrypt try to tackle).

While this may slow down dictionary attacks it won't prevent them. Preventing dictionary attacks can only be done by using long enough, random passwords.

As far as I know (I might be wrong since I'm not a cryptographer), there should not be a faster  way to compute AES^N more efficiently than N iterations of AES. The primary reason they are using this algorithm is because it's just really hard (impossible) to make computations more efficient and thus makes it less susceptible to brute-force.

I hope Thomas Pornin will be able to give you more insight on this one.


Replying to an SMS message will not have infected your phone.

(I am assuming your phone is secure enough not to be infected by trivial means like displaying an SMS)


Why should I use firewall to block ports with no running services?

Blocking not in use ports is part of security in depth (or layered security) it makes it harder for an attacker to find unintentional publicly accessible services. And if an attacker manages to access the server through some exploit to not have an easy way to create a reverse shell.

It also makes it so that your server has less things to do (than continually drop packages for not in use ports. )


Would it be okay to check only a part of a hash value

If you check only the first half of the host key you reduce the checked bits from 128 bits to 64 bits. Since there are not 2 keys but 2^64 keys which share the first 64 bits the security is not reduced by a factor of 2 but by a factor of 2^64, i.e. you don't get 50% security but 5e-18% security.

Note that even the reduced check of 64 bit might still be sufficient depending on the kind of attacker you expect. But, since you usually only need to check the host key on the first connect to a new system or on the first connect from a new system it might be worth the effort to spend a few seconds more to check the key more thoroughly.


benefits of generating temporary SSH key-pair for temporary connection

Only benefit I could see is that for example when this third-party
  forgets to delete my public key from their system and I have deleted
  my key-pair from my workstation, then if my workstation gets
  compromised, then third-party system is not in danger because I have
  deleted my temporary key-pair.

If they aren't revoking user privileges, that is their security problem, not yours.

As far as your security, modulo crazy bugs it should be safe to connect to servers with a standard key you use on other machines.  The ssh client is specifically designed with this in mind, and similarly the public key you distribute to them is specifically designed to be public.


Use a Pre-Calculated Hash for Signing a File with GnuPG

I'm pretty sure there's no way to make it indistinguishable with standard GnuPG. GnuPG is open source so you could of course modify it, and it implements an open standard so you could use another implementation (that can get/use the signing key) which is probably easier to modify, such as BouncyCastle at least in the Java version (which I use; I'm not a dotnetter) (although whether you can install Java on a security-significant system may be an argument on its own).

An alternative which is fairly common and accepted IME is to use two stages:

use sha1sum (no longer preferred) or sha256sum or similar to create a (small) file e.g. 'hash' containing the name and (hex) hash of the real file(s); if there are multiple component and/or variant and/or otherwise related files in one logical release, you can put multiple hashes and names into one 'hash' file
PGP detached-sign or clear-sign the small 'hash' file

The recipient correspondingly

PGP verifies the 'hash' file
uses sha256sum -c hash or similar to verify the real file(s) match the hash(es) in the 'hash' file

This allows a recipient who doesn't have a PGP implementation (or can't get or doesn't trust the signing key, but that's less likely) but who can get the 'hash' file securely enough, e.g. from an HTTPS website, to verify the file(s), which would range from hard to impossible with only a PGP signature.

Obviously you need to make sure that the hash value(s) in method A, or the 'hash' file in method B, is transferred from the hashing maching to the signing machine by a channel that can't be blocked or tampered by any adversary, as well as each of them being secure on its own.


It is not in the file hosting sites' best interests to be directly malicious towards end users. You'll find however, that some more unscrupulous advertising companies will load advertisements that entice you to click through which will then install things like adware. This type of advertising usually pays a little bit higher than standard banners and thus result in being more widespread among less scrupulous businesses (like some of the filehosting sites).

Off the top of my head, most of the above hosts are more or less 'safe'. You face more of a risk downloading unknown or 'cracked' applications from these sites that users have uploaded and shared links to.

You'd be relatively safe visiting these sites with an upto-date browser (and associated plugins like flash and java), AV and patched machine. If you use things like Ghostery , ad-block plus and a patched HOSTS file you'll be improving your security even more.

To say that any site is more or less safe than any other is difficult because if any of these sites get compromised then its entirely possible that they'll be unintentionally spreading malware. This also extends to the linked advertisements.

Simply put:

Block as many ads as you can
Dont click on anything that isn't the (sometimes disguised) download buttons
Don't download unknown exe's/cracks/etc from such sites
Make sure you system is patched and up-to date

Hope that helps.


Can a firewall tamper with email attachments?

When you send an email, it doesn't go directly from the sender to the receiver. It is sent via a mail protocol (e.g. SMTP) to a mail server, which then routes it to the mail server responsible for the target address, or just stores it if the sender and receiver servers are the same. From there the target asks their mail server (via another mail protocol, e.g. POP3) for any new emails, and downloads it.

For example (domain names not accurate):

Alice, whose email address is alice@hotmail.com, wants to send an email to bob@gmail.com.
Alice looks up the MX DNS entry for hotmail.com and gets mx1.hotmail.com, so she connects there and sends the email via SMTP, optionally via TLS for security.
mx1.hotmail.com looks at bob@gmail.com and finds the MX entry for gmail.com, which is mx1.gmail.com. The Hotmail server forwards the email along to Gmail.
Bob checks his email. He talks to mx1.gmail.com via POP3, optionally over TLS, and gets the email.

This is an oversimplification, since the forwarding step often involves sending the email to a mail exchange gateway of some kind, which then selects which internal mail server it should be sent to.

Whilst the protocols involved may be encrypted, the emails and their attachments are not encrypted when they reach the mail server. At any point in this chain, the email contents could be inspected or modified. They may do some form of malware scan on the files, or strip attachments based on whatever policy they choose.

The standard way of preventing this is to use an email encryption scheme, e.g. GPG. This involves encrypting the data at the sender's end and decrypting it again at the receiver's end, with keys preshared via asymmetric cryptography.


Avoiding password cracking by using custom hashing procedure?

The problem is that you would need to justify the extra design, and subsequent processing costs, against the benefits. Then compare that to simply using established, strong, hashing processes.
And, as you say, all that extra effort and cost remain while the benefit evaporates once someone knows the procedure you use.
Instead, what people do is design strong hashing processes that do not need to be a secret and do not need "custom" hashing beforehand to remain strong. This approach follows "Kerckhoffs's principle".
Yes, there are cases where "obscuring" your process can have a place, but those cases tend to be niche and obscuring solves a very particular problem. It's not a great general design principle.
A Pepper is a version of obscuring. The problem is that once someone knows the pepper, its benefit goes away. Peppers have very specific use cases.


Using a single application for user and admin (with different auth methods) vs separating them into two applications

Either option can work, if done correctly. In general, I would prefer to use the same application because it is simpler to maintain, particularly if the two applications share a lot of common code. However, there are some considerations which could tip the scales in favor of two distinct applications, mainly:

It is easier to lock down a separate HR application to more than simply a login role. For example, the Employee app may be publicly accessible via the internet, but the HR app could be locked down to the internal network, or even certain user's workstations.
It would be much harder to brute force a valid login for the HR app without having access to it.
With a single app, it is possible for a developer to make a mistake and accidentally expose admin functionality to regular users. This obviously would not happen with separate apps. (This is why I stressed "if done correctly" in the first sentence.)


Pin required for accessing (smartcard) Card Authentication Slot

The sole purpose of a CA is to issue digital signatures, specifically to sign the public keys of subordinate certificates;
Choosing a key function other than "digital signature" is contrary to this purpose.

Shouldn't you have the CA cert in the Digital Signature slot, and then a subordinate certificate (trusted by the EAPOL device) in the card-auth slot?


Should a penetration tester have training in ISO 27001/ITIL etc?

While it may not be the hardcore technical pentesting you are used to, it will definitely aid you in understanding processes and security controls within a company. This may help you to bring your findings in an understandable way to the business and IT management.

Obviously it also means you could do more than just pentesting as you could also write a standard or baseline (27001).

Don't be afraid to try something new from time to time :).


Does a secured guest network on my router create significant vulnerability?

If the router has an explicite feature to create a guest network then it is likely separated from the normal network - but you still might be liable to what the guests do since they still share the internet access for you. If the router does not have an explicit guest network but instead something else you use as guest network than it is unknown how good the separation actually is.
Of course, this is only assuming that the guest feature is implemented in this specific router like it typically is (i.e. full separation from the other network) and there are no bugs. While this is probably the case one cannot be sure.


Does Ephemeral Diffie-Hellman require a certificate?

You do need a certificate, because the Diffie-Hellman parameters have to be signed. Diffie-Hellman only makes sense if the client can rely on the authenticity of the parameters (meaning: they actually come from the server). Otherwise a man-in-the-middle attack would be trivial.

You just need a standard RSA (or DSA) certificate. In fact, the only difference between DHE-based cipher suites and “classical” RSA suites is how the certificate is used: With DHE, the certificate is only used for signatures, not for encryption.


Yes, anyone can encrypt with a public key but the use of keys in this case isn't for non-repudiation i.e. proving who sent, but only ensuring that only a specific recipient can decode and read the plain text i.e. that any interceptor of the message can't read it. This is the confidentiality part.

In order to ensure that the receiver can trust the sender, the sender needs to sign the encrypted file in some way, i.e. use some system to prove to the recipient that one person sent the file and that sender can be 'proven'. In public key systems this is done by the sender hashing the file they have encrypted and then encrypting that hash with their private key. The receiver then uses the public key of the signer/sender to decrypt the encrypted hash and comparing it with the hash they generate from the decrypted file, and, because only the sender can have created that hash, the receiver knows, beyond doubt, that the sender was the person who they said they were. This is the integrity part.


You can generate the CSR wher ever you want. The thing is, the private key is created at the same time, and whichever server is using the signed certificate in the end also needs this private key. Usually you can export this private key on machine A and import it on machine B together with the (sigend) certificate.

The minimum information required for the CSR depends on the CA you are using.


I woke up and my email has been signed up to hundreds of online services. How can I fix this?

1.How can I fix this so I stop getting signed up for accounts?

You can't - anyone who knows your email address can do this. Anyone whom you ever emailed or anyone who read an email they forwarded has your mail address; it could be nothing to do with the breach

2.Is that email address far gone and I just need to get a new one?

Maybe, but you need to balance inconvenience of changing email, and be aware that it could simply happen again at some point right after you send you first email or someone CCs you into an email; both these actions put your email address out there

3.How could this happen, so I can better prevent it in the future?

Software exists to register your email with a massive number of companies; effectively everyone who sets up a "register your account with us, we just need to confirm your email" with no barrier such as captcha or having to pay them first effectively creates a robot that can be manipulated into flooding your mailbox with junk. The real question is why was it flooded; it's less likely that the person who broke in last time is doing it just to annoy, and more likely that this flood of emails contains in the center a couple of confirmations of things they bought as you etc. The hope being that you just select all 900 and hit delete

4.Could this somehow be related to my last breach, or is it just a coincidence?

I think it's highly likely, and you should carefully examine the extent to which you were compromised; they'll have been able to comb your entire email history and find all the sites you've purchased from that may still be holding your credit card details, and possibly made purchases from those sites, not just eBay and amazon

5.What’s the point of breaching an email to sign up for hundreds of accounts in one night?

You don't need access to an email address to sign up for an account, even if they just reach "confirm your email" stage with some company, then the company still sent you an email. These emails aren't of any concern unless they're actually completing signup (indicating the third party still has access to your email). Bear in mind that if someone does have access to your email then the follow up "you're fully signed up!" could be erased, though it might be curious that the "verify your email" emails remain. The read/unread status isn't much help either as that can be toggled - what you need is a log of activity as to what IP addresses have signed into your mail and when, and review them carefully


On File delete, using java File delete method what could be the security issue?

A failed deletion is a security risk only if all of the following hold:

the target file does exist;
that file contains sensitive data;
the deletion fails for "some reason";
in the assumed attack model, the attacker can at some point access the contents of the file that was deleted, but, for some reason, would not have been able to access these contents if the file was deleted.

(The fourth condition is about an often overlooked feature of file deletion: it does not really delete the data, it just marks the corresponding slots in the physical medium as free to reuse, but the data itself may still linger for unbounded amounts of time.)

Even when there is such a risk, then there is very little that you can do. The deletion failed, so chances are that it will keep on failing; throwing an exception would, at best, prevent the deletion failure from occurring silently. Note that throwing an exception or raising some sort of alert could also help attacks, depending on the context: leaking confidential data is a security issue; killing running applications is also a security issue (if it can be forced from the outside).

It would be wrong to flag any unchecked deletion as "a security issue". At best, it could be flagged as "a bug that might be a security issue (just like any other bug), depending on conditions".


Hacker used picture upload to get PHP code into my site

Client side validation
The validation code you have provided is in JavaScript. That suggests it is code that you use to do the validation on the client.
Rule number one of securing webapps is to never trust the client. The client is under the full control of the user - or in this case, the attacker. You can not be sure that any code you send to the client is used for anything, and no blocks you put in place on the client has any security value what so ever. Validation on the client is just for providing a smooth user experience, not to actually enforce any security relevant constraints.
An attacker could just change that piece of JavaScript in their browser, or turn scripts off completely, or just not send the file from a browser but instead craft their own POST request with a tool like curl.
You need to revalidate everything on the server. That means that your PHP must check that the files are of the right type, something your current code doesn't.
How to do that is a broad issue that I think is outside the scope of your question, but this question are good places to start reading. You might want to take a look at your .htaccess files as well.
Getting the extension
Not a security issue maybe, but this is a better way to do it:
$ext = pathinfo($filename, PATHINFO_EXTENSION);

Magic PHP functions

When I store data from edit boxes, I use all three of PHP's functions to clean it:
$cleanedName = strip_tags($_POST[name]); // Remove HTML tags
$cleanedName = htmlspecialchars($cleanedName); // Allow special chars, but store them safely.
$cleanedName = mysqli_real_escape_string($connectionName, $cleanedName);

This is not a good strategy. The fact that you mention this in the context of validating file extensions makes me worried that you are just throwing a couple of security related functions at your input hoping it will solve the problem.
For instance, you should be using prepared statements and not escaping to protect against SQLi. Escaping of HTML tags and special characters to prevent XSS needs to be done after the data is retrieved from the database, and how to do it depends on where you insert that data. And so on, and so on.
Conclusion
I am not saying this to be mean, but you seem to be doing a lot of mistakes here. I would not be surprised if there are other vulnerabilities. If your app handles any sensitive information I would highly recommend that you let someone with security experience have a look at it before you take it into production.


Most probably, your account is compromised. Change your password and use Google's second factor authentication if possible.

There is also the possibility that you have malware on your system that will use your active sessions to post this kind of spam. Use a free AV and consider buying one.

Update:

I looked for your spam message, followed the link and landed on a site that enticed me to download malware detected by very few antivirus products. This adds to the probability that there is malware on your system. Antivirus should be your first action but re-installing is the safest way.


Is CloudFlare's SSL half-baked since they become the Man-in-the-Middle (MitM)?

CloudFlare isn't promising anything they're not delivering.  Any service provider decrypts the data at the cloud end; they have to in order to perform their service.  CloudFlare's architecture simply decrypts it at the point of entry, instead of at each and every service endpoint.

This offers a couple advantages to their clients:  they don't have to do anything to maintain their certificates, and they aren't paying any performance or CPU penalties to re-encrypt the internal traffic.  Meanwhile, their customers see https locks, and are comforted.

Is the data from the CloudFlare server traveling in cleartext to the web service?  Sure.  Who can intercept it?  Backbone providers, and other large entities.  In some cases they're trustworthy, in others they aren't.

But if the NSA or other Three Letter Agency has a warrant, National Security Letter or other desire to view the data, they're going to find a way with or without this architecture.  In a repressive regime like Iran, China, or other, they're going to demand this access anyway.  No decision CloudFlare makes will change any of that, so they may as well use the cheapest architecture that provides the most benefit.


How to prevent abuse of SMTP by sending spam emails?

At first glance, your first log line looks like your mail server is trying to send bounce messages to fake senders.

In other words, you get spam with a fake sender. This gets rejected, and your system tries to return an error message but fails. The bounce gets put in the deferred queue, to be tried again.

Short-term solution is indeed to clear the queue (but use postsuper -d ALL deferred to clear only that specific queue). Also first make sure there isn't any useful e-mail in there (mailq or postqueue -p).

But also, it seems that your server is on some kind of blacklist, which may be caused by your system being abused by spammers, but could also just mean that your hoster has a poor reputation for spam (reputation systems sometimes work by blocks of IP addresses).

See also here: https://serverfault.com/questions/115161/fixing-my-mtas-poor-reputation


Strange HTTP request from binaryedge.ninja

The company isn't 'attacking' your servers, rather it's just part of a scan that the company provides as a service to it's customers.

On their website they claim they "scan the entire public internet to create real-time threat intelligence streams...bla bla bla". Basically they scan the internet, and provide the data to their customers.

These logs are probably just the result of them trying to scan whatever HTTP things you've got on your server.

Nobody likes having their server being poked at by a unknown third-party, sometimes you can reach out to these scanning services to get your IP removed from the scanned results -- not sure how effective that's going to be though.


What is blocking me from accessing my locked Android's file system on my unencrypted phone?

When you attempt to access files through a USB port against a running phone, that access is mediated by the running OS.  That OS has rules about what can grant access - and one of those rules is (generally) that the phone must be unlocked (and often specifically configured to allow USB file access).

This is because the phone OS is designed to protect the legitimate owner and their files - they have no reason to allow the OS to provide the files unless you can demonstrate you are legitimate (by unlocking / configuring).

Encryption is intended for a separate purpose - for preventing you from doing an end-run around the OS.  The data is, after all, stored on NVRAM (or equivalent - not an expert on phone storage) - for someone willing to directly access this memory using hardware (or for someone able to root the phone without clearing the storage), the OS protection is nullified (since it either isn't running (hardware attack) or is under control of the attacker (root))

File System Encryption prevents access to the data even if the user can access the raw bytes on the file system - without the key, that access becomes useless.


Does putting salt first make it easier for attacker to bruteforce the hash?

Actually, you are tackling it the opposite way.

It is true that doing hash(salt + password) would allow you to precompute the salt (but see note below) and only hash each password candidate for all those trials. The cost be the same you would bear if you were not using a salt at all.

However, the goal of the salt is not to make bruteforcing a single hash harder, but to ensure that the hashes for different users are different even if they chose the same password and so the cracking effort can't be applied for multiple users.

Let's assume you dumped a PayPal database hashes where they were using MD5 hashes. You want to check passwords 'paypal', 'PayPal', 'PayPal123'...

If they used MD5(password), you can trivially hash any of them and find out if anyone is using such weak password.
If they used MD5(salt + password), you could precompute the partial MD5(salt) for everyone, but still need to hash each password candidate for each user.
If they used MD5(password + salt), you could precompute the partial MD5(password) for each candidate password, and then apply their salt for each user.

#1 is clearly the worst here. You could argue between #2 and #3 based on the different lengths of passwords and salts, as well as the number of users, but I would consider #2 to be preferable. Based on length alone, the enforced minimum length for your passwords is probably higher than the salt size. But I suspect there could be other weakness with the #3 construct, too.

Is it a significant advantage?

Not really.

First of all, many hash functions work in blocks, and the precomputation for values smaller than the block size simply store a copy of the "precomputed bytes". In 99% of the cases the length of both salt and password will be shorter than the block size, so actually there would be no real precomputation being performed. You would need to be using really long strings there for that to be of use.

Additionally, any modern password hash function will at the very minimum use many iterations, if not using more advanced means to make bruteforcing expensive, and your optimization is only applicable the initial iteration.

In any case, rather than simply concatenating salt and password, the most secure way to combine them would be to do an HMAC over them, which mixes them in a better way.


Use of JavaScript by LastPass to encrypt & decrypt the password database a secure approach?

Lasspass is a browser plugin and is not vulnerable to MITM attacks to its javascript the way that a website is. The plugin resources are not installed the same way that a website requests its javascript files via http requests.

Javascript is not inherently more vulnerable to attacks other than the nature by which the code is requested and loaded. (MITM)

It can however be considerably slower than native code (internet explorer), but it can also be considerably faster than native code implementations (Chrome's V8 engine).

From LastPass's website login, the valid HTTPS certificate authenticate's the resources loaded by the browser. Certificate authenticity can be confirmed by looking to the left of the website address at the top of the window.

Same Origin Policy along with SSL prevents malicious iframes from hijacking any javascript resources that may be loaded in the child frame.


Extensions and Modules and Packages, Oh My!

The safest way is to vet it yourself by reading the source code before installing and the changes before each update. You can find guides to read each browser's extensions/addons source code here:

Chrome
Firefox

As for Visual Studio, you can choose only the extensions which are open source and read their linked repository from their marketplace page.

Regarding security policies, I believe most big companies have a policy for vetting each extension being installed in any service. You'll need an application or infrastructure security team for that.


What can I do to separate users best way if they are allowed to run their ruby (python) code

I'd say your best bet would be to have each user on a virtualized environment where you can sandbox their activities. That is assuming your server can handle the additional load.


Is it possible to modify your user agent http header for malicious use?

Yes. You should research what exactly goes in an HTTP request.

The user agent is easily changed as it is set by the client. There are many tools that allow you to change your user agent for your browser. If you are using curl, you can also just craft your own HTTP request and set the user agent to whatever you like.

If a web application depends on a user agent for security purposes, this is 100% vulnerable.