Key generation: Differences between GnuPG classic, stable, modern?

Different versions of GnuPG

All versions of GnuPG mentioned are (as of 2015) still maintained and updated. Differences are mainly of architectural kind; classic (1.4) is proposed to be used within for server and embedded platforms (from man gpg2), while stable and modern are recommended for desktop use (having more dependencies, but being more modular and flexible). GnuPG 2.1 heavily relies on the gpg-agent for all operations requiring the secret key, which delegates the most risky operations to a much smaller piece of software with less exposure to vulnerabilities.

Keys created with all of those versions are equally secure, and can be arbitrarily interchanged with the other versions (by importing/exporting). There are no known vulnerabilities regarding key generation within all those versions.

GnuPG 1.4.12 (Seemingly) Outdated

Also, while 1.4.12 is seemingly outdated as 1.4.14 resolving critical issues is published, Debian backports relevant security patches to older versions to keep the packages stable. You might also have GnuPG 2 available (as gpg2, otherwise install using apt-get update && apt-get upgrade gnupg2). GnuPG 2.1 would require adding the experimental repositories (which might change in future, I'd guess for Debian 9). You can look up which GnuPG 2 version is available in which repository in Debian's package tracker.

Entropy with Live CDs

If you're using a live CD, be aware the entropy pool is reinitialized each time you're booting it. It might take slightly longer until the kernel decides having enough entropy for GnuPG, and key generation might take a little bit longer than usual (just longer, not less secure).


There is no "8 ms rule". There's an equation that was explained by Thomas Pornin (your first link) which stated in that example that for 32 bits of password quality and an attacker with 200 times the computing resources as your hashing system devoted to cracking hashes would complete the task in one month if it took you 8ms to run a hash. You need to adjust those assumptions about password strength, attacker resources, and your devotion of resources to fit your needs.


Prevent Plain-Text Passwords Output by a Script From Being Accessible in the Future

The script you wrote does not put the password into any easily accessible long-term storage (like a file). Even if typical linux auditing would be enabled (which would write all unix program invocations to a log file, including arguments), the password is not visible, as it is only passed via streams. The only exception is the "echo" command, which happens to be a shell builtin on bash, so it is not a "unix program invocation".

If the script finished, the memory allocated to $PASSWORD is freed, and if another processs happens to allocate that memory, it will be cleared before. But the memory used for "$PASSWORD" (or the copies made inside chpasswd, the echo builtin, the graphics library to display the password) is not necessarily cleaned after termination of that script. If you happen to use a GUI with a console window, the password obviously is in memory as long as you can scroll back to it. Depending on security settings in the kernel, root processes might be able to search the whole physical memory or swap space for copies of the password, but any program allocating memory via the kernel is guaranteed to not find the password in there, because the memory will be cleared before it will be handed out for another process.

If your computer has plenty of memory, or the password ended up in swap space, it might be around for along time after you script finished. Having no swap (or disabling swap and clearing the whole swap partition/file) prevents the password ending up in the swap file. Allocating and overwriting lots of memory can clear the password from memory, but is a dangerous thing to do on linux because the OOM killer which will kick in just as you can be sure you have overwritten all memory that might contain the password might kill some unrelated process.

If you need security against memory scraping, the password generation would have to make sure that the password is never copied to uncontrolled memory, and the controlled memory is cleared before the program exits. There is no way to do that in shell. I think the is even no way to display a password (short of writing it to video memory yourself) which is 100% guarantueed of not copying the password to some random memory.


Optionally using Sha-3 before scrypt depending on password length?

An attacker would not guess the 128 long character that goes into scrypt, they would simply guess the 127 character long password that goes into sha-3. This might not seem like a problem if the password is 127 characters long, but it's arguable that scrypt is needed in such a situation to begin with.

Using realistic measures of password length, i.e. 5-10, this discrepancy becomes larger - the adversaries work factor will be limited by the length of the actual password, not the length of the output of the sha-3 hash.

Doing this may leak whether or not the length of the password is greater or less then your threshold, due to the operation requiring variable lengths of time.

So there should not be any sha-3'ing of anything at all. Remember: adding more crypto doesn't solve the problem magically, and doing things that are not explicitly beneficial can only increase your attack surface.


Securely hashing the username in the database protects the confidentiality of that information in the event that your database falls into the hands of an attacker.

Be aware though that if you use the un-hashed username in other ways in your application that information may still be obtained by an attacker.

For example, you mention:

  When the user logs in, the unhashed username is stored in a session.

If we assume that your session information is sent to the client as part of the normal http response for a logged in user (e.g. as a cookie), the username may be obtained by an attacker if they get access to that session token. OWASP advises against storing user specific information in sessions sent to a client.

  Using this unhashed username, specific user data can be obtained from
  the database and the username can even be displayed on pages for
  logged in users.

In this case the fact that you can use an un-hashed username to lookup database information implies that there is some un-hashed user information in the database, which undermines the hashing of the username in the first place. Also, if the information can be displayed in pages, be aware that unless the connection between client and server is secured at the transport layer (TLS) then that username may be visible to an attacker.


The primary difference between the two is that the KRACK attack targets the end-user and not the network itself. The attacker essentially creates a clone of a network that has already been associated and trusted with the target user's device. The attacker then "forces" the victim to connect to their rogue access point at which point they are in a Man-in-the-Middle position. They are now in a position to eavesdrop on traffic and potentially implement an SSLStrip attack to eavesdrop on TLS connections.

The linked question refers to an attacker joining a wireless network for nefarious purposes. At no time during the KRACK attack does an adversary join a network, nor do they compromise the network password. They impersonate that network.

EDIT : It should be stated that the KRACK attack is a form of sniffing, though the method you use to be in a position to sniff is different from the WPA2 sniffing question you linked to.


Can Tor nodes infect my computer with malware?

Some Tor exit nodes are known to be hostile, typically injecting advertising Javascript into any unencrypted web page that passes through them.  There's no reason such nodes can't inject attack Javascript or other malware.

Barring a security flaw in the Tor software itself, an entry or relay node cannot attack your computer (other than trivial attacks such as traffic flooding) because they can't perform the encryption needed to modify packet contents (only the exit node can).

In general, any traffic you send through Tor should be encrypted, to prevent the exit node from sniffing or tampering with it.


Passphrase using same word several times

Your analysis is correct in this: randomness is everything. The attacker will try "potential passwords" and will be defeated only by choosing your password in a large enough set, so that the number of "potential passwords" far exceeds what the attacker may practically try with the computing power and free time available to him.

In practice, repeating the same word several times is a classic trick, which many people use because of the widespread myth that longer passwords are stronger: this is wrong, but many people nonetheless believe it. Since many people follow the repeated-word strategy, password cracking tools follow it, too.

Therefore, the best you could hope for the entropy of a repeated-word password is the sum of the entropy of the base word, and the entropy of the repeat count (or total password length)(this is a sum because I am expressing the entropy in bits, which is a logarithmic scale). For instance, if you choose the base word in a list of a bit more than 30000 possible words (which is an already quite large vocabulary, by today's standards), then that's 15 bits for the base word. If you then repeat the word to achieve any length between 12 and 27 characters, with the length being chosen randomly, then that's 4 extra bits (16 choices for the length), for a grand total of 19 bits of entropy -- i.e. not a lot of entropy after all.

An extra point to consider is that password length may leak. Not in the hash, but in other contexts:

"Shoulder surfers" may have a peek at your screen when you type the password. They will only see a collection of bullets (password entry fields are hidden), but they could see how many such bullets appear, yielding the password length.
In a similar context, people within earshot may try to work out the number of keystrokes, there again yielding the number of passwords.
In an HTTPS context (i.e. a login form of the Web), the password you type will be sent into the SSL tunnel, encapsulated in a Web form. Eavesdropper on the line will not be able to see the password (SSL does encryption) but they will be able to see the length of the HTTP request, because data length leaks from SSL (with single byte accuracy when an RC4-based cipher suite is used, as Web servers are prone to enforce in a slightly misguiding attempt at defeating the BEAST attack -- which does not work anymore, by the way).

Summary: the repeated-word strategy does not yield a lot of extra security, possibly none at all if the password length has leaked, which happens in several password usage contexts. As such, this strategy is not a good usage of the user's willingness to type a complex or long password (and that is a scarce resource).


Unix Privilege Escalation: "sudo must be owned by uid 0 and have the setuid bit set"

what's to stop an attacker from compiling their own custom sudo binary that allows it to execute with any uid?

There's a basic misunderstanding going on here.  The program does execute, it just stops when it notices it's not running as the root user.  Recompiling the program to remove the check would only allow you to run the task as the user who executed sudo, not root.  In other words, the check for running as root in sudo is only an error check and diagnostic, not a security feature.

The misunderstanding is that programs don't have any special ability to execute as another user, the extra privilege is a property of the file permissions on the file.  Any program with the setuid bit set will execute as the owner of the file.  If you were to compile your own program the file would be owned as you. While you are allowed to set the setuid bit on your own file, you  aren't allowed to change file ownership without extra privileges.  So setting the setuid bit would only allow others to execute your program as yourself.


It depends on the situation - type of application, deployment model, especially your threat model, etc.

For example, certain compilers can substantially change some delicate code, introducing subtle flaws - such as bypassing certain checks, that do appear in the code (satisfying your code review) but not in the binary (failing the reality test).
Also there are certain code-level rootkits - you mentioned C++, but there are also managed code rootkits for e.g. .NET and Java - that would completely evade your code review, but show up in the deployed binaries.
Additionally, the compiler itself may have certain rootkits, that would allow inserting backdoors into your app. (See some history of the original rootkit - the compiler inserted a backdoor password into the login script; it also inserted this backdoor into the compiler itself when recompiling from "clean" code). Again, missing from the source code but present in the binary.

That said, it is of course more difficult and time consuming to reverse engineer the binary, and would be pointless in most scenarios if you already have the source code.
I want to emphasize this point: if you have the source code, don't even bother with RE until you've cleaned up all the other vulnerabilities you've found via code review, pentesting, fuzzing, threat modeling, etc. And even then, only bother if it's a highly sensitive app or extremely visible.
The edge cases are hard enough to find, and rare enough, that your efforts can be better spent elsewhere.

On the other hand, note that there are some static analysis products that specifically scan binaries (e.g. Veracode), so if you're using one of those it doesnt really matter...


Is it a good idea to have a "master" password?

Safely deriving site-specific passwords from a master password is possible. It requires, namely, a deterministic one-way function: "deterministic" so that the site password can be recomputed, "one-way" so that it is not feasible to recompute the master password from a site-specific password. As first order approximation, a cryptographic hash function does the trick.

The system can be enhanced by making the password derivation (from master to site-specific) configurably slow, to avoid an efficient dictionary attack (an evil site could "try" potential master passwords, to see if it gets the one you used). A "slow hash" is a hash with many iterations. You may also add a salt: a piece of data which is not secret, but yet chosen randomly so that two distinct users of your master-to-site-password software do not end up with the same site password if they happen to use the master password. Salts can be stored in a file (they are not secret) but this would prevent you from rebuilding all your site-specific passwords from your knowledge of the master password alone (i.e. to the problem of remembering, you are adding the problem of data backup).

This is very similar to the question of storing server-side password hashes (for which the usual solutions are bcrypt and PBKDF2). The problem is made easier by the master password being "master". Since you have to remember only one password, you may as well make it a big, fat, random, high-entropy password. Generate a sequence of 17 random lowercase letters, learn it, and you will be fine (because 2617 is about 280, and invoking 280 times a hash function is beyond what is feasible with current technology). An all-lowercase letter password is easy to type, especially on smartphones.

Others have given pointers to existing software which does just that.

Your idea of using a RSA key and encrypted random passwords also works. However, it means storage. If you are traveling and someone steals your laptop (an unfortunate but alas not utterly implausible event), then not only are you deprived from your machine, but you also lost your passwords, until you buy a new machine and retrieve your backup of the encrypted file full of passwords. This can be inconvenient. Deriving the passwords deterministically from the master password means that you will not lose them while you remember the master password.

Also, any new password (for a new site) requires fiddling with the file and its backups, there again something which might be difficult while traveling.

Using an intermediary storage allows for password renewal, but why would you do that anyway ? Password renewal is useful when you manage a big organization with hundreds of passwords and you assume that some passwords will be weak, and some will be broken. It is a way of containing damage and makes sense only if there is a non-zero proportion of broken passwords at all times. Password renewal is a field army thing. It does not scale down: when you get down to a single master password (your case), that password is either fully not broken or fully broken. In the former case, there is no need to renew the master password; in the latter, you have more urgent issues to deal with, including changing all your previous site-specific passwords.

To state it briefly: if your master password needs renewal, then it was broken; which means then all your site passwords are toast. Thus, master password renewal without changing the site passwords is useless.


Is my code safe enough to be publish on the server side?

I just wanna ask if my PHP code is secure enough

This question cannot be answered. A security assessment is very complex and bases on a thorough risk assessment.

Secure for what? What kind of attacks are you foreseeing?

DOS? I don't see any protection from what you've shown here (might be implemented somewhere else)
SQL injection? You're using htmlspecialchars(), not htmlentities(), UTF-7 XSS attacks will be possible. In addition I suggest using PDO prepared statements instead of mysqli


For an end-user, is HTML5/JavaScript more secure than Flash?

In theory, if all servers and connections to them were perfectly secure (impossible) and trustworthy (not true), neither one would be more "secure" than the other - mainly because the developer(s) of the website are in full control of the content of the site. Since Flash and the JS is served to clients, the server would have to serve malicious content to the end user in order for the end user to be affected.

Sadly, we don't live in a perfect world and JS tends to be more secure in the case of a server compromise - it is far more limited in its ability to affect the client. Many Flash vulnerabilities have the ability to execute arbitrary code, which is far more damaging than  browser exploits, which often require multiple vulnerabilities to break out of the sandbox. This means that JS exploits often can only manipulate the client while the client is viewing that page and is usually unable to persist after it is closed, whereas Flash exploits can infect clients with RATs or other malware, which enables the attacker to have control over the client even after the browser is closed.

Another benefit of using JS is that the source is viewable by clients. Someone using the site may notice something suspicious in the source and notify the developers, allowing for the intrusion to be more easily detected. In the case of Flash, a malicious attacker can inject malicious code into an existing swf and since users cannot view the source without dissembling the swf, malicious code may go undetected for longer.

For an end-user, scenario 2:

  JavaScript enabled, Flash not installed or enabled

would be much safer for the reasons above and given Adobe Flash's history of exploits. A search in the NVD reveals a total of 610 vulnerabilities, 330 of which are between January 2014 and December 2015. Most JS-related exploits tend to be browser specific, which reduces the number of clients affected, while Flash is meant to be cross-platform, which increases the number of affected clients (less nowadays, considering that many people have Flash disabled).

TLDR: Keep Flash off and use JS instead.


How can I access the certificate transparency logs?

The CT endpoints are correct, however you need to access it with the correct paths and parameters instead of the root endpoint.

For example, to access the STH (signed tree head), you use the URL: https://ct.googleapis.com/pilot/ct/v1/get-sth

Or to access log entries numbered 1000 to 1100: https://ct.googleapis.com/rocketeer/ct/v1/get-entries?start=1000&end=1100

RFC 6962 describes all the paths and parameters used for CT operations, or you can use a library like https://github.com/google/certificate-transparency.


Prevent GPG from exposing portion of private key

When you use the --export-secret-subkeys command, it will export the public part of the key as well. You're seeing the output of that. You can test with the following:

gpg2 --export-secret-subkeys > /tmp/cancelled.gpg
gpg2 --export-secret-subkeys > /tmp/not-cancelled.gpg

Cancel the passphrase input on the first one, and then try this:

export GNUPGHOME=$(mktemp -d)
gpg2 --import /tmp/cancelled.gpg
# the output will mention importing the public key
# you will not be asked for the passphrase
gpg2 --list-secret-keys
# the output will be empty

Do the same with the non-cancelled one:

export GNUPGHOME=$(mktemp -d)
gpg2 --import /tmp/non-cancelled.gpg
# the output will mention importing the public and secret keys
# you will also need to put in the passphrase to import the key
gpg2 --list-secret-keys
# the output will show the secret key

So, when you click "Cancel" only the public key is written out.


I'd recommend nipper for this.  Runs on a wide range of devices, and is targeted at firewall audits, rather than configuration management.

In my experience it's very easy to get working.  Generally, you give it a copy of the config and it runs :)


Does running random "docker pull" essentially mean I'm giving someone root access?

Welllll....  The simple answer is 'no'.  docker pull must execute with elevated privileges, but that does not grant those rights to other users.  The kicker is "What comes next?"  If you are not allowing other users the right to run docker (such as creating a docker group with lots of users or generic users) than the risk is only a question of avoiding dodgy containers by only sourcing from reliable sites.

The real question is, "Why are you using docker?"  If it is just to manage images and build environments, the tool can be used with very little risk.  The closer you get to letting regular users run these system administrative functions, the more risk you undertake.


Persistent Connection Attempts By Akamai Technologies

CDNs commonly serve their pages based on the geographical allocation of the ip addresses of the connecting user. You could use a proxy server for all your http requests but directed at a country that is nowhere close to where you are located. At the end of it, if the requests still head off towards those ip addresses, you'll know that something isn't quite right.

However, that was a while back. Now CDNs also serve contents such as updates, etc. So if you can corroborate the connection as a valid service for something like Apple updates, especially with real life users, then you can be sure that it is a valid request.


Is it a bad idea to add random characters to user ID and password?

Yes: you're re-writing security here. There are already several password derivation functions that are known to work, the most well-known one being PBKDF2. Use that instead of your custom scheme.

What you're trying to do is, in essence, salt the password (with a short salt) and store the salt value in the user name. It's not really much of an improvement.

Something else you might want to rethink: with your system, the encryption key is directly derived from the user's password. This means that not only can an attacker attempt to decrypt the user data by attempting to use known password lists (even if using a password-based key derivation function makes it harder) but you also effectively prevent the user from ever changing his password (otherwise, you need to re-encrypt all the user's data).

Without knowing more about your requirement and environment, it's hard to suggest the best way to proceed but, from what you describe, I'm sure that this can be greatly improved. I suggest, therefore, that you hire a specialist to help you find a proper solution in this case.


With HSTS, the browser will automatically convert HTTP links to HTTPS links. However, to prevent mistakes and abuse, browsers will only accept the HSTS header on a secured page.

As it relates to your case, HSTS will not allow users to manually accept a self-signed certificate once HSTS has been enabled (which can only be done from a secure page). That explains why example.com does not allow you to accept the invalid certificate.

Furthermore, I suspect that the subdomains are not being properly protected because the header says include SubDomains rather than includeSubDomains (as defined in the specification).

On a related note, HPKP can provide additional protection against malicious certificates.


Touch Screen Password Guessing by Fingerprint Trace

This is known as a 'Smudge Attack'

It really depends on how much you've used your phone since you've last unlocked it, but the general principle still stands. If you use the pattern feature of Android phones, this can be particularly obvious.

The University of Pennsylvania published a research paper on the topic and basically concluded that they could figure out the password over 90 percent of the time.

The study also found that “pattern smudges,” which build up from writing the same password numerous times, are particularly recognizable.

Furthermore:

  “We showed that in many situations full or partial pattern recovery is
  possible, even with smudge ‘noise’ from simulated application usage or
  distortion caused by incidental clothing contact,”

While this is a plausible risk, It is not a particularly practical vulnerability as an attacker needs physical access to your phone. Using a PIN Code over a pattern may reduce the chance of this presenting a threat but it still exists depending on the strength of your PIN and the cleanliness of your hands/screen. However, these same researchers postulate another possible attack using the heat residue left by contact between your fingers and the screen which would be another problem altogether.

Obviously, cleaning your screen after every use is a practical (and not too difficult) defense against this specific attack. I'd expect that if you have used your phone (say to make calls/send a message/any kind of web browsing) it would also sufficiently obfuscate the patterns/codes. From examining my screen this seems to be the case.


There is absolutely nothing wrong with encrypting files on a volume (hard disk) that is also encrypted. Encryption doesn't "distort" anything; it's a reversible mathematical transformation of the input data. The cipher neither knows nor cares whether the input data is already encrypted; there's no special flag saying "this data is encrypted already!" that might get somehow confused. It's all just data.

File contents in plain text: A
File gets encrypted using per-file encryption utility: ENCf(A) = B
Encrypted file gets stored on an encrypted file system: ENCv(B) = C
Encrypted file is read off of the encrypted file system (for example, to upload): DECv(C) = B
Encrypted file is uploaded to a cloud service: upload(B)
Encrypted file is download from a cloud service to an encrypted volume: ENCv(download(B)) = C
Encrypted file is read off the disk and into the per-file decryption utility: DECf(DECv(C)) = DECf(B) = A.

("A", "B", and "C" are placeholder variables for the actual data, not literal values. "ENCf" and "DECf" are the per-file encrypt and decrypt functions, using the key you supply. "ENCv" and "DECv" are the volume-wide (VeraCrypt) encrypt and decrypt functions, using VeraCrypt's key for that volume.)

Now, it is important to not mess up the ordering (some ciphers will tolerate this, but some will not); DECf(C) != B, and DECv(DECf(C)) != A (probably). However, in practice this won't happen. You can't even tell where files begin and end on an encrypted volume unless you decrypt (some of) it first, so you aren't going to do something silly like try to decrypt C using cryptomator* and then try to decrypt the result of that using VeraCrypt. If you can even see the encrypted file is there, it's already passed through VeraCrypt so the data you see if you read it is B, not C, and you can safely pass it to cryptomator or whatever.

I've actually built, with a friend, a simple tool for doing this using the open-source gpg program for the file-level encryption. It worked fine.

*I don't know cryptomator and am not specifically endorsing it.


Is it secure to consume services over HTTPS which is not signed by a trusted CA?

You can use it safely if you pin their certificate. This adds complexity to the maintenance and deployment but it does actually improve security.

If you do not, then it depends on how they built their trust chain: if they are only using self-signed certificates, then you're out of luck and can't securely use their services. If they just use a private CA, you can still import their CA and trust it.

Overall, I would recommend you implement certificate (or root) pinning.

Edit @LieRyan made a good comment that I'd like to expend on.

In some configuration, pinning a certificate will require your to add it to the machine's root anchors lists. For instance, this is required if you're using IIS on Windows to host your application.

Now, depending on how the certificate was generated, this might be or might not be an issue. Specifically: if the certificate does have a "key usage" property and if that property does NOT list "Certificate Signing", then it can safely be used because it can't be used to sign other certificates (details are a bit more complex but that is the most important one).

If the certificate does NOT have a "key usage" property or if that property has "certificate signing", then it could potentially lead to other certificates signed by that cert to be trusted by the OS. If you implemented certificate pinning, that should not be an issue for your app (since pinning will prevent even otherwise valid certs to be used) but it might be for other part of the OS.


The remote server has no access to your machine; the SSH session is essentially a tunnel into a shell account on the remote machine.

The reason SSH is secure is that it uses similar mechanisms to TLS, which enforce confidentiality and authenticity. Essentially the SSH server has a public key, which is transmitted to you and stored on your machine. You then trust that key for all future communications. As long as the original transmission of the SSH public key was not tampered with, you can maintain security for communications in the future.

When you connect, your client uses the server's public key to encrypt a randomly generated session key, and sends that encrypted key to the server, which uses the private key (which is secret, and only known by the server) to decrypt the message. At that point, only you and the server know the session key, and can use it to encrypt messages using a symmetric cipher. The session key is also used to enforce authenticity and integrity of the messages, via a message authentication code, which allows both sides of the conversation to ensure that no part of the transmission was altered by a 3rd party.

A simplified version of the handshake is as follows:

The server generates a key pair for an asymmetric cipher, e.g. RSA. The private key is kept secret. This key pair is used as the server's identity, and is usually only generated once, then updated infrequently.
The server sends the client its public key. This only has to happen once, for the first time the client communicates with the server, or if the server changes its public key. After that, the client keeps a local copy of the public key.
The client and server agree on a cipher suite to use, e.g. AES-128 and SHA256. This process is rather complex and somewhat out of the scope of this answer.
The client generates a random session key for the chosen symmetric cipher (e.g. a 128-bit key for AES-128) and encrypts it with the server's public key.
The client sends the message to the server.
The server decrypts the message using the private key, and uses the decrypted session key as the key for the chosen symmetric cipher.
Each message is encrypted using the symmetric cipher, and authenticated via a HMAC based on the hash algorithm chosen in the cipher suite agreement. Both sides can now exchange messages safely.

Obviously this glosses over some details, but it's a reasonable representation of what happens.


It's possible the shell is getting stuck once it gets dropped down.

Try running your command via the built in meterpreter shell command.

execute -i -f "/bin/bash /data/data/com.metasploit.stage/files/and.sh"

I have not tested this exact command with a space in it, but it will start you in the right direction.


Is Server-Side Includes injection really common vulnerability?

Not particularly common anymore.

One exception would be web interfaces for embedded devices as many of these just shell out to bash commands and don’t escape well if at all, but again, this is rare to see on a public facing anything these days.


There are literally tons of ways to do this, but the simplest is to transfer them over text.

For example, you can base64 encode the file and echo it out to the remote host (or vice versa) then decode the base64 on the other side.
There's also this technique demonstrated by SANS.
Be creative!


Facebook does something similar to the "presigned URL" - their image CDN doesn't check for authentication, nor is it on the same domain so it can't even get the Facebook session cookie if it wanted to - instead they use the URL as a key (the URL is only ever shown to the authenticated user). It seems to be working out just fine for them so I don't see any issue with using that approach in your project.


The standard method is a Discretionary Access Control List (DACL). Such a structure maps entities (e.g. users, user groups, etc.) to resources (e.g. files, mutexes, sockets, etc.) with a defined set of permission attributes placed on each link.

For example, the following represents a simple read/write DACL:

Resource        | Entity   | R | W |
----------------+----------+---+---+
/foo/bar        | Alice    | 1 | 0 |
/foo/bar        | Bob      | 1 | 1 |
/bar/foo        | Eve      | 1 | 1 |
/log            | Everyone | 0 | 1 |
/log            | Alice    | 1 | 1 |

In this case, Alice has read access to /foo/bar and Bob has read/write access to /foo/bar, whereas Eve has no access to /foo/bar because she has no entry in the DACL table. Only Eve has access to /bar/foo.

The interesting case is when we look at the /log resource, which the Everyone group has write-only access to. Since Alice is in the Everyone group, we would imagine that she shouldn't need an entry, but her entry actually overrides the group setting. At this point, we've build a hierarchical DACL, which allows us to inherit permissions and provide specific overriding behaviours lower in the hierarchy.

Such a model provides extremely flexible permissions and can be implemented in a variety of different data storage systems, e.g. filesystem, RDBMS, key-value storage engine, etc.

Of course, the example above doesn't directly translate to a relational database table, because of the ambiguity between user groups and users. This can be resolved by using a security identifier (SID), which uniquely identifies any entity. I'd probably implement it something like this:

TABLE resource_dacl
  resource_id        INTEGER NOT_NULL
  security_id        INTEGER NULL
  perm_read          TINYINT(1) DEFAULT 0 // permission to read the resource
  perm_write         TINYINT(1) DEFAULT 0 // permission to write to the resource
  perm_delete        TINYINT(1) DEFAULT 0 // permission to delete the resource
  perm_acl           TINYINT(1) DEFAULT 0 // permission to change the resource's ACL
  ...
PRIMARY_KEY ( resource_id, security_id )

The security_id should be unique for each entity, and would be stored within the user and user group tables.

This allows you to easily query for permissions in SQL using a JOIN with WHERE EXISTS, resulting in a single value from the database, containing a 1 or 0 to signify whether the required permission(s) are set.


Security on passwords stored by Firefox vs password manager

Well, they are encrypted with AES, but they are not as safe. FF does not use slow key derivation function, which allows the password to be brute forced. Also sync is not encrypted anywhere as well, so you should at least disable sync on FF. In general, FF is convenient and secure enough for basic protection but not as secure as keepass.


need an Alternative to ssl pinning for web applications

It is unclear what exactly you want to prevent. MITM is only possible if the client side explicitly trusts the MITM (i.e. corporate proxy on firewall vs. attacker). So an attack against the client is not easily possible. Additionally HSTS can be explicitly said which makes overriding certificate warnings impossible on modern browsers.
You can also require a client certificate issued by a CA you control. This certificate is impossible to simply replicate by a MITM. And is thus effective against MITM in corporate proxies where the proxy CA was added as trusted to each clients CA store but where the proxy usually does not retrieve client certificates installed on the client. If there is a risk that the client certificate gets retrieved one can back it by a smart card so that physical representation of the smart card in the client is needed and nobody can replicate the client certificate. Of course, this makes it more complex since somehow the client must get and install the client certificate first.
If your goal is instead to prevent the client itself from reverse engineering or manipulating the application protocol by running some local MITM proxy (i.e. Burp or others) then neither client certificate nor SSL pinning would help. The client has full control over its site and can provide the proxy with the client certificate or could disable SSL pinning. In this case one could only try to obfuscate the protocol to make reverse engineering harder and to keep all important state and computation on the server side to protect against local modifications on the client side.


Envelope formats to store (symmetric) encrypted text

The standard format for storing encrypted data is the Cryptographic Message Syntax (CMS), a.k.a. PKCS#7. Encrypted data contains a ContentEncryptionALgorithmIdentifier, which has to contain the type of encryption used (for instance AES-128-CBC) and all parameters neccesary to decrypt it (for instance an IV). The ASN.1 types for the AES-CBC encryption are defined in RFC 3565.


my iphone 6 S keeps getting this s3.amazonnaws site pop up

s3.amazonnaws is not a valid site (domain name) so it would be helpful if you let us know exactly what you are seeing. A screenshot would be useful.

s3.amazonaws.com (S3 Amazon AWS) is a valid domain owned by Amazon and from which many files can be served since it is the service Amazon provide to people to store and serve files.

You will need to provide further information for us to work out exactly what is happening but it seems at first look to be that the website has some annoying advertising on it that is popping up the image. Make sure that you close the page in the Google app completely so the ad is not re-triggered.

Since you are using an iPhone 6S, you should be able to install an ad-blocker and I strongly advise you to do so in order to avoid such issues.

I also advise installing ad-blockers for all browsers since there are too many rogue adverts around capable of installing malware


What you're asking about involves knowing the details of the TOR protocol design.  The Tor White Paper explains everything in detail.  Look to section 4 (4.1-4.3) contain the design portions relating to circuits and streams.

The summary is that underneath the layer of TLS there are 512 byte cells that describe how Tor routers talk with each other.  There are control cells and relay cells that are laid out as follows:

Control Cell

+---------------------------------------------------------+
| CircID | CMD |                 DATA                     |
+---------------------------------------------------------+

Relay Cell

+---------------------------------------------------------+
| CircID | Relay | StreamID | Digest | Len |     DATA     |
+---------------------------------------------------------+

This is how each piece of data knows what stream and relay it is associated with, as well as the circuit.  Each Tor router will likely keep some type of "Tor policies" to ensure they keep track of these circuits, relays, and stream IDs.  Much like ISAKMP/IPSec handles its traffic.  Whatever Tor uses as a daemon on the router would handle this management.


To avoid BREACH, can we use gzip on non-token responses?

I'm answering my own question because I think I now understand BREACH and how to prevent it. I'd love feedback.

How BREACH works (as I understand it)

(Expanding on an explanation here that helped me.)

Suppose you're an attacker. You are signed into a service as yourself. You notice that there's a search endpoint, and if you send the search term rabbits, you get back a response like this:

<SearchResponse>
  <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
  <SearchTerm>rabbits</SearchTerm>
  <Results>
    <Result>rabbits rock</Result>
    <Result>yay rabbits</Result>
  </Results>
</SearchResponse>

You also notice that the response is gzipped and encrypted (HTTPS).

You try searching for a string that's formatted like the <AuthToken value, likeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa. The response is:

<SearchResponse>
  <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
  <SearchTerm>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</SearchTerm>
  <Results>
  </Results>
</SearchResponse>

There are no results for this. You then modify your search term slightly:

<SearchResponse>
  <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
  <SearchTerm>d2a37aaaaaaaaaaaaaaaaaaaaaaaaaa</SearchTerm>
  <Results>
  </Results>
</SearchResponse>

As you hoped, something interesting is happening. Because the search term is nonsense, the <Results> are always the same: empty. The only thing chaging is the <SearchTerm>. And because of compression, the more the <SearchTerm> value resembles the <AuthToken> value, the smaller the response is.

This is because of how gzip compression works: it removes repetition when compressing, and restores it when decompressing. The more repetitive the input, the smaller it compresses.

You search again, using the exact value of the <AuthToken>.

<SearchResponse>
  <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
  <SearchTerm>d2a372efa35aab29028c49d71f56789</SearchTerm>
  <Results>
  </Results>
</SearchResponse>

This time you make a note of how small the response is. Now you know that any time the response is this size, it means the search term matched the auth token exactly.

Now, because these are your requests, you've been able to read them directly. If you could do a MITM attack on another user of the site (eg, by running a rogue router), you'd be able to see the size of the encrypted response, but not the actual contents.

You think to yourself: if I can trick someone else into sending the search terms I want them to, and if I can see how big the encrypted response is, I can tweak the search term over and over. The closer I get to guessing the auth token, the smaller the response will be, and when it's the size of the response I just saw, I've guessed correctly. Once I know their auth token, I can sign in as them.

If you can somehow execute an XSS attack on your victim, you can get them to make the necessary requests.

Mitigation

This attack would not work if:

The server did not use HTTP compression (like gzip, in our example)
The request could not be made successfully without a CSRF token, which the attacker could not know
The server never put both sensitive data (like an API token) and user-supplied data (like the search term) in the same response
The server never returned the same API token twice (eg, if raw token values were timestamped and signed before sending, the timestamp would ensure the token in the response changed constantly)
The response always contained random-length padding, as @AndrolGenhald pointed out in a comment (although with enough requests, an attacker might separate the signal from this noise)
The request could not be made successfully without a session cookie, and site's session cookie had a SameSite attribute, and the would-be victim was using a browser that understands this attribute so that it understood not to include the cookie with requests originating from another site.


After the Cryptoperiod timespan, do we need to encrypt all the data again?

Well, since re-crypt all the data could be a pain in the... There are different approaches to this (which is known as "secrets management"):

Low security level: you just keep a list of your private keys and if you need to get old data you can use the old key.
Medium security level: the same as the low level but before leaving all the information encrypted with the old key, each time you access to the secret you re-crypt it with the valid key and you wipe-out your old secret.
High security/sensitive data: yes, you have to re-crypt all your secrets. (Might be extremely costly).

As I usually recommend, don't try to overkill and don't choose "re-crypt" by default, consider asking yourself the following questions:

Are your data sensitive in a way that put your business in risk if disclosed?
Is the amount of time to re-crypt your data reasonable? (Meanwhile re-enciphering your data you might not have availability of it).
Does the information expire with the cryptoperiod as well?
Are your keys protected well enough?
Is the cryptoperiod/key strength balanced?

[Edit (improving answer as suggested by @LucasKauffman ]

My response has to do with the PCI-DSS (sections 3.5-3.6) and you have to read them carefully to be sure you fully understand how to put in practice these methods. I will not paste them here since it is copyrighted material (it is freely available in their webpage).

The PCI-DSS does not contain the exactly points I have made, but it is implied in the document if you read it carefully. Pay special attention to the "guidance" column.

(Feel free to add any grammar/syntax correction since English is not my mother tongue).


is this a good practice for storing private keys?

Don't try to learn data security by building a crypto exchange. It's like learning how to make a boat by creating a cruise ship. Or learn Physics starting with Quantum Chromodynamics.
Try a secure file storage first. Or a secure messaging platform. Or a secure emoji election. Simpler things, no financial damage if done wrong, no massive lawsuits, no need to flee from your country.
In a crypto exchange, the users don't have private keys, they have passwords for their accounts, like an email, or bank account. Think of a bank: the users usually don't have a private safe inside the bank, only the bank have one. Users have their funds stored on the bank database, and the bank is the owner of all the money. Regulations aside, the bank is the real owner of the money.
When users want to transfer their funds to another wallet, you is the one making the transfer in your own name. You can have a wallet for every user, but you are the owner of the wallet. Users will either don't care about the private keys (the vast majority of users), or will never ever trust you their private keys. There won't be much users not on those groups: ones savvy enough to have their own private keys in hand and willing to give you access to their key.
Crypto stored on your exchange will not be on a hot wallet, but a cold one. The hot, online wallet will only cover the day to day withdraws, and all the funds should stay offline. In the case of a wallet theft, you don't lose everything.
You don't want to have only one cold storage either. Losing access to it would lose access to all the funds, and that will be catastrophic. You will rather have several cold wallets, and keep them balanced. And the private keys should be stored in a way that in the even of the death of the owner, someone could access the funds. This is usually called Break Glass Procedure, and it's a safeguard against losing access forever in case of a disaster.
It should be tested before a disaster, and be implemented in a way that's not possible to use the emergency passwords undetected, and require more than one user. It could involve, for example, the Shamir's Secret Sharing scheme for half of the private key, and a printout stored on a tamper-evident container stored on a bank safe with an access ledger (or the owner will, safe with his attorney). In the case of disaster, a couple of high rank employees would get together to have half the key, and get the other half on storage.
Backing up private keys are usually a bad idea. They are the only protection against the total loss of funds, so the backup would have to be protected as much as the private key itself. And you will not want to use a VPS for hosting a crypto exchange. You will either have your own datacenter, or at minimum a co-location of your own custom server chassis with tamper proof sensors and automated data destruction in case of tampering.


Your salt probably doesn't need to change any more often than your password. Rotating through salts doesn't protect you from anything in particular.

Note that the salt that the attacker uses to brute-force a password does not have to be the same as the salt in use when he uses the password. Only the password needs to be the same. And since the result of his attack is to determine the correct password, that password will continue to work no matter how often you rotate your salt.


Is user password in ubuntu 13.04 in plain text?

I have never seen a unix system that stores passwords in plain text. Traditional unix systems used a hash construction based on DES (which included a salt, but truncated the password to 8 characters and did not perform any slowdown). In the late 1990s most systems switched to a password hashing scheme based on MD5, with salt and a non-configurable slowdown. Nowadays most Linux distributions, including Ubuntu, use a scheme based on SHA-2 with salt and a configurable slowdown. You can tell the password scheme from the first characters in the password field; $6$ indicates a SHA-512-based scheme.

Password hashes were traditionally stored in /etc/passwd, but modern systems keep the passwords in a separate file from the public user database. Linux uses /etc/shadow. You can put passwords in /etc/passwd (it's still supported for backward compatibility), but you have to reconfigure the system to do that.

So the answer for you is: no, it isn't in plain text (and there's no way to make it in plaintext even through misconfiguration). The hash is in /etc/shadow.


What are the consequences for deceptive practices against stated privacy policy

In most cases the provider will do the minimum necessary for compliance - be it compliance with legal requirements or with the binding industry standards they require to operate (such as PCI-DSS). If you have evidence that the provider is not complying with these requirements then the route to address these would be via the body which sets out these requirements. However I suspect that proving non-compliance would be rather difficult in most cases.

All the countries in the EU have very specific requirements regarding data privacy. And certainly within the UK there have been several instances of companies being fined for non-compliance with the data protection act.

However (IANAL) there is also a contractual issue between the provider and the user if the provider makes false claims about the security it provides. But since the provider is unlikely to go any further than the requirements previously described, then its unlikely that you'd need to exercise your options in this scenario.


How do two Tor relays communicate with one another?

They do know eachother's IP address. Tor works so that every relay node knows the previous and the next hop. However they never know the full route.


OpenSSL's EVP functions, more specifically EVP_SealInit

Yes, EVP_{Seal,Open}* do 'hybrid' encryption: symmetric-encrypt the data with a nonce key, and publickey-encrypt that key to the recipient(s), and decrypt accordingly. (EVP_Digest{Sign,Verify}* similarly do hybrid signing: symmetric-hash the data and public-key sign the hash.) If you don't want this functionality, don't use these routines.

If you want to publickey-encrypt and decrypt a small amount of data, such as a symmetric key, use EVP_PKEY_{encrypt,decrypt}{_init,}. Most symmetric keys are just random bytes (or bits) and you can generate with RAND_bytes. Assuming you want to subsequently symmetric encrypt and decrypt data with that key, see EVP_{Encrypt,Decrypt}* or EVP_Cipher* which has a flag to select direction.


What approaches are used to discover zero-day vulnerabilities?

I'd like to know what is the approach to find a zero day exploit/vulnerability and how can I, as a developer, make my software more consistent?

Learn and understand fuzzing techniques if your goal is to develop your skills in finding zero day vulnerabilities in your software (and other software)

From Wikipedia:

  Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, or failing built-in code assertions or for finding potential memory leaks -https://en.wikipedia.org/wiki/Fuzzing

Metasploit Unleashed created an excellent starter tutorial on Fuzzing:
Writing a Simple Fuzzer

Google Project Zero is known to conduct Fuzzing at scale (Maybe the entire Internet?)  Learn more about their fuzzing approach here:
Google Fuzzing at Scale

Remember to have fun, be safe, and always practice responsible disclosure.


Encryption as bijective data masking function

In general, you don't want to use deterministic encryption for non-uniform data (so cryptographic keys are okay, but other data is not).  That's because secure encryption tells us nothing about the contents of the data except possibly its length, so it shouldn't be possible to determine anything about two messages based only on their encrypted versions.
However, with a deterministic encryption method, two identical messages encrypt to the same thing.  That's bad, because if we take a large set of city names, the most common encrypted values are generally going to be the largest cities in the region.  For example, in the United States, the most common cities will be New York, Los Angeles, Chicago, and Houston.  If we also see first and last names encrypted deterministically, with a large enough data set, we can easily deanonymize data.  For example, two people in the same city with the same uncommon last name might be related.
That's why this approach isn't secure and shouldn't be used, and it's why ECB mode can't be used for data.  Moreover, if you use certain types of encryption, such as CTR mode with a consistent nonce (or another stream cipher), you make it very easy to recover the plaintext via crib-dragging attacks.  You need to use a secure mode with a suitable nonce for each different piece of data.
So there isn't a secure way to do what you want to do.  If you don't have a better suggestion than deterministic encryption for your test environment, I'd suggest generating test data independent of your prod data and using that.
Because modern encryption modes are not designed to encrypt multiple pieces of data with the same nonce and still protect the information, if you want some way of obscuring data which is unique, I would use something like HMAC-SHA-256 with a fixed and secret key.  For things like phone numbers, which are unique or nearly so, this provides a secure way to obscure the data and provide a one-to-one correspondence with it, but it isn't invertible.  This is secure because it's unlikely that people will be able to deanonymize your data, so it's okay for things like phone numbers and email addresses, but not for data which multiple people will share in common and which differ in frequency, such as names or city locations.  For those, any deterministic technique will be a problem.  If your data set is large enough and contains enough personal fields, an attacker will almost certainly be able to discover the identity of at least some of your users with at most a couple of days' worth of work.
I fully agree that using encryption or some other cryptographic method is better than not doing it, but if you're using these techniques to obscure personal data that isn't unique or nearly so, then you need to treat your development data as just as sensitive as your production data because its exposure will expose your users.


Infected employee using office VPN was part of a DDoS attack

As you mention, you should definitely setup "split tunnel" VPN, wherein traffic only traverses the VPN when it needs to -- other traffic goes over the internet.  That is likely the simplest solution to your issue.  However, the caveat is that these infected computers can still be used as a hop-off point to access resources on your VPN; so you can have a security issue and not be aware with that solution.

There are many other, more complex ways of addressing the problem.  Of course, not just advising but requiring VPN users have active, up to date AntiVirus is important.  Many VPN concentrators (Cisco, Juniper, etc) have features in their VPN clients that allow for testing for compliance to a host profile -- e.g. see if updates are installed, antivirus is current, etc.

Moving up an order of magnitude, an IPS (Intrusion Prevention System) system is the ideal solution to this problem; if budget allows as these systems are prohibitively expensive and often require significant resources to setup.  A properly configured IPS will immediately revoke VPN access if seriously anomalous activity is detected -- a DDOS attack will almost certainly trigger this.

In this case, you can still use a "full tunnel" VPN with all internet traffic using the VPN as the default gateway if you prefer.  While speed may suffer on a full tunnel VPN connection, it will be more secure as all traffic will have to traverse the IPS system.


How does non-ephemeral Diffie-Hellman key exchange become compromised in SSL when the RSA private key is leaked?

First let's be sure that we talk about the same thing. In SSL, there are "ephemeral DH cipher suites" (DHE) and "non-ephemeral DH cipher suites" (DH).

With DHE, the server private key (the permanent one, the one which is stored in a file, and whose public key is in the server certificate) is of type RSA (DHE_RSA cipher suites) or DSS (DHE_DSS cipher suites), and is used only for signatures. The server generates a new random DH key pair (the private key will not be stored, which is how perfect forward secrecy is achieved: a private key cannot be stolen afterwards if it has never been stored), and sends the public key to the client, in a message which the server signs with its RSA or DSS private key.

With DH cipher suites, the permanent server private key is a DH private key. The server certificate contains the DH public key. The server cannot see its RSA key be stolen because the server does not have a RSA key. The server only has a DH key. When a cipher suites is called "DH_RSA", it means "the server key is a DH key, and the server certificate was issued (i.e. signed) by a Certification Authority who uses a RSA key".

Stealing the DH private key of one party involved in a DH key exchange allows ulterior reconstruction of the shared secret, just like RSA. In "ephemeral DH", the PFS is obtained through "ephemeral", not through "DH". Technically, it would be possible to have "ephemeral RSA" but it is not done in practice(*) because generating a new RSA key pair is kinda expensive, whereas producing a new DH key pair is cheap.

(*) Ephemeral RSA keys were possible with old versions of SSL as part of the "export" cipher suites, meant to comply with the pre-2000 US export regulations: the server could have a 1024-bit signature RSA key, and generate an ephemeral 512-bit RSA key pair for key exchange, used in encryption mode. I don't recall having ever seen that in the wild, though, and it is a moot point since US export regulations on key sizes were lifted.

Non-ephemeral DH cipher suites exist in order to allow servers with DH certificates to operate. DH keys in certificate exist because in older times, RSA was patented but DH was not, so standardization bodies, in particular NIST, were pushing DH as the must-implement standard.

Reality caught up with that, though. I have never seen a SSL server using a DH certificate. Everybody uses RSA. The RSA patent expired a decade ago anyway.


How can I find out if someone has been on my home wifi network?

It's not possible to find this out about past connections unless it has been logged by some device. The prime device for logging this would be your access point because this is the device that authenticated the request to connect to your wifi. Whether it is capable of logging such requests will depend on the capabilities of your wifi access point. It may already be logging this information, I'd look around in the web interface.

You could also setup a computer with a wifi card to listen in promiscuous mode with wireshark. This means it will listen to all frame also those not addressed to it and you should be able to see clients authenticate to the access point and also authentication failure. You could also be logging mac addresses via ARP or DHCP.

I think your virus scanner not working is completely unrelated to the security of your wifi network. Even if your wifi was compromised it'd be unlikely for your virus scanner to stop working. If you distrust your wifi do the following:

change the password into a complex long random string like "hXs0#/;W#y38!u0aIi$o65>Ra", you only have to input it once anyway.
change the admin password that allows you to change these settings into a proper one too.
update the firmware on your wifi access point / router
make sure WPS is disabled
make sure you're using WPA2


Bachelor's degree transcript (Marks Sheet) and Certificate Watermarking

Watermarking your resume or transcript doesn't protect you from serious threats. I'm not familiar with the the content of transcripts from Pakistan but in the USA they do not contain government IDs which would be one of the pieces need to full assume someone's identity.

If I were you, I would reach out to universities I want to attend and work with them directly. Universities have advisers that can give you the information you need and give you feedback on your transcript. I advise you to send your transcript directly to a university over a random facebook group admin.


How to protect my email and social media accounts?

Two step authentication, make it send a text to your phone anytime you need to login. check your logs on your computer and check all programs. run ccleaner, and malwarebytes.


Let's do some math and study the language to see how this compares to the standard password requirement of 8 characters upper, lower, number and symbols.

Now we are going to be rigorous, so we assume that the attacker knows that you use a sentence as your password and is only trying to break it based on that information. He also knows that you do not use any spaces, capitalization or punctuation in the sentence. I am also intentionally ignoring grammar and syntax since it's too complicated and doesn't provide much insight to an attacker, apart from some words occur primarily at the beginning and or end of a sentence.

While there are a million or so words in the English language people don't use or know that many. The average person uses about 500 unique words in a day, and it is believed that an average person needs between 1500 and 2500 words in their vocabulary to communicate effectively for an extended period of time. Average person also knows about 15,000-20,000 words that they use infrequently.

So let's try those numbers with a 5 word pass-sentence:

Standard to compare is 95^8 = 6.6 x 10^15

500^5 = 3.1 x 10^13

1500^5 = 7.6 x 10^15

2500^5 = 9.8 x 10^16

From this we can conclude that using the expanded vocabulary of the average English speaker we can create a password that is as resilient to specialized attacks as the industry standard is to a brute-force. It would however be significantly more resilient to that same brute force, 26^16 = 4.4 x 10^22. (I used 16 as an average length of 5 words)

Take this all with the same mentality as a normal password. The password "P@55word" has all the features of a secure password but is totally insecure. The same would be true for a pass-sentence like "ilovemygirlfriendmelissa" especially with a little social media recon on the target.

I'm sure some security experts will disagree with this, but then again the security expert quoted in another answer on this page advocates writing down passwords, so I just assume they'll never agree like most experts.


Would DNSSec and DANE be more secure if the same key was published to different TLDs?

If your website (for example) is on a TLD you do not trust, then many things can happen (like the registry could change the nameserver of your domain making your website unreachable) even if the underlying TLS certificate would list many SANs (I'm not sure how a CA would validate such a certificate, since it would have to gain proof of ownership for each separate SANs at the almost same time; but maybe you are thinking about the DANE case where you directly publish the certificate without later on needing CA validation).

Also, in all cases, you still depend from the DNS root key and management/governance, so if you do not trust DNSSEC, you have this point that is impossible to remove.


This case is prevented by the Same-origin Policy.

  "Under the policy, a web browser permits scripts contained in a first
  web page to access data in a second web page, but only if both web
  pages have the same origin. An origin is defined as a combination of
  URI scheme, host name, and port number. This policy prevents a
  malicious script on one page from obtaining access to sensitive data
  on another web page through that page's Document Object Model."

In the context of your example, the malicious site is not permitted to perform a request on the banking website, and an attempt to do so will result in a message similar to the following in the browser console (taken from Chrome):

  Failed to load XXX: Redirect from 'XXX' to 'XXX' has been blocked by
  CORS policy: No 'Access-Control-Allow-Origin' header is present on the
  requested resource. Origin 'null' is therefore not allowed access.


From those links you posted, it is clear that Debian is not patching them because they consider them too minor and or unrealistic to exploit:

CVE-2019-19603 [buster] - sqlite3  (Minor issue, too intrusive to backport)

CVE-2019-3844 [buster] - systemd  (Minor issue; exploit vector needs control both of the service and a helper

The high severity could be overstated, but only you can determine if the above notes are good enough for your threat model.
If not, you could download the newer, patched versions of these programs and build them from source. It also looks like the issues may be fixed in Debian sid (unstable). You could try to configure apt to install these newer versions, but it may cause dependency issues.


What problem would there be with an open private key for developers to use?

I have the feeling that you are trying to tackle the problem you have from the wrong end:

  I always find it a pain to create a new key for development ...

I'm not sure what you are doing which causes so much pain, but if you are doing the same steps again and again it might be actually useful to find a way to automate these steps for yourself.

  It actually seems more secure for me as a developer than creating a self-signed certificate using publicly available tools and having the key sitting around on my hard drive for my tools to use. If anyone got that, they could spoof any website for me because I have to trust it, right?

If I interpret this correctly you are creating a self-signed server certificate with basic constraints CA true (i.e. this certificate can be used to issue certificates). It is correct that this can be used to create more certificate and thus access to the certificate and its key can be used to man-in-the-middle all sites - provided that you've imported this certificate as trusted CA (certificate authority) instead of a trusted server certificate. Note that just adding an exception once the browser complains will not add this certificate as certificate authority.

It also would mean that the attacker needs to have access to your system in the first place - in which case it might do even more harm. Nevertheless, this particular problem can be easily mitigated:

Most (all?) browsers actually can import a self-signed server certificate which has basic constraints CA false. There are though tools which cannot deal with this and expect CA true on a self-signed certificate.
One could create a CA with its own private key, let it issue some leaf certificates (basic constraints CA false) with another private key and then throw the private key of the CA away. The CA can still be imported as trusted into the browser so that all certificates issued by this CA will be trusted too. Since the private key of the CA is deleted one cannot create more certificates though.

  fakesite.com would send all subdomains to one page on the main website which would explain what it was for. The actual certificate and private key would be made available elsewhere such as in a github repository.

It is not a good idea to use a publicly available domain for this. The problem is that it is insecure by default, i.e. the browser will resolve the domain and try to connect to it and man in the middle attacks to the domain will not be detected since everybody knows the private key to mount invisible attacks. And then the attacker could do the attacks you've already described and maybe more.

Fortunately the public CA which has issued the certificate would revoke the certificate anyway if the private key gets known publicly and thus this idea would not work (provided that the browsers check for revocation - which many don't or don't do properly).

But the general idea could be modified to be safer. If one simply uses a domain which will never exist publicly, a browser can only connect to the domain if the system is specifically setup for this. RFC 2606 defines some top level domains which might be used for this, i.e. .example, .test, .invalid and .localhost. When using any of these top level domains an attacker could only harm developer systems which are specifically setup to resolve such domains and which have explicitly imported this certificate as a trusted server certificate, instead of being able to harm arbitrary systems.


Skype encrypts all traffic.

https://support.skype.com/en/faq/FA31/does-skype-use-encryption

Your VPN provider can record this traffic, but I think they won't be able to decrypt it.

However... Skype itself is able to decrypt this. Since MS took over, all traffic is directed over their servers, and they have the keys used for encryption. In the old days, once the connection was setup, traffic was between sender and receiver directly, which was much more efficient, but less convenient for certain US agencies.


Implementing SRP Challenge login system *with SSL* (Using PHP)

The algorithm was ported to JavaScript for clients (browsers) and to PHP for servers: See Ruslan Zavacky's spr-6a-demo on GitHub.


anti-CSRF tokens vs Referer and POST testing

This is not a solution because common desktop firewalls offer an option to strip the Referer header for privacy reasons.

Furthermore some plugins allow to set the Referer header to arbitrary values, although the common plugins (Java, Flash) prevent this in recent versions.


Can my iPhone photos be viewed by the person I got it from?

If your iphone is not jailbroken, and you did a factory reset (be sure of that) your datas are safe.

For extra precaution you can also verify that all the possible accounts are deleted on the phone : google drive, dropbox, iCloud ...


You can do this easily with openssl:

openssl req -new -out myserver.csr \
  -newkey rsa:2048 -sha1 -nodes -keyout myserver.key  \
  -subj "/C=US/ST=New York/L=New York/O=My Company/OU=1st OU/OU=2nd OU/CN=www.myserver.net"

(If you already have a key you wish to use, omit -newkey rsa:2048 -sha1 -nodes and use -key myserver.key instead of -keyout ...)

You can inspect the CSR before you submit it with:

openssl req -in myserver.csr  -noout -text


Is publishing CRLs over HTTP a potential vulnerability?

There is no such thing as a non-signed CRL; the signature field is mandatory, and any system that uses the CRL will verify the signature.

In pure X.509, a CRL will be deemed "acceptable" as a source of information about the revocation status of a given certificate E if it is signed by an "allowed revocation issuer": the CRL's signature must match the public key contained in an already validated certificate, whose subjectDN is equal to the issuerDN of E (you can have a distinct DN if E contains the relevant CRL distribution point extension and the CRL has a matching Issuer distribution point extension; but let's forget this additional complexity). Complete rules are exposed in section 6.3. Note that "pure X.509" is supposed to work in the context of the Directory, the kind-of worldwide LDAP server that references everything under unambiguous Distinguished Names.

Since the Directory does not really work, because it does not, as it were, exist at all, existing implementations tend to implement stricter and simpler rules. Generally speaking, a Web browser validating a certificate E issue by CA C will accept a CRL only if it is also signed by the same CA, with the same key. This rule keeps path validation simple and bounded (otherwise, you may imagine a situation where you must get a CRL for each certificate in the path, and each CRL is to be verified against another CRL issuer certificate that requires its own path validation, and so on). Therefore, producing your own CRL relatively to your own root CA is unlikely to have any actual effect.

CRL, like certificates, are thus objects which are always signed, and never used without verifying that signature(*), so they can be served over plain HTTP. Using HTTPS to serve CRL is just wasted resources; it may even prevent CRL download from working since some implementations (e.g. Windows) refuse to follow HTTPS URL when validating certificates (be it for CRL, OCSP, or extra intermediate CA download), because that would mean SSL, then another certificate to validate, and possibly an endless loop.

(*) I here exclude root CA "certificates", traditionally self-signed; these are not real certificates in the X.509 sense, but only objects that mimic the encoding rules of certificates.


How to get site's 'real' URL (before being rewritten)

I'm not sure what your question is.  Let's say you have a simple rewrite rule like to redirect content from http://www.example.com/old.html to http://www.example.com/descriptive-directory/new.html something like:

RewriteRule ^old.html$ http://www.example.com/descriptive-directory/new.html [R=301,L]

Then a user's web browser sends a GET http request to http://www.example.com to fetch old.html:

GET /old.html HTTP/1.1
Host: www.example.com

The web server catches this in the rewrite rules, and sends back a http response from the server like:

HTTP/1.1 301 Moved Permanently
Location: http://www.example.com/descriptive-directory/new.html

and then your browser fetches whatever content is at http://www.example.com/descriptive-directory/new.html as if you had originally type in the rewritten url.

So what is your question?  You presumably know (and can easily log) the web addresses your browser has been requesting before it has been rewritten.  At the very least you can capture the GET requests by following the TCP stream with a tool like wireshark.

You know where the redirect rule has ultimately sent you; e.g., the location is now displayed in your web browser.  If you have access to the apache logs from the webserver side you'll see something like:

127.0.0.1 - - [2/Feb/2012:12:36:17 -0400] "GET /old.html HTTP/1.0" 301 315 "-" "Mozilla/5.0"
127.0.0.1 - - [2/Feb/2012:12:36:17 -0400] "GET /descriptive-directory/new.html HTTP/1.0" 200 1702 "-" "Mozilla/5.0"

though you could easily just look in the apache configuration to find the actual rewrite rules.

Note: none of this has anything to do with where the content is stored on the web server.  There may be no directory called descriptive-directory or files called new.html or old.html on the web server.  The entire http response from a request to http://www.example.com/descriptive-directory/new.html could be taken by the web server and then return a dynamically written html page.  E.g., the following simple webpy code can be executed to act as web server without any html files existing.

# call this file silly_website.py
import web
urls = (
    '/descriptive-directory/new.html', 'new',
    )
class new(object):
    def GET(self):
        return "<title>Hello</title>World! from new"

app = web.application(urls, globals())
if __name__ == '__main__':
    app.run()

which could be then run as python silly_website.py [your_ip] and you have a running webserver that will give back a very simple webpage for a request to /descriptive-directory/new.html.  As such there's no generic way of finding out where content returned from the web server is actually stored on the webserver (even in relation to the web server's root directory).


Best practice to share google drive API credentials for being used by a script?

We decided for option A: users need to create client_secret.json and credentials.json files themselves. It is unfortunately not the most straight forward, but the most secure one. Sharing credentials in a public repo is just a big no-go, no matter the details.

Also for the sake of completeness: another alternative would be to have our application running on a server where we could save the client_secret, so then a user would just be presented with a browser-popup where he/she would authorize our service.

But we don't follow that option either since the script shall only contain the core logic and it shall be a base for other to develop upon.

That's our motivation behind the decision.


Are old Wordpress versions still secure?

In practise yes
There was a XSS bug (XSS vulnerability was discovered in the Flash fallback files in MediaElement), affecting all versions since WordPress 3.7 (at the point where it was discovered, of course).
https://wordpress.org/news/2018/01/wordpress-4-9-2-security-and-maintenance-release/
Wordpress team fixed it, and released version 4.9.2 to fix it on the 4.9 branch. It also released version 4.8.5, 4.7.9, 4.6.10, 4.5.13, 4.4.14, 4.3.15, 4.2.19, 4.1.22, 4.0.22, 3.9.23, 3.8.25 and 3.7.25 to fix the respective branches.
You can easily view the changes and see that they are backports covering this same issue.
So, as far as you update to a newer release of those "old versions", you would be fine... if there are patches.
Now, what you need is to stay at a version for which someone (preferably Wordpress team) will issue a fix if there a new vulnerability affecting it was discovered. This is documented on
https://codex.wordpress.org/Supported_Versions
And there they say:

The only current officially supported version is WordPress 4.9.1. Previous major releases before this may or may not get security updates as serious exploits are discovered.
Support Policy
WordPress will be backported security updates when possible, but there are no guarantee and no timeframe for older releases. There are no fixed period of support nor Long Term Support (LTS) version such as Ubuntu's. None of these are safe to use, except the latest series, which is actively maintained.

So, they give no warranties that they will continue doing so in the future, but are fixing the security bugs (no new features, of course). Regarding version 4.7.9 note that Debian stable wordpress package also uses the 4.7 series and this branch is likely to continue receiving security fixes (by both wordpress team and downstream maintainers) for quite a long time.
Given this, I wouldn't consider requiring that the webmaster updates to 4.9.2 if they are already at 4.7.9, as the security issues have been fixed. They are updating their wordpress. The lazy webmasters are those that installed 4.3.5, and are still running that version.


What are the common vectors for installing rootkits? (And if I understand correctly, this would include MBR as well as BIOS? So same question for each.)

Mainly by hooking the system calls. I suggest you read a book about this because I cannot cover it all here. I suggest: practical malware analysis and rootkit arsenal

How common are rootkits that survive OS reinstall (and are these limited to BIOS, or can MBR infections achieve this?)

Depends on the rootkit. Read rootkit arsenal for details

How common are USB key infections? I know many government agencies have had policies for a few years now of not allowing employees to even use USB keys on their machines, but these are high security settings.

Not every rootkit is delivered using USB. Some can use your email attachments, 0day vulnerability in your browsers, etc..

If there's a concern about attacks that are unknown to commercial AV tools, would commercial tools still be useful in detecting a rootkit from a fresh OS install? E.g. detecting unexpected network traffic as it tries to download additional malware?

They are called 0days exploits/vulnerabilities. Security engineers are working on detecting those using a technique called behavioral malware analysis. It is a mouse-cat game.

On a previously compromised machine, is there really any hope of detecting a keylogger? I am suspecting not (unless a very poorly written keylogger, or already known to AV software.)

A real hacker (not script kiddies) would make his/her attack persistent. First thing to do is kill any AV.


Securing a REST api at the message level

Unless I have missed something your solution looks awfully like a Security Token Service. For an STS the key is to have a party that is trusted to identify the initiating party to the relying party. In your case the trust broker and relying party appears to be the same entity.

If your goal is to have trust propagate to the final destination, just use SSL through the proxy, and use a client certificate to identify the end point. Assuming you want HTTP going through your proxy so that you inspect traffic, implement a standard STS.

As Xander has said, REST is great for lightweight service calls, but the moment you want to do security you should use SOAP, specifically the WS-Security extension. It really isn't that hard, especially if you control both ends as you do. See this stack overflow question for how to do this in Java on Android.

If you do go ahead with your home baked solution it is worth noting that the last three bullets in your Authentication look to be your weak point.


Authencity of information displayed on an untrusted device

I understand your question as follows: there is a tangible device which may produce data and send it over radio (Bluetooth); and another device (say, a smartphone) which receives said data, and displays it; the problem being that the second device cannot be trusted. So the question is: can we do something about it, so that we may gain some confidence in the data as displayed being a faithful representation as what the first device sent ?

Generically speaking, no, we cannot; liars lie. Unless the data that the first device sends comes with some sort of checksum or signature that the second device cannot forge or fake (digital signatures and MAC might prove useful cryptographic tools for that), and that the human observer verifies independently of the untrusted smartphone. This latter point is the true problem: a normal human observer will not compute in his head a signature verification or a MAC.

Workarounds for that kind of situation come in two kinds:

Add a display directly on the first device, so that the device may display its data directly, without interaction from the potentially hostile smartphone. This is what is done with payment terminals: though they are linked with a cash register which is, basically, a PC, such terminals still have their own screen and keyboard because the cash register is not ultimately trusted.
Add a third device to the dance. Give the user a device that he trusts, and that will verify whatever MAC or signature computed by the first device. Mutatis mutandi, this is the Internet, with the untrusted smartphone mapping to mere routers; some SSL between source and destination protects the integrity (and confidentiality) of data from mishandling by routers.

(We may note that this problem is also an inherent issue with smart cards inserted in PC through dedicated readers or USB ports. When we enter the PIN code, it is on the PC; we cannot really know what the PC asks the smart card to sign.)


Is it secure to store an rsa private key with aes encrypted in your database?

If encrypted private key can be requested by an attacker (you didn’t specify any authentication for the request) or your servers are compromised then you’re opening your users to offline attacks. Now the only barrier between attacker and user’s private key is the user’s password.

Generating per-device key pairs is preferable, for example user can deauthorize key pair of a lost device.

If you insist on sharing one key pair I suggest transferring it from client to client within an end to end encrypted channel. This way:

the private key transmission is protected by a much more secure keys generated by DH key agreement. Beware of MITM attacks, they could be discovered by comparing hashes of keys between the devices
the encrypted key is transmitted only once and never stored, unless the attacker is eavesdropping at the moment of transfer
the transfer could be performed directly between the devices through a local network or a cross-nat p2p protocol. This fully excludes your server.


Reset links in password expiration emails

The short answer is no.   Sure you can make your email very legitimate looking, that isn't the problem.  The problem is you are conditioning your users to click on links in emails and email is a 100% insecure medium.  Links in emails are an anti-pattern.

"Official looking" isn't secure.  Almost everything in your email can be replicated by a dedicated attacker.  If you are mycompany.com an attacker using myc0mpany.com would almost certainly phish some significant percentage of your users.  The attacker can use SSL and SPF as well.  Which means some very subtle things which are not strong identifiers.

It is clear you have put some thought into this. Things like identifying the user by username adds legitimacy but would most of them notice if another email from "you" didn't?  As an experiment, if you sent a similar email to a test group without those extra legitimacy boosters or from a spoofed domain (myc0mpany.com) my guess is you would see a click through rate that is almost as high.

Now if your bosses pressure you into using links well I certainly understand.  We as an industry have done an incredibly good job of conditioning everyone from end users to policy makers to expect this anti-pattern.  However if you can, take a step back.  Why do you need a link in the email?

Why can't you just handle password reset on the next login? Send an email to users advising them they will need to reset their password on the next login.  You could include a screenshot of a browser (with url) and the login page if you think users are incapable of finding their way to the login screen without a direct (insecure) link.

Also I would not roll out a password reset to all 40,000 users at once.  Handle it in batches and take time between batches to get feedback.

Even for lost passwords there is no need to include links in emails.

On website user tries to login and can't.
User clicks forgot password and completes any alternate identification requirements.
Server side generate reset code, update user record in db to store account status (reset), store reset code and expiration.
Send email to user containing reset code (no links).
Page loads to indicate to user an email has been sent containing reset code.
User copies reset code from email and pastes it into the secure site

The most important thing you can do to prevent phishing attacks is regularly and continually remind the users to never click links in emails.  This should be done both in all your email communication and at the website login.  You should also have a dedicated email address such as fraud@mycompany.com and advertise it in all email communication.  This won't prevent phishing emails but it may alert you to an attack earlier.


To answer your question:

If you're using SSL/TLS to access your e-mails, regardless of whether it's POP or IMAP then it would be very difficult for anyone to decipher the text of the e-mails from analysing the traffic alone. That said some large companies e.g a law firm I used to work for have a server which sat between us and the internet, stripping out the SSL so the answer is a qualified yes in saying you're safe.
Also if the message is still sitting on the e-mail server after you access it, then it is possible for your e-mail provider to be bribed/coerced into handing it over. Of course GPG does solve this problem. You can also ask your e-mail provider to delete messages you download through POP though you have to trust that they're both able and willing to delete the messages securely.
With SSL, when logging in using your e-mail password, your password cannot easily be read by intercepting the traffic between your computer and e-mail server subject to the proviso I mentioned in point one.
Your understanding of PGP is largely correct. If a message is sent to you encoded with your public key then only you our someone who has broken your private key can read it. The sender's private key is irrelevant as he can't use it to decode a message meant for you. If your e-mail password were sent in plain text though you're absolutely right in thinking it could be intercepted and someone could access your e-mails or send them on your behalf pretending to be you. If you used PGP at all times to encrypt and sign all messages and others did the same for you, this would protect the content of your messages though.
I can't imagine why an e-mail provider wouldn't want to offer SSL beyond sheer laziness. You can even get free certificates these days! Most of the free webmail providers offer SSL e.g Gmail, have you thought about using them?


How well the OpenVPN router defend against mitm

I'm not an expert in VPN, so I'm curious about how well does a router
  with installed vpn defend against an mitm attack. Since ARP Spoofing
  can decrypt https, I'm concerned if it's able to decrypt a vpn too.

ARP spoofing cannot decrypt HTTPS traffic. HTTPS 'sits higher' in the network stack and therefore layer 2 cannot 'see into' the packet. It can though do things to the packet, such as change the physical machine address of whom sent it or where it is going. But it definitely cannot decrypt the packet

  Also will the hacker be able to DOS your internet connection?

An attacker could cause a denial of service to any service sitting publically on the internet if they have enough bandwidth to overcome your ingress bandwidth. I do not see though that DOS is a concern within the context of your router being ARP spoofed.

  Then, what if let's say one of the device using the vpn is
  compromised? Will the hacker be able to use it to hack the rest of
  your devices?

Yes - If the VPN is not segregated from the rest of the network via say a Firewall and the other hosts do not have suitable host based firewalls.


Is this a symptom of an attack (DoS/DDoS)?

From the summary of your issue, if it is causing resource consumption then even if this is not an evil 'attack' it is still causing you a Denial of Service condition and you are right to revisit your architecture.

However, in terms of identification of this being an attack, you would need to investigate the query terms further, to understand if any of them are attempts to conduct injection based attacks (such as cross-site scripting (XSS) / SQL Injection etc.). The high volume of numbers and names could be used to create noise to hide malicious attempts.

You should also look for trends within the data to identify if this is potentially a coordinated effort and thus classify all of the bad traffic as the same or if you have a specific subset of bad traffic that you can focus on.


The symmetric encryption key is derived using a key exchange, even in the case of using a pre-shared key (see RFC 2409 section 5, particularly at the end of page 8 and then at section 5.4).
In the case of certificates, the public keys are used for the key exchange in order to negotiate a symmetric encryption key (see RFC 2409 section 5 again).  The client and server (or peers) must know each other's certificates in advance or establish pair trust; you're correct.  The server certificate isn't used to encrypt data; the symmetric key negotiated during the key exchange is.
You're correct on the mitigation of MITM attacks.  The authenticated key exchange establishes a symmetric key known to only the two peers (client and appliance), thereby preventing an attacker from modifying the key exchange packets or decrypting/modifying the encapsulated packets.


Is an open source web application server publishing it's version at a public endpoint a security issue?

It's generally considered an unnecessary risk, yes. There is no need to make things easy for the automated vuln scanners or worms, much less an intelligent attackers. Legit users have no use for the information, developers / sysadmins can examine the server or connect to some internal-only diagnostic page with more info, and you'll save a smidgen of bandwidth to boot.


What can a 3rd party learn about a user through only CSS and images?

This answer might be considered as a partial answer since it's not intended to be exhaustive.

With CSS only, a 3rd party can indeed (to a certain point) fingerprint a user's browser by:

CSS querying by detecting some browser's unique properties (using prefixes. For example, Chrome & Safati present CSS properties prefixed with -webkit-)
Retrieving system fonts / Font Inspection: For compatibility reasons,
web browsers have fallback fonts for each font-family:

  The collection script queries a device for installed fonts by
  generating hidden elements on a web page. The hidden element contains
  a predetermined character string and for each queried font, the height
  and width of the hidden element is compared to the height and width of
  an element containing the same string but formatted in the fallback
  font. If the height and width differs, it is be assumed that the font
  is installed.

CSS Media Queries : Media queries can be used to gather almost the same amount of information as Window and Screen objects

Even if it's a bit out of scope, there is also "Canvas Fingerprinting":

  That works by exploiting the HTML5 canvas element: when a user visits a website their browser is instructed to “draw” a hidden line of text or 3D graphic that is then rendered into a single digital token, a potentially unique identifier to track users without any actual identifier persistence on the machine.

Here is a pretty interesting piece of code that implement some CSS fingerprinting techs.
And here (in chinese) a good paper on browser fingerprinting only with CSS.


Generally, one time use tokens are used to mitigate replay attacks and to make it harder to steal authentication information.  They have other uses in protocol design for multi-tentant and multi-user systems.  I am going to assume those don't apply because you said this was a custom API built just for you.

If you are calling the API over the web using SSL/TLS then TLS/SSL already provides mitigation against replay.  It also provides encryption to help mitigate someone stealing your authentication information.  I would say they have over-designed the security in the API. However real security is about layers and adding another layer makes it more secure. How much more secure versus the cost of the second call is debatable.  You might suggest they issue you a time limited token vs a one time token.

That being said there is no limit to the number of Apex callouts from Salesforce.  There is only a limit to the number of callouts per transaction.  See here and here


There are several models already designed for you not to think precisely on categorisation of threats, but to create a safe architecture. The worldwide known entity about this is called NIST, who provides a Policy Framework about cibersecurity.

You can check out on the official site but not before getting an intro about NIST here and here (Wikipedia).

FYI, NIST is recognised worldwide, but it is still a national entity in the USA.

If you find it a little bit heavy, another alternative can be the Ishikawa model which categorises threats by kind and I’m not sure if provides strategical solutions for each sector.

Ishikawa diagram

I think there is no official site for this, but there is plenty of information about it anywhere.


How can information be recovered after it has been overwritten (single pass) by a secure deletion program?

The whole multipass overwrite is fundamentally an urban legend hold over from a disk technology that hasn't been in use for decades.

Overwritten data (even once) is not recoverable, there is no tool to do it.

That said, the real issue is being able to actually overwrite the data in the first place. It's fairly simple to accomplish if you're wiping the entire drive (with standard caveats on overlays, protected regions, etc.), but if you are trying to overwrite only selected files, it's harder than you might think. There are numerous reasons, I'm not going into, as to why the attempt to overwrite individual files on a file system may not actually overwrite.