What is the proper terminology for the various SMTP tunnel encryption solutions?

I've mostly seen the first case referred to as "SMTP with STARTTLS" and the 2nd as "SMTPS".  The first case is defined by RFC3207 which has the name "SMTP Service Extension for Secure SMTP over Transport Layer Security," but that's too much of a mouthful for use in documentation.  I've also seen "the STARTTLS extension" when the rest of the context makes it clear that SMTP is being discussed.


Ethical Hacking - Penetration Testing Book(s)

As a penetration tester I don't think that books are the best medium,  because there is no substitute for experience.  Hunt for bugs in open source software,  obtain CVE's and put that on your resume.

...That being said there are books that I have enjoyed and that i think are relevant to modern systems:

The Tangled Web

Cryptography Engineering  (Formally known as Practical Cryptography)

Exploiting Software:  How to Break Code

A Bug Hunters Diary


Secure high-portability way to store passwords?

On today's systems, you can use TPM. It can be used to store (or wrap) the root key and protects additional keys created by an applications. The application keys cannot be used without the TPM, making this a very useful authentication method for endpoint devices.

Read about the how-to here .

Another advanced method which will probably be used a lot in the future is to use Physically Unclonable Functions.  Instead of keys being stored (and susceptible to reads), keys are instead derived from unique physical properties of a chip’s SRAM memory and exist only when powered up. Using an SRAM-based PUF, the keys are guaranteed to be unique since they utilize the inherent randomness in silicon bit patterns. Even if this sounds more futuristic, it's something usable today.

PUF Details and documentation about key storage using this method.


Is there a point to obfuscating form field values?

I can absolutely see the value in this: if you are supplying sensitive information to the client-side that you hope the client never sees.

One used to see this when you had hidden form fields, like "sale_pct". If a user was able to see that field, they could modify the sale price, and potentially buy product at a negative price. Don't laugh. It happened.

The much, much, MUCH bigger question is why one would rely on obscurity on the client side at all. Don't send it to the client if you don't want them to see it. But maybe the business has a legitimate reason to rely on this ... I doubt it


What makes linux systems more appropriate for pen testing?

Pen testing means interfering with multiple different components of a remote system, working at different levels of abstraction - crafting a customized single network packet, or sending a specific series of interactions via HTTPS while capturing/replaying cookies.

Further, each case is slightly different - you are constructing attack tools out of the available primitives as you go. This is how Unix works - its a bag of tools which allow a competent person to solve problems. Unix is an IDE (integrated development environment).

MSWindows on the other hand is a platform for running programs. There's little economic justification for third parties to build the granular tools which are so common on Unix systems that we think of them as part of the OS. Its only really practical to make money by building "solutions".

A really important consideration for doing pen-testing is that you need to be able to protect your system against the munitions you are deploying and potentially against counter measures. Unix has always been a multi-user system and the concepts of permissions and privilege seperation run deep in its design. Historically there has been a lot less malware targetting Unix than MSWindows.

Linux distinguishes itself from other versions of Unix by being open-source, well-supported and running on cheap hardware. Most of which could also be said about BSD - but typically Linux is delivered in a more user friendly package.


What's the algorithm to generate a modulus and a base for a Diffie-Hellman key exchange app?

The easiest method to generate the DH modulus and base (collectively called the "DH parameters") is to use values which have already been generated. This does not imply security issues -- several people can share the same DH parameters without trusting each other.

Technically, you need three values: the modulus p, the base g, and the sub-group order q. Ideally, q should be a prime integer, and gq = 1 mod p.

There are nice pre-generated values in RFC 3526 and RFC 5114.

If you want to make your own, then the basic algorithm is "try random values until you hit a prime", but there are details. You have basically two choices:

Generate random q values and compute p = 2q+1; do that until both q and p are prime. When you have found a q and p with these characteristics, then you can use g = 4 as base; it is guaranteed that g will have order exactly q.
Generate random q values of the "right size" for a sub-group order (say, 256 bits) until you find a prime q. Then generate random values r and compute p = qr+1 for each r; do that until you find a prime p. At that point, generate a random value h and compute g = hr mod p. That value g will have order q (it is theoretically possible but in practice highly improbable that you get g = 1; in that case, generate a new random h).

The first method allows the use of a very small g, which gives a slight performance advantage when using Diffie-Hellman (not a big advantage in practice, something like a +15% speed at most when proper optimizations have been applied). However, generating the modulus p with that method is quite expensive, because you have to try about a few millions of q values until you find one such that both p and q are prime.

With the second method, parameter generation is a lot faster, since it goes in two stages: first finding a prime q (a few hundred tries), then a prime p (a few thousand tries). It also gives you a relatively small sub-group order, which can be nice too. However, you end up with a "huge" base g. This method is really what is done in DSS, as specified in FIPS 186-4, so if you want a formal specification with all the details laid out, go read appendix A of that standard ("Generation and Validation of FFC Domain Parameters").

In any case, you will need computations on big integers, including modular exponentiations and primality tests. Java provides both in java.math.BigInteger.


Is it secure to store a cryptographic key in a class member variable?

It depends on your threat model. Will a potential attacker have access to the machine?  Might they be able to escalate their authority enough to either dump the process space of the application, or to attach to it as a debugger? Or if you’re concerned about the attacker downloading the entire database and being able to decrypt all the images, consider moving the decryption process or image storage to a separate machine with better security. Or you could encrypt each image with a unique key, and keep each key in a remote database, and use the user’s database to store their master decryption key.

If your concern is that a rogue or compromised client will download each decrypted image in an attempt to acquire the entire database, consider a monitoring process that alerts you to excess activity. Also, consider slowing down each key or image request (this process is known as “trust anchor dragging”) making it harder for anyone to download the entire database in a reasonable amount of time.

Rather than use a private member to store the key, use your platform’s provided cryptographic service library. On Windows, use the CryptoAPI. In Java, use the Cryptographic Service Provider. These tools are designed for secure storage of keys.

If you can’t use the cryptographic library, the key might be persisted in swap space, and end up on your hard disk. If you have the option in your language (C/C++, go, ASM) consider allocating memory using your operating system’s secure memory function, such as mlock() or VirtualAlloc().


This may or may not answer my question, but I did some digging after asking the question and I've got a solution that's working for me at the moment. I'll outline it below.

First of all, there is a useful command line tool called oathtool. You can use it to generate the 6 digit codes for 2fa using your 2fa key. The steps are outlined here.

So one solution that addresses my convenience complaint is that I could store my 2fa key in my password manager, and write a script to generate the 6 digit code from that.

However, this removes the "something you have" aspect of 2fa, which I would like to keep. To address this, I did the following:

Store the 2fa key in an encrypted file, and store that file on a flash drive.
When I plug in my flash drive, mount the folder containing the (possibly many) 2fa keys into a folder my password manager can see. I use pass, so this is very easy to do. At the moment I do this manually, but I may try to automate it.
The interface is something you can customise, but I wrote the following bash script, called 2fa:

pass 2fa/$1 | xargs -d '\n' oathtool -b --totp

The net consequence of this (with my naming system) is that I can write 2fa gitlab and get the 6-digit code at my terminal. I have another script that writes it to my clipboard, and prompts me with a list of names (the same interface as my password manager).

Of course, none of this works without the USB drive, which makes it a bona-fide "something you have" solution. However, it will only work if you can decrypt the gpg files, which requires my private key. I only use 2fa on a few trusted machines at the moment, so this is okay for me. If I needed it to be more versatile then I may reconsider using a phone or Yubikey.

I welcome criticism or ideas for improvement, especially if there are any obvious vulnerabilities to this system that I've missed.


If you have people connecting to mysql you have already seriously messed up.  You need to change your firewall settings to make sure that only trusted hosts can connect and no one else.

An attacker could easily summon a bot net of 1,000,000 in size to brute force your mysql server.  You need a white list approach to this problem.


You are correct that brute force attacks are feasible, especially if the data being hashed comes from a relatively small search space. Here is a recent example where New York cab details were inadequately disguised using a hash. From the article:

  It turns out there's a significant flaw in the approach. Because both
  the medallion and hack numbers are structured in predictable patterns,
  it was trivial to run all possible iterations through the same MD5
  algorithm and then compare the output to the data contained in the
  20GB file. Software developer Vijay Pandurangan did just that, and in
  less than two hours he had completely de-anonymized all 173 million
  entries.

Note that it is not the use of MD5 that is the problem here. Any hash algorithm could be brute forced in exactly the same way.

It may be possible to render the hashing irreversible by adding salt before hashing; however at that point you would do just as well to create a lookup table mapping sensitive data to entirely random values—then there will be no hash algorithm to break.

Of course this all assumes that there are associations in the data that you wish to preserve after anonymising. Otherwise the safest approach is to entirely omit or mask any sensitive data.


As a private individual, what might I learn from hiring a pentester for my home network?

There are two primary assessment types that a penetration tester can provide: internal and external security assessments. There are many other subcategories within this classification, but for simplicity's sake, let's talk about these two primary types of penetration test.

An External Penetration Test is conducted from outside your network -- from the Internet. This simulates what an arbitrary online attacker might see, and could identify flaws in services you're running that are exposed to the Internet. For example: if you were running a web server at home, but potentially forgot to patch it, a penetration tester might be able to exploit known vulnerabilities and pivot into your home network.

