Certain browsers have certain features. The service runs JavaScript they provide you, so they can run a lot of feature tests in the actual browser. This can be used to validate your userAgent string.

For example (purely hypothetical), if everyone knows that Chrome after v50 supports CSS variables, and any Chrome after v40 no longer support the old vibration API, but your browser claims to be v55 and seems to support both features, you're busted. A quick visit to https://caniuse.com/ offers numerous "smoking guns" one could use to detect such version/feature correlation.

There's also a lot of web APIs that only one or another browser supports, like -ms-browse CSS and microsoft browsers. This is basically the reverse of the web developer advice "don't browser detect, feature detect for forward compatibility". By doing both, recaptha can spot liars, unless you're so good at spoofing (altering JS and DOM internals along the way) that you might as well be using the browser you are pretending to be, and at that point it can't/won't care.


Is it bad practice to use the same password on different sites?

Even if the passwords to a site are compromised the attacker still doesn't know the user names or sites the same password is used on, or even if the same password is used anywhere again at all!

Why does he need to know? If he has a set of usernames and passwords, how will it hurt to try the set against common sites like Facebook, Twitter, Gmail etc? What are the odds of someone using the same password but different usernames?

Yes, it is bad practice. Use strong, random and unique passwords for each site.


What kind of damage can a website with malicious javascript do?

Javascript is an engine executing code client side. If you allow third party uncontrolled javascript in your site, that means that potentially visitors of your site may execute arbitrary code in your browser.

Damages can come at various levels:

simplest and lightest: simply play with the browser. As an example start a background loop that repeadetly shows popups
slightly more advanced: remove the browser menu and intercept the close event to prevent user to simply close the application to get rid of the popups
still one step further, play with the stored browser config by changing shortcuts or favorites to call an infected page
hardest but more harmfull: use flaws of browsers to escape from the browser sandbox and directly access the underlying system

Depending on the system, the browser and their configurations, some of those attacks will not be possible. But even the lightest one, the background loop that continuously open popups is extremely annoying for a user, and you can be sure that he/she will never come again to your site.


Does Google/Dropbox/Github Two-Step Verification count as Two-Factor?

TOTP is an extension of the HMAC-based One Time Password algorithm (HOTP). Both TOTP and HOTP require an secret key to be incorporated into the algorithm. Devices and tokens that implement TOTP (Yubikey, Google Authenticator app) are designed to protect the secret key against extraction.

For example, Yubico mentions:

  Secure manufacturing process
  The YubiKey is manufactured in Sweden, in a fully access automated process, using YubiHSM technology to
  ensure that no staff or IT administrators can have access to
  encryption keys.

  Easy to program own secrets The YubiKey requires no special hardware for programming, enabling you to easily program and control your own
  encryption keys. If required, Yubico offer optional password write
  protection of the settings, but all YubiKeys sold on our web store can
  be re-programmed. For security reasons Yubico firmware is not
  upgradable, it’s a write only device and the encryption key can
  never be read out from the device. [Emphasis mine]

  Tamper proof casing The YubiKey is based on standard components, high-pressure moulded into plastic, making it practically impossible
  to tamper. If tampered, it will require sophisticated equipment to
  read out the secrets and cannot be done without physically destroying
  the device. Each YubiKey is seeded individually, so any breach would
  be for that unique Yubikey only, there is no systemic breach. If lost
  or stolen, the user administrator can easily disable the YubiKey so
  that it no longer can be used.

If we assume that the secret key cannot easily be extracted from the token (and the above examples indicate that we can make that assumption), then it counts as "something you have". Even though the token may be mass produced, once combined with the secret key it becomes unique for the purposes of two-factor auth.

Edit:
Thank you to Terry Chia who has pointed out that the Google Authenticator app stores the key in cleartext in a sqlite database on the device. This was reported in a bug report in March 2013. Google promptly noted that this is a "won't fix" issue:

  Reported by wolfka...@gmail.com, Mar 26, 2013 What steps will
  reproduce the problem?
  1. Open the databases database from within /data/data/com.google.android.apps.authenticator2/databases/database...

  klyu...@google.com
  Thank you for your report. This is working as
  intended/designed. Step #1 assumes you have root access or have
  otherwise compromised the security of the Android device. Security of
  data stored on or processed by such devices cannot be guaranteed. ...

I'll note here that you can and should encrypt your Android device, and doing so will mandate a password to unlock the screen. This will protect against key extraction, among other things.


Yes it will be possible to successfully achieve a MITM attack.

Consider the simple scenario where the origin IP you are allowing has a LAN inside so any person in the LAN will be able to MITM any connection since all of them has the very same "outside" IP.

SERVER <-- IPTABLES (only IP1 filter) <--------- LAN(IP1) (natting) <-|--- MITM Client
                                                                      |
                                                                      |--- Client 1

Here Client 1 may init a connection, and MITM client can intercept it transparently. (you have the very same problem in the other way).

The best way you have to solve this is using point to point connection with authentication (using certificates or similar).


Can a web application administrator access the database of that application?

After reading your question several times, I think I understand what you mean. You're talking about an Administrator in the sense of Joomla! or WordPress administrator. Where an admin is a concept created by the application itself, and that admin has no access to the actual server.

In applications (Joomla!, WordPress, ModX, Concrete5, DotNetNuke, etc.), the administrator is able to install components and plugins that are basically server-side code that is able to read server files and eventually have as much database access as your application itself has. So if your application can store and read the sensitive data, then the application's admin can very likely read said data.


Any issues with this security design for cloud storage? Server doesn't even need to know password to log someone in

The tricky point in all such password-based protocols is prevention of offline dictionary attacks. A dictionary attack is when the attacker tries potential passwords; it is offline if the attacker can do that at home without interacting with the genuine server or the target user. Offline dictionary attacks tend to work well, because users are human users, and thus, on average, their passwords suck big time. Slow and salted hashing (see this answer) can help to some extent, but will not ultimately fix the issue. Passwords are weak.

It is unavoidable that there is enough on the server to run an offline dictionary attack. Indeed, if the attacker gets a complete copy of the server contents, then he can emulate the server on his own machines. The running server must somehow device whether an incoming client, armed with only his password, is to be allowed destructive operations on files or not; therefore, the server must be able to distinguish between a correct and an incorrect password. An attacker emulating the server and the client can then "try passwords" and that's by definition an offline dictionary attack.

The problem, then, is to make sure that only the server has this power; that values allowing offline dictionary attacks are not needlessly distributed to the public at large. So, in your proposal, there are vulnerable areas. In particular:

The "key A and B encrypted with the password" may allow to run an offline dictionary attack. Since this blob is obtained from the server before actual login, then anybody can have it, including the attacker. The encryption format has to be quite special in order to prevent it being abused that way (a hand-waving description of it is that decryption with the wrong password must still appear to work). Usual encryption formats will be weak.
Similarly, there are stored files, encrypted with key B. An attacker with the "keys encrypted with the password" blob and an encrypted file can use that to test for potential passwords (try passwords until the file decryption yields something which "makes sense"). This implies that the encrypted files must not be shown to anybody except the rightfully authenticated user (you need user authentication for read access, but also for write access).

It would be more generic and less confusing to separate your two keys A and B: they really are distinct kinds of objects, and are used in different ways. What you really want is the following:

A password-based authentication method, in which the server does not learn the user's password but can verify it nonetheless.
A storage for files with password-based encryption. This storage will use a two-step encryption system: a symmetric key K is encrypted with the password, and all other files are encrypted with K (this speeds up password changes).

Note that the part about not learning the user's password really is: not learning that which is used to actually encrypt the files. The generic method would be the following: for a given user password P, compute f(P) with a proper password-hashing function f (say, bcrypt or PBKDF2). Extend the result with a Key Derivation Function into two keys U and V (PBKDF2 includes its own KDF; otherwise, a cheap KDF can be a simple invocation of a hash function like SHA-256 if the output size is large enough to be split into U and V). Server stores h(U) for some hash function h, and V is used to encrypt the symmetric key K.

With this system, the server learns U but this gives him no hint on V, by application of the virtues of the KDF (a KDF is, mostly, a hash function with a configurable output size). Moreover, U is still after the f() function, hence U allows for only a slow offline dictionary attack, something which the server could already have done.

This system requires that any user can obtain his salt prior to authentication. This is not a problem, since this salt is just a random value. Notice how this alternate protocol removes the need for a "special encryption system" which does not allow an offline dictionary attack.

For extra brownie points, use U as the password for TLS-SRP. This will ensure mutual authentication between client and server, based on the password, without needing any certificate at all.


How does the Windows 10 picture password work?

Identifies certain elements in the users face that appropriately matches the saved hash of the owners system. It removes the need to use passwords which users previously had to recall or write down and improves the user experience of its customers.

Windows doc explains it more. Here is a quick link:

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-face-authentication


What are the security flaws in web based TOTP app?

what possible security flaws are there beyond  having information phished, key logged, or copied in person

Does one really need more problems on top of these? Basically it is asking to enter critical information into an untrusted third-party site. Untrusted means here both that one cannot trust the third party to not have shady intents nor that one can trust the party to not being hacked and backdoored - since such site would be a very valuable attack target.
Apart from that what you describe is basically a black box similar to a software app and a hardware token, i.e. the specific implementation is not clear and thus one cannot point out specific implementation problems. Compared to existing approaches it is kept online though, which might provide a use DoS attacks to make it unavailable. If users rely on it to provide their authentication tokens this essentially means to deny authentication for the users.


How to properly create a password reset token?

