Is it okay that a payment app is sending my payment details via a GET request?

HTTPS protects the entire web request, which includes the url path and parameters. So the data being in the url doesn't make it any less securely transmitted. Only the domain name is exposed via SNI.
GET requests are avoided when transmitting sensitive information in web apps because the url containing sensitive information may be exposed in the user's browsing history (which may have misled you into thinking urls themselves were insecure). However, this is obviously a concern with web apps only. Since this scenario is a mobile app, you are fine from a security point of view.


Can you bruteforce a SSH password without alerting the server owner?

Sure, you use the techniques used by attackers: you hire a botnet to try to bruteforce the password. This doesn't mean that the attempts won't be noticed. It means that the attempts will get lost amongst all the other botnets doing the same. And if detected, you just switch bots. The attacker won't know it's you.
If the attacker has access to the logs, and is looking, then any connection, let alone login attempt, can be noticed.
One other idea: if you can determine if there is traffic to the server, then you can know when the attacker is logged in. You could try to time the bruteforce attempts when they are not active.
But, it is unlikely that you will bruteforce the password. Attackers don't use super long random passwords, but they don't use password123 either.
So, this whole thing is an academic exercise and likely futile. Gain access some other way.


Does hanging up on a UK landline call not terminate the connection?

This is because of Called Subscriber Held (CSH). This is not specific to telephony in the UK but rather a line state applicable on PSTNs caused by the person who made the call not hanging up.

The person from which the call originates must hang up for the call to disconnect as it is the person from which the call originates that is paying for the bill. The person receiving the call may hang up, but this will not disconnect the call unless the originating caller also hangs up. Usually once a CSH condition is detected, a timer will start which will clear the call after a specified period of time (for example 3 minutes).

Back in ye olden days when people had phone handsets connected to base stations with a wire(!) this feature meant they could put the phone down and move to another room without it dropping the call. :)

Using the recall (R) button on most phones will put any current call into an on hold state and give you a dial tone.


Does the “post/redirect/get" pattern create security problems?

It seems someone can pretty easily get my Querystring parameters and then go look at my transaction at any later time.

Maybe it is like this, maybe not. The actual implementation is not known. But one can prevent the behavior you describe by

Having a short expiration on the string, so it can only be used within the very short time the redirect is expected to be processed by the client. This way it cannot be used later.
Clearing the validity of the string after first use (i.e. after successful redirect) so it cannot be used again.
Binding the string to the current session of the client, i.e. session cookie or similar, so that it cannot be used without also having access to the session information.

It should also be used with TLS so that the attacker cannot just capture the request and use it before the client does, since the request contains the string and also the session information. But this is actually not only true for this kind of pattern but for all kind of actions which include the session information - these could otherwise be simply hijacked and changed to cause different things.


How secure is Snowden's MargaretThatcheris110%SEXY password?

As tylerl noted, entropy isn't really a measure of password strength, but it is the best that we've got:

  The purpose of password complexity is to stand up against a
  brute-force attack. The size of the smallest available dictionary that
  contains your password determines the amount of time required to crack
  your password. We can guess at what dictionaries will be available to
  the attacker, but we can't know for certain. Therefore, as a proxy for
  dictionary size, we instead use entropy. It's a poor substitute
  because it doesn't reflect the actual attack mechanics, but it's
  potentially better than nothing.

  Comparisons of passwords based on entropy calculations may potentially
  be fruitful, but you should be careful to avoid ascribing too much
  value to a number which is, in the end, only indirectly related to how
  well the password will hold up.

Even though the MargaretThatcheris110%SEXY. password, when analysed, has an entropy of 39.6 bits, the generation method is randomised (albeit by the human brain). This  makes it difficult to gauge its actual strength. This faux randomisation will also make it difficult for an attacker to put together a wordlist without knowing the structure itself of that particular password. Unless the end-user is using the same structure for multiple passwords (which might accidentally happen should they generate enough that they need to remember), then this lack of entropy doesn't really help the attacker. This is why Graham disagrees that Snowden's password is weak.

It is impossible to judge whether any given single password is "weak" or "strong".

DyZ29ZQ8JswmeKutXHDHh77YqpkmD

might be a secure password, however if it is in the attacker's dictionary then it is not. Password "strength" meters like zxcvbn can give a breakdown of how your password might be constructed, and if it falls into a common sequence then that may prompt you to go for a different one.

The sequence of

female_names + surnames + english word + english word + digits + common password + character

that zxcvbn determines from MargaretThatcheris110%SEXY. is not likely to be very common, therefore an attacker would only choose to attack the keyspace of this entropy distribution if they have a specific reason to do so. This means MargaretThatcheris110%SEXY. is probably as NSA proof as Graham suggests.


Yes and no.

Salt protects you against someone obtaining your database and deducing the actual passwords even though they are hashed. (If someone steals your entire database, it is likely that they have also obtained the user data that the passwords were supposed to protect in the first place, but let's assume that passwords are even more valuable than use data, because many people use their passwords on multiple sites, which would then also be compromised.) therefore, both hashing and salting is standard practice to optimally protect your users.

However, salt doesn't protect you from people choosing "password123" as a password, and an attacker simply trying out common passwords. Nothing can protect you from that - if the user can enter their lame password and obtain access, so can an attacker (the system doesn't know who is at the other end of the line, which is the entire point of passwords to begin with).

For good security, both the provider and the user have to act in a minimally competent manner - one of the two isn't enough.


A "leaf certificate" is what is more commonly known as end-entity certificate. Certificates come in chains, starting with the root CA, each certificate being the CA which issued (signed) the next one. The last certificate is the non-CA certificate which contains the public key you actually want to use.

If the PKI is represented as a tree, with the root CA as, yeah, the root, then end-entity certificates are the leaves.

The Apple Push Notification Service is a system in which a component of your system connects back to Apple to get "notifications" (small messages related to your installed applications). From the messages you observe, it is plausible that the connection uses SSL, and the server certificate (on the Apple side of things) was recently changed, and (for some reason) does not make apsd happy.

Some Google searches show that other people get these messages, and don't seem to notice any bad consequence. This might be a consequence of some dysfunction at Apple's, and could possibly fix itself in a few hours. To be sure, try to run Wireshark to see if you could get a copy of the network traffic: if there indeed is some SSL, then Wireshark will show it, and you will get a copy of the offending certificate.


Is it safe to store a password hash history for preventing user to keep same password repeatedly in some cases?

Security of storing Hash History

  Is it safe to keep the history of hashes?

Relatively. I can imagine some scenarios where this would harm the security of the user, eg:

A user uses a relatively weak password, realizes this and updates the password to a better password, based on the previous password (simple example: superawesome -> !sup3eraw3s0m3!), this would lead to an attacker being able to easier crack the now more secure password (they first crack the easy password, have it in their wordlist now, and then apply basic rules to it such as e -> 3, etc).
They previously used a password on your website that they also use at a lot of other websites, stopped trusting your website, and thus changed the password at your website. An attacker could get your database, crack their old password (which they thought would be deleted from your database), and then try the login credentials at a different website.
After a while, you have a lot of history on a user that changes passwords frequently. An attacker cracks lets say 30% of the history hashes, and now has a pretty good idea how that specific user creates passwords. If the user doesn't create passwords truly random, it will be a lot easier to break the current password.

So I would not recommend keeping a password hash history.

Alternative

  How can I stop him to keep the same password from the previous history?

Don't keep a history. When a user changes their password, you still have the original password hash in the database. You can compare it to that to prevent exact duplicates.

But using bcrypt, this happens:

  According to my observation, if a user changes his password and keeps the same as a previous one, the hash values become different

It happens because bcrypt automatically manages salts for you. So when you hash a new password, it is hashed with a different salt, and thus the hash is different. You could retrieve the old salt, and then pass it onto password_hash as argument to get the same hash.

Better Alternative

You could also require the user to submit their old password when changing passwords (which also increases security[*]), and then you can even check if the new password is similar to the old password (eg using hamming distance or similar).

Both of my alternatives do not prevent cyclic changes though (eg super-secure-password -> another-awesome-credential -> super-secure-password), but I'm not sure if I would really be worried about that.

[*] someone highjacking a session can't change the password, and the password can't be changed by CSRF (even if there is an XSS vulnerability).


Can a proxy server redirect traffic to malicious websites or modify downloads?

Proxy servers can modify both request and response in arbitrary ways, can connect to different systems instead of the requested ones etc. This also includes manipulating downloads or manipulating responses so that the browser gets redirected. And this is not just theoretical but actually happens in practice, i.e. proxies injecting ads, injecting malware etc.

This is especially true for plain HTTP connections. For HTTPS connections this will not work as long as the browser properly checks the certificates (which it usually does) and the user does not skip over certificate warnings and of course if the users system is not already compromised. But note that the proxy might already intercept some initial plain HTTP connections which originally would redirect to the HTTPS site and could redirect the user instead to a similar looking HTTPS site under the proxies control.