An Internal Penetration Test places the security assessor inside your home network. In this case, you would either grant the pentester physical access to your home, or spin up a VM with VPN access, or something similar. The scope of this test is much different: you don't need to be running any public services to be attacked. A tester in this scenario would be able to scan your internal network, identify devices, and -- depending on your network configuration -- might even be able to sniff your network traffic.

In my experience, you probably wouldn't find much on an External test (unless you're using your home as a server host of some kind), since most people don't have any Internet-facing services. Maybe your router has a web interface that could have vulnerabilities or misconfigurations -- but more likely, the report would be relatively empty.

An Internal test, on the other hand, would almost certainly identify weaknesses in your home network. The question for you, then, is whether untrusted individuals are being given network access in your home. If they are, and you want to see what a skilled attacker might be able to pull off, this could provide some valuable insight.

In truth, if you're keeping all your systems and software up-to-date and aren't running any Internet-facing services, you're probably relatively OK from a security perspective. If this is the case, your biggest threats will be in the form of spearphishing/social engineering, or online services you use getting hacked. Don't re-use passwords (use a password manager + random passwords), and don't upload data to services without thinking about what would happen if they were breached. Utilizing full-disk encryption on your hard disks keeps you safe in case of physical theft of your computer.

Here's the really short answer: you probably wouldn't learn much from an External test, and you'd likely get compromised by a skilled attacker that's already on your Internal network. It is probably not worth the cost, but you won't know what an assessor would find without buying the assessment!


How can someone use my phone to make an outgoing call and have it show up to network provider as my number that made the call?

There are many reasons this could have happened but there is one primary that springs to mind:

Error on Provider Network causing the disconnection and an erroneous forwarding and recording instead of a proper reconnect

This isn't that uncommon, especially during maintenance windows. It is however always startling.

Basically what happened is that you changed communication points. Usually during these times you're handed off without interruption in service by being forwarded to the new point. It's why you can make a call and it will keep in contact as you cross points.

However every now and again you make a call and the forwarding logic hits a hiccup, and instead of being forwarded correctly your phone's link to the point has gotten confused and it thinks it's supposed to make a call.

In the cases the dropped call is seen as received because the call received a forward notice... that instead initiated the call out.

To be certain though you should DEFINITELY call and confirm this was the problem with your provider. The main reason we can come to this conclusion however is that your records show and incoming call when it was actually outgoing on one record, but the correction on the other. This shouts carrier error but it's always better to get an authoritative answer form the source.


Generating QR code from seed in browser - possible security issue?

A lot of what happens on the user's machine is going to be out of your control, and reliant on a sanitary system and/or browser isolation.

To that end, you can just do your best to clear the memory contents when you're done. Perhaps fill a byte array with zeroes, or explicitly delete a property reference if you're paranoid. Though the latter at least won't force the GC to clear the memory, and it will do this in its own time.

It also boils down to the fact that if you have a machine or browser compromised in some way that browser memory is being read from your site's tab, then you have bigger problems.


Insecure Direct Object Reference - Change email from client end

No, this is normal behavior. Because the reset password email is sent to that user, only the owner of the email address can reset the password. So even though you can trigger the email to be sent, it is not possible to actually reset the password of another user since you don't have access to the link in the email. Most sites work this way, where you can enter a username or email address to request a password reset for.

However, if the password reset functionality makes it possible to bypass two factor authentication, it is a serious issue. If a user has SMS tokens as second factor and the application also allows password reset through SMS, having access to SMS messages gives total access to the account.


Passwords propagation, Password Trend and Word Generator in Human Mind

I think you're misunderstanding users.  People can't be understood as code (i.e. a "biased word generator").  People have different motivations and understandings of the world than you do or I do.

Some really don't care if they get hacked.  Some don't understand that automating attacks are relatively trivial.  Some think that "why would anyone attack me?".  They don't understand that automation doesn't care about them personally.

RockYou is a free "social media gaming website".  Is that really a site that a lot of users care about security?  I wouldn't, and would likely use an easy to remember password that I don't care about.  I also didn't care about my NY Times password back when they required registration.  I believe it was "password" (Go ahead hax0rz, hack my NYT account!).


Stolen Remote Desktop Protocol (RDP) credentials

Truthfully the best way would to protect yourself from having your credentials stolen is to protect them.

If you are building a login script make sure the password is not hardcoded into the script.
Have a strong password against bruteforce
Change your password every 30 days or so (Windows has a built in reminder that can be turned on)
Do not share the password with anyone you do not trust
Keep your system up to date so all vulnerabilities are patched

  Are there IDS for such events?

I was not able to find one but you could use the RDP log file to make sure there is no intrusions (Depending on your windows machine the log system is in different locations. A quick Google search will find you the location)


SSL Mixed Scripting Vulnerabilities and XOR Attacks

What you call the "XOR attack" is based upon the secret stream being reused; i.e. there is some secret stream S, data D that gets encrypted by XORing it with S, and some other data D' that gets encrypted by XORing it with the same secret stream S. In that case, if the attacker knows D he learns D'.

However, when RC4 is used in SSL, the key is brand new for that connection, and the various data elements that get encrypted are XORed with different parts of the stream. An important security feature of stream ciphers is indeed that key-dependent stream bytes cannot be guessed from knowledge of other bytes of the same stream. A good stream cipher is akin to a cryptographically secure PRNG: without knowledge of the key, chunks from the same stream still appear unrelated to each other.

(Of course RC4 has its own shortcomings, e.g. known biases; but, at least, SSL employs it properly, i.e. with a new key for each connection.)


I would say that the conceptual difference is one of primary functionality.

Certification Rules lay out how the system certifies that a particular data object is in a valid state (according to another set of rules).  Enforcement Rules make sure that already-certified data object stays certified (maintains its integrity) as the system interacts with it.

To be more specific using Clark Wilson IM vernacular:

Certification rules specify how to guarantee that a CDI has been subjected to integrity verification procedures.  Enforcement rules specify how the system must maintain the certified CDI as transactions happen.


Alternatively, you can simply capture all traffic as pcap and run snort rules in offline mode for research/investigation.


It depends.
There could be benefits if you envision theft of the key and want to ensure that it cannot be used after a period of time. This is why you'll also want to generate a revocation certificate, but I suppose that could also get lost.
However, the benefits of not having to move around an offline key every year or so could outweigh the benefits of setting an expiration, if that is suitable for your threat model.


Can someone figure out the encryption method?

There are three solutions here:

Try to find the encryption method. It can be something custom, it can be encrypted in all sorts of weird ways, and you might need a key from somewhere. This is what you are trying to do now.
Find the code that encrypts/decrypts the data.
Write a script that simply calls the decrypt function for all records.

I'm not sure which is easier, 2 or 3, but trying to figure out what kinda code this is doesn't seem like the way to go.

Moreover, this is a problem specifically for you. It's not useful for future readers if it was solved using solution 1, thus the question would be closed as too localized.

I don't know why you didn't try solution 2 actually, can't you read VB well enough to find it or so? I don't mean it accusing, but if you can't find the code or script something to fix it (solution 3), you might want to find someone who can. It would probably save you (and anyone trying to find what encryption it is) a lot of time.