Password reset tokens aren't very much like passwords. They're short-lived, single-use, and - most relevantly here - machine generated and non-memorable.

You absolutely must use a cryptographically secure random number generator to produce the token. crypto.randomBytes is good enough, yes. Make sure the token is long enough; something on the order of 16 bytes (128 bits) should work.
Because the "preimage" (the value fed into the hash function, in this case the token) is random, there's no need to use a slow hash. Slow hashes are for brute-force protection, because passwords suck and usually don't take long (in machine terms) to guess; 128-bit random values are not brute-forceable for any practical meaning of the term. Just do a single round of SHA-256 or similar.
Bad idea; it just complicates things. Store all that stuff in the DB instead. Yes, you could do it statelessly by putting it in a JWT, but the DB makes much more sense:

You'll need to interact with the DB anyhow, to reset the password.
You'll need to bypass any caching anyhow; even if you have a distributed system they'll all need to see this change so there's no point making it stateless.
You only need to do one DB read to verify the token (both that its value is correct and that it hasn't expired yet, which can be done in a single query), which is a relatively rare event; it's not like needing to do a session token lookup on every request.
JWTs have expiry but there's no convenient way to make them single-use (you have to store state saying "these JWTs are no longer valid" on the server until each one expires, which kind of misses the point of JWTs.) Password reset tokens stored in the DB can (and should) be made single-use by deleting them upon verification.
You can have a cleanup task that goes through and periodically removes expired tokens (that were never used), if you want. They don't take up that much space in the DB, though (a hash digest and a timestamp on each user, if you only want one per user valid at a time, or a hash digest, a timestamp, and a foreign key into the Users table if you want to allow multiple tokens to be valid at once for a user; both have advantages and disadvantages).
JWTs have more potential vulnerabilities (somebody steals your signing key, somebody discovers that the key was generated insecurely and hasn't been rotated since the bug was fixed, your JWT library is vulnerable to key or algorithm confusion, etc.) compared to just checking the DB (which is vulnerable to basically nothing except SQLi, I guess, which hopefully you know how to avoid).

Your basic process makes sense.


How secure is GSSAPI single-signon over SSH?

This is really broad question and not exact. There are two ways how to use GSSAPI for SSH logins:

GSSAPI Key Exchange - not implemented in openssh, but distributed as a patch (part of RHEL, Fedora, but probably also Debians)
GSSAPIAuthentication - part of openssh

GSSAPI Key Exchange

The plus is certainly the manageability - with GSSAPI key exchange you don't have to even care about host keys. Just register the host to domain.

For key exchange, there are used basically these methods. The first is considered possibly vulnerable, because they use 1024 b primes. They are based on respective DH key exchange methods.

gss-group1-sha1-*
gss-group14-sha1-*
gss-gex-sha1-*

GSSAPI AUthentication

About the GSSAPI Authentication, you use normal SSH key excahnge methods (ECDH preferably), which has to be managed somehow else (certificates?) to mitigate MitM. Then authenticate to remote host using kerberos. This communication is already encrypted so there is no different security question than authenticating to any other service.


Chrome doesn't see SSL certificate for main domain while sees for www

I would suggest an easy alternative to test it out by just redirecting all the traffic for non-www urls to the equivalent www urls using the server configuration.

Here is an example for the nginx server.

https://serverfault.com/questions/624848/redirect-non-www-to-www-over-ssl-with-nginx

or have a look at this solution

https://serverfault.com/questions/738883/ssl-certificate-non-www-not-working

Hope it helps


It is impossible to make a network where it is not possible to tell you are communicating.  You can build a network that will hide what you are communicating or even make it look like you are communicating something else.  You can make it impossible to tell who the end user of your communication is if you have enough participants, but you can't make it so it can't be noticed that you are using that network.

Any form of communication involves sending messages and those messages can be observed by not only the recipient but the attacker.  The best you can do is make it look innocuous or unintelligible.


Designing a cryptographic file-sharing protocol

Making your own crypto is fine as long as you understand that it is for learning, not for using.

There are several "layers" in cryptography. There are algorithms, like RSA, AES, SHA-256... Then there are protocols, which assemble algorithms together. And then, there are implementations, which turn protocols into executable code. For a first grasp of cryptography, I usually recommend to go to implementation first: get an existing protocol, and implement it. This has some nice benefits, including the possibility to test your implementation against others, which is great in tracking bugs. This will also give you some insights on how protocols are structured, e.g. to support streamed operation.

Since you are concentrating on the sending of a file as a single message, the model appears to be close to what OpenPGP purports to solve; therefore, making a working implementation of OpenPGP in C# is what I recommend.

If you still choose to make your own protocol right away, then the following can be said about your choices:

Your key sizes are overkill. 256-bit AES keys are quite useless in practice, since 128-bit keys are already quite far beyond that which is breakable with existing technology (e.g. see this answer). Similarly, 4096-bit RSA keys are oversized; 2048 bits are already more than enough to ensure security. Since larger keys imply reduced performance, oversized keys imply unrealistic slowness which will not be representative of what can be achieved, thus lowering the pedagogical value of the whole endeavour.
Conversely, 1000 rounds of PBKDF2 could be considered as too small. For a password-to-key conversion, the iterations are there for a "muscle show", to cope with the inherent weakness of the password (that is, the inherent weakness of the meat bag who will have to remember it), so you want that iteration count to be as high as is tolerable, thus relating to the power of your computer and your patience. A typical count value, with today's computer, would be around 100000 or even some millions.
You use a MAC for the encryption of the file, but not for the encryption of your private key. This looks strange. There are situations where a MAC is not necessary, but most contexts where encryption is warranted also call for a MAC. It would be simpler to use the same format for both encryptions.
You apply the MAC on the encrypted file: that's encrypt-then-MAC, and that's good -- and you did think of making the encryption IV part of the MAC input, which is even better (that's a classic mistake which you neatly avoided). You might want, though, to make some allowance for some future algorithm agility: maybe, at some point, you will want to use another symmetric encryption algorithm. In that case, some symbolic identifier for the encryption algorithm should also be part of the MAC input; this can be as simple as a first byte of value 0x00, leaving you some root for 255 other future algorithms.
You use HMAC with SHA-512, which is not bad, but SHA-256 is not bad either and will offer substantially better performance on 32-bit systems. There again, race to the largest outputs and key sizes is artificial and sterile. SHA-256 is more than "secure enough".
CBC mode and a separate MAC are "old style". There are modern encryption modes which combine the encryption and the MAC within a single primitive, reducing the possible scope of implementation errors; in particular, EAX and GCM. I understand that .NET does not offer them (yet); CipherMode is limited to CBC, CFB, CTS, ECB and OFB. In that case, CBC is not the worst choice, with an extra MAC (i.e. HMAC, as you suggest). To use CBC properly, an unpredictable random IV is necessary, and that's what you suggest (good).
Be extra wary when implementing the decryption. You should first verify the MAC, and then, only if the MAC verification succeeded, may you proceed with the decryption. The tricky point is in the padding handling: an attacker could try to extract secrets from the recipient, by sending altered files and see how the recipient reacts, e.g. when the recipient found a syntactically valid padding or not. This is the basis of padding oracle attacks. You can process the incoming data in blocks, computing both the MAC and the putative decryption in parallel, but take care, for the last block, to compute and check the MAC first (this is the kind of hurdle that is avoided with GCM or EAX).
Encrypting the key for AES and the key for HMAC is weird; it would allow a creative attacker to swap them around, making the recipient use the HMAC key for decryption, and vice versa. Although the benefits would not be obvious, it is very hard to tell whether a vulnerability exists that way; it depends on how "different" AES is from HMAC, a property which is not well-defined and, in any case, has not been thoroughly investigated.

It seems safer, and also more performant, to use a single "master key" K, encrypted with the recipient's public key, and to derive the AES key and the HMAC key from it with some Key Derivation Function. It can be as simple as making K a 256-bit key (generated randomly) and splitting it in two halves, one for AES and the other for HMAC. Or you could make K longer (or even shorter), hash it with SHA-256, use split the SHA-256 output into two halves. The point is that a single RSA encryption is needed, not two. Also, deriving the encryption and MAC keys from a single source will map better to a possible future use of GCM or EAX.
Your file format does not allow for streamed processing. In your format, the MAC is computed over the complete encrypted file, but its value comes first, before the encryption result. This means that the sender will have to process the whole file before beginning the sending. Thus, for a 1 GB file, 1 GB of temporary disk space (or RAM) will be necessary. This could be avoided if the MAC value was appended at the end, rather than stored in a prefix.

Note that this buffering issue necessarily exists for the recipient, who must verify the MAC before using the decrypted data in any way. To fully cope with that, you would have to make a more complex format, with moderate-sized chunks, each with its own encryption and MAC, and some glue for secure assembly. The model would be SSL/TLS here.
There is no authentication ! The recipient has no way of knowing whether the file he received indeed came from the alleged sender. To add authentication, in your setup, you will need digital signatures. Note that a digital signature may replace a MAC, if applied adequately, which is not an easily guaranteed property. It is safer to simply compute a signature (with the sender's private key) over the complete structure.
There is no protection against replay attacks. An attacker, observing a file in transit, could send the same file again at a later date. It is then up to the recipient to take measures to detect such duplicates. This can be as simple as a date somewhere within the data file, under the protection of the MAC (and possibly the encryption, although this is not necessary), but it must be given some thought.
By encrypting the private key yourself, I understand that you do not let the operating system take care of it. This could be limitative. Indeed, a RSACryptoServiceProvider instance could, potentially, use a key which physically resides in a smart card; and even for software keys, there can be some security benefits with letting the OS take care of the storage (the OS has privileged access to the hardware, and can, for instance, avoid leaking secret keys to the disk through virtual memory). By using an explicit key file, you make your system incompatible with such potentialities, which is a shame.
There is no room for metadata, in particular a content type. The same sequence of bytes can have several interpretations, and there can be amusing consequences if the recipient can be induced into opening a HTML file as PDF or vice versa. Ideally, that which you actually encrypt should be a structure with a header containing a designation of the type of data (e.g. a media type) followed by the data itself.

All of this is said in no particular order and without claiming exhaustivity. The synthetic conclusion is that protocol design is not simple; it helps to have some solid implementation experience on which to base the design.


You will not achieve anything. Consider two users with the same password, salt, among others, is designed to achieve different hashes for the very same password.

In example:

User A pass: foo, salt: abcd = hash ( abcd + foo ) = 23424098FAD
User B pass: foo, salt dkes  = hash ( dkes + foo ) = 8734536EA43

But with your algorithm you will end up with the very same hash:

User A pass: foo = hash ( hash(foo) + foo ) = 123AB2344
User B pass: foo = hash ( hash(foo) + foo ) = 123AB2344

Also, don't roll your own.


As dave_thompson_085 suggested, the sequence at the beginning of the encrypted application data is the explicit nonce used by the GCM (Galois Counter Mode). Apparently, this is some kind of initialisation vector shared with the peer. Note that there might be an implicit part of the nonce which is not sent over wire.

The Transport Layer Security (TLS) Protocol (RFC5246), 6.2.3.3. AEAD Ciphers:

  For AEAD [...] ciphers (such as [CCM] or [GCM]), the AEAD function
  converts TLSCompressed.fragment structures to and from AEAD
  TLSCiphertext.fragment structures.

  struct {
     opaque nonce_explicit[SecurityParameters.record_iv_length];
     aead-ciphered struct {
         opaque content[TLSCompressed.length];
     };
  } GenericAEADCipher;

You can clearly see here, that the Ciphertext is preceded by nonce_explicit.

After some testing, i noticed that these bytes seems to involve a counter that increments with each sent message. Now I asked myself what sort of information is sent there?

RFC5246, 6.2.3.3.  AEAD Ciphers:

  Each AEAD
   cipher suite MUST specify how the nonce supplied to the    AEAD
   operation is constructed, and what is the length of the    GenericAEADCipher.nonce_explicit part

This means that I have to find the RFC where the AES with GCM is specified for TLS. Again, dave_thompson_085 also led me to this answer.

AES Galois Counter Mode (GCM) Cipher Suites for TLS (RFC5288), 3. AES-GCM Cipher Suites:

  Each value of the nonce_explicit MUST be distinct for each distinct
  invocation of the GCM encrypt function for any fixed key.  Failure to
  meet this uniqueness requirement can significantly degrade security.
  The nonce_explicit MAY be the 64-bit sequence number.

So these bytes are the explicit part of the nonce as specified in TLS. The implemtation (mbedTLS) used the sequence number for it. Thanks again to dave_thompson_085!


if the hypervisor is hacked are all guests affected as well?

Simple answer is yes. If an attacker controls the hypervisor they can potentially get access to everything within it, including the memory space of a VM (which could include keys)

Worst case is to assume all may be lost if the hypervisor is compromised, so in order to prevent this, a well structured, layered security architecture may make it incredibly difficult for an attacker to exploit the vulnerability.

One of the reasons we always encourage defence in depth!


Can I connect to a network without being detected?

You could sniff the network for traffic and change your network configuration to an active machine(i.e. MAC address):

# ifconfig wlan0 down
# ifconfig wlan0 hw ether DE:AD:66:55:12:34  <== sniffed MAC
# ifconfig wlan0 up

assuming wlan0 is your wireless network interface. On Windows you can do something like this.

Now there should be two work stations with the same network configuration, so it's difficult to tell who is who since whoisonmywifi can't tell the difference. You can always clone the access point(the router itself) so that your traffic becomes more difficult to block(at least to non tech savvy people).
Note that the network may be less stable due to the conflicting packets arriving to both connected machines(yours network session is (most likely) different than the one on the machine you are impersonating).

In order to sniff traffic you can use wireshark and set it to your wireless network interface(i.e. wlan0).


Benefits and drawbacks of giving an Administrator two accounts for elevated rights and another for daily use, such as email

Surfing the internet is a risk to an organisation - usually this is mitigated to some extent by having limited functionality for users, so an exploit is limited in what it can do. When an administrator is doing the surfing his account is not limited, so an exploit can have major consequences.

  If an Administrator knows they may be visiting a hostile website,
  they are probably smart enough they should be testing this on an
  isolated network/machine

Sadly this isn't true - admins are people too

  Administrators usually aren't tricked into running scripts, or hostile
  code (ActiveX) that other users may be

There are attacks already out there that require no interaction other than browsing to a website, and as I said, admins are people too (mostly)

  Suppose a person's daily job is administration, and deals primarily
  with troubleshooting using their privileged credentials. It seems
  self-defeating and unproductive to ask them to "RunAs" for every new
  task.

For this, you could argue the case for separating by machine, rather than by account - ie all the admin tasks are carried out on an admin machine which can't connect to the internet etc., and the user type tasks are carried out on another one which can.

  Taking the last idea a step further, perhaps it would be better to
  RunAs for non-administrative tasks, such as email, file and print
  services, etc. Does it make sense for an Administrator to use his privileged credentials for signing into his PC, and using RunAs for non-administrative tasks?

RunAs downwards is just susceptible to the admin forgetting, or just wanting to do something quickly and easily.


Scan for Vulnerabilities Without Network Connection

In addition to the existing response:
You can mount indirect attacks where you use another device which has access to both the (external) attacker and to the internal target device. A common available device is  a normal computer where the user surfs the internet with a web browser. Since the web browser has access to both the internal and external network it can be used as a trampoline for the attacker. To just give some examples of possible attacks which could be delivered for example within a displayed advertisement:

Scan the internal network, i.e. find out which hosts exists and even which ports might be open. Sending HTTP requests to internal hosts can be done for example with embedding images like <img src=//internal-host:1234/> and with some Javascript it can be determined if the request timed out (host does not exist or packets gets dropped) or not (host exists). With some more logic one can even find out some browser controlled devices available on the network by trying to access device specific URL's.
Using CSRF or similar attacks it might even be possible to take over these systems then, i.e. change the DNS settings of routers so that the attacker can MITM any outgoing traffic from the network or even modify the firmware of printers. None if these attacks needs that the devices can be accessed from outside. These are not only theoretical attacks but are actually done at a large scale.


How can I securely delete items in a database?

There are two ways to answer this. The first way follows your line of thinking, the other does not.

While it's hard to be sure for any specific database, due to slack space (i.e. not shrinking the data file when stuff is deleted), journaling, and other database features, I'd suspect that the following is reasonably sufficient for a system like InnoDB:

Do an UPDATE on the rows to replace all data with blank data of the same length. So, if you've got Polynomial in a cell, you replace it with AAAAAAAAAA.
Delete the rows as normal.
Add a bunch of new rows with large-ish blobs of dummy data.
Delete those rows.
Take down the database and run a shrink / compact / re-index operation.

This isn't guaranteed to do the job, because database implementations have all sorts of weird behaviour, but for most cases it'll at least make it more difficult to recover the data. In fact, in a high usage environment I'd suspect that emptied out row slackspace gets overwritten pretty fast.

But here's the more complete answer - your threat model in this case appears to be that someone has captured the database file. So why not encrypt it? Full-disk encryption is computationally cheap (and LUKS is easy to set up) and would help prevent someone from getting at the database file from a stolen disk.


MSTG-PLATFORM-11: Prevent custom third-party keyboards on Android?

So this is an L2 requirement that only is relevant if your threatmodel asks for it (See MASVS introduction) (when eavesdropping at keystrokes or forwarding the information you enter would cause a real problem for instance).
In its current form/shape it seems only applicable to iOS.
It could be passed on android as well by just creating your own keypad for a pin for instance (Which was the original V9.1 requirement in an older version of the MASVS).
In that case you should be able to resolve accessibility issues as well by means of a proper custom keypad with assistance implemented into it.


How to protect network equipment in public spaces?

I haven't found an International (or National) Standard that goes into detail on protecting remote physical assets; the closest I have found is in ISO 27001 - Annex A.11: Physical & Environmental Security. According to Wikipedia, ISO 27001 itself is a much wider-ranging standard on the whole subject of "information security":

  ISO/IEC 27001 specifies a management system that is intended to bring information security under management control and gives specific requirements. Organizations that meet the requirements may be certified by an accredited certification body following successful completion of an audit.

However, from the first link, Annex A.11 of the standard is more specific, and comes in two parts:

  Annex A.11.1 is about ensuring secure physical and environmental areas. The objective in this Annex A control is to prevent unauthorised physical access, damage and interference to the organisation’s information and information processing facilities.

  Annex A.11.2 is about Equipment. The objective in this Annex A control is to prevent loss, damage, theft or compromise of assets and interruption to the organisation’s operations.

A lot of the annex is to do with "on site" assets, but Annex A.11.2 does include:

  A.11.2.6 Security of Equipment & Assets Off-Premises

  Security controls need to be applied to off-site assets, taking into account the different risks involved with working outside the organisation’s premises. This is a common area of vulnerability and it is therefore important that the appropriate level of controls is implemented and tie into other mobile controls and policies for homeworkers etc. Considerations should be made and risk assessments carried out for assets that are taken off site, either routinely or by exception. Controls will likely include a mixture of; Technical controls such as access control policies, password management, encryption; Physical controls such as Kensington Locks might also be considered too; alongside policy and process controls such as instruction to never leave assets unattended in public view (e.g. locking in the boot of the car). It is particularly important to review security incident trends relating to off-site assets. The auditor will expect to see evidence of this risk assessment taking place and the proportionate controls selected according to the evaluated risk levels. They will also expect to see evidence of policy compliance.

Some other resources that may help:

Physical security on Wikipedia includes in it's overview three "layers":

  deter potential intruders (e.g. warning signs and perimeter markings);
  detect intrusions and monitor/record intruders (e.g. intruder alarms and CCTV systems); and
  trigger appropriate incident responses (e.g. by security guards and police).

The UK's Centre for the Protection of National Infrastructure has pages on Physical Security and Protecting my Asset that both cover the multi-layered approach, including from the second link:

  Deter: stop or displace the attack
  Detect: verify an attack, initiate the response
  Delay: prevent the attack from reaching the asset (including measures to minimise the consequences of an attack)
  Mitigate: minimise the consequences of an attack against your site
  Response: actions to prevent the goal of the attack being completed

The US Government's Physical Security Systems Assessment Guide (PDF), while appearing to be mainly aimed at larger (and often manned) facilities, covers similar ground and many aspects will apply to the protection of remote equipment.


' OR 1=1/* SQL Injection Login Bypass Question

There are a few considerations here, first is to explain how this is supposed to work:

SQL injections are a very old kind of hack that should not affect modern SQL implementations.  Back before you could use prepared statements, SQL queries were normally made using concatenated strings.  This meant that whatever your input was would become part of the executed sql like this:

$login = "John";
$password = "' OR 1=1 --";
$myIP = '555.555.555.555';
$sql = "SELECT * FROM users WHERE login='" . $login . "' AND password='" . $password . "' AND userip = '" . $myIP . "'";
echo $sql;

  OUTPUT: SELECT * FROM users WHERE login='John' AND password='' OR 1=1 -- AND userip = '555.555.555.555'

That first ' will close the string quote to keep the syntax valid.  Then, because 1 always equals 1, you create a select statement that is always true.  That means that you will select the user "John" allowing you to log in as him with no knowledge of his password.  Then -- is the SQL syntax to remark anything that comes after it.  This is used to eliminate any other conditions that might prevent your successful login such as IP validation or something of that nature.

The second thing here is the /*.  This will actually break a 1=1 injection because that is invalid transact SQL syntax.   That said, /* can be used in an execution level attack.  Many developers put too much trust in prepared statements. Just because it does not execute input at the SQL transaction does not mean it can't contain stuff that can be executed later.

For example, if you have an input box on a website, and you want to test to see if the site is vulnerable to JS-XSS attacks, you could input "<script> /*".  This means that when your program goes to take this from your database and run it, you'll execute a JavaScript that remarks the remainder of your page, then it will kill your program when you try to load the output of that information.

In short your source is mixing up remarking syntax for 2 different kinds of attacks, but they are both legitimate concerns given the right vulnerabilities.


What are the security implications if systemd is not restarted after it has been updated?

It's still running the old binary, having all its vulnerabilities. You can restart Systemd without reboot using the Manager Lifecycle Commands: systemctl daemon-reexec should be enough after a package upgrade.

The details depends entirely on the vulnerabilities found in the specific version and is information that will become obsolete too quickly to be meaningful on a Q/A site. You should check

the release notes (for Ubuntu, Debian e.g. stable systemd_232-25+deb9u8) and
Common Vulnerabilities and Exposures (CVE). Last vulnerabilities were memory corruptions (CVE-2018-16864, CVE-2018-16865) and an information leak (CVE-2018-16866). (You could also notice that there's CVE-2018-16888 that hasn't currently been fixed in Debian stable.)

If you aren't able to evaluate whether these vulnerabilities have security implications in your situation, just upgrade your packages regularly and restart the services.


How a website knows if a video has been watched or downloaded?

It could be done in several ways. For example, the page where you are supposed to watch the video could have some JavaScript code that monitors the users' interactions with the platform (page, player, etc.). So, for example, if you watch a 1-hour video on their platform, your browser is going to download the whole video of course, but at the same time the JavaScript will send data that shows you have been visiting the page for about 1 hour. It could be something like this, for example:

// Every 120 seconds, send data about what you are doing
setInterval(send_browsing_data(video_id, user_id, video_time),120000);

If the website notices that somebody downloaded the whole video but at the same time they received no data to justify that from the browser, they might suspect that something is wrong.

I personally wouldn't worry about it at all, though. Go ahead and download it, if you have a good reason to do so.


Is there any way to safely examine the contents of an SD card?

Define "safely".

The core SD data protocol can only expose itself as a mass storage device, which prevents a lot of the fun badUSB style attacks. If your host supports SDIO, the attack surface grows massively.

The card also contains a full MCU, typically ARM/8051, which can (at minimum) lie to you about the contents of flash a la IRATEMONK. See https://www.bunniestudios.com/blog/?p=3554. Formatting the card is thus NOT sufficient to "clean" it. Given the price of SD cards, if you're at all concerned about its provenance it's better to just chuck it and buy a new one from a trusted source.

TL;DR probability of RCE is lower than with USB, but there are definitely still nasty things possible.


You could take OWASP ASVS as a baseline. It provides quite comprehensive coverage of software checks broken down into next categories:

Architecture
Authentication
Session Management
Access Control
Input validation and output encoding
Cryptography
Error Handling
Data Protection
Communications
Malicious Code
Business Logic Flaws
Files and Resources
Mobile
API
Configuration
Internet of Things

As you can see the field could be quite wide, so I'd recommend to build a threat model of reviewed application to prioritise your approach - basically, to review most critical parts first.

Going further, you can implement language-specific checks like those provided by CMU.


Is ZRTP for secure multi user group video conferencing?

ZRTP is only used for end-to-end encryption... https://en.wikipedia.org/wiki/ZRTP

Since you can't make groups with end-to-end, there are other protocols that would support that https://de.wikipedia.org/wiki/SILC (as an example). Afaik - there are just text-chat implementations of this protocol.


How do we secure image parsing libraries against buffer overflow?

There are a couple of obvious things which are not limited to image parsing libraries:

Don't assume that the input is well-formed but actually check it. It is actually a common problem with image or video libraries that they were not designed with deliberately malformed input in mind but which are nevertheless used to process input from dubious origins.
Use a safe programming language which by design is not affected by buffer overflows or makes it at least very unlikely. This means use a language which does not allow to write out of array boundaries and which does not allow to double free memory or similar memory management problems. Most higher level languages don't have this kind of problems though they might affect the performance more than you like. But there are also lower level languages like Rust which provide both memory safety and high performance at the same time.
Limit impact of programming errors by using compiler-specific or system-wide mechanisms which protect the stack (canaries), prevent code execution from the stack, provide some kind of sandbox around the application etc.


How to make sure that a password manager is not malicious?

Without certification by an independent body or access to the source control and a real understanding of what you are looking for you can't be absolutely sure that it isn't malicious.

What you can do is to use well established, known password managers like Keepass and keep them updated to patch any vulnerabilities, so you should not disable updates. You could create a rule to ban the application connecting to the internet via something like Windows Firewall or Zonelarm.  Though with so many security researchers, if these well respected products were phoning home, we'd know about it by now.

There's always a small risk a  malicious insider may sneak something untoward in, or a backdoor to serve the government maybe,  it's hard to be sure. It's about balancing the likelihood and risk against the benefits you gain.


Is it possible to lock down the http / https proxy settings on an Android phone?

Mobile Device Management (MDM) solutions exist that allow you to control and lock down settings on the device, as well as manage devices from a central location.


Is using trusted CA to issue certificate for a VPN server insecure?

If the certificate authority gets hacked (unlikely, but it has happened several times), they can generate another certificate, and trick your client into thinking their VPN server is your VPN server, and watch all your VPN traffic. That's because if you use a CA, your VPN client will accept any certificate signed by a CA that says it's the right server, not just the certificate you generated.

If it's a self-signed certificate, then they can't do that.


I think it is a poorly written robot. [% tools.ua.random() %] looks like a template that should pick a random user agent. But it does not substitute the value (the UA).
It must be a bad bot hiding behind various user agents.

To mitigate some attack against WordPress please take a look at my plugin:
https://github.com/szepeviktor/wordpress-plugin-construction/tree/master/wordpress-fail2ban
The plugin analyses the HTTP request line-by-line.

Use the "must use" (mu-plugin) version, that is the up-to-date one. I hope you understand commented PHP code. I would gladly help you to set this up. It even works without the fail2ban daemon (running on a Linux server) but it is designed to immediately block bads bot through fail2ban.


In your particular example, StackExchange uses OpenID.  OpenID supports the idea of identity providers -- Yahoo is an Identity Provider, same as Google, MyOpenID, etc.  To log in StackExchange asks you which provider you want to use, and then redirects you to that providers login page.

Once you authenticate against the provider, the provider redirects you back to StackExchange with a token.  This token contains your identity information.  This is generally called Claims Based Authentication, where a Claim is a piece of information about an identity, e.g. your name, and claims are bundled into a token.

Communication is done through HTTP 302 redirects and HTTP POST's all via the user's browser.  Yahoo knows its StackExchange because the Yahoo URL contains a parameter saying it's StackExchange.  StackExchange knows the identity token is from Yahoo because it is signed by Yahoo.

See here: http://openid.net/get-an-openid/what-is-openid/

And here: http://openidexplained.com/


Yes - both are current.

Real time biometric analysis on keyboard input has been looked into by a few teams now. The guys at Pace University seem to have a strong presence in this area. Have a read of :

Continual Keystroke Biometric Authentication on Short Bursts of Keyboard Input
Keystroke Biometric Identification and Authentication on Long-Text Input

The first one is probably more what you are after:

  Short bursts of
  keyboard input  are analyzed to continually authenticate computer
  users and verify that they are the authorized  ones

As far as video goes, all the facial recognition programs used in identifying users in public places work off video streams, either using single frames, or collating multiple frames to improve quality - this is used all over the world.


What happens to a pass vault when the GPG key expires?

Yes*, you would still be able to get in. Expiring a key tells people not to use it anymore, but anything already encrypted with the public key can still be decrypted with the private key.

A GPG key's expiration can also be extended at any time unless it's been revoked.

*The software may prevent using expired or revoked keys, but if so this limitation isn't necessary and could be removed.


Preventing artificial latency or "Lag Hacking" in multiplayer games

I see two conceptual paths for dealing with lag attacks:

Punish lags. When an "artificial" lag is detected, evict the offender and enforce a ban period. This is hard to do in practice because there is a delicate balance to be found between people who cheat through lagging, and people who simply suffer from an occasional hiccup in their Internet connection. It is bad business practice to smite your own customers. Such kinds of solutions will necessarily end up with a threshold to distinguish between bad people and unlucky people. Cheaters will stick close to the threshold and this will probably be sufficient to gain some strategic advantage.

One promising approach along the punishment line is to apply small but cumulative penalties for each lag: whenever a packet is lost or shows up late, remove one hit point, make the player flash, whatever... this can even be integrated in the game universe (for instance, for a FPS convert the detected lag into a rifle jam). This implies that people with reliable Internet connections and big computers will be at an advantage -- and I believe that players are ready to accept that, on the basis that similar things happen in a lot of other leisure-competition situations (e.g. if your hobby is skateboarding, you know that a better skateboard will not replace talent, but will help nonetheless, and skateboarder accept that as a fact of life). Ultimately, this might incite ISP to work a bit on their latency, which would be good for everybody, not just gamers.
Don't trust clients. Massively online games are distributed computing. Most of their security issues are due to the fact that many game rules, i.e. the properties of the world in which the players act, are maintained by the client systems. The players themselves, and in particular the potential cheaters, have extensive control of their machines. Existing countermeasures tend to have limited effectiveness for the same reasons that software DRM and antivirus may fail: this is an arms race in which attackers and defenders are locked into a fast-paced battle of patches and counterpatches which is tiresome and requires expensive, continued maintenance.

The generic architectural response is to maintain the game rules server-side only; clients become "thin" and are just display interfaces. This is unfortunately hard to implement, because display performance (hence game experience) becomes very sensitive to latency, artificial and natural alike; and ADSL links will have a minimal latency close to 50 ms, which is high with regards to average gamer reflexes. Also, this means that the game servers need more CPU muscle. But the security advantage is huge: when a player induces lagging, he inherently punishes himself and none other.

Maintaining all game state and rules on the servers is not completely science-fiction either. Back in the late 1980s, one of the very first MMO games was "CarCrash", an offspring of the defunct French magazine Jeux et Stratégie; it was played over the Minitel, another old French technology where users simply had text terminals (with limited graphics) with no local computing abilities; the central server(s) maintained the game rules and computed the screen updates for everybody, and it worked. Computers at that time had far less CPU muscle than today; a 20 MHz CPU was enough to be deemed a "supercomputer". A 35$ home router of 2013 is more than ten times as powerful as a big server of that era. And yet it worked.

Maintaining game rules on the server implies departing from the way games are usually architectured. Historically, most games were local and became multiplayer by connecting clients with each other, with possibly a central server which only served as rendez-vous point. To take a political metaphor, games became multiplayer by forming confederations, but security against cheaters requires a federation.

Mixed strategies are possible, of course. The core idea is the same: give as few  sensitive data as possible to client systems; and when you must trust them for something, use a big stick or a big carrot to maintain them in line.

(If you understand that players should be handled like cattle herds, well,... there is truth in that, indeed. You don't want your cows to be unhappy, but you will not let them choose their walking direction and pace either.)

Edit: just got an insight while waiting for my tea to cool a bit. A game architecture could include several (possibly dozens) of cooperating "trusted" servers spread worldwide, which "play the game" like game clients do today. Each gamer would connect to one server which is "close by" (in a network sense) so as to have a low latency, allowing for the display-only strategy outlined above. If ISP themselves can be involved in the deal (each ISP would host a few servers in its own infrastructure) then this could make sense in a business way.


How can a user defeat anti-live forensics software?

There are many ways to compromise a running computer if you have physical access. How likely it is that you will be able to obtain the level of access you need depends on several factors, including your resources, the level of skill of the defender, and the amount of time you have available. You haven't provided much information about your target, so this answer will be fairly general but will assume they are fairly sophisticated and have a good understanding of the x86 architecture and hardware security. Specifically, it would be helpful if you provided more information on the following:

Is the target using COTS (Commercial Off-The-Shelf) hardware, or is it custom?
Are there physical security measures in place, like chassis intrusion detection?
What is your budget? Can you pay for custom attack hardware?
Are you willing to sign an NDA with Intel to use their JTAG SDK?
Is the memory acquisition done on-scene, or in a dedicated laboratory?
Do you prefer higher risk of detection, or higher risk of data corruption?

All of these points, especially the ones about the target's particular choice of hardware, can help narrow down exactly what the optimal strategy is. Otherwise the answer will be broad. The worst-case scenario is that the target has a deep understanding of the x86 architecture and has developed a sophisticated solution similar to vCage, reducing the TCB to that of the CPU itself and mitigating virtually all physical attacks. This would require novel acquisition methods to be created.

Below are some general classes of memory acquisition attacks against x86 hardware.
IEEE 1149.1
The "best" course of action would be to use the IEEE 1149.1 protocol, aka JTAG. This is a debugging protocol which puts a processor into probe mode. From there it can be halted, registers can be read or modified (including the instruction pointer), addresses in memory can be read or modified, etc. There is generally no defense from a JTAG attack short of destruction of the physical JTAG header (XDP) on the motherboard. A JTAG attack for Intel motherboards requires an expensive probe. Newer systems support DCI, which allows JTAG debugging to be performed over USB. Many BIOSes will disable DCI support, requiring a fallback to the expensive alternative.
Bus mastering
PCIe devices natively support hotplugging and have in their configuration space a two-byte command register. Bit 2 is bus master enable which, when set, allows the device to perform DMA requests to read and write to generally arbitrary locations in memory. While the PCIe device cannot set this bit on its own, all it has to do is convince the operating system that it requires a driver which does grant it DMA abilities. At that point you can read or write to arbitrary locations in memory. Note that some systems will use DMA Remapping, or DMAR, which can restrict the locations of memory you can access (though this might not be enough to mitigate such attacks, and some older systems have a broken IOMMU). If this is the case, or if you expect the system is further hardened to detect the insertion of new DMA-capable devices, then it may not be fruitful to attempt to use a PCIe device for DMA. DMA is among the most commonly used for memory acquisition.
Cold boot attacks
There are two types of cold boot attacks. You can either reboot the system into another bootloader which then reads memory, or you can physically remove (and optionally freeze) the memory modules and transfer them to a system under your control. This cannot generally be detected unless you attempt to freeze the memory while it is still under control of the target computer, but it risks large amounts of data loss if done improperly. Modern memory (DDR3 and DDR4) also uses a feature called memory scrambling to reduce excessive electrical interference. The scrambling seed is very weak as it uses an LFSR, but it still requires at least basic cryptanalysis to break. There is an additional benefit to the cold boot attack, though, which is that the memory acquisition is atomic, leaving no memory smear. I wrote more about this in another answer.
Attacking TRESOR
TRESOR is a kernel patch for Linux which does encryption entirely outside of memory, mitigating cold boot attacks and passive DMA. The keys are kept only in the CPU's x86 debug registers, and key material never enters memory (except during an NMI or SMI). Defeating TRESOR requires the ability to write to memory. The most effective way to do this is to modify the IDT, triggering the execution of custom code in supervisor mode at the next interrupt. This code can be used to read the debug registers. This attack is described in more detail in another paper. Your target may not use this particular mitigation, or they may have developed their own using any number of innovative techniques. You should know as much as possible about your target before interacting with their machine.

Let's assume five different skill levels of the defender in order to approximate what attack vector would be ideal. These will be simplifications and the proper course of action should be to learn more about the target before attempting any risky procedures.

No skills at all. The target knows effectively nothing about hardware security. They may run antivirus software and lock their computer when they leave, but that's about it. Any of the above techniques are liable to work. The average person may fit into this category.

Low skill-level. The target has a very limited understanding of hardware security. They are capable of finding and running pre-written defensive software. They are using unmodified consumer hardware and likely do not check if DMAR is enabled. In this case, a DMA attack would easily be the most effective. Plugging in a PCIe device could make it possible to read memory. A security-conscious power user may fall into this category.

Moderate skill-level. The target has a good understanding of hardware security. Their computer may have some basic modifications made to it, such as epoxy resin blocking sensitive ports. They may be able to write basic defensive software for a variety of attacks. DMAR is likely supported and correctly enforced, making DMA attacks impractical. The system may or may not react defensively when a new PCIe device is attached. In this case, a JTAG attack would be most effective. If TRESOR is not in use, a cold boot attack may do. A particularly clever amateur security researcher may fall into this category.

High skill-level. The target has a deep understanding of hardware security and may have access to unreleased or confidential documents from their hardware manufacturer. Their system is either heavily modified, or completely customized. Intrusion detection may include cameras inside or near the chassis. Individual sensitive chips, traces, and buses may be encased in anti-tamper epoxy. JTAG headers could be physically destroyed or wired to alert the system to an attack. Attacking a system operated in this way requires in-depth knowledge of the target, a fair amount of custom hardware, and novel attacks. An employee for a large security contractor for a government working on sensitive data may fall into this category.

Nation-state skill-level. The target has resources on par with a nation-state. The chipset itself is likely designed in-house and manufactured in a secure, on-site fab by a contractor. Every component is part of this target's own supply chain. Custom defense mechanisms are likely enforced, all the way down to the microscopic level (e.g. sophisticated chip-off protection mechanisms). Physical destruction (and black bagging) may occur if tampering is detected. The device is completely shielded from RFI/EMI leakage. Cryptographic modules may be certified with at minimum FIPS 140-2 level 4, and software running on the machine is likely to be at least partially formally verified and tested up to EAL7+. A highly-sensitive and well-funded branch of an FVEY or SSEUR member may fall into this category.


The mime type isn't built in to the file in any way. One could even say that files don't have mime types. Sure, whoever created the file may have intended it to be of a certain type, but on disk it is still just a strings of ones and zeros.

The place where you encounter mime types in the context of file upload is in the HTTP headers, both when the file is uploaded to you and when the file is then downloaded from you by your users. Note that an attacker could try to send any file with any mime type, correct or incorrect.

Unless your server software doesn't explicitly store the mime type the client provided that information will be gone the second the HTTP request is processed. So when the file is downloaded, your server may very well give it a different mime type (Apache, for instance, derive one from the file extension).

So, what does this mean for you?

During upload, whitelisting on mime types isn't as important as whitelisting on file extensions. The file extension will be preserved on the server, and can affect how the file is treated (e.g. PHP files might be executed). I would still do it though, as an extra layer of security even though the mime type can be easily faked.

During download, you need to make sure that your server only puts "safe" whitelisted mime types in the Content-Type header. For instance, you don't want to serve anything as application/javascript since that would open up for XSS. But again, file extensions is just as important. E.g. don't serve anything with an exe extentions even if you don't allow the application/vnd.microsoft.portable-executable mime type (unless you want people do be able to up- and download executables, off course).

File upload is complicated, and I have tried to focus on issues related to mime type here. Please don't read this as a complete guide - there are many more things to consider, depending on your context.


Two SSIDs on same Access point- not good?

Quite a lot of "enterprise" type access points offer functionality to allow multiple SSIDs on a single AP, and it's a pretty common configuration from what I've seen.

From a logical perspective the networks should be isolated (using VLANs or similar type of segregation).  You should also be able to specify different authentication mechanisms, encryption types etc.

If correctly configured and patched, this shouldn't pose a major risk, however it does increase the complexity of the environment which always poses security risk (ie, one logical misconfiguration can cause a serious issue)

In terms of the Denial of Service risk, wireless networks can effectively always be DoS'd if an attacker wants to as a powerful enough radio source can cause denial of service on the signal and things like Deauth floods are pretty hard to stop too, from what I've seen.


Does using NATO's phonetic alphabet increase password strength?

I understand that password strength increases with length ....

The strength increases with the amount of unknown information in the password, which often correlates with the length of the password. But in your proposed scheme you get a long password with only few information inside, at least if the attacker has detected your scheme.

Example: simplify your scheme even more and let the password only consist of different amounts of "A", i.e. "AA", "AAAA" etc. If the attacker knows this scheme then the only information to guess is the length of the password, that is a password with 20 characters will be not really be harder to crack than a password with 10 characters.

You might think that the attacker does not know your secret scheme (i.e. security by obscurity) but in reality password cracking today is no longer done with brute forcing all variations. Instead there are a lot of cracked passwords out there which are used as the basis for password cracking, that is it will try these passwords and modifications of them. Thus unless you have a very original idea chances are high that others had the same idea already and that this idea also got (or will quickly get) integrated into the password crackers.


Getting a Root CA accepted in systems and browsers

Different browsers and operating system have different procedures. For example Chrome takes the trust store of the operating system (with the exception of EV certificates) as seen on the Root CA Policy of chromium.

Firefox, on the other hand, maintains all its CAs themselves and doesn't use the systems store at all. They also have a published Inclusion Policy. And of course operating system, like Apples Root Certificate Program.

Generally, all of them require that the CA is certified by an acknowledged authority like WebTrust or something equivalent. To get certified the CA has to prove a few things, like how it determines the owner of a domain, how it keeps the root CAs private key secure, processes and a lot of other things. There is a PDF online from WebTrust with all the requirements. Some examples:

  The Certification Authority:

  Discloses its Business, Key Life Cycle Management, Certificate Life Cycle Management, and CA
  Environmental Control practices in its Certification Practice Statement; and
  Discloses its Business, Key Life Cycle Management, Certificate Life Cycle Management, and CA
  Environmental Control policies in its Certificate Policy (if applicable).
  The Certification Authority maintains effective controls to provide reasonable assurance that:
  The CA’s Certification Practice Statement is consistent with its Certificate Policy (if applicable); and
  The CA provides its services in accordance with its Certificate Policy (if applicable) and Certification
  Practice Statement

and

  Service Integrity

  The Certification Authority maintains effective controls to provide reasonable assurance that:

  The integrity of keys and certificates it manages is established and protected throughout their life
  cycles;
  The Subscriber information  is  properly authenticated (for the registration activities performed by
  ABC-CA); and
  Subordinate CA certificate requests are accurate, authenticated and approved

Then of course the CA has to provide some value to the operating system or browser vendor. Private CAs won't be added to the root CA store of any browser or OS. A list from Apples Root Certificate Program:

  What is the business purpose of the certificates issued from this root certificate? What business is this root enabling?
  To whom will you issue certificates? For example, the general public, members of a certain organization, and so on.
  What Extended Key Usages does the root support? For example, SSL server authority, secure e-mail, code signing, and so on.
  What is done to validate the identity of someone requesting a certificate issued from this root?
  Pointers to Certificate Practice Statement
  List of any third-party audits your CA practice has undergone.
  URL of a publicly accessible server where certificates issued from your roots can be verified

As you can see, it isn't that easy to get into the root stores, and the vendors will reevaluate each and every CA in its store periodically. They also remain the right to kick out any CA it deems isn't secure enough, as has happened with DigiNotar.


Would Insecure Direct References and SQL Injection be solved by using Row-Level Security and Per-User Connection Strings?

Not effectively, no. You're always going to have cases where row-level security can't properly emulate the business processes. You'd also need to have a lot of "general purpose" accounts for things like user signup. The whole thing would be convoluted, difficult to maintain, and largely ineffective.

Keep in mind, also, that SQL injection potentially does not only affect the data, but also the database. Special commands (like xp_cmdshell in TSQL, debug segfault in Redis) have all sorts of secondary impacts outside that of row data.

Regardless, SQL injection is largely a solved problem, so it's really not worth creating inferior solutions that are much more complex and costly.


There are many different ways to do DNS spoofing:

  Compromise a DNS server

This one is as simple as it sounds. If the attacker controls a DNS server that is in the resolution chain that the victim is using, then the attacker can control which IP addresses domains resolve to.

The initial compromise would be via any normal method that an attacker would use to compromise a server - password guessing, weak SSH keys, reused credentials, vulnerabilities, leaked details, etc. Once they have control they can do what they like, including in regards to DNS responses.

  Mount a DNS cache poisoning attack (such as the Kaminsky attack
  against a vulnerable server)

If the attacker can send enough responses to the server to cover the 16 bit query ID address space, they can make their victim's DNS server cache one of these rogue responses. Now, whenever the victim's machine queries the hostname, it will resolve to one of the attacker's choosing, rather than the real domain name. This is usually mitigated by using random source ports to increase the entropy pool.

  Mount a man-in-the-middle attack (if you can get access to the
  network)

Again, as simple as it sounds. If you can intercept DNS response, then you can alter the IPs in the data stream.

  Guess a sequence number (maybe making many requests)

This is essentially the Kaminsky attack, although you could execute it directly against the victim rather than the victim's DNS resolver.

  Be a false base station and lie about the DNS server to use, and
  probably many more.

True. At the end of the day DNS is a network service, just like any other. Its unauthenticated and unencrypted nature means that it's game for eavesdropping and MitM attacks.

Other attack vectors could include dropping a hosts file on the victim's machine as a very easy way to redirect their traffic to a specific domain. A similar one is the badusb attack where the USB device acts as a network card, and provides rogue DNS settings to the victim's machine directly.


OWASP ZAP FUZZ functionality not highlighted

Can't fuzz in Safe Mode. Core help info on modes here: https://github.com/zaproxy/zap-core-help/wiki/HelpStartConceptsModes

  ZAP has a 'mode' which can be:

  Safe - no potentially dangerous operations permitted
  Protected - you can only perform (potentially) dangerous actions on URLs in the Scope
  Standard - as in previous releases, you can do anything
  ATTACK - new nodes that are in Scope are actively scanned as soon as they are discovered

  It is recommended that you use the Protected mode to ensure that you
  only attack sites that you mean to.

  The mode can be changed via the toolbar (or the ZAP API) and is
  persisted between sessions.

  Examples of the things that will not be possible in either Safe mode
  or in Protected mode when not acting on URLs in the Scope:

  Spidering
  Active Scanning
  Fuzzing
  Force Browsing
  Breaking (intercepting)
  Resending requests


Is Plaid safe if I change the password after deposit?

I know nothing of the services you're discussing, but I wouldn't be comfortable with giving my username and password for my bank account to any third party. At that point the other party is you, as far as your bank is concerned. The third party could change the password, change your email, change your address, etc. You might be able to convince a bank to roll back the changes but it wouldn't be fun. Your bank may even have specific language in your banking contract to limit their liability in case of negligence on your part.


What are the security implications of rewriting SSH_ORIGINAL_COMMAND to allow rsync run from rsnapshot cron job?

[Disclosure: I wrote sshdo which is described below]

As mentioned above, rrsync can be used to control what rsync can do over ssh but, like most uses of ssh forced commands, it's limited to a single rsync command per authorized key (or single directory anyway). What if you want to rsync multiple areas of the file system? What if you want to execute some non-rsync commands as well? How many authorized keys would you need to create and install?

Another way to control what rsync can do over ssh is to use a generic command whitelisting control for ssh.

There's a program called sshdo for doing this. It controls which commands may be executed via incoming ssh connections. It's available for download at:

http://raf.org/sshdo/ (read manual pages here)
https://github.com/raforg/sshdo/

It has a training mode to allow all commands that are attempted, and a --learn option to produce the configuration needed to allow learned commands permanently. Then training mode can be turned off and any other commands will not be executed.

It also has an --unlearn option to stop allowing commands that are no longer in use so as to maintain strict least privilege as requirements change over time.

It is very fussy about what it allows. It won't allow a command with any arguments. Only complete shell commands can be allowed.

But it does support simple patterns to represent similar commands that vary only in the digits that appear on the command line (e.g. sequence numbers or date/time stamps).


Enter the password outside the password field

I see two possible problems with this:

Browser/Application Autocompletion

If you do it in a web browser, and the field you enter the password in can allow data to be stored by the browsers autocompletion - then people with access to the browser can find your password. Either by chance, or intentionally. If you enter passwords in a password field, it should not be stored by autocompletion - but in the password database (if opted in).

Server side logs

In the related question you posted a link to in your question, the username field is often found in logs - and possible logs that are accessibly to multiple users. For other fields, it is entirely up to the application and what it does with other input fields.


Security on Login whats the best practices

This is a very good read: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

In general you are going to usually want to store your passwords as a "salted hash". Then you accept their password, run it through your hash function (I use bcrypt) and compare the two.

Also another little detail to note that some people do not think about is the messages you are returning to your users. For example: If someone submits the credentials {user1, mypassword} and either of those credentials are incorrect, you should return "user/password combination invalid" instead of giving a specific message as "password incorrect" which would reveal that they are attempting against an existing account. Never give more information than needed.

This question will be useful as well: How to securely hash passwords?


Call center recording my credit card info

They are allowed to record everything but the SAD (Secure Authentication Data, the security code that's printed on the back of the card) as long as they encrypt the recording or otherwise scramble it.  To quote the PCI SSC Information Supplement
Protecting Telephone-Based Payment Card Data:

  Use strong cryptography to protect any CHD that is stored - for
  example, in audio recordings or in a database - or otherwise render
  the stored data unreadable - for example, via truncation or hashing.
  Sensitive authentication data (SAD) must not be stored after
  authorization, even if encrypted. This applies even where there is no
  PAN in the environment.

Other precautions are laid out, such as making sure call center employees do not have note pads or cell phones with which they can make copies of your card data.

Unfortunately, you have no way of knowing which precautions are in place.  It's common for a merchant to take your call off recording for the recitation of card details, and return to recording after that's done.  Usually this is announced to the caller, but it need not be.  And there's no way for you to know what encryption they may or may not be using for the recordings.

For what it's worth, the risk you face here is no greater - and probably lower - than you face every time you hand your card to restaurant waitstaff and allow them to take it away in order to charge your card.


Why does my Cordova app contain an SQLite file with credit card tables?

The /data/data/packagename/app_webview/* stores the webview cache. The Web Data.db database is the default database that is created to cache the webview data and all the tables such as credit_cards, masked_credit_cards are created by default irrespective of the application using it or not.

First of all I would suggest that you must ask your application auditor to share the POCs(Proof of Concept), if the sensitive details are stored in the local data storage of the application.

I would suggest the following to get rid of the cache:

For the Cordova application you can use this plugin to delete the webview cache.
Alternatively you can programatically delete the folder (/data/data/packagename/app_webview/*) when the webview is destroyed. You can refer this for the logic.

Coming to the security risk, if the credit card details are stored locally then it is a severe risk since the sensitive data stored in the device can be accessed by a malicious user who gains the physical access to the device. Additionally, if the device is rooted i.e. OS security measures are circumvented by the device owner, this data can also be accessed remotely through a malicious application installed on the same device.


Does an existing SSL connection outlast the certificate's expiration

The certificate is validated at the beginning of a full TLS handshake and usually not validated again during a SSL session (although possible). A SSL session usually lasts at least from the initial handshake to the end of the TCP connection. But with session resume it can also span multiple TCP connections.


Not supporting session resumption is not a security vulnerability; but it implies a new handshake per connection, which can increase latency (a full handshake implies more roundtrips than a resumed session) and CPU cost (mostly on the server, with the common RSA key exchange).

The first server is somewhat discourteous, in that it returns a non-empty session ID that it will refuse anyway; what the second server does (returning an empty ID) is what the SSL/TLS standard recommends. Yet returning a non-empty session ID for an unresumable session is not a true bug.

Presumably, ssllabs.com uses the red color here because it is relatively uncommon to deactivate session resumption -- and thus this may be a "configuration bug" worth reporting (although the red might veer a bit too much on the scary).


Is it secure to use bcrypt-generated salt in cookie to serve as token in place of a password?

My two cents, you are not overlooking anything. Your scheme is correct. But do mind that what you are doing is not secure. The session id should be unique for every sessions. Why you may ask?

Well suggest an attacker is able to steal the cookie. Then he can log in as that user. Until the user logs out, because then the session id expires. However if your session id remains the same through all your sessions, the attacker will be able to keep logging in as the user, regardless of the user logging out or not.

In short this means, once an attacker has stolen a cookie, he will have a permanent key for that user's sessions (unless the user changes password). Do realize that this is considered a high risk. The impact of such an attack can be rather high.


Would the Heartbleed bug have been prevented if OpenSSL was written in Go/D/Vala?

Actually none of these languages would have prevented the bug, but they would have lessened the consequences.

OpenSSL's code is doing something which, from the abstract machine point of view, is nonsensical: it reads more bytes from a buffer than there actually are in a buffer. With C, the read still "works" and returns whatever bytes lingered after the buffer. With stricter languages, the out-of-bounds memory access would have been trapped, and triggered an exception: instead of reading and sending the bytes, the offending code would just crash, leading (in the context of a Web server) to termination of the current thread and probably closure of the connection, without altering the rest of the server.

So, still a bug, but no longer a real vulnerability.

This has only an indirect relationship with automatic memory management. The real safety net here is the systematic array bounds check on accesses. That systematic check is then indirectly supported by the strict typing (which prevents using anything else than an "array of bytes" as an "array of bytes"). Strict types are themselves indirectly supported by the automatic memory management (the GC), because it prevents dangling pointers and thus the use-after-free conditions which violate strict typing.

The recent "heartbleed" is not qualitatively new thing; OpenSSL already has had quite a few of buffer overflow-related bugs over the years (a number of which coming from the ASN.1 handling code, for certificate parsing). This one is just another to the list.


Package managers such as aptitude which is used on Debian implement GPG keys to authenticate the package. The Debian install will come with the public key of the package signer, which is then checked before installing downloaded packages.

Sometimes you'll find you end up with an error if this process fails:

W: GPG error: http://www.debian-multimedia.org etch Release: The following signatures couldn't be verified because teh public key is not available: NO_PUBKEY 07DC563D1F41B907
W: You may want to run apt-get update to correct these problems

You can see more details about the solution, called SecureApt, here: https://wiki.debian.org/SecureApt

To address your revision regarding the downloading of installer CD images:

Yes, multiple mirrors exist and one of the primary delivery methods (HTTP) is vulnerable to a MITM attack which could modify the image in such a way as to make your installer contain a rootkit. However, unlike updating packages, installing the base system is a much less frequent event.

Manual PGP protections are also in place for the CD images. Firstly, all disc images on the mirrors should provide MD5 and multiple SHA hashes for every image. These hash files are themselves signed by Debian to ensure they also cannot be forged on a mirror site.

Before downloading the ISO, verify the integrity of the SHA256 or SHA512 (most secure) using for example gpg.

gpg --verify SHA512SUMS.sign SHA512SUMS

This will give you an error if you don't currently have the public key the file was signed with. In that case check the signature given and compare it against the trusted keys on Debian's website: http://www.debian.org/CD/verify

This is the most important part of verification, because integrity of the hash file revolves around the integrity of the key you trust.

Once you've verified an appropriate key, install it in your keychain like so:

gpg --recv-key --keyserver subkeys.pgp.net LAST8CHARSOFFINGERPRINT. This
fetches a key matching the signing key's fingerprint from a server.

Finally, gpg --verify SHA512SUMS.sign SHA512SUMS should now tell you whether the hash file is authentic. If it is, you can safely compare the result of your sha512 chosen.iso with what's in the sums file.

Naturally this all assumes you run these commands from a trusted computer, where sha512 and gpg are unaltered by an attacker.

YPMV (your paranoia may vary).


If I want a more secure and up-to-date Linux, in what cases should I avoid the official repositories?

The Tor Project officially recommends you do not use a PPA or your distro's package manager, and instead install directly from their website. This is not usually the case and typically, good package maintainers will keep software up to date. Debian for example releases new security updates for packages promptly and provides public security advisories for vulnerable packages.

It is important to keep track of your distro's public advisories so you can be made aware of the state of your installation and all the relevant packages you have installed. The recent wget vulnerability is reported by Debian as a DSA (Debian Security Advisory), for example.


"Mousejack" a wired (non-wireless) mouse

There's actually an attack documented which fits pretty good to your description. The original post was deleted but you can read it for example here.

Short version: They (Netragard) managed to break into a corporate network in a penetration test by using a manipulated mouse which was sent to an employee as a faked lottery price. The USB connection was intercepted inside the mouse with a tiny USB hub where a rubber ducky or a similar device was connected.

This schema is called trojan devices. There's also a Blackhat talk about this topic.

  The OS I use is Linux, so I am interested whether Linux is more secure
  in that respect.

AFAIK there are no pre-configured defenses against this but you could harden your system by creating a whitelist of devices which are allowed on specific ports. (udev rules to the rescue!) When you have only one port whitelisted for accepting a simple keyboard without USB hub or re-programmable firmware you're pretty safe against any manipulated devices which are trying use trojan device techniques to emulate user input. Alternatively you could get rid of USB keyboards in your whitelist entirely by using the PS2 port instead.

I'm not aware of any build-in defenses in other operating systems. However there's some software around for windows which does a similar job like you can do with udev on Linux.


Security considerations when opening port for a service?

I have taken some precautions in the service itself, for example I
  have parameterised database queries/inserts and I should be able to
  ask the user to include some sort of username/password in their
  message.

If you are asking them to pass a username and/or password of sorts through to the service it ideally wants to be running over HTTPS.

  I also noticed that in windows firewall there is a Only allow
  connections from these computers option under Remote Computers when
  creating a rule. How reliable is this?

I would personally stick with IP restrictions if its a publically facing service. You can either whitelist or black list IPs. White listing is obviously more secure.

  Much appreciate any help at all as I have no idea where to start with
  this!

I would make sure you pen test your service (application) before publishing it. You mention you have done some protection against user input, but I would spend some time going through testing it in as much detail as possible - ideally ask a third party to help, they may spot things you missed. For example make sure any authentication you are using is strong, and that your application doesn't have any errors that may allow an attacker to circumvent your access control. e.g. Check that all service paths require the correct authentication, and log successsful and failed attempts so you can see what sort of attacks are being tried.

Regarding the server security, the usual protection mechanisms should be used:

Change any default passwords for the server/services
Choose strong passwords
Test that only open ports are exposed, close the ports and services that are not needed
Install a good AV
Regularly patch the OS and any applications
Regularly re-test the above to make sure nothing has changed and accidentally exposed your server and/or application.


Some sketchy ideas:

TLS is a protocol working over TCP and you already use it in many applications, like HTTPS, SMTPS, NNTP (port 563), FTPS, etc. The main use is related to HTTP, for web browsing (especially for e-commerce). In these cases, often only the server is authenticated.

You cannot use TLS, for instance, in many real-time applications, since they are not based on TCP, but on UDP.

IPsec is a level 3 protection method could be used, for example, for establishing a VPN connection, maybe among multiple company offices.
Since TCP/UDP packets are encapsulated in IP datagrams, you can use IPsec to hide some level 4 informations like session numbers or source/destination ports. IPsec can hide also the IP datagram's header itself, so you can avoid the attacker to do traffic analysis. Both things that with TLS you cannot do.

You cannot use IPsec with NAT, because the latter modifies values in the headers which interfere with the integrity checks done by IPsec.


Malicious .so Library creation in CVE-2017-7494 Sambacry

Here you can see the code of a poc library.so and the process to compile
https://github.com/omri9741/cve-2017-7494/blob/master/payload/


can I ask with an app for CVV without having the credit card number

No. The CVV is "Sensitive Authentication Data", and according to the PCI DSS page 7:

  PCI DSS also applies to all other entities that store, process, or
  transmit cardholder data and/or sensitive authentication data.

So, yes, transmitting (receiving and re-sending) just the CVV is enough to put you in scope; if you're already using Tokenization, you're probably doing that to stay out of scope, and this would be a bad idea for you.


Brute forcing domain accounts without hashes

The main thing is to have policy on all users to lock accounts after few failed logons. This way no account can be brute forced quickly. This should include local accounts as well.

Another thing is to have strong passwords so you can't guess them with little attempts. E.g. by trying only 2-3-4 times after each user logon.

If the accounts are not locked it's possible to use various protocols to brute force them, like SMB and sometimes LDAP.


The way vulnerabilities like CVE-2014-4148 are discovered

Fuzzing and reversing. Kernel mode vulnerabilities can be discovered by fuzzing the working code, and if any memory corruption occurs, you can try to reverse the app and, try to write suitable exploit for it. But it is illegal, you must know it :)


Is an ADFS "proxy" required in a production, Internet-facing ADFS deployment?

It's certainly not required, but it does change the attack surface significantly. It switches from having a domain-joined server publicly accessible to having a server a DMZ hop away from a domain-joined server.

The proxy explicitly disables Windows Integrated auth because the assumption is that 1) the client machine won't have access to AD to request a ticket, and 2) the proxy is in a DMZ that won't have access to AD to validate the ticket. If WIA was attempted it would fallback to something far less secure.

It is definitely wise to disable those endpoints since they probably wont work from the internet.


What are the tradeoffs between a common login site and login-per-site?

From a security point of view, both have their own issues and both have their advantages. Both can be made more or less equally secure.

If you use a login-page per service, you might want to synchronize passwords, using, as an example, LDAP or something like that. Otherwise, users may need different passwords per site/service. On the other hand, if you do not synchronize passwords, you allow users to have different passwords per service.

If you use a single login page for all your services, you need a security token to allow access to different sites. There are a number of frameworks for this, so try not to re-invent the wheel.

In general, when you make a choice, you will consider at least:

What is the image that you want to give to the users? A single entity or just a bunch of services?
Are the development groups of the different services sufficiently aligned with your security-token solution?
Do you want to allow your users to use different passwords per service? Did you think about password-resets?


Is a router a better device for a IoT botnet than something in the router's network?

When you're talking about DDoS attacks utilizing botnets on this scale, the attacker may actually benefit from actually not having each infected device send out lots of traffic. With a botnet the size of Mirai, you could have each device contribute a small enough amount of the attack traffic to remain undetected and still end up with enough bandwidth hitting the target to bring it down. The objective in this case is no longer necessarily to find the most powerful devices to add to your botnet, but a rather large number of devices with default passwords that are easily compromised, which could be something as simple as a webcam or other connected IoT device.


Are NFC tags with cryptographic features "write-only"?

This varies by implementation and manufacturer. But in a nutshell. The keys are written once to the card and then protected against tampering. The keys are commonly stored in chip with the ROM, which has technical and physical controls in place to destroy the key if tampered. These are not 100% guaranteed and attackers have indeed found clever ways overtime to manipulate them.

Just to make it clear then. The keys are written into the card and then no further writing is allowed without the existing key being destroyed. - again implementations vary but in essence that's the basic idea.

I found this thesis a really exciting read if you want lots of detail about smart card security. It's long but excellent. http://theses.gla.ac.uk/3091/


Multiple TLS / SSL sessions originated between 2 Windows Servers (2012R2) sharing the same symmetric session keys - is this possible?

If they use a different client cert they can't share an SSL/TLS session, because the peer cert (and its status) is part of the security context.

Even if they can/could share a session and thus use the same master secret, the actual keys (plural) (and IVs if applicable) used on each connection are different because the per-connection nonces are used in the KDF, see F.1.4 in rfc5246 (same as 4346 and 2246).


Good password hashing algorithm compatible with PHP and Linux apps

I don't really understand the limitations you have with 3rd party applications, but I'll address the question you asked.

Instead of focusing on "which algorithm should I trust forever?", you should make your hashing system up-gradable.  SSL was invented 20 years ago, and one of the strengths of SSL was that the ciphers were designed from the start to be replaced as new attacks became apparent.  As we've seen recently, many ciphers suites have been broken and retired, but SSL itself continues on because it was designed to change.

This isn't terribly difficult.  You only need to store the hashing algorithm along with the hash.  If a flaw is discovered in a hashing algorithm, change the hashing algorithm you use for new or changed passwords, and the next time a user successfully authenticates, re-store the hash with the new hashing algorithm.  Over time users will be upgraded to the new hash.

MD5 and SHA1 are considered broken and shouldn't be used in new hashing implementations.  SHA256 and SHA512 are currently well trusted algorithms.  I'm not sure what problems you have with finding support for them in PHP, but it looks like they're both directly supported using the crypytography extension.  http://php.net/manual/en/function.hash-algos.php

Otherwise I'm sure you can find a library somewhere that supports them.

The other standard precautions are advised.  Be sure to use at least 128 bits of randomly generated salt for EACH hash stored.  You might consider adding "pepper" to, which is a single salt stored in a place separate from your hash.


Using gpg to encrypt backups stored on remote untrusted servers

You don't need to do anything with the session key. Like you said, GPG is already using hybrid encryption; generating a symmetric session key and using it to encrypt the data, then encrypting the session key with the recipient's public key.

You could devise a more intricate method like you describe, but I believe GPG alone should be sufficient unless you truly can't handle the GPG key as a single point of failure.