For more see “Free” Proxies Aren’t Necessarily Free from 2015 or a more recent paper An Extensive Evaluation of the Internet’s Open Proxies.


Why would people connect to reverse shell's server side?

A reverse shell is a post-exploitation mechanism, meaning that you can only use it after you've already exploited the system. If you hacked a server somewhere at a bank, you will want to be able to look around the server to see what you can get from it. This exchange of sending a command (such as "show directory listing") and receiving responses ("there is credit_cards.txt") is what you use a reverse shell for.

You are right that a user will never run such a command on purpose. You indeed don't post those commands to a website hoping for someone to run it; rather, you insert the command into your exploit so that it connects back and gives you access.

  if the attacker has already exploited the system, why don't he simply run some commands in the exploited system and find out?

So if you made some malware with an exploit and sent it to a bank employee by email. If they open the email and run your exploit, the malware can do whatever you programmed it to do. But what if you have follow-up commands? Like, you might have programmed it to send you a directory listing, but what if you want to retrieve one of the files? You will have to have some way of communicating this command ("download file X") to the victim's system, and sending another email to the employee with updated malware would be rather risky.

A reverse shell is just a fancy word for any two-way channel between the victim's system and your (the malware creator's) system. It typically involves a real shell that (for convenience) works the same way that bash or powershell does, but the term is often used for any two-way post-exploitation communication system.


Is there a way to see if an Nmap scan in the background is progressing?

First, get the process to the foreground:

$ fg

Then, you can use these keys:

v - Increase / decrease the verbosity level
d - Increase / decrease the debugging Level
p - Turn on / off packet tracing
? - Print a runtime interaction help screen
Anything else - Print out a status message like this:

Stats: 0:00:07 elapsed; 20 hosts completed (1 up), 1 undergoing Service Scan
Service scan Timing: About 33.33% done; ETC: 20:57 (0:00:12 remaining)

Edit: then to get the process in the background again:

hit Ctrl-Z to pause the process
enter bg to run the process in the background.

You can use jobs to view the currently running processes.


How can I check if a Mac application has NX or ASLR enabled?

NX bit is for AMD architecture and XD is for Intel. You want to know if a page is executable, basically. vmmap <pid or partial process name> will list out memory chunks permissions.
You can check for ASLR (PIE, to be correct) in OS X by using otool -hv <file_path> and checking out the "PIE" flag.  For example my i386 Wireshark has no PIE flag (most probably b/c it was compiled without one). I don't know how it is in 10.9, but in 10.7 you could link your program with --no_pie flag to disable PIE.

There's an interesting script at https://github.com/electron-archive/brightray/blob/master/tools/mac/change_mach_o_flags.py which can answer your question. You can actually use it to opt-out already compiled binaries with --no-pie flag to the script. Let me cite a part of it and invite you read the full source:

  ...

  NON-EXECUTABLE HEAP

  Traditionally in Mac OS X, 32-bit processes did not have data pages set to
  prohibit execution. Although user programs could call mprotect and
  mach_vm_protect to deny execution of code in data pages, the kernel would
  silently ignore such requests without updating the page tables, and the
  hardware would happily execute code on such pages. 64-bit processes were
  always given proper hardware protection of data pages. This behavior was
  controllable on a system-wide level via the vm.allow_data_exec sysctl, which
  is set by default to 1. The bit with value 1 (set by default) allows code
  execution on data pages for 32-bit processes, and the bit with value 2
  (clear by default) does the same for 64-bit processes.

  In Mac OS X 10.7, executables can "opt in" to having hardware protection
  against code execution on data pages applied. This is done by setting a new
  bit in the |flags| field of an executable's |mach_header|. When
  MH_NO_HEAP_EXECUTION is set, proper protections will be applied, regardless
  of the setting of vm.allow_data_exec.

  ...

On top of that I have to add a link to SO page with two very good answers related to the issue: https://stackoverflow.com/questions/12824045/what-exactly-is-randomized-with-aslr-in-macos-x-and-ios


SSH reverse tunnels: can the intermediate server eavesdrop on an SSH session?

Assuming that there is no active MITM attack going on (which can be detected by properly checking the host keys when connecting to rpi), the server sees only the SSH traffic between laptop and rpi.
Since the payload is encrypted in SSH the server can only do some broad traffic analysis (i.e. source, destination, timing, size of data, ...) but not see or even modify the actual payload. Note though that in some cases such traffic analysis might already be valuable, see for example Timing Analysis of Keystrokes and Timing Attacks on SSH.


How to detect changing IP address and user agent on a HTTP session?

A lot of websites tie the session ID to the IP address, so a session valid ID valid associated to on IP address will be considered as invalid if presented by another IP address.

A more permissive approach might be, instead of blocking such access to simply log them and if needed send a warning to appropriate persons.

Be aware that some privacy protection tools rotate the IP address used (automatically switching from one proxy to another each n seconds for instance) and maskerade browser's user agent while keeping cookies and session information to allow normal browsing. Such tool will produce exactly the behavior you describe while not necessarily be used with any malicious intentions.

The measure indicated in the first paragraph will prevent people using such tool to access to your services. It's up to you, depending on your policy, to decide what attitude to adopt under such circumstances: block, warn, or simply log.


Find algorithm from Digest and Plaintext

All my thinking is based on the fact that this is base64 of the hashed password... so a 128 bit binary, if I'm right.

Yes, it's entirely plausible that you're dealing with a base64-encoded 128-bit hash. But you'd still have to guess which hashing function with 128 bits digest length was used - there is no shortcut for that.

E.g., the length would match MD5. In that case you could verify it with your known password like so:

$ echo "password" | openssl md5 -binary | base64
KGdV+tBIacpSMyCszg3GpA==

The output string would have to match the hash in your config file.

Wikipedia has a list of cryptographic hash functions with their corresponding digest lengths. You could check all 128-bit entries via trial and error. But the smarter approach would of course be looking into the source code of the application you're dealing with, if that's possible.


Beside the fact that you should realy upgrade to a non vulnurable system/cms, have a look at mod_security - http://www.modsecurity.org/


Expected cost and time frame for black box pen testing?

Because there are no definites in testing, and especially so in black box testing, I would charge a daily rate, and aim to propose a limit on the number of days based on assumptions. Occasionally we revise the number of days (up or down) if it becomes clear that the assumptions are incorrect (for example if we are provided with no information as to the size of an application we may assume a certain level of complexity which may turn out to be incorrect)

There will be a difference between a pen test only company, which will provide a technical report, and  a company which will provide analysis of the technical issues based on your business and information flow.

(disclosure: I have managed teams of >100 in this area for global consultancies - and we have always offered the end to end, business focused testing/assessments. These are most valuable for CIO/FD/CEO level - providing them with a useful report for their money, while providing a technical appendix (similar to the technical report) for deliver to IT.)


I'm away from my laptop right now but I remember that the ettercap configuration file is called etter.conf. I frequently use ettercap with arpspoof as a MITM attack and it always outputs any cleartext unencrypted HTTP POSTs. I would make sure that the login page you are trying to sniff isn't HTTPS or if it is unencrypted, that it doesn't post to HTTPS.

Edit: I only glanced over the question and didn't notice the spanish comment. Yes, it's likely ettercap is skipping it because of the form name.  Follow JayfromA's advice.


The security professionals are worried about this but this is an area of security which already has a working (good enough) solution.  The solution is part of the Operating System and its function is to protect what shows up on the login page from compromise.  In other words you cannot easily run a program you want instead of the default OS login page and log credentials this way.

There are social engineering attacks which mimic this scenario, for example once logged in you may be able to run a program which to an end user looks like a login screen.  It isn't possible to make it look exactly like that special screen because of built in graphical "modes" that are part of OS protection, but it can be made to look close enough to fool an inexperienced user into providing their login information and someone capturing it maliciously.  These attacks are more used in phishing and logins into web based services than a local terminal workstation in your library.

Additionally other attacks can accomplish the same goal without running a special program on the system, for example someone could rig the keyboard to record electrical signals as a key logger, though it may not be trivial either.

Whether the security measure is applied against these attacks is also a function of risk of attack succeeding.  Some environments will have better security budgets than others and apply varying degrees of protection.


Is it possible to make a spoofing attack in a access point with same SSID target network?

Yes, all it takes is for an attacker to have a stronger signal. Due to how common it is for institutions to have multiple access points for a single wireless network, BSSID(an access point hardware identifier) is no longer used for network identification.

An attacker can use an off-the-shelf device like a Wifi Pineapple by Hak5. An attacker could also use a custom device that also acts as a rogue access point to perform a tailored attack(i.e., create a webpage with javascript that forces download) to a device. There are more sophisticated attacks, it may be worth looking into security of the 802.11 protocol or using Wireshark to sniff some of your own traffic and test out common attacks.

You can reduce your exposure to wireless attacks by using only trusted networks. If on public wifi use a VPN, or just skip it and use a cellular hotspot you control.


How much sense does it make to use AES-CTR when you are encrypting local offline data?