A peek at the source code, especially the AES256BitExpress.cs file, reveals the following excerpt:

    public static byte[] AES_Encrypt(byte[] bytesToBeEncrypted, byte[] passwordBytes)
    {
        byte[] encryptedBytes = null;
        byte[] saltBytes = passwordBytes;

        using (MemoryStream ms = new MemoryStream())
        {
            using (RijndaelManaged AES = new RijndaelManaged())
            {
                AES.KeySize = 256;
                AES.BlockSize = 128;

                var key = new Rfc2898DeriveBytes(passwordBytes, saltBytes, 1000);
                AES.Key = key.GetBytes(AES.KeySize / 8);
                AES.IV = key.GetBytes(AES.BlockSize / 8);

It uses AES (with a 256-bit key), which is good. It derives the key and IV from the password using PBKDF2 (that's what Rfc2898DeriveBytes implements), which is kinda OK (though 1000 iterations are a bit too low for comfort with modern machines). It uses the password itself as salt for PBKDF2, which can be described only as "atrociously weak". This totally ignores the point of the salt and allows parallel attacks, including time-wise parallelism (also known as "precomputed tables").

This is a nice illustration of how sane, secure algorithms can be assembled into something which offers only very little security. I can only advise against using that software for any security-related purpose.


Backing up an encypted drive on an encrypted drive

You can encrypt encrypted material as many times as you like and assuming proper implementation by your software vendor, should also be able to unwrap all of those layers of ciphertext without issue.

However, keep in mind that if you have ransomeware running on your system and it is encrypting the data it has access to, every time you connect your primary, secondary, tertiary -> ad nausem, drive to the system, it runs the risk of also being partially or completely encrypted by said ransomware.

A point of clarification, BitLocker does nothing for you to protect against ransomware.  Drive encryption or whole-disk encryption protects your drive if it is physically stolen.  Then an attacker would have to have your key to unlock the drive and read the contents.  While your machine is turned on, the key is dynamically decrypting the drive on the fly so to your OS (Windows), it does not appear encrypted at all and can have individual files encrypted with no problem.

Your best bet, in my opinion, to protect against ransomeware is to rotate your backup cycles with different hardware.  Lets say you perform backup once every two months.  Use 3 different same sized hard drives (don't necessarily need to be encrypted) that you rotate their use.  Each containing roughly the same amount of data.  If you lose your computer's drive to ransomware, you have 3 drives over a 6 month period that is less likely for the ransomeware to be patient enough to get all of them.


Canary token on desktop triggers when I plug in my phone

Windows Explorer Canary Tokens are used to trigger "browsing activity" within a specific folder and not system wide.

You have put the desktop.ini file on your desktop, which will for sure trigger the alert action.

Canary code should look like:

[.ShellClassInfo]
IconResource=\\%USERNAME%.%COMPUTERNAME%.%USERDOMAIN%.INI.TOKEN.domain.tld\resource.dll

try to put the file inside a folder: C:\testfolder\desktop.ini let's say, so that whenever someone tries to "browse" that path as in C:\testfolder\ locally or within the network (if the folder is shared), an alert will be triggered.


SQLMap extracts weird chars in one column

Try playing with character encoding options:

--charset=CHARSET


Your assumption is correct, with one limiting factor: any encrypted content can only be accessed when iOS has been unlocked, even when jailbroken. It's not much of a limit, but there it is.


Is it possible for a vulnerability in one application to be exploited to attack another application on the same server?

If the Magento vulnerability led to a shell, then that shell could be used to get root access by a privilege escalation vulnerability. When that happens, the attacker has complete control over the system.


Common forms are PKCS#12/PFX (an encrypted key pair, possibly with additional certificates) and PEM or DER form PKCS#1 as used by OpenSSL and OpenSSH (that's what id_rsa will be). PEM is a base64 version of the DER binary (ASN.1) form with identifying header/footer, it's not otherwise a distinct form, except that it allows encryption where as PKCS#1 DER does not.

If the key is encrypted (PEM form only) it will contain extra header lines to indicate the encryption and IV, e.g.:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,AA171F6005B3DD31
...

PKCS#1 is RSA only, PKCS#8 is a more general purpose "container" for keys, it too is ASN.1 but it explicitly indicates the type of data within, e.g. (see offset 9, line 4):

$ openssl pkcs8 -inform PEM -in ~/.ssh/id_rsa -topk8 -nocrypt \
  -outform DER -out id_rsa.p8
$ dumpasn1 -tilda id_rsa.p8
 0 1213: SEQUENCE {
 4    1: . INTEGER 0
 7   13: . SEQUENCE {
 9    9: . . OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
       : . . . (PKCS #1)
20    0: . . NULL
       : . . }
22 1191: . OCTET STRING, encapsulates {
26 1187: . . SEQUENCE {
30    1: . . . INTEGER 0
33  257: . . . INTEGER
       : . . . . 00 B1 1F 09 61 C1 A1 09    ....a...
 ...

(I'm using dumpasn1 here instead of openssl asn1parse, embarrassingly, the latter fails to parse the pkcs8 output correctly.)

OpenSSH doesn't (AFAIK) support PKCS#8 other than for import/export, they have their own format. That format is used for newer key types only (Ed25519) but is planned to be the default in future.

There are a few things you can usefully check:

identifying header/footer line in PEM, and base64 encoding validity
valid ASN.1 format (mostly limited to type and length checks)
numeric integrity of RSA parameters

You might also ruminate on the value of the public exponent (too large can cause interoperability problems, too small is implicated with security problems for some applications).

The openssl rsa ... -check command checks 1 (PEM only) and 2 implicitly, and 3 explicitly. See the OpenSSL API RSA_check_key() documentation for details of the checks. That should be sufficient checking for most, I think.

An RSA private key file (almost always) contains more than just the private key exponent, it also contains the public key parameters and some intermediate values for optimisation (via the CRT), those values can be checked for consistency or primacy. The "key size" is the length of the ''modulus'', with the caveat that there will (usually) be a leading 00 byte to ensure it's interpreted as a positive integer (ASN.1 signed-ness issue).

For a different view you could also do:

openssl asn1parse -inform PEM -in ~/.ssh/id_rsa

(but that does not check the RSA parameters)


Problems with destroying your SSL private key?

A local copy of the certificate really makes no difference one way or another - anybody who knows your domain can pull a functionally identical copy.

The private key is needed by your server, notably, to negotiate the key-agreement protocol

  When Alice and Bob have a public-key infrastructure, they may digitally sign an agreed Diffie-Hellman agreed key, or exchanged Diffie-Hellman public keys. Such signed keys, sometimes signed by a certificate authority, are one of the primary mechanisms used for secure web traffic (including HTTPS, SSL or Transport Layer Security protocols)

It also ensures the confidentiality of the messages it encrypts more generally, using Public Key Encryption:

  The encryption process of using the receivers public key is useful for preserving the confidentiality of the message as only the receiver has the matching private key to decrypt the message. Therefore, the sender of the message cannot decrypt the message once it has been encrypted using the receivers public key. However, PKE does not address the problem of non-repudiation, as the message could have been sent by anyone that has access to the receivers public key.

You could arguably delete both once they are loaded into memory, if they are assured of remaining there - i.e. your server will never suffer any unexpected event.
That, however, seems a bad bet to make.

As mentioned by @Arminius, the key can also be used for things other than TLS, such as PKI-related activities.


None of those options are great, although (1) is the worst. The bottom line is that SRP is a fantastic idea, but it's difficult to see how to deploy it. Especially as browser support is patchy - beta quality plugins for a handful of browsers.

If you want to make a practical working site now, use (3).

You could, in theory, use (2) over SSL with anonymous Diffie-Hellman so there's no CA. In that case, on your first exchange, you don't know who you're talking to. But in the future you at least are sure that it's the same site. So perhaps you sign up at first with no trust in the site, build up trust over time, and have the confidence that an attacker couldn't then impersonate the site you now trust.

It does raise some broader issues of trust and how you transact online. A lot of consumers like the model of "I know Amazon are trustworthly, I want to use them" and the existing CA model matches that quite well. If you're more into peer-to-peer, non-hierarchical arrangements, then how do you establish trust online?

Your question only covers online registration - if you have another arrangement, such as in-person registration, you may have better options.


What does chacha20-poly1305@openssh.com mean for me?

Two things that it means to me are:

it's a stream cipher, therefore not parallelizable.  Although it's a stream cipher, it has a randomly accessible output stream (PDF), so it can be parallelized (unlike RC4, and stream ciphers in general). Poly1305 is also parallelizable

SSH already has a set of counter mode block ciphers which are parallelizable (RFC4344 Section 4) though they don't get you a performance gain out of the box. ChaCha20 (20 rounds) is a little faster than RC4, comparing cycles per byte, and is faster than AES256.
it's an extra algorithm in the SSH negotiation

The second point needs some elaboration: there have been a number of extra key-exchange (EC), MAC (SHA-2) algorithms added recently, and now another cipher. This increase causes problems with older (including embedded/devices) SSH server implementations. In SSH the various algorithms are spelled out, rather than having short, fixed identifiers like TLS. The workaround is to chop the list down with explicit Ciphers, MACs and/or KexAlgorithms in your ssh config. There's also the potential for protocol enforcing firewalls or IPSs to misfire.

I believe one protocol difference between TLS and SSH is that the authentication, key-exchange, cipher and MAC are identified and negotiated independently, with TLS each publickey-kex-cipher-mac set is one of a defined suite. Poly1305 adds authentication, so ChaCha20-Poly1305 is (effectively) an authenticating stream cipher, no separate MAC is required by SSH for it, the benefit of this is explained in David Miller's article linked to in the question.


Firefox can import the .p12 format, but that contains a private key? Isn't this a security risk?

The private key is need by Firefox for client authentication, i.e. when the client demonstrates to the server ownership of a certificate. By definition, this requires knowledge of the private key on the client side. This does not happen often, because most Web servers authenticate clients with passwords, not with certificates.

Of course, Firefox has no need of the private key corresponding to a server certificate, and in practice won't have access to that private key.

Generally speaking, the less a private key travel, the happier we are. However, when it becomes necessary, for some reason, to transport a private key and its accompanying certificate, then we prefer to do it with some extra security to maintain confidentiality; this often uses the PKCS#12 format, also known as "PFX" or ".p12". Such a file is an archive which can contain just about anything, but in particular certificates and private keys, and (that's the point) it includes password-based encryption: parts of the archive contents (e.g. the private key) can be encrypted with a key derived from the password chosen to lock the archive.


Notepad++ updater had no tittle or info. Is this okay?

This is perfectly fine.

When a program opens a window, it sends to it a few parameters including the window title, main text, button labels, etc. In this case, it seems like the updater simply hasn't given any such information. It's silly from a UI point of view, but there are no security implications with this behavior.


Encrypt part of users' data in web application vs. password recovery

Question 1

  Question 1: Are there any obvious security flaws in that scheme
  (except that the attacker can access the data of all logged-in users)?

Proposed scheme:

Registration

The user digests a password key P from the plain-text password p using SHA 256
The user sends this key over a secure connection to the server
The server generates a random key k which is used to encrypt data before it's stored
The server encrypts k with P and stores it for later use

Authentication

The user digests the password key P and sends it to the server
The server decrypts k and stores it in memory

Security concerns

Password derivation

The above scheme suggests p to be hashed. This alone does not ensure "perfect" forward safety since a hash value can be looked up in a Rainbow Table to retrieve the user's plain-text password. Attackers can also use one cracked hash value to determine other users' passwords due to the lack of salts. These concerns are mostly privacy related ones since they only cover what could happen when the database has been accessible to attackers.

To conclude the above mentioned vulnerabilities:

Rainbow Table lookup
Brute Forcing
Identical hash values

What to do to address the issue

Registration

The user generates a random salt S of sufficient size
The user derives a password key P from the plain-text password p and S using a strong key derivation function such as PBKDF2
The user sends this key along with S over a secure connection to the server
The server stores S
The server generates a random key k which is used to encrypt data before it's stored
The server encrypts k with P and stores it for later use

Note:
The salt should be unique to the user and the key derivation function should run for as long as possible (calibrate it to run for about a second).

Question 2

  Question 2: To what point does this way of doing the password recovery reduce the effect of the encryption? (Is it still worth doing?)

Proposed scheme:

Registration

The user's email is sent alongside P
The server encrypts the user's email and P with the recovery server's public key and stores it

Recovery

Disregarding the actual "user selects new password" part ( identical to the registration process )

Server sends the user's email and password key ( which are both encrypted with the recovery server's public key ) to the recovery server
The recovery server decrypts the requested data and sends it back to the main server
The main server is able to encrypt the data with the new password key

Security concerns

There is always a physical threat when using "master keys". It is good that you've understood that it is vital to have it on a seperate system on a seperate server so that if one system is compromised - actions can be taken to ensure that the stored data remains safe.

Private key storage is to broad to answer here but I'll try to give you some resources to further look into it yourself.

The security of the connection between the both servers are extremely important. They must be able to trust each other even when there's a middle man. HTTPS is not enough and multi-layer security is one step to ensure that users' data won't get compromised. An application layer of security can do good in this case with session keys and RSA on top of SSL/TLS.

Then there's the practical...

Trusted administrators of the recovery system can obtain the private key and use it for different mailicious causes.

Encrypting larger amounts of data with RSA isn't feasible today. It will take way too long time to ever be of use. The standard solution today is to generate a random encryption key, encrypt the payload with the key and the key itself with the recipient's public key. Then both the payload and the encrypted key is sent to the server which then decrypts the encryption key with it's private key and the payload with the encryption key.

Anyone with access to the user's email should not be able recover a user's password. You mentioned "a 2-factor authentication service" which will help ensure that only the user can change the password.

To conclude:

Every time the data is sent over a network it is exposed to vulnerabilities. The fewer time it crosses a network - less likely a MITM will be encountered. This can be solved using tokenization which replaces sensitive data with a random string that only your servers can relate to data.

Large amounts of data cannot be sufficinetly encrypted using RSA as of now.

What to do to address the issue

Recovery

Disregarding the actual "user selects new password" part ( identical to the registration process )

The server generates a random encryption key to encrypt the payload with
The key is encrypted with the recovery server's public key
The server encrypts the user's email and password key ( which are both encrypted with the recovery server's public key ) with the "payload key" and sends it and the encrypted payload key to the recovery server
The recovery server decrypts the payload key using it's private key and then decrypts the requested payload using the received payload key and then decrypts the data with it's private key
The same communication step with multi-layer encryption is used to send the data back to the main server.
The main server is able to encrypt the data with the new password key and store it again


Are URL shorteners "vulnerable" due to open redirects?

URL shorteners meet the definition of sites with open redirect vulnerability, yes, but it would be perverse to describe them as vulnerable when their sole purpose is to act as an open redirect.


is it possible to test out remote host by using nmap?

She's probably using NAT.

Proper, publicly routable IP addresses are scarce and expensive. So, in a small home or business network, like most of us have these days, it makes sense for the ISP to only provide you with a single public routable IP address, and use some clever trickery in the router to allow all the devices in the network to share it.

While NAT lets home users do 99% of what they need to, there are many limits on what you can do when one is in place, and you're seeing one of them.

(To forestall the comments: obviously, from a security perspective, the fact that you can't easily do port scans from outside is a benefit, rather than a limitation!)


Advantages to killing sessions after 5 minutes?

I'm completely confused, though. What is the security benefit here?

Nothing.  The most likely scenario is that something in between is timing out the connection after 5 minutes to conserve resources.  That could be a firewall, a WAN accelerator, an SSL accelerator, etc.  Or it could be just a bad default setting.  Who knows?

Network admins often have different concerns than everyone else, that often times can come into conflict with others.  We work in a silo-ed world where the holistic picture isn't taken into account.

Don't assume there's a particularly good reason for every setting, but leave room for the potential that the 5 minute timeout was a quick fix for some other problem they're having, and your application problem was blowback.


Flaw in encryption through pseudorandom number stream (from PGP documentation)

A PRNG being "good" (having strong statistical randomness guarantees, say, plus having a long period) says nothing about its security. See e.g. discussion in this thread.

The thread discusses the difference between:

one time pads (unbreakable in principle as long as they are neither leaked nor re-used, but usually impractical)
stream ciphers (which can be made as secure as necessary, and can be quite practical)
PRNGs (that weren't designed to be cryptographically secure) used as stream ciphers (typically easily broken)

What Phil should have used was a stream cipher not just any old PRNG. MT (and earlier PRNGs) are not suitable for use as a stream cipher. Salsa20/ChaCha (by Dan Bernstein) and ISAAC are two specific stream ciphers. ISAAC is used by shred. Salsa20 is part of the EU eSTREAM/ECRYPT programme. Of course, Phil can be forgiven for not using a stream cipher: RC4 (which is considered broken -- its weakness are part of what makes WEP insecure -- but which is the basis for ISAAC) was only invented in 1987.

The cryptographic weaknesses of normal PRNGs (including MT and Wichmann-Hill) has lead to vulnerabilities in e.g. TCP sequence number attacks. Those vulnerabilities are sometimes addressed using a different sort of CSPRNG, which gathers entropy "as it goes" (e.g. from mouse/timing jitter). To be suitable for use as a stream cipher, a CSPRNGs must have all the input entropy available at the start, rather than gathering it as it goes. See the wikipedia pages on CSPRNGs and on /dev/[u]random.


Your Hitron device is still acting as a gateway. This means that any traffic targeted to your second device must be handled by the Hitron. When the Hitron device is running out of resources, every host which is using the Hitron as a gateway is affected.

First of all, it's not very effective to work around this issue without a external gateway like VPN. However you could evaluate the possibility to get a secondary, physically separated connection. (In Germany for example there's the option to use the TV cable for internet besides the phone line) You could also ask your ISP for help.


VeraCrypt - Windows boots Automated Repair on UEFI/GPT

OK, I came up with a solution and it works even after I switch off the computer. In BOOTICE I modified the Windows Boot Manager to load "\EFI\VERACRYPT\DCSBOOT.EFI" (the VeraCrypt loader) instead of the original Windows loader (\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI) and saved it. I only modified "Media file:" text field in BOOTICE. When I reopened BOOTICE to see if the change sticked I noticed that there are now 2 separate Windows Boot Manager entries: the original (which I presume Windows automatically recreated after I changed it) and the one I changed with the VeraCrypt loader path.

My UEFI (BIOS) now sees 2 separate Windows Boot Manager entries (which are named the same, no need to change that I guess). I hope it doesn't compromise my security and Windows performance in any way. And I hope any future Windows Updates won't mess with my solution.

I realize this is a "dirty" solution, so it would be nice if someone made up with sth better.


Short answer:

  Does MAC filtering in WLAN protect against MAC spoofing?

No, in no way.

  he manages to spoof one of the user's MAC address,

You make it sound like that's a hard thing. The MAC address used by your network card is a setting in the network manager – trivial to change.

MAC addresses of other users can be observed in plain text on the air, which is trivial, too.

  will the attacker be able to connect at the same time while the user is connected to the WLAN?

Yes. But that will confuse the access point, and it will probably throw both out of the network. Which makes no difference – you and the other user will instantly try to register back in.

But usually, any wireless network will be encrypted and will require the user to authenticate with his specific password (WPA2-Enterprise) or at least a pre-shared (i.e. common to all) key (WPA(2)-PSK, WEP). WEP is obsolete, but WPA2 makes it hard (brute-force hard, in fact) to enter if you don't know any password.


How to prevent MITM DNS attack by router

If it's only DNS you're worried about, then just use DNS-over-TLS or DNS-over-HTTPS. However, if you're worried about this, then you should probably be worried about the rest of your traffic too, so I'd recommend you use a VPN.


I'm assuming that you're not running a relay yourself, which would of course explain multiple connections.

According to the Tor FAQ, Tor will reuse a same entry node for TCP connections for a duration of 10 minutes, and will then switch to a new entry point. This avoids profiling all of your Internet traffic via a specific entry point (which could help fingerprinting attacks based on the sites you visit).

Previously open TCP connections will keep using the same entry node until the session expires, so if you browse multiple sites but keep the TCP connection active on the first websites, you could easily end up using three different entry nodes.


When hashing passwords, is it ok to use the hashed password as the salt?

To answer this, one has to understand why salts are needed in the first place. This is explained pretty well in How to securely hash passwords?; here's an excerpt from the accepted answer:

Salts: among the advantages of the attacker over the defender, is parallelism. The attacker usually grabs a whole list of hashed passwords, and is interested in breaking as many of them as possible. He may try to attack several in parallels. For instance, the attacker may consider one potential password, hash it, and then compare the value with 100 hashed passwords; this means that the attacker shares the cost of hashing over several attacked passwords. A similar optimisation is precomputed tables, including rainbow tables; this is still parallelism, with a space-time change of coordinates.

The common characteristic of all attacks which use parallelism is that they work over several passwords which were processed with the exact same hash function. Salting is about using not one hash function, but a lot of distinct hash functions; ideally, each instance of password hashing should use its own hash function. A salt is a way to select a specific hash function among a big family of hash functions. Properly applied salts will completely thwart parallel attacks (including rainbow tables).

So the problem of your salt is that it doesn't interfere with parallelizing breaking the hashes, which is the very purpose of salting. I strongly recommend you to read the original answer, it has further advice on salting.


Is knowing the decrypted and encrypted data enough to find the key?

What you are referring to is a known-plaintext attack, where you attempt to figure out the key by comparing the encrypted and unencrypted versions of a sample of data.  Fortunately, pretty much all major encryption algorithms in use today, including AES, are not known to be susceptible to this kind of attack.  Knowing what something decrypts to is completely useless as far as figuring out the key goes (unless, perhaps, your approach is to attempt to brute-force the key.)

While Spideroak technically could use the method you describe (i.e, encrypting a known sample file), they actually use a procedure known as hashing according to their website.  Hashing is a very common password storage technique; in fact it is used by nearly all websites that process user logins.  It's is a mathematical process that takes in some data (such as a password) as input, and generates a unique, fixed-length string as output.  It is easy to calculate the hash of some data, but given the hash, it is very hard to figure out what the original data was.  But as long as you provide the same data, the hash will always come out the same.

According to Spideroak, when you create an account, your browser calculates the bcrypt hash of your password and sends the hash to spideroak. Presumably, when you log in, spideroak sends the hash back to your browser, and your browser will take the hash of whatever you typed in to check that it matches.


Mail server (sendmail) sends spam to innocent people

This sounds like you have Open SMTP relays that need to be configured. The SMTP relay machine should only accept mail for relay to domains you host. For example, if you host the domain maildomain.com, the SMTP relay should only accept mail for that domain and reject mail for any other domain. (At least, this should be the case for unauthenticated connections). The reason for this is that if external SMTP servers and clients can send mail to other domains through your SMTP relay, then those machines will be able to relay spam through your SMTP server. You want to reject mail sent to the SMTP relay for domains you do not host.

This is a critical configuration. I’ve talked to a lot of ISA Server  and Exchange administrator’s who have been put on dreaded RBLs because they did not correctly configure their SMTP relays to prevent unauthenticated relay. If you’ve been victimized by one or more of these RBLs, you know that you might as well try to come out a winner in an IRS audit. For this reason I highly recommend that you do not publish SMTP relays to the Internet until you have a good understanding on how to configure the relay to prevent spammers from abusing it.

The IIS SMTP service allows you to create remote domains and then configure those remote domains to relay mail to a server on your internal network. The SMTP relay is configured with remote domains for the domains you host and relay mail to your Exchange Server or to another SMTP relay on your internal network. The default IIS and Exchange SMTP server configuration blocks mail relay while allowing relay for mail addressed to the remote domains you configure.


What are the main security considerations that must be taken into account if you intend on creating a (localised) whistleblower website?

I wouldn't start from scratch. Try looking at SecureDrop. It's used by the New Yorker for anonymous sources.

In addition to the right software, you also need to consider physical security and legal security. You'll want to know what are the laws concerning whistleblowing and privacy in the jurisdiction where you are hosting it. The software may be great, but if you live somewhere where you can be arrested just on suspicion, or they can break in and steal you server without a warrant, then software won't do anything to protect you.

Finally, everybody using it needs to pay attention to OpSec: learn how the system works and how it is meant to be used, then don't ever veer from that.

One last thing to mention. If the type of activity you plan to engage in is illegal where you live, you shouldn't post anything to Stack Exchange that links to your real identity. Ross William Ulbricht (of Silk Road infamy) was caught in part because he used his real name – briefly – on StackExchange.


Statistics about Significant security breaches in 2013

One option, although it focuses on dataloss as opposed to specifically security breaches, would be the data loss db.

In terms of the most important breach of 2013 as mentioned in comments already that's subjective, but arguably one could suggest that the NSAs data loss was the most significant of last year


What are the security implications of disabling SELinux?

SELinux is largely about confining processes to specified resources and not allowing them to access other resources.

SELinux knows what Apache is, what files it should be able to access, what ports it should be able to bind to, etc. If someone exploits a vulnerability in your website and trys to read or write to files that aren't part of the webroot, SELinux will actually stop it from happening even if you've screwed up on your permissions and left it vulnerable (and it will send up a nice loud error too).

This is especially useful when running websites or other applications that may or may not be safe, due to dumb customers or old software that people are scared to update (or often exploited platforms like Java). It doesn't generally stop an exploit, but it does mitigate the damage afterwards and is supposed to keep the security problem contained to the exploited process.

Another example for desktops: Web browsers. Should they be able to read ~/.ssh? No! There's never a reason for a web browser to go in there, unless that web browser has been taken over by an attacker. SELinux will stop web browsers from accessing ~/.ssh, even though the browser is running with your user privs (as it probably should be).

EDIT: Many people turn off SELinux because things don't work when they turn it on. This is because SELinux expects things to be configured "like we told you to configure it in the Red Hat docs" (in the case of SELinux on EL systems), which means you run things on standard ports with standard file paths and don't do weird stuff. If you want to do weird stuff, audit2allow is your friend and you can build SELinux policies for whatever you need to do.


ip_forward reverting back to 0 during ettercap subnet scanning

Read the doc man ...

Based on the manpage:

  It has two main sniffing options:

  UNIFIED, this method sniffs all the packets that pass on the cable.
  You can choose to put or not the interface in promisc mode (-p
  option). The packet not directed to the host running ettercap will be
  forwarded automatically using layer 3 routing. So you can use a mitm
  attack launched from a different tool and let ettercap modify the
  packets and forward them for you. The kernel ip_forwarding is always
  disabled by ettercap. This is done to prevent to forward a packet
  twice (one by ettercap and one by the kernel). This is an invasive
  behaviour on gateways. So we recommend you to use ettercap on the
  gateways ONLY with the UNOFFENSIVE MODE ENABLED. Since ettercap
  listens only on one network interface, launching it on the gateway in
  offensive mode will not allow packets to be rerouted back from the
  second interface.

In short, depending on the mode used, ettercap disable ip forwarding since it forwards packets by itself.

I guess you're probably using the UNIFIED mode ...


How can I hide proprietary elements of test data in tests that are automatically run?

That's a bit unfortunate.

So long as your code and testing framework are both public, there's nothing that you can do that your unauthorized users can't. You need to lock something down.

The best this I can think of is to put the data on the server running your tests. Limit access to the server to only authorized individuals. That way even if people find the server information, they won't have access to pull the data from it.


Does LUKS protect the filesystem integrity?

LUKS formatted with --integrity <algorithm> option will provide integrity protection for the encrypted volume.

For that to work, --type luks2 must be used when formatting the device (opening of the device formatted with LUKS2 and integrity protection works exactly as for "normal" encrypted devices).

The downside is that the integrity target requires data to be written twice to preserve atomicity of the writes. It is possible to disable this feature (--integrity-no-journal) with the possible risk of data being lost – mismatches between checksums will be reported as I/O errors on reads. Second downside is that some space is lost to checksums, between 0.1% (for crc32) and 0.78% (for SHA-256).

With Advanced Format drives (4K sectors), it's good idea to also provide --sector-size 4096 as that will ensure block-alignment of virtual blocks to disk-physical blocks.

See FOSDEM presentation.


How to determine what type of encryption has been used?

First of all, it sounds like you're trying to cheat at a game. Don't do that.

Now some background on what is going on. Lets first look at the difference between encryption vs hashing:

Encryption is the process on encoding information in such a way that it can be decoded again given the right information about the encoding process (such as an encryption key). This is used for secure communications such that the recipient understands a message (and is able to retrieve the original) but third parties are not able to read the message. The process goes something like this:

"Message" » {secret formula} » (scramble) » {reverse of secret formula} » "Message"

In other words what goes in can be gotten out if you know the secret. Obviously in this scenario what the secret is is pretty important. In computer cryptography is is usually not the formula itself that is secret, it is the values used in the formula that are the secret keys. More on this in a second.
Hashing is the process or reducing a blob of information down to a single value (usually of a fixed length much shorter than the original) that is unique to the given input. This is can be used to confirm the integrity of a message but does not actually contain the message. This looks something like this:

[Value1] » 7a258c461b48c794c0b5110b35382d1e
[Value2] » 926e0eddb765d66502eac40a4ead9409

Hashing is often used to store passwords. Note that this is a one way operation. Given the same input you will always get the same hash1:

[Value1] » 7a258c461b48c794c0b5110b35382d1e
[Value1] » 7a258c461b48c794c0b5110b35382d1e

But one cannot know just from the hash what the input was2.

That background aside, MD5 is a hash algorithm. It is not likely that your game sends hash data back to the server because the data would be uninterpretable. It wouldn't tell them what your score was! You can pretty much rule out anything that is a hashing algorithm.

Now there are two basic ways an encryption process like in the first bullet point above can work.

The same secret value can be used both to encrypt and decrypt the content.

This is the usual pattern for things like password protected documents.

User A uses {password} to encrypt a document.
The encrypted document is passed around.
Only users that know {password} can decrypt and read the contents.

A matched pair of values can be generated such that one half of the pair is used to encrypt content that only the other half of the pair can decrypt.

User A generates a key pair.
They then pass around the public half of the key pair but keep the private half to themselves.
Any user may encrypt documents or values using the User A's public key, but the resulting data may only be decrypted by User A using their private key.

If you game uses a basic password model as in #1, the password and algorithm used will be hard coded somewhere in the source code and burred somewhere in the actual app. Anybody that does some dissection work will be able to figure out what that value is and decrypt any further messages they intercept. Hopefully your application did NOT do this!

The proper way would be for to public key cryptography as in #2 above. The software developer would have generated a key pair for their software. The public half would be built into the software somewhere and all values can be encoded using that key before being sent over the wire. Once they reach the developer's servers, the data may be decoded using the private half of the key.

Conclusion

If the developer has used the proper technology for the job, you will not be able to decrypt the data being sent because you do not have the private key needed to decode it. The public key may be buried in the software somewhere, but that will not get you the data.

If they have NOT done their job properly then there might be trace clues in the software itself that give you enough information to decrypt the data yourself.

Actually identifying the method and specific algorithm used in this case is beyond the scope of this answer and is left for the reader to do further research on. Hopefully this overview of the possibilities will provide a better understanding of what sort of things you are looking for.

2 This is why using salted hashes is paramount to the security of password systems!

2  Note I said just from the hash because is is possible to guess or use pre-defined tables  to know what input generated a hash, but a secure hash itself will not actually contain the data used to generate it.


Are weak passwords acceptable for internal development?

It is all a matter of trust and/or accountability. If your internal environment is completely secure/separated from the internet you can, but it is not generally a good idea.

Example: What happens if an employee is let go? Can you trust that person then? If attached to the internet that is very bad and I have seen it happen in companies I have worked for in the past.

-

Response to comments for clarity:

Stronger than 'password' or 'Password1' does not necessarily mean extremist. For production environments I ask my people to do better than that but not requiring codes bordering on extreme or ridiculous unless it is banking data or there is a high security risk.


In CIA triad of information security, what's the difference between confidentiality and availability?

Confidentiality is concerned with ensuring unauthorised users cannot access a protected resource.

Availability is concerned with ensuring authorised can access a protected resource.

It is important that a resource is available, because otherwise an attacker might cause damage simply by preventing authorised users from accessing a resource, even without the attacker being able to access the resource themselves.

A physical metaphor for availability might be an attacker going to all the fire escapes on a building and bolting them shut from the outside. The attacker doesn't need to compromise the existing locks to do this (and therefore they can't get inside the building themselves), but if there's a fire the attacker can still cause significant harm.


RestApi Libsodium SealedBox end-to-end request encryption scheme

TLDR: If you don't trust TLS, there is no easy way to establish secure data exchange.
You said that one of the threats is

the network is compromised

If you don't trust network, then sending client token via such network makes no sense. Also all further steps that you described make no sense because they are based on a compromised client token.
Another threat is compromised authentication:

make sure that who is requesting that data is that user

If you don't trust network, then you cannot trust user login. Means, you need to use some pre-shared secret which was shared via some other, trusted channel. For instance, you can send a list of one-time passwords to the client per SMS, or Email, or even per normal mail, or provide a one-time-password generator to each client.
Another approach may be using a separate public key on the server (for encryption of client requests) and public keys for each client. Actually, good practice is to use separate keys for signature and for encryption. Thus you need to provide 2 certificates to each client. Also you need to manage client certificates: Issue new certificates when the old ones expire, have a revocation list and organize revocation process.


How to encrypt the data such that only the user (owner) can decrypt them

Knowledge is power. In other words, if the user must be able to perform some action and nobody else should be able to do the same action, then there must be some value (a "key") that only the user knows, and nobody else.

Moreover, use of a value necessarily means having that value at hand; when you decrypt with a key, then you have that key, at least as long as you decrypt. If the key must be known to the user only, ever, then this implies that decryption shall occur only on a system that is under exclusive control of the user. To put things simply, decryption will have to happen on the user's machine (desktop system, laptop, tablet...) and not on any system that should never see the key (e.g. your server).

You thus have two issues to solve:

How to store the key such that the user can access it, but only that user may access it.
How to make the decryption happen on the client system in a way that you cannot easily circumvent.

The first problem can be dealt with using a local file or storage area. To some extent, you can help the client with some server-side storage and password-based encryption: if you have some piece of data D, then you can store on the server Ep(D), which is the encryption of D with a password p that the  server does NOT know. Password-based encryption is hard in general; begin by reading this answer. In that model, the really user-specific knowledge is the password p, that the user transports in his head.

The second issue is more problematic. You won't solve it in pure JavaScript (in a Web context) because whatever JavaScript is executed by the client will be sent by your server, so your server always has the conceptual ability to send, one time, a malicious JavaScript that grabs the password/key/whatever and sends it back to you. I suppose that your problem here is not only to give the ability to decrypt data to the user alone, but also to do it so convincingly, i.e. to be able to demonstrate to third parties that you really cannot access the data. At the best of times, this is difficult; a possible strategy is to make the client use some local application code that can handle the decryption, and is signed by you, and is amenable to easy reverse-engineering (C#/.NET and Java come to mind here). If there is such a client application, then you can claim that you cannot discreetly plunder the user's data because it would entail pushing a malicious application on their system, that could later on be reverse-engineered, the signature incriminating you.

In pure Web without such a local application, forget it. The Java applet model could have been applicable, but will be hard to do in practice because not many people support Java applets nowadays (and .NET+SilverLight is even less widely deployed).


Windows Certificates - where is private key located?

The locations are listed in Microsoft Docs on Key Storage and Retrieval.
For Local system private the locations are:

The Microsoft legacy CryptoAPI CSPs store private keys in:
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\S-1-5-18\
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\S-1-5-18\

CNG stores private keys in:
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\SystemKeys

In practice they are by default under C:\ProgramData\Microsoft\Crypto\ on Windows 10.


X.509 algorithm identifier parameters vs. extension values

Nominally, the contents of the extension (the extnValue) could be any sequence of bytes. The "value bytes" are to be interpreted relatively to the extension ID; each extension is free to define its own syntax.

The extension which are defined by X.509 itself all use ASN.1: for each "standard" extension, the syntax for the corresponding value uses ASN.1, so the extension value, to be stored in the OCTET STRING, shall be the DER encoding of some ASN.1-based object. Hence the comment. However, extensions can be, by definition, arbitrary, and X.509 uses an OCTET STRING so that other standards or implementations may define their own extensions which are not necessarily based on ASN.1 (I have seen that in the wild).

There is nothing really profound here. X.509 could have defined the Extension type as you suggest, with an ANY; in which case people who want to use non-ASN.1 extension values would have had to encapsulate them in an OCTET STRING. The discrepancy between Extension and AlgorithmIdentifier just shows that these structures were defined by distinct people, and the whole ASN.1 ecosystem is known never to have exhibited tremendous consistency. Also, for backward compatibility, decisions such as using an ANY instead of an OCTET STRING (or vice versa) tend to stick for a long time.


Is there a site like plaintextoffenders.com that shames companies that force insecure passwords?

You can just submit them to Plaintext Offenders. They accept any type of password-based idiocy.


Is it possible to send HTTP packet via spoofed IP?

No you can't.

HTTP is a protocol on top of TCP and doing IP spoofing with TCP is nearly impossible due to the internals of the protocol. You would not only need to send a single spoofed packet like in UDP but you would actually need to reply the packets of the peer with the matching sequence numbers without being able to watch the peers packets which contains this sequence number you need to match. And this reply must happen just to establish the connection, i.e. before even sending your HTTP payload.

Apart from that many systems will simply drop packets which do not fit the routes, i.e. a packet claiming to be from 127.0.0.1 (localhost) should never come in at the network card connected with the local network.

if($_SERVER['REMOTE_ADDR'] === '127.0.0.1') {

But given your code you might actually be more interested if the value in $_SERVER['REMOTE_ADDR'] could be spoofed. While most assume that this is the source IP address of the client it can actually be different from the real source IP of the HTTP connection and it might even be manipulable by an attacker.

In case of a reverse proxy (or load balancer) in front of the web server the real IP of the client is not known to the web server because the connection from the client actually terminates at the reverse proxy. Therefore it is not uncommon for the reverse proxy to propagate the original clients source IP by inserting a HTTP header, typically X-Forwarded-For. Some web servers are setup to put the value from this header into $_SERVER['REMOTE_ADDR'] instead of the real source IP. And in some situations this is actually exploitable by the attacker to bypass IP based access control like employed in your case.

For a specific example of this kind of bypass see Anatomy of an Attack: How I Hacked StackOverflow.


PII Data Masking rules - what's acceptable and what's not

Just to literally answer your question, "is there a standard?.." - yes, for USA it is NISTIR 8053.
More specifically - you can de-identify or anonymize your data, depending on the nature of your dataset and the UAT. The difference is:

De-identification of data refers to the process of removing or obscuring any personally identifiable information from individual records in a way that minimizes the risk of unintended disclosure of the identity of individuals and information about them.
Anonymization of data refers to the process of data de-identification that produces data where individual records cannot be linked back to an original as they do not include the required translation variables to do so.

There are many methods that you can use, such as masking, shuffling, randomization, etc. Again, use whatever is appropriate for your use case.


Try using Fiddler2.  It is free and has a built in HTTPS stripping proxy for exactly the kind of thing you are trying to do.  The one trick is that the application will know that the certificate doesn't match so it may or may not complain, but something like Fiddler2 is your best bet at trying to see what's on the HTTPS connection.  (You may also be able to add Fiddler's root cert to your trusted certificates to make it think it is valid, but it depends if they are looking for a particular cert or just one the system sees as valid.)


Are all cipher suites with rc4 in them intrinsically flawed?

RC4 has known biases, which have been measured with great accuracy. Exploiting these biases into an actual attack requires observation of many (millions) of successive connections where some specific secret data (say, a given password) always appears at the same place. Such a scenario can be forced in lab conditions but barely applies to practical, real-life situations. This is why it is usually considered "not urgent" to obsolete RC4.

Some SSL clients prefer RC4 over AES because of all the bad press about the BEAST attack (despite the fact that the same clients are not actually vulnerable to BEAST).


It is possible to fingerprint the OS to some level, but you won't be able to differentiate Kali Linux from Ubuntu/Red Hat. Or between some Windows versions.

On the other hand detecting the behavior (eg. a port scan) instead of the OS would be simpler.

If you are happy with the detection quality and don't mind some false positives, eg. that your boss new smartphone gets misidentified as a malicious OS, I would recommend using p0f.


Is storing a user's IP address, in their browser, a security concern?

This is like asking can you safely store someones mailing address inside a postcard from/to the person.

No, this isn't a security concern unless the user is using something like TOR and even then its not the end of the world because it will be the exit nodes IP.


Can ISP detect a proxy connection's contents?

If all the Internet resources are requested through the ISP, then why can't they detect a disallowed website being requested via a proxy site?

The only way to make sure that the ISP really can't detect what is being requested is by using encryption. You need either an encrypted connection to the other endpoint, or at least to the proxy.

Everything else they might detect, depending upon how sophisticated their equipment is and how motivated they are.


So I need to unzip and process user submitted zip files - how to do so securely?

First of all, I would suggest to perform some kind of content inspection (e.g. antivirus / malware detection)

Second, I would read the files inside the ZIP file. Since you're using Python, I would suggest to have a look at: http://pymotw.com/2/zipfile/

By reading the content of the ZIP file, you could determine if the files are allowed or not (for example: .exe, .php or .asp(x) files)

Third, extract the user content to a folder where scripts like PHP / ASPX cannot be executed, preferably outside the web server's web directory.


What is the use of the "secret" displayed when setting up 2 Factor Authentication?

Google Authenticator supports the TOTP and HOTP algorithms.

In both algorithms, a secret needs to be shared between the server and the client to successfully generate the one time passwords. I suggest you read the respective RFCs of the algorithms (or my answer here) to understand it better.

Yes, if the attacker manages to get hold of the shared secret the algorithm is defeated. However, this isn't very practical. The secret is only displayed in the form of a QR-code once when setting up the algorithm. Presumably you will be sitting in front of the screen when this happens and will take notice if someone suspicious walks up and starts scanning the QR code with his phone. There are plenty of physical measures you can employ if this is the case.

Once the secret is shared, it is stored on the server and the client (in this case your phone). At least in the case of Android, the secret is stored unencrypted in a SQLi database file. However, this file can only be accessed by the Authethenticator app unless your device is rooted so it isn't easy to get your hands on it. It should be just as difficult if not harder on an iOS device. You have much bigger worries if an attacker manages to compromise the server.

So yes, the algorithm is defeated if the secret is leaked. But the secret leaking is not an easy thing to happen. In any case, it's TWO-factor authentication. You still have the other factor to protect you.


What is the best way to analyze results of a technical security assessment?

It sounds to me like you want to do is a vulnerability scan. I know Nessus has the functionality to discern if virus definitions are out of date:

  Nessus will generate a finding if the scan target has an Anti-Virus agent deployed with the virus detection rules out of date. We've often received feature requests asking us to allow customers to set a grace period (in days) to avoid generating this alert. Such a preference was added this week under the heading 'Antivirus Software Check':

Source: https://www.tenable.com/blog/keeping-anti-virus-in-check

I'm not advocating for or against Nessus as a vulnerability scanner, but this sounds like what you're searching for.

The powershell idea is good in theory, but pretty bad in practice. How can you be sure every workstation you're managing runs the script and reports successfully?


Store Virus/Keylogger on hardware component?

I doubt that a little bump on the cable would be enough room to hide a listening or attacking device.

But it is possible to hide such a device in an usb cable. One well-known example is the Cottonmouth-1 used by the NSA.


Yes, you can. Here's how:

See section: "HOW TO INSTALL SNORT ON A RASPBERRY PI"

  Follow some of the recommended best practices for expanding the memory space on your SD card once Raspbian is installed.

https://blog.holdenkilbride.com/index.php/2016/10/25/turn-your-raspberry-pi-into-a-snort-ids/

and another solution that uses Kali Linux as a starting point:

https://www.securityforrealpeople.com/2014/09/installing-kali-linux-and-snort-on.html


file-integrity monitoring tools for PCI compliance

An important part of the considerations for this, will be whether the Docker container is running in ECS "classic" or in Fargate. If you're using Fargate then there's no possibility (AFAIK) of deploying file monitoring tools outside the container itself, as you have no access to the underlying VM.
With ECS Classic, you could use something like falco on the host and it would provide alerts on events on the host. I'm not sure if there's pre-built rules for this but it would be possible to write them.
Another option (which may allow you to check the "not applicable" piece) would be to set the container root filesystem as read-only. At that point it wouldn't be possible for the attacker to change files in the container, and you could just do VM level FIM for the underlying EC2 instances (assuming you're not doing Fargate)
For the git piece, if that's in-scope, you could perhaps look at using signed commits which would essentially stop someone from modifying the contents of the repository, unless they've also compromised the signing keys.


Detect if another Process reads my Programm's memory

Simple answer: No.

But why? I don't know of any common OS that separates processes enough to reliably prevent or detect reading memory. In Windows, you are especially lost, unless you run in administrator mode, in which case non-privileged processes should only be able to get some limited information about you (unless it runs in privileged mode too). I can also simply freeze your "extremely secure" application, read all it's data and then simply kill it.

When attacker has a driver on it's side, you are especially lost, since now attacker is on ring0 and can essentially do anything to your system.

Would another application help? No. Nothing will help, because it's essentially playing game of "I detect X" "so i move to Y, X wont help you". If attacker knows how your application works (and this applies to any program you release), then he can think of yet another method to bypass all it's security. This is essentially what happens in online gaming, in virus development and in software cracking for years. And even multimilion companies weren't able to solve this problem.

Only help would be getting level lower than attacker is. In your case that's hardware.


Why is Symantec/Verisign CA appearing as an invalid authority?

Solved.
The problem was indeed triggered by installing Apple Mavericks/ML Security Update 2015-004. As mentioned in this Apple release note, it included updates to the certificate trust policy. There was a duplicate certificate installed (with a wrong serial no.), removing it fixed the problem.

The serial number for the cert as published by Apple matched what was installed in the System cert repository, but there was a "VeriSign Class 3 Public Primary Certification Authority - G5" in the "Login" repository. Once I deleted it, everything got back to normal.

There is still some mystery as to why the certificate appeared in the Login repository in the first place, especially since as I just found out, several other people experienced the same exact problem:
https://discussions.apple.com/thread/6984765
https://apple.stackexchange.com/questions/180570/invalid-certificate-after-security-update-2015-004-in-mavericks


Content Security Policy: postMessage into foreign iframe

You allow the advertising partner’s code in the context of your page, giving it full access to the DOM and everything on the page. If the script is compromised and you load it there isn’t much you can do. There is however, a way to detect if the script you are including has been altered from a previously known state. This is called Subresource Integrity.

This way, if your partner is compromised and his script has changed you instruct the browsers not to load it. This obviously has its drawbacks.

For one, your partner won’t be capable of updating their script on your site without your help (unless they use the loader which inserts scripts).

If the partner is using a loader with SRI that will work. The loader loads other scripts, hopefully with SRI. You can use CSP’s require-sri-for directive to demand SRI for all resources.

Keep in mind though, if the partner is compromised and the loader behaves dynamically, even with SRI, he will most likely be able to run malicious scripts on your site. He simply needs to generate the integrity tags for the malicious scripts.

  What can save me from this attack?

Your best bet is to utilize SRI for their script and hope it is static. If however, it behaves dynamically (loading other scripts, inserting an iframe and communicating with it) then there isn’t much you can do.

As an alternative you can ask them to create a compact version of the script for you and host it yourself.


How to verify the SSL fingerprint by command line? (wget, curl, ...)

NEW ANSWER:

Reviewing your link #4, it seems like you've investigated existing utilities and received the answer that what you want would have to be programmed.  Doing so is relatively trivial.  The following Perl script will do what you want:

#!/usr/bin/perl
# Code snippets taken from Net::SSLeay documentation and mildly modified.
# Requires a newer version of SSLeay (tested with 1.48)
# Needless to say, verify correct $host and $fingerprint before testing!!!

use Net::SSLeay qw(get_https3);

$host = "www.google.com";
$port = 443;
$fingerprint = "C1:95:6D:C8:A7:DF:B2:A5:A5:69:34:DA:09:77:8E:3A:11:02:33:58";

($p, $resp, $hdrs, $server_cert) = get_https3($host, $port, '/');
if (!defined($server_cert) || ($server_cert == 0)) {
    warn "Subject Name: undefined, Issuer  Name: undefined";
} elsif (Net::SSLeay::X509_get_fingerprint($server_cert, "sha1") ne $fingerprint) {
    warn 'Invalid certificate fingerprint '
        .  Net::SSLeay::X509_get_fingerprint($server_cert, "sha1")
        . ' for ' . Net::SSLeay::X509_NAME_oneline(
             Net::SSLeay::X509_get_subject_name($server_cert));
} else {
    print $p;
}

As is outlined in the Net::SSLeay documentation, this method means verification after the HTTP transaction, and so should not be used if you want to verify you're talking to the right server before sending them data.  But if all you're doing is deciding whether or not to trust what you just downloaded (which is sounds like you are from your reference #4) this is fine.

OLD ANSWER:

You can use openssl as described here:

To wit,

openssl s_client -connect <host>:<port> < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin

(Old answer was) Updated

As @Gilles has pointed out, this doesn't meet the requirement to combine the certificate verification with the actual content retrieval.

Because openssl s_client combines the certificate information and the server response into the stdout stream, it cannot be simply used for this purpose.  It is probably possible to write a script that would slurp up the combined output and separate the two based on some simple test parsing, but that's not exactly a turnkey solution.


The Finished value checked by Secure Renegotiation is for the previous handshake on the same connection as seen by each party, but the attacker had to tamper with the initial (full) handshake, so the check values differ. Look at the items in red in their figure; those cause log1 and log1' (prime) to differ, similarly log2 and log2'.


If I change my private key PGP passphrase, will the old private key+old passphrase work to decrypt already encrypted data?

You are correct: the passphrase protects the key, so if both have been leaked, then the attacker can decrypt any previously intercepted messages, and any future messages using the same key.

Remember that the attacker has a copy of the key with the old passphrase in his posession - changing the passphrase on your copy of the key does not affect his copy. Also a passphrase change does not affect the key itself, so any compromises of the key are permanent.

So if you suspect a key + passphrase has been leaked, revoke it immediately and generate a new key.


Is there any way to cover the sensitive data, at least the CVC without
  having to worry about a sticker being peeled off and stuck in an ATM
  for example?

Paranoid people remove the CVC* from the card using ablation ("they scrape it off").  There is no need for the CVC to actually be on the card, provided you write it down somewhere safe and/or remember it.

For all other values, the standard protections are to cup the card in your hand as much as possible and be alert for suspicious environmental cues, such as a new fascia on the ATM.  There's no golden fix.

As @RápliAndrás points out in the comment, the CVC can still be brute-forced.  If this interests you, there's a fascinating paper called Does The Online Card Payment Landscape Unwittingly Facilitate Fraud that you must read.  Specifically, it shows that the vulnerability to guessing operations varies from site to site, and that overall there is no systemic limit to prevent multiple sites from being used together to optimize the guessing.  And not only do the card brands not have systemic limits to block CVC guessing, but many card transactions do not require the CVC to complete in any case.

But in general, people scraping the CVC are defending against a low-level physical access attack.  They are making it so that the waiter that takes their card into the back room can't jot down their PAN (card number) and CVC.  They are not defending against the case of an attacker who wishes to brute force card parameters given the PAN.

Remember that credit cards are not designed for security - they are designed for commerce.  The entire credit card industry has a tolerance for acceptable levels of risk, which is to say, if a single-digit percent of transactions are fraudulent, then that's considered the cost of doing business.  Small tweaks - such as the CVC and EMV - have been made to improve the statistics, but not to eradicate risk.

*Card Verificaton Code or Value is also known as CVC, CVV, CSC, CID, CAV, or "That number on the back of your card."


How to ensure that cookies are always sent via SSL when using ASP.NET on IIS 7.5?

You can use app.config to force it; the format is (in the <system.web> section)

<httpCookies domain="String"
             httpOnlyCookies="true|false"
             requireSSL="true|false" />

so you really want, at a minimum

<httpCookies requireSSL='true'/>

But preferably you'll also turn httpOnlyCookies on, unless you're doing some really hooky javascript.


SMTP injection, how it is done and what can it cause?

First and foremost,  in the example above your injection is URL encoded and the SMTP traffic is in plain ASCII. This is confusing,  its assumed that a web application would decode the URL encoded payload prior to the injection point, also this quesiton has nothing to do with web applications.

So what about the DATA command?  I can understand that RFCs can be intimidating to new comers. On the Wikipedia page for the SMTP protocol it says that the DATA command is used to specify the body of the email.

In the context of SMTP command injection a new DATA segment allows an attacker to specify a new SMTP body to terminate the previous SMTP email.  SMTP command injection is always in the header of the email, and header may contain values such as a subject/from/to that is undesirable to the attacker.  Therefore the previous email is terminated with a null body or a body of foo in the above injection, and a fresh email is injected.

Before working with any injection,  work with the language or protocol natively.  In the case SMTP use telnet to interact with an SMTP server on localhost.


Where to submit an algorithm for analysis?

There is no easy way to achieve this.

You first have to read enough literature to understand why current algorithms are designed the way they are, and how earlier algorithms have been broken.

Next you have to write a research paper documenting how your algorithm has been secured against all known attacks in existing literature and what your algorithm can do better.

Finally you submit this paper to a serious cryptographic journal and get it accepted. (Beware that if you did not fully understand what you were doing at the earlier steps you are going to get stuck at this step.)

Once your algorithm has been accepted in a journal you wait to see what response you get afterwards. If your algorithm gets attention of the cryptographic community for a few years and does not get broken, then it may be safe start using it.


Mechanism used for offline authentication of software

Your question is a little bit confusing, so I'm not exactly sure what your asking, but I'll have a go.

Sometimes, when you download software, there will be information provided which often looks like a long hex value and sometimes referred to as a checksum or signature. This is a unique value generated by using the software as input to a hashing or checksum function. The output from this process is guaranteed to be the same provided the input is exactly the same. If the input has been changed in any way, the output value will be different. This is essentially an integrity check. If I was making software available for download, I might include this information along with details of how it was generated i.e. SHA1, CRC-32 etc. With that information, you can then use a program to generate the signature or checksum from the downloaded version of the software and see if you get the same value. If you do, then you can be confident the software has not been modified (either by accident during download or by someone being a bit more malicious).

The other place you will see things which can look a bit like a hex string is with software license keys. These are used to ensure that the person using the software is licensed to do so. There are a few ways this can be implemented. For software which is going to be used in an off-line scenario, the general approach is a long key which the software can verify as being a legitimate license key. The key might have a mixture of components, some of which can be verified off-line while others may only be verified on-line or it just might be a very simple algorithm where it just checks that certain bits of information are all in there and in the right position. With an off-line verification, you need to have an approach that doesn't rely on specific user details as there is no way to verify such details. In this case, the verification process is likely just verifying that the key has necessary elements or structure. Normally, the key will be long enough that guessing a valid key is very difficult with a very low probability. Long keys also make it harder for people to share keys, but this is one of the limitations of off-line key verification. With on-line key verification, it is possible for the software to send a query off to a central database which tracks license key use. This database may even record associations of the software and key to prevent the key being used with multiple instances of the software.


Can someone debit cash from my debit card just with an ATR Number?

The ATR is a value output by a smartcard on power-on to tell the reader which communication protocol it supports. Some OSes like Windows also use this value to tell which driver or software to use to handle the card.

The ATR doesn't contain anything confidential and is often the same across a series of cards - there are even databases of known ATRs online. The ATR doesn't contain any information related to the financial aspect of the card.


Essentially yes it is risk. If you choose to use a third party hosted JavaScript (one example is Google Analytics) in a secure page you open the door for information to be collected. That may involve a maliciously forged certificates or simply a change in the ga.js script by Google.

You could consider the flow of you web application to try and push people through sections that don’t require security to capture analytic data, alternatively you could consider a Google Analytics for Mobile devices implementation.

Devices that do not support JavaScript would not normally be able send analytic data to Google. In this case Google provide alternative server-side implementation samples. See http://code.google.com/apis/analytics/docs/mobile/mobileWebsites.html

In this case if you have access to change the code or extend your web application you could send only the information you want to Google. This will obviously require you server to initiate a connection to Google which may induce load and should be carefully secured.

This design was not the intended for web clients that support JavaScript so you should verify that it does not violate Google’s service terms.


Applying IT Sarbanes-Oxley (SOX) to a tool management application

If the apps can be used to push app modifications to your production environment with regard to financial applications, they will be subject to SOX. Considering your Bitbucket, Jenkins and Nexus all are used for ensuring certain controls (e.g. controlled deployment to prevent pushing unauthorised code), they may be considered as part of the control environment.


Is it safe to use createHTMLDocument to sanitize HTML?

You should use the DOMParser to parse HTML when available, and only fall back to DOMImplementation.createHTMLDocument if the former is unavailable.

In Opera Presto, I observed network activity when I passed <img src=...> (but not <video>).
Internet Explorer 9- is worse: media, styles and event listeners will be activated with this method. IE10+ supports DOMParser, so if your audience uses IE10+, then you're safe.