Compared to CBC, it is easy to do bit flip attacks on CTR. So it makes the most sense when you are also checking a MAC when decrypting.

  I think the counter of the AES-CTR must be randomly generated every time and kept along the encrypted data in clear text, right?

If you change the AES key for each file, you could start counting at 0 (or a fixed IV). If you are not changing keys between files, you need to be absolutely sure you are choosing non-overlapping counter regions for your files or you will leak the XOR of plaintexts which is fairly catastrophic. Note that if you choose the IV randomly, it will almost certainly be non-overlapping at the block size of AES.


Are files encrypted with 7ZIP vulnerable to password crackers?

7zip is secure since it uses AES-256 in CBC mode that can provide CPA security and there is no problem there. Keep in mind that CBC has no integrity and authentication. The real problem comes from the human side; the password!
7zip uses 219-times iterated SHA256 to derive the AES-256 key from passwords. SHA256 is not a memory-hard function and therefore this is not safe from massive parallelization. The collaborative power of Bitcoin miners can reach around 292 double SHA256 in a year. A single Nvidia RTX 390 can calculate 9502.7 MH/s... Therefore one needs a really good password mechanism to be secure from the password list/guess/search attacks.

A password with high entropy like generated from diceware is recommended XKCD.
Use a password manager like keepass that handles this for you.

Additionally; You need to transfer the password to the other party this means that you need a secure channel to do this. A signal program is a good candidate, or you can go for Diffie-Hellman Key Exchange (DHKE), better its Elliptic curve version (ECDH) to establish a key, and then use a key derivation function to derive a long password.


How to stop or restrict Web attack on apache? and how to know which type of web attack it is?

The information you are giving is insufficient, however you may Harden your Server, by filtering ports or closing the ports that are not in use. Additionally, you may add a Network Based Intrusion Detection System to get information regarding any intrusion occurs in your network.
Also, you may update the services running on ports since, using the older versions of services lead to un-authorized access to the Server by exploiting their vulnerability or a Denial of Service attack might be possible in order to crash your server.


Authentication and security of a REST API

If you're using TLS already, I would lean towards using a secret API key in the header.  With an API key you can store that encrypted which protects you in the case of a breach.  Make sure your application and server aren't logging the secret key in any form and I would push your client to use long, complex keys.  These will be handled by systems not people so there shouldn't be heartburn with having them present a long, complicated key with every request.

The hmac signatures are useful if you want to use an unencrypted channel and accept a little bit or risk.  In this case the HMAC provides no benefit and would require you to store the secret in plaintext.  In this case, I would consider a secret key to be more secure than a signature.

Performance-wise they are going to be similar.

One other note: Since you are TLS you should take care to make sure your example docs and howtos make it clear how to establish that connection correctly and alarm at certificate mismatches and your client SDK should do that by default.


What is the equivalent European organization of NIST, especially in the Security Computer Division?

The appropriate organisation for Europe is ENISA, however as Rory points out there are also organisations specific to the sovereign states, which all have their own legislation regarding data protection and information security.


Android Keychain: what is a system wide credential?

Before answering your question I need to ensure that you have basic knowledge of KeyStore and Android keystore system. Therefore, at the beginning, I will be covering some basic overview of these terms in case if you require. After that, I will try to answer your questions.
KeyStore
KeyStore can be defined as a database, API or even a class depending on the context. To make it simple, KeyStore can be defined as a secure collection of aliased keys and certificates. Typically, KeyStores are saved in the file storage, protected with password.
Android keystore system
If we read the official documentation, it says

The Android Keystore system lets you store cryptographic keys in a container to make it more difficult to extract from the device. Once keys are in the keystore, they can be used for cryptographic operations with the key material remaining non-exportable.

So, from the above statement we can infer that, it lets you,

Store cryptographic keys (private, public keys)
Perform cryptographic operations using stored keys (encrypt, decrypt, sign, verify, etc.)

Now you might be wondering, where and how it stores those credentials? Actually, it stores the credentials in a system credential storage or KeyStore either by the KeyChain API or by the AndroidKeyStore provider feature. For better understanding, let's know a little bit about their history,
A system KeyStore was introduced in Android 1.6 (Donut). But unfortunately, at that time, apps were not able to access it as it's access was only limited to VPNs and for Wifi authentication. Therefore, apps were maintaining their own KeyStore. It was okay but sometimes it was causing manageability issues when multiple apps were wanting to share common credentials among them. To address this problem, Android 4.0 (ICS) introduced the KeyChain API which allowed apps to access the system KeyStore with user's permission.
KeyChain
With KeyChain API, apps can request user to install or choose credentials by prompting system dialog. It also allows apps to list and access their allowed credentials stored in the system KeyStore. Most interestingly, the apps don't have to use separate password to protect the system keystore as it is protected by lock screen and device administration. The credentials that are imported by any app can be accessed by other apps with the user's permission. You can also see the list of user credentials in the System Settings by navigating to Settings > Security & lock screen > Encryption & credentials > User credentials. (The settings path and menu may vary depending on the device manufacturer and OS version. It is given based on my Oneplus 6. see the Screenshot)
AndroidKeyStore provider feature
This feature was introduced in Android 4.3 (API level 18) to let apps generate, store their credentials in the system keystore which can only be accessed by the app itself.  To perform operations, no user interaction is required.
I think I am done with providing sufficient information to move forward with answering your questions. Now let's try to answer your questions,

What is a system-wide credential?

In general, the credentials that are stored using KeyChain API are system-wide credentials. Because they can be used by any other apps within the system if the user permits. On the other hand, credentials stored using AndroidKeyStore provider feature can only be used by the app itself.

When should I use it? Can you explain it with an example?

You should use it when you have multiple apps installed in the same device need to talk to the same server with a common set of shared credentials. For instance, you have an email app and a browser app which talk to the same backend server with the same set of credentials. KeyChain API allows you to use the same credentials that can be used by both the email app and the browser app as they are system-wide credentials. This type of credentials can also be used for VPN, SSL authentication, digital signature and encryption/decryption etc.
I hope now you have a clear understanding of Android Keystore system. I will appreciate any type of corrections as I am not perfect.

Update
To clear up your confusion, I would like to divide Keystore in the following two categories depending on manageability,

Self-managed Keystore where you are responsible for saving the Keystore in a file or retrieving it from that file, and also generating or importing keys into that Keystore as well. This documentation shows how to implement self-managed Keystore.
System managed Keystore where the system is responsible for storing or retrieving the Keystore in a file which is accessible by the system only. Android System provides two APIs i.e. KeyChain and Android Keystore provider to access the system managed Keystore. Now let's see the difference between these two APIs,

KeyChain vs Android Keystore provider

In KeyChain API you need to generate keys by your own and import in through this API. On the other hand, Android Keystore provider lets you both generate and import keys into the system managed Keystore
The keys imported using KeyChain API is shareable across the system. That's why it's called the system-wide credential. Once an app imports a key in the system Keystore using KeyChain API, not only the app can access the key but also the other apps can access the key using KeyChain API. On the other hand, keys generated or imported using Android Keystore provider are not shareable i.e. the keys can only be accessed by the app that generated or imported the keys. As other apps in the system can not access the keys using Android Keystore provider API, they are not considered as system-wide credentials.

I hope the above explanation helps. Let me know if you have further confusion.


Confidentiality and Authenticity of the Key in a Key-Value Store

If I understood your goal correctly, consider following.
Since you want to have "confidentiality and authenticity" of the keys, encrypt them. If you choose an encryption method that is not fast enough, consider using something other instead of map keys and store tuple of (original encrypted key, original value). For instance use a hash of the original key or, if this is critical for you from the security point of view, use a KDF key as a map key. So, consider following approaches:

map.put(encrypt(key), value)

map.put(hash(key), tuple[encrypt(key), value])

map.put(argon2(key), tuple[encrypt(key), value])

Of course the map should be able to deal with collisions.


Starting a new job after working at home for years. How to best protect data, secrets, and privacy in the workplace?

Firstly I think you need distinguish between personal risk and company risk. You're probably used to being responsible for all risk, but in a corporate scenario you probably won't be responsible managing risks to the company (except through applying company policy).

Personal and company risk need to be managed differently from your point of view so I'll discuss them separately.

Personal Risk

These are risks to your personal data and accounts when accessing them through company resources. For example: Your Facebook password being compromised by an onlooking co-worker, your personal cloud storage being compromised by malware on the corporate network, etc.

The thing is that you can't be certain of the integrity of a company owned machine. You cannot rule out that the company isn't running key-logging software for monitoring purposes or that they haven't installed their own CA certificate so they can monitor HTTPS traffic. Even if it's not company policy to do these things chances are that someone besides you will have administrator access on your machine and therefore a rogue employee could potentially be a threat. Someone else having root/administrator access means they could change just about any aspect of the system and hide almost any indication of their changes.

Under that scenario you should treat your workstation like any other system which could be a threat to your personal accounts, therefore:

Use different master keys and passwords at work and for work accounts
Avoid accessing especially sensitive personal accounts at work
Separate your work and personal accounts, avoid registering company email addresses as recovery addresses, etc.
If you need to access a personal account while at work then use a personal device instead

Personally, while my workplace doesn't have an issue with accessing personal accounts like Facebook or email from work I generally avoid it. Instead I just use my phone (which isn't company owned) over 3G. If there's something I want to access from my workstation which doesn't pose a significant risk (eg. a link I saved in my personal inbox) I'll just forward it to my work email from my phone.

Company Risk

Risks to company resources, for example cryptolockers, data loss, work accounts, work passwords, etc.

Generally this probably isn't your responsibility. Your company should have policies in place which consider these threats relative to the cost of mitigating them and you should apply these policies as required.

Going beyond the company mandated policies at your discretion is probably okay but keep in mind there will be some scenarios that this won't be okay, for example:

Taking your own backups of important/valuable company data might be seen as suspicious
Some precautions might be deliberately forgone because it has been determined that the cost (eg. to productivity) outweighs the risk it mitigates
Introducing your own software (eg. 1Password) might create risks which haven't been considered by your company even if they are intended to increase security

TLDR; Keep your personal accounts/data separate from work and follow your company information security policies.


How do I isolate/compartmentalize different use cases on one machine?

I think you would need to dual-boot, as installers often require elevated privs to do anything meaningful, and there would be no guarantee that some residual process isn't running that may access your higher-value data, encrypted or not - at some point you will unlock it.
On that note: you might consider VeraCrypt for your non-game system volume and data (encrypted at rest while your gaming os instance is running). At boot time, you would select this partition (or drive) and then you will be prompted for the password from which to derive the volume master key. (This occurs courtesy of a custom pre-boot authentication boot loader termed system encryption.)
If you find yourself needing to boot into Linux, cryptsetup can mount a VeraCrypt volume, which gives you additional recovery or access options.
One caveat: but if that's the case I need the data corruption to be immediately detected/noticeable - any of the ciphers for VeraCrypt will operate in XTS mode, which means there is no authentication of the ciphertext data block. This means that you won't receive any notice of corrupt blocks 'til you next try to use them. My understanding is that BitLocker also uses XTS mode.
To achieve this goal, you would need to check the integrity of your files from within the secure Windows instance using some hash, and you would need to store the previously calculated baseline hashes with authenticated encryption. (Even though XTS will provide confidentiality, of the files' contents as well as your database of file hashes, it can't validate the integrity of the encrypted data.)
Edit, eg: each line in your baseline file contains the filename and hash of each of your work files. Now, use a tool such as Gpg4win to store the signed+encrypted baseline file. All of this can be automated, except for your typing the password to unlock the private key used by GPG when it verifies the most-recent copy of the signed+encrypted baseline data file, before your script checks the integrity of your work files. You could also run this verification independently in a Linux live usb/ iso without even booting Windows.


This sounds very much like an "Administrator" account, which typically otherwise has unlimited access to the things that it's the administrator of.

The security implications of an admin account are pretty well-understood, as are the best practices. I won't go in to all the details, but your implementation breaks with best-practice on one key feature: traceablity.

You want to be able to tell who did what, especially when it comes to administrators. If an admin can log in to my account using his password, then there's no way for an auditor after-the-fact to determine what was done by me versus what was done by the admin.

But if instead the admin logs in to his OWN account with his super-secure password, then through the access he has through his own account performs some action I could have done as well -- well then now we can have a log telling who did what. This is pretty key when the manure hits the fan. And even more so when one of the admin accounts get compromised (which it will, despite your best efforts).

Also, say the business grows and you need 2 admins. Do they share the superawesome password? NO NO NO. They both get their own admin accounts, with separate tracing and logging and all that. Now you can tell WHICH admin did what. And, most importantly, you can close one of the accounts when you fire one of the admins for stealing the donuts.


Is my sending of encrypted information secure?

I assume the client and server communicate via some secure channel e.g. TLS? Otherwise anyone sitting on the wire can mount a replay attack i.e. intercept the ciphertext sent to the client, and send that ciphertext back to the server to impersonate the intended recipient.

From the comments it sounds like you are using the ciphertext passed to the client as a way of not maintaining state on the server. More specifically, you send a message to the client of their encrypted state and then have them send it back and decrypt / process that state on arrival. If you are already storing the encryption keys is it really that much harder to refactor to storing session tokens?

Regarding your question using GCM

The iv (or nonce as it's generally called in GCM mode) is sent along with the ciphertext, the security of GCM does not rely on the iv being secret, only that it is never reused, so 128 bits of random is fine (though as Xander's answer states, there are theoretical attacks against ivs that are not 96 bits). As long as your key has enough entropy you should be fine.
GCM does get around some of the problems other modes have. CTR (which you mentioned) and CBC for instance have bit-flipping attacks against them where the ciphertext can be modified without knowledge of the key to produce meaningful changes in the plaintext. CBC and CTR modes would require a MAC of the ciphertext sent along with them to verify the integrity of it. So while it is possible to use these modes securely it's requires a couple more steps than GCM.

In conclusion this construction is rather unorthodox, and a mechanism such as session tokens would improve performance (and give the benefit of being a tried and tested method). If you must go this route though GCM should be fine for keeping the data secure from the client.


Security concerns of downloading websites contents

In general, no: you should not be excessively worried about such an attack.  To exploit this would require a bad guy to figure out a way to embed malicious code in their images, videos (or whatever) that activates after that image (or whatever) has been converted to a PDF and is then viewed.

Bear in mind that the thing doing the to-PDF conversion in this scenario is your phone: you would want to be much less trusting of a PDF generated by a third party.


Kaspersky wah hit by Duqu 2.0 and according to them:

  We detected the attack in early spring of this year. We were able to
  discover it thanks to the expertise of our researchers and our
  technologies: during a test, a prototype of an anti-APT solution
  developed by Kaspersky Lab showed signs of a complex targeted attack
  on its corporate network. After the attack was noticed an internal
  investigation was launched. A team of Kaspersky Lab researchers,
  reverse engineers and malware analysts worked around the clock to
  analyze this exceptional attack.

How they analyzed it ? Here is the full technical report on this.


If I sell my printer, can the last printed pages be recovered? And how can I wipe it?

From what I read here and after a quick look in the User's Guide this does not seem to be the case.

Print jobs are stored in the local memory (RAM) of the printer, but this is not the same as a hard drive (see also forest's comment). This is true for the majority of modern printers. If the printer is turned off for a moment, there should be no more data inside the memory (aka no more old print jobs). That moment can be crucial, research has shown, that data persists in RAM for some minutes even after a device is powered down.

Speaking to your specific case: unless you are a government official or another target that prints top secret/highly valuable documents every 5 minutes on his printer, this is probably not a risk for you.

The printer (5470-DW) also seems to have ROM2. How do I know? Becaue you can format it.1 According to the manual macros and fonts are saved there, but who knows what else ends up there. If you decide to format the ROM, you might have to reinstall some firmware if you/somebody want/s to use the printer again. I don't think it's necessary, but if you have the itch (and the time) to do it, do it.

Concerning the the HL-5370DW: print jobs are also saved in the printer's RAM, not too sure about the ROM2.

I also looked for known vulnerabilities, there seem to be none.

1 see page 78 in the english User's guide

2 this is probably an EEPROM unit


Authenticated Encryption vs. contained and encrypted checksum/hash?

Overview. Your proposal is not secure (see below for cryptanalysis).  That's why it is not a reasonable alternative to authenticated encryption.

A little more background.  Why do we need authenticated encryption?  It is because encryption without authentication is not secure.  Many developers don't know this, so they end up with an insecure use of cryptography.

It is possible to manually use both an encryption algorithm and an authentication algorithm.  For instance, you can use the encrypt-then-authenticate construction using a secure encryption scheme and a secure message authentication (MAC) algorithm.  However, this requires some extra effort from the developer.

Authenticated encryption was designed as a single primitive that is easy for developers to use, and that provides all the necessary authentication (so you don't have to do some extra stuff to provide security).  Thus, it is helpful for security.  Some authenticated encryption schemes also have the benefit of better performance than separately encrypting and then authenticating, but that is a secondary consideration.

Please read Don't use encryption without authentication for more detail on this subject.

Cryptanalysis of your scheme. You proposed that we append a hash of the message before encrypting: in other words, C = Encrypt(K, M||H(M)), where || represents concatenation of bit strings.  This scheme is not secure against chosen-plaintext attacks, with many encryption algorithms.  For instance, I'll show an attack against your proposal, if you are using CBC mode encryption (though the attack applies to many other modes of encryption as well).

Note that if a man-in-the-middle truncates a ciphertext that was generated with CBC mode (at a block boundary), the recipient won't notice the truncation, and after decryption will receive a truncated version of the message that the sender was trying to send.  So, with that background, here's the attack.  Let Alice be the sender, Bob the recipient, and assume a chosen-plaintext setting.

The attacker chooses some message M that he wishes Alice would send: but Alice refuses to send it (maybe M says "transfer $100 from my account and give it to the attacker", or something).  The attacker constructs some other value X such that Alice is willing to send M' = M||H(M)||X (maybe X says "just kidding! don't you dare").  The attacker convinces Alice to encrypt and send M'.  This means that Alice is going to transmit the ciphertext C' = Encrypt(K, M'||H(M')) = Encrypt(K, M||H(M)||X||H(M')).  The attacker plays man-in-the-middle, captures C', and truncates it while it is in flight.  Let's call C'' the truncated ciphertext.  Bob will receive C'', decrypt it, and then check the hash.  If the attacker chose the truncation point correctly, then after decryption Bob gets M||H(M), checks the hash, sees that the hash is correct, and concludes that Alice must have sent M.

In other words, at the conclusion of this attack, Bob concludes that Alice authorized transmission of the message M -- but she never did.  (She authorized the transmission of some other message, but not M.)

Whether or not this is a serious security vulnerability will depend upon the context in which it is used, such as the format of the message M.  But, empirically, in at least some applications, this kind of attack could pose a serious danger to the application.  Therefore, cryptographers consider that this is not a good general-purpose scheme.

Given that there are good schemes out there which have been carefully vetted and proven to be secure for general-purpose use, cryptographers would recommend that you use one of those general-purpose schemes (such as authenticated encryption, or the encrypt-then-authenticate construction) -- and in particular, don't use the one you mentioned.


It is never zero, there is always a probability that there are many files that have the same hash value due to the pigeonhole principle and almost uniform distribution of the output of the cryptographic hash functions. This can be understand by the arbitrary input size of the hash function but fixed output size, like MD5 has 128-bit and SHA-1 has 160-bit output sizes but they can hash every file.

The probability will be reduced if you use two different hashes or even more, however, you don't need that. Just use a hash like SHA3-512 or Blake2-512 that has higher resistances then when both MD5 and SHA-1 combined. If you want the longer output to decrease the probability of successful attacks you can use XOF like Shake.

You can also use HMAC-SHA3 so that you will have a keyed hash that also provides unforgeability. This will help in the case that if attackers can access the file and hash of it at the same time then they can replace it with a new file with the hash of it. Since HMAC requires a key, they can not execute this attack.

Note that neither MD5 nor SHA-1 is considered secure anymore. MD5  and SHA-1 has collisions attacks.


Standard disclaimers apply, however user Lighty is correct in that it's a proxy server.

Proxies operate by filtering websites by URL, IP, content, or category.  Websites like Facebook, Twitter, and LinkedIn are categorized as "Social Networks" and your company sounds like it blocks access to them.  Youtube, Hulu, and Netflix are all probably categorized as "Streaming Video" and is also probably blocked.  You will probably also find that porn sites and websites against company policy (weapons, online shopping, gruesome content) are also blocked.  Your sysadmin will also be able to block certain websites based on IP or domain name, which could be done if he specifically does not want you to visit Facebook or Twitter, but will allow LinkedIn.  You can see if you are behind a proxy by comparing your own system IP address with that of a looking-glass server like http://whatismyip.com

Proxy servers are enforced to endpoints in different ways, such as:

WCCP redirection
Proxy.PAC files (most common)
WPAD.DAT via DHCP
Local software client

Often, firewalls and proxy servers work closely together to maintain a good security posture.  If a firewall blocks egress traffic from any other an IP address than the proxy server, circumventing is not possible.  If this is the case, then encrypting your traffic, which is what you're doing with TOR, may work.  Even encryption is not a surefire way to get out if the proxy server is using SSL decryption (which some do).

It goes without being said that circumventing corporate security measures has consequences, but it likely can be done given the firewalls permit.  Try the following in order of ease:

Use another browser such as Firefox or Chrome (be sure it doesn't use the proxy [see #3])
Visit a site by IP instead of hostname (Ex. One of Facebook's servers is 173.252.110.27)
Uncheck the proxy.pac file or "automatic configuration script" as it's labeled in Window's Internet Options

In IE:

  Go to Settings > Internet Options > Connections Tab > LAN Settings >
  Uncheck all boxes

In Firefox:

  Go to Tools > Options > Advanced > Network > Settings... > Check "No
  Proxy"

When circumvention doesn't work, you can try to encrypt your traffic.  Encryption is what you're doing with the TOR network, and sounds like you're having success with it.  This is how the encryption is working:

The TOR client on your workstation encrypts your traffic and sends it into the TOR cloud of systems
The proxy server intercepts your request and will fetch the information for you
The proxy queries the TOR cloud to get the data on your behalf
Your request is routed through a series of nodes in the TOR cloud and reaches the destination server
The server responds with the data you seek and it works its way through the TOR cloud and back to your proxy server
The proxy server forwards the data to you, but because the data is encrypted and your proxy server doesn't have a way to decrypt it (unless it has SSL decryption enforced) it cannot look at or filter your data
You receive the data on your workstation

  TOR Note: Because of the large number of hops needed to retrieve every little bit and byte of data, encryption and routing through the TOR cloud can add detrimental amounts of latency and/or could cause the connection to be extremely slow.

If encryption doesn't work, it's likely because your proxy is enforcing SSL decryption with a decrypt or drop rule.  At this point, you're best off using your phone to cruise Facebook at the like.


Whitelisting Email Service for Anti-Spoofing and DMARC

DMARC requires either SPF or DKIM passing with alignment to the From header domain.
If you've added the encryption service gateways to your SPF record, all mail from those gateways will pass your domain's DMARC.


Encryption is used to provide confidentiality of data that may or will be accessed by an untrusted entity. Access control is used to limit or otherwise control an entity's access to an object. Asking "when do we use them" is an open question.

Access controls can be anything from a padlock on a gate to a permission set on a filesystem. They can be simple or complex, can control different operation types independently (read, write, delete, etc.), may involve audit logs, but are generally artificially enforced limitations. By that, I mean there's nothing to physically prevent you from bypassing them, if you've got access to everything. As an example, a filesystem DACL on Windows could be bypassed simply by reading the disk directly, or loading it up in a system which ignores access control (e.g. a Linux NTFS driver). In the physical realm, you can just cut the padlock or chain with bolt croppers, or cut a hole through the wall, or blow the gate up with explosives.

Encryption aims to provide some level of confidentiality based on a differential in computational complexity between an authorised user (i.e. someone with the correct key) and an unauthorised user (i.e. someone without the correct key). A user with the correct key can expend a small amount of resources on decrypting the data, and get the message. A user without that key must expend a significantly larger amount of computational resources in order to decrypt the message - usually so much that it becomes infeasible. The key difference here is that strong encryption provides a real, unavoidable boundary to access. You can't simply side-step it by doing direct reads to a disk or implementing a different accessor - or blowing the data store up with explosives for that matter.

The goals and uses of these two concepts are different. Encryption can provide very strong controls over data confidentiality, but is difficult to get right, can be computationally expensive, and becomes difficult to manage at scale when lots of users need access to the same data. Encryption also isn't trivially applicable to complex models where some users need to be able to read but not write, or write but not read (e.g. writing to a log file but not be able to see other log entries). Access control is much more flexible and can be easier to implement, especially in cases where complex relationships exist between users and data, but it is only enforced by the code that is running on the system. As such, access controls are much weaker (or even worthless) in threat models where local / physical access is a potential (e.g. theft of a hard disk).

The real answer to your question is that they're used whenever they're appropriate for the business logic and threat model in your particular scenario.


Are consumer-grade routers any more or less vulnerable?

TL:DR - Yes, routers CAN be vulnerable.

Misconfigured/Unconfigured routers -
A ton of people just install their routers and leave the default accounts turned on without modification. Thus allowing attackers easy access.

Vulnerable built in scripts - http://www.reddit.com/r/netsec/comments/1xy9k6/that_new_linksys_worm/

See:

What is the "Moose" worm and how can I protect myself from it?
http://www.pcworld.com/article/2899732/at-least-700000-routers-given-to-customers-by-isps-are-vulnerable-to-hacking.html
http://www.pcworld.com/article/2464300/fifteen-new-vulnerabilities-reported-during-router-hacking-contest.html
http://searchsecurity.techtarget.com/news/4500246976/NetUSB-router-vulnerability-puts-devices-in-jeopardy

As for answering whether your 'current setup' is secure. We would need a bit more information about the entire scope of your security onion before being able to answer that.


Is using the username encrypted with the password as key a good password storage scheme?

What you do really is hashing: you built a hashing function out of a block cipher. Incidentally, "encryption of a known value with the password as key" is how the traditional DES-based crypt scheme for Unix was designed.

On the plus side, your construction includes the user name, which partially provides the effect of a salt: parallel cracking is discouraged because two users using the same password will end up with two distinct hash outputs. "Partially", because upon password change, the user keeps his username, so some form of parallelism is still feasible here; and, perhaps more importantly, the same username may be used in several Web apps (e.g. 'admin'), which makes precomputed tables worthwhile (and the point of the salt is to prevent parallelism, in particular the efficient use of precomputed tables).

On the minus side:

This is a homemade construction. 50 years of research in cryptography have taught us that homemade crypto is very rarely good. In fact, we can "know" that a given algorithm is correct only through years of review by other skilled researchers, and homemade schemes, by definition, never got much of a review.
This is limited. Rijndael is a block cipher that can accept keys up to 256 bits; thus, if you use the password as key, then it must fit within 256 bits. This prevents using so-called "passphrases" which can be strong but easy to memorize passwords by using a lot of space for its entropy (human brains don't like concentrated entropy, but are happy with diluted entropy).
This is way too fast, and this is the biggest immediate problem in your scheme. With a basic PC, an attacker can try a lot of passwords per second, in particular since modern PC have dedicated opcodes for AES. With a quad-core PC, one should be able to try up to about half a billion
of passwords per second. Not many user-chosen password can survive such an onslaught for long.

If you are interested in how password hashing works, then read this. The short answer, though, is still the same: don't use a homemade scheme; use bcrypt.


Is it possible to exploit a server using an C library with a vulnerability?

If this library is set in root mode (but local user can execute), can someone write a C program to elevate the privileges to root?

I'm assuming that you mean that the library is owned by root and can only modified by root but that a non-privileged user can use this library inside its own program.

It actually does not matter who owns a library as long as the non-privileged user who is trying to use it can read it. In this case the library is loaded into the process started by the non-privileged user and is executed in the context of this user, i.e. only with the permissions of the user and not with root permissions even though the library itself might be owned by root. That means that no privilege escalation is possible this way.


How to avoid the cross-frame scripting attack over core php we application

Cross-frame scripting allows an attacker to embed your website within their own, as a frame/iframe and then spy on the users of your website.

This requires some social engineering. An attacker would trick someone into visiting their web page, with an iframe containing (say) the login to your website. The parent website would also need to have some malicious Javascript to read keystrokes to capture login. Theoretically, browsers have a same-origin policy that should prevent the attacker from being able to do this, however in reality this attack is possible, often due to browser bugs.

Defenses:

As per the W3 spec, you should include the Content Security Policy frame-ancestors header in your HTTP response to prevent your website being loaded in a frame. Some older browsers may not have support for this header, so also use the X-Frame-Options header with value DENY, SAMEORIGIN or ALLOW-FROM uri. X-Frame-Options takes precedence over CSP frame-ancestors in some browsers.
You could additionally have some Javascript "frame-breaker" code that will prevent your website from being "framed" in older browsers.

These solutions and more details are discussed on this OWASP cheatsheet.


How do you protect against your IT domain admins accessing your data?

What you're asking is not simple. It ranges from very difficult to impossible.

Your company has outsourced the highest privilege level in its environment, and now it wants to prevent those highly privileged individuals from doing something.

They can disable or manipulate any of the native Windows tools. Bitlocker, EFS, etc cannot help you if they have configured GPOs to deploy recovery agent certificates or to backup recovery keys into AD.

They can perform remote monitoring sessions or deploy monitoring/keylogging applications if they want. It takes less than five minutes to setup a software deployment policy if you know what you're doing. You could use non-Microsoft solutions, but those accomplish little if they are running on untrusted systems.

Compartmentalize... if you can.

The problem with compartmentalization is that it's all or nothing. If your email and office apps run on domain systems, it probably won't work.

All of that super important and sensitive data needs to be analyzed, shared, discussed, tasked out, and managed. It will make its way into specifications, project plans, emails, and executive summaries.

If you run unmanaged systems to compartmentalize, you cannot introduce that compartmented data back onto centrally managed machines. This will make some normal business tasks very burdensome. You can run a second, isolated domain to facilitate this---but that is likely more work and expense than simply running everything in-house in the first place.

Accept the risk, or retake control.

In the end, you'll have to make a choice.

You can accept that these contractors have access to sensitive data because they have ultimate control over the systems that process it. Or, you can bring the management roles back in-house, and then you can vet/monitor your admins as you see fit.

Depending on the cost involved, management may simply accept the risk. If there are underlying legal or contractual requirements to protect that data, then maybe the hassle of compartmentalization is worth it.


Is it possible to compromise a mobile phone just by using the telephone number?

Such an assertion sounds conspirational and not founded in reality. However:

The SMS system has many known security issues. Network operators and state actors can locate mobile phones via a “silent SMS” or “stealth ping”. Network operators can associate a new SIM card with the number. SMS can easily be re-routed to a different recipient (without the intended recipient noticing). Since such attacks are possible at low cost, SMS is not a suitable mechanism for two-factor authentication or as a account recovery channel.
Unencrypted data transfers can be analyzed by anyone in a MITM position, such as network operators and state actors. In particular, SMS lacks encryption. However, all popular messaging apps use transit encryption.
Especially older phones have many known security vulnerabilities. For example, MMS handling is highly vulnerable under old Android versions due to the Stagefright bugs. This could be leveraged by an attacker to perform a no-click attack. As a high-profile example, Saudi Arabia allegedly hacked Jeff Bezos' iPhone via a malicious video file sent over Whatsapp in 2018.
Some countries (including the UK) allow devices to be actively hacked for security purposes. However, this can only work if there are vulnerabilities such as the one discussed above. In some cases, installation of surveillance software might require physical access.

However, exfiltration of data from a device necessarily requires more than just knowledge of the number – it generally requires physical access to the device, or an exploit to install malware on the device that will then send data from the phone to the attackers. However, that necessarily requires an active network connection.
There are more theoretical approaches for exfiltrating data from a device, such as side-channel attacks that monitor electromagnetic radiation from the device. However, these generally require close physical proximity to the device to work in lab settings.
So what is that tweet about? Clarification comes in a follow-up tweet from the author:

To be clear: I’m talking about messaging not apps such as banking or a Word document on your phone. The Italian police told me they could listen to and read any message traffic in real time
– @krishgm, https://twitter.com/krishgm/status/1388082271815671808

This indicates they are talking about interception of SMS, which is trivial, especially if the mobile network operator cooperates – which they might be legally required to do. SMS have next to no security guarantees like Confidentiality, Integrity, or Authenticity. This is in stark contrast to all mainstream messaging apps that do use transport encryption, or even end-to-end encryption. For example, it is exceedingly unlikely that Italian police have cracked Signal encryption. For messaging services with transit encryption but without E2EE, the messaging provider (such as Facebook or Telegram) does have the plaintext messages and could be compelled to hand them over to the police.


Why do they use misspelled names in spams?

It's a very easy way for spammers to spoof an e-mail address without altering any header information: just create an e-mail account that looks similar to the naked eye at a glance.

Some e-mail security controls may also flag differences between the displayed name and the sender or, in the case of SPF checks, actually check the originating IP with the sender.

As an aside, there's also the theory that this sort of low-hanging fruit is deliberately done so that the only respondants to a social engineering attempt are those who are so gullible it, they will fall for whatever scam the advesary is attempting. They're effectively trying to maintain a high success rate for the time spent e-mailing users bacmk and forth: someone who misses small details like a Cyrillic rather than Latin letter may also believe that this Nigerian prince really does need their help in funneling money out of Lagos through their bank account.

It's quick, it's easy.


tcpdump packets have bad and incorrect checksums on localhost, how to investigate further?

The bad checksums might be the result of checksum offloading: https://wiki.wireshark.org/CaptureSetup/Offloading#Checksum_Offload

Also, you can use the "-p" switch in netstat to show the Process ID, I believe this requires sudo for that switch.

Hope this helps.


Burp suite - trying all parameters such as numbers|numbers

You can set up that payload set within the Burp Intruders options.

Just set the payload position in the "Positions" tab in Intruder, and then set the payload type to "Numbers" with your required setup.

For the described scenario with two independent sets for the two positions you should use the "Cluster Bomb" attack type. Then you define two payload sets (one from 1 to 99, the other one from 1 to 999) as described above.

That will iterate through all combinations for payload set 1 while keeping the first element of the second payload set:
1|1
2|1
...
99|1

Then the intruder will choose the next item from payload set 2 and iterate through all of set 1 again until every combination was tested.
1|2
2|2
...
99|999

Edit: Forgot to said that you should also check the "Attack type" in the "Positions" tab to fit it to the request you want to perform. Read about the attack types here: http://portswigger.net/burp/help/intruder_positions.html#attacktype (The attack type is just how Burp is going to handle the payloads in the requests).


Group Policy - Best Practice for Default Security Settings

From the Microsoft perspective, I can tell you that this is something that the team responsible for publishing the security configuration baselines has changed position on over the years. In the past, they use to publish baselines with the recommended values specifically set, even if they were already the default.  However, they no longer do that.  Now, for policies that already have secure defaults, they are left as "not configured" instead. This makes administration and management significantly simpler, which experience appears to show is the better option.


How are private keys handled in an enterprise?

Encryption and signatures are two distinct activities, and the difference matters a lot in that respect.

Encryption is about maintaining data confidentiality, except for "authorized users". When these users have private keys, encryption is said to be "end-to-end" in that the decryption will occur on the recipient's device, and can be done only with the help of a private key made accessible to that device by its owner. Corporations, generally speaking, don't like that at all. Encryption prevents them from performing some automatic processing, in particular antivirus scanning (for incoming emails) and detection of information leakage (for outgoing emails). Moreover, encryption raises the issue of data loss: if the private key becomes unavailable, the encrypted emails are no longer readable, since they are typically stored encrypted. Notably, when the user becomes unavailable (he was fired; he retired; he was killed in an accident;...) then the new tenant of his function in the organization must be able to read the corporate emails which were received by that previous user.

Therefore, in a business context, it is often preferred when encryption is centralized -- if there is encryption at all. Emails would often be stored "as is" on servers for which security is done on an "intrusion prevention" basis, rather than mathematically (with cryptography). Encryption is used for data in transit (typically SSL). Users authenticate with the central server when reading or sending emails, but this does not necessarily entails a RSA private key in a smart card. When an email is sent to an external recipient (outside of the organization) then, even if encryption is to be applied, it will be done on a dedicated gateway system, after all due analysis systems have inspected the outgoing email contents and have given the go for further email propagation.

Signatures are avoided. Strictly speaking, a signature is a legal weapon that you build and then point toward yourself. The point of the signature is it is a proof, convincing for third parties, that the email contents are indeed what the signer sent. This can only serve as a way to coerce the signer into accepting extra responsibilities.

If you think properly, then you do not want to sign. You want other people to sign what they send to you. So business try to avoid signatures, and will deploy a system for signing emails only if it is to replace another pre-existing system where there already are signatures done in some other way which is even more inconvenient.

This sums up as the following: if you want to support end-to-end encryption for emails, and/or email signatures, then... think again. Chances are that it is not that good an idea.

Private keys on smart cards, though, are deployed for authentication. Users receive smart cards (possibly with USB token format) containing private keys, and they use that for client SSL connections with a Web server; the client is then their Web browser. This will be for access to sensitive data, so, generally, the corporation will ban such access from "home devices": the employee is not supposed to connect from his own iPad. He shall use only the approved, company-provided laptop computer that is riddled with company-approved antivirus software, and suitably "locked down".

If the daily business calls for some signatures (e.g. medical prescription, in a world of computerized medical file: physicians must be accountable for what they prescribe), then this will not be a basic email, but a strictly formatted "message", signed through a local specific application or some similar trickery (ActiveX control or signed Java applet in a Web site). There again, home devices will not be considered acceptable.

All that being said, some companies have tried, over the years, to sell "virtual smart cards" which usually boil down to some secret value (e.g. a RSA private key) stored with password-based encryption on a server. To a large extent, a GnuPG keyring is an instance of such a system: contains a private key, protected through encryption with a password; put a copy of that keyring on a backup server, and you are all set. "Virtual smart card" commercial solutions mostly aim at making this process easier and more integrated with existing applications (in particular Outlook and Internet Explorer).

To my knowledge, none of such systems was a true commercial success, for the reasons explained above: the added value of these "virtual smart cards" is for situations which you would like, company-wise, to avoid altogether.


Why does TLS need an explicit heartbeat protocol?

The heartbeat serves two purposes: to make some link-level activity (to avoid closure by zealous firewalls) and to make sure that the peer is still alive. If you want to do both with empty fragments, then you need some convention between client and server, so that when you send an empty fragment, the peer responds with an empty fragment. This has potential for infinite loops if not done correctly.

Moreover, when empty fragments were used as a countermeasure to the BEAST attack, it appeared that some widely deployed implementations had trouble with them. This is why we do a "1/n-1 split", not a "0/n" split.

Thus, the heartbeat extension is mostly a formalization of that ping-like convention, with its own initial negotiation and format so that interoperability issues do not arise.


Proxied server requests + forwarding authentication info in a secure fashion

This question is really one specific to your business needs.

In general what you have proposed is commonly done.  You are always faced with the challenge of balancing usability with security.  Take Yahoo or Google for example.  They authenticate you once then store information in one (or more) cookies that are passed to other sites with which they integrate.  Then look at the Yahoo wallet (when it was the prime thing for payment on the internet in the late 1990s and early 2000s), it required yet another authentication with different credentials.  They thought, and I agree, that this piece of their infrastructure needed an additional layer that was from the rest.  That is, they did not trust the main site credentials.

Note neither Google nor Yahoo pass the user passwords around their sites or store them directly in cookies or databases.  Rather, they establish a verification system.  For example the hash that becomes the cookie can contain tidbits of information identifying the browser client, a fraction of the source address, authorization tokens, ++++.  There are many sufficient schemes.

So, does the security of your site need the user to perform authentication for both servers A and B?  Only you can answer that.  If the answer is no, then you should trust the result of the authentication from server A. If your answer is yes, then authenticate at both places.


Storing Argon2id parameters in a database?

Question 1

You need to store all the information, but you should store it encoded in a single column. You probably already get the encoded output from your hash library. It should look something like this (source):

$argon2i$v=19$m=65536,t=2,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

To understand what the different part means, see this question.

Question 2

Note that password hashing should take place server side, so it is not the client machines you should care about. But I assume this is some sort of server software that might run on servers with different performance.

If would advice you to make this configurable, and set a strong secure default even if it might be to slow for some machines. You should probably update these defaults in future versions as well, as best practice evolves and hardware improves. (I don't know what that would mean for Argon2 in the year of 2020.)

To help people who run into performance issues, I would aim to write good documentaiton explaining why they have this issue and why using lower settings would be risky.

Setting a weak default or just doing a performance test would come with the risk of people unknowingly using unsafe settings. I would rather force my users to think about this issue than give them a false sense of security.


How to forget LUKS keys during emergency?

Wiping the LUKS header would make the data completely irrecoverable, even if the password/encryption key is later discovered, since the passwords/keys used by LUKS merely encrypt a master key stored in the header and that master key actually encrypts the data.

So first, deleting the first 2MBs of the device where the LUKS volume resides should make further decryption impossble even if the password is later obtained (through rubberhose cryptanalysis for example). Make sure to overwrite the header synchronously so that the writes don't end up buffered and discarded because you then restart the computer without waiting for the buffers to be flushed.

Then, the RAM must be wiped. Shutting down the computer is one possibility but the data may remain in the RAM long enough for someone to soak it in liquid nitrogen and further extend the data remanence period. Another approach which is used by Tails is to erase the RAM from software by kexec'ing a special kernel that overwrites the RAM. That should defeat the cold boot attack.


You can check this paper : http://media.blackhat.com/bh-us-12/Briefings/C_Miller/BH_US_12_Miller_NFC_attack_surface_WP.pdf

It's from a talk given by Charlie Miller at BlackHat 2012 :

  Near Field Communication (NFC) has been used in mobile devices in some
  countries for a while and is now emerging on devices in use in the
  United States. This technology allows NFC enabled devices to
  communicate with each other within close range, typically a few
  centimeters. It is being rolled out as a way to make payments, by
  using the mobile device to communicate credit card information to an
  NFC enabled terminal. It is a new, cool, technology. But as with the
  introduction of any new technology, the question must be asked what
  kind of impact the inclusion of this new functionality has on the
  attack surface of mobile devices. In this paper, we explore this
  question by introducing NFC and its associated protocols.

  Next we describe how to fuzz the NFC protocol stack for two devices as
  well as our results. Then we see for these devices what software is
  built on top of the NFC stack. It turns out that through NFC, using
  technologies like Android Beam or NDEF content sharing, one can make
  some phones parse images, videos, contacts, office documents, even
  open up web pages in the browser, all without user interaction. In
  some cases, it is even possible to completely take over control of the
  phone via NFC, including stealing photos, contacts, even sending text
  messages and making phone calls. So next time you present your phone
  to pay for your cab, be aware you might have just gotten owned.

There is a tons of links at the end.


Should users be allowed to to login with the same email when an email change is requested but not completed?

Verifying the email upon change is more of a UX protection than a security protection. If a user has a typo when they enter the new email, and don't notice it, then they will end up permanently locked out of their account unless they can login with the old email. As a result, it's actually the opposite:
A user MUST be able to login with their old email until the new one is verified.
A user SHOULD NOT be able to login with their new email until verified (this will just cause confusion and the user will skip the verification process)
One quick note on why this isn't really a security measure: an attacker can easily provide and validate an email address, so this doesn't provide any protection against account theft.


On most systems, OpenSSH supports AES, ChaCha20, Blowfish, CAST128, IDEA, RC4, and 3DES. I am assuming you are talking about the symmetric ciphers used. If you are also wondering about the HMAC and key exchange, I can edit my answer to explain which of those are strong or weak as well.
The good
AES and ChaCha20 are the best ciphers currently supported. AES is the industry standard, and all key sizes (128, 192, and 256) are currently supported with a variety of modes (CTR, CBC, and GCM). ChaCha20 is a more modern cipher and is designed with a very high security margin. It is very fast. While AES is secure, the CBC mode leads to some potential vulnerabilities, so it is no longer recommended. CTR mode, or better GCM, would be preferred. ChaCha20 on the other hand is a stream cipher, so it does not use a block mode of operation and is therefore not able to use CBC insecurely. ChaCha20 additionally uses Poly1305 for authentication, making an HMAC unnecessary. Unlike an HMAC, Poly1305 does not rely on the assumption of security of any hashing algorithm. As long as the underlying cipher is secure, the authentication will be unbroken.
The bad
Blowfish, IDEA, and CAST128 are not bad ciphers per se, but they have a 64-bit block size. This means the key must be reseeded periodically. 3DES additionally, due to a meet-in-the-middle attack, has its effective security reduced from 168 bits to 112 bits. This is not horrible, but it is not ideal. The issue with 64-bit block sizes is described quite well on the Sweet32 website, describing the attacks made possible. The gist of it is that encrypting a large amount of data with a single key can leak information about the plaintext. When 32 GiB of data are encrypted, things get really bad. It's often recommended to change keys after every 4 GiB. While small block sizes are not great, OpenSSH does automatically reseed these ciphers more often than otherwise to attempt to mitigate this flaw. The ciphers themselves are not particularly bad. These ciphers, while old, are not subject to any known attacks that allow a complete break of the cipher. There are simply better alternatives out there.
The ugly
Arcfour, or RC4, is as you stated not particularly secure. Severe statistical biases have been known to exist for a while, and new attacks keep being discovered. While OpenSSH does drop the first 1536 problematic bytes of the cipher, it is still subject to a variety of other attacks. Avoid using RC4.
Overall, you should be using ChaCha20 or AES and avoiding RC4. Use 3DES only when necessary for backwards compatibility. The default OpenSSH settings on any modern installation should be fine in virtually all circumstances. You can't go wrong by using the defaults.


KRACK - does the ability to replay broadcast and multicast frames affect all clients in a wireless network?

Your assumption is false. KRACK is a vulnerability that allows an adversary to MitM and decrypt supposedly encrypted traffic. If one attack is successful this does not make it possible to attack non-vulnerable clients.


How to prevent a web application from accessing local URLs (SSRF)

... prevent users from specifying internal URLs and only specifying servers accessible through the external internet?

I doubt that this is securely possible to proactively filter user input for this. An attacker can easily setup a DNS server which points to some internal IP address or domain, either by A/AAAA record or by CNAME. And given that this DNS server is controlled by the attacker the result of the DNS resolution might be changed whenever the attacker likes.
This means that to check only when entering the domain is not sufficient. Instead the check need to be done whenever the service uses the user-controlled data, i.e. whenever the user-specified URL is accessed and the domain name gets resolved in this process. See also Time-of-check to time-of-use bugs.

The web server might have access to parts of our internal network or some services might be running on localhost.

It might be easier and more secure to fix this design. For example one might put the service inside a container with no other services inside and allow only access to the internet for this container. This approach would provide robustness even against bugs in the application since by design no access to internal sites would be possible.
Another (less secure) option would be to setup a DNS resolver like dnswall which only returns external IP addresses and make sure that only this server is used by the application. Of course one need also be sure that no direct IPv4 or IPv6 can be specified by the user.
A similar approach is to enforce the use of an external proxy server which just based on its location can only access external sites.


If you want security you scan the file on every access. If you want to take the trade off of less security vs greater performance, then turn off active scanning and just use your scan scheduler.

Your talk of trusting the file doesn't make a lot of sense in the context of file storage and access, however you could just scan on your web gateway inbound before the file lands on your server. This doesn't take into account infection from your server itself, so you'll still want to regularly scan your server.

Your point regarding FTP servers is a bit irrelevant here. It is a server. If you want av on the server, you implement it, and depending on the risk profile you either scan on every access or schedule scans.

If you want greater performance while keeping security, use faster disks, raid or other disk speed improvements.


What are the Netscape Cert Type attributes? Why/when are they needed?

The Netscape extensions were defined by Netscape during Days of Yore -- around 1996 or so. Netscape did that because the "official" extensions were missing, ill-defined, or found to be lacking some way or another by the Netscape developers.

Old Netscape versions (when it was called Navigator and Communicator) used these extensions, so you had to include them in your SSL server certificate for proper operations. Newer versions and derivatives (including Firefox and the AOL Web browser) simply ignore them if present, and there is little reason to use them anymore.


Can you ever get partially decrypted data from a decryption algorithm?

Depending on the block mode you are using, you can get partially decrypted data. For example, in CBC mode, if an incorrect IV is supplied, the first block of data will not decrypt properly. However, the rest of the data will decrypt successfully (assuming you are using the correct encryption key). This is because the IV of block (x + 1) is the ciphertext of block x.

Wikipedia's diagram is pretty helpful in visualizing this.

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29


Same wildcard cert from two different 3rd party CA's

You are describing a situation in which you have two separate, valid wildcard certificates signed by separate CAs. Unlike what the current title claims it is not the "same wildcard cert".

There is nothing that stops you from having multiple certificates for the same domain(s).

Clients will verify the validity and trust of the certificate presented by your server according to the steps described in the certification path validation algorithm Wikipedia article.

For a given domain, if a signing root CA for a certificate sent by the server and its intermediate CAs, was trusted by the client, the certificate will be considered valid and trusted.

Unless there was some custom implementation on the client side, it will not consider previously received certificate at all.


A cursory look at the Web yields no precise detail, but it seems (from what is said on this page) that the vulnerability is one of the usual suspects: buffer overflow (probably on the heap, not on the stack) or access-after-free.

Among possible analysis methods:

Setup two virtual machines, with external accesses properly filtered; the two machines should differ only by the version of Office they contain (one patched, one unpatched). Take snapshots of both. Record the hashes of all files on both machines. Open the file in both, while recording every attempt at external traffic. Afterwards, see what changed on both machines (recompute all file hashes, compare with previous lists, use the snapshots to see what exactly changed in each file).
Open the RTF file with a binary editor (or a text editor such as vim, not an editor which will try to interpret the RTF file). Decode "mentally" the file with the help of the RTF specification. Think very hard. An overflow exploit would probably appear in the RTF file as a funky-looking structure with overlong weird identifiers or inordinate nesting.
Contact Microsoft and ask for details. This method works better if you are a government official from a big enough country, or you are very rich, or both.


@QuestionOverflow pointed me in the right direction. greping the server logs for shell.php showed me exactly when it started and how many cards were affected.


Return-oriented programming: Address of system() contains NULL byte

Is there some reason you need to leave the original process alive when your shellcode executes? Just call execve directly (assuming you can control the stack well enough), or one of its helper functions, which will turn the current process into your target process.

A trickier approach that might work is to use dlsym to retrieve a pointer to system, which you could then call with your target command. You might have to call dlopen first, though; I'm not sure about the semantics of dlsym. The corresponding Windows function GetProcAddress takes the base address of the loaded module (library or executable) as the first pointer, and dlsym might do the same; since you're using ROP you presumably aren't bothered by ASLR so that address should be predictable.

Finally, since you're using ROP, you can simply find one or more gadgets that let you arithmetically produce the desired address. There are many combinations of operands (constants in your shellcode, registers or addresses with known values at exploit-time, etc.) and operations (add, subtract, or, xor, etc.) that could be used to produce a specific value that contains a NULL byte from pieces that don't contain one, and ALU ops are short so it shouldn't be hard to find suitable gadgets.


Which key is actually used for encrypting data traffic in WPA after the 4WHS?

It is the PTK used for data transfer, it is derived from the PMK (PSK).
If the PMK is compromised (You get to know the passphrase/password) all you can get is the Broadcasts packets, because you can connect ONLY to the AP, and not the other clients, since you need the handshake to generate the PTK.

By definition from the IEEE 802.11i:

  pairwise transient key (PTK:) A concatenation of session keys derived from the pairwise master key
  (PMK) or from the PMK-R1. Its components include a key confirmation key (KCK), a key encryption key
  (KEK), and one or more temporal keys that are used to protect information exchanged over the link.

And the PMK:

  pairwise master key (PMK): The key derived from a key generated by an Extensible Authentication
  Protocol (EAP) method or obtained directly from a preshared key (PSK).


"Your connection is not private" when connected to work's server through VPN (Cisco AnyConnect SMC 3.1)

There is probably SSL interception done by your company, i.e. man in the middle of SSL connections to analyze for malware and data leakage. Please contact the works system administrator for details on how to configure your system to include the necessary certificates. Apart from that make sure that you are even allowed to connect private PCs to the work network.

See also Does a TLS interception proxy present the user's browser with the end server's certificate? and Is it possible for corporation to intercept and decrypt SSL/TLS traffic?