SSL session ID in TLS ticket based resumption

What is the significance of this session ID and can it be used to resume the session?

You always get an ID.
You may establish more than one session with a server. The ID tells them apart. It's basically an index into a table where the server will find all necessary keys/etc. for that session.
The client can TRY session resumption by supplying the old ID during the handshake. But the server can just ignore that attempt and issue a new ID instead. Which is just what happens when that particular ID has expired from the server's ID table (session cache). It doesn't cost the client anything extra to try resumption.
Further reading

Section "TLS session resumption" here: https://istlsfastyet.com
Related question here

Update 1. Empty IDs
I don't really understand this. Maybe some SE-user can expand on this.
I don't really understand the interaction when both IDs and Tickets are enabled. So I decided to read that section in my copy of "Bulletproof SSL and TLS":
(quote is from Chapter 2. Protocol | Extensions | Session Tickets)

Note
When a server decides to use session tickets for session resumption, it sends back an empty session ID field (in its ServerHello message). At this point, the session does not have a unique identifier. However, the ticket specification allows the client to select and submit a session ID (in its ClientHello) in a subsequent handshake that uses the ticket. A server that accepts the ticket must also respond with the same session ID. This is why the session ID appears in the TLS web server logs even when session tickets are used as the session-resumption mechanism.

And having read this, now I'm not so sure anymore that I actually understand the concept of the session ID.
Anyway, the relevant section from the session ticket RFC is 3.4.  Interaction with TLS Session ID.
And this seems to say that session IDs either don't exist or don't matter when tickets are in use. Dunno.


In the majority of cases, this kind of social authentication is based on some form of (hopefully) secret authentication token that is generated at the time you allow access and is stored on the 3rd party service.

When the 3rd party service makes a request from then on, they pass the authentication token they have stored and Facebook then allows them to post on your behalf.

You can read more about Facebook's "access tokens" here


What is span of the HTTPS protection? Does it protect traffic between client and destination or is it only in between proxy and destination?

With a HTTP proxy the client requests a tunnel to the server (using HTTP CONNECT request) and then creates an end-to-end TLS session between client and server over this tunnel. A non-intercepting proxy will only forward the initial handshake and the encrypted data.

An intercepting proxy though might terminate the TLS connection from the client at the proxy and create a new one between proxy and server, thus having access to the decrypted traffic. Of course the proxy cannot use the original server certificate, thus the client must somehow trust the certificate generated by the proxy. This is either because the proxy is trusted and has its CA in the client (i.e. corporate proxy, local antivirus) or because the client has explicitly ignored the warning that the connection is not trusted.

  Is it trivial for the malicious proxy to directly sniff critical data. With trivial I mean not using significant computational power. With critical data I mean things like secrets or passwords not metadata like ip addresses and so on.

No, since a non-intercepting proxy will only see the encrypted traffic and the certificate of an intercepting proxy will not be trusted by a proper client.

  Do SOCKS and HTTP protocols make difference in difficulty of such attack.

There is no practical difference, its only a small difference in the initial data between client and proxy (i.e. HTTP CONNECT vs. SOCKS handshake).


Search on encrypted data of multiple users

What you are looking to do cannot be made secure.  Regardless of the implementation, if it is possible to efficiently search across multiple users, then the scheme is necessarily vulnerable to dictionary attacks.  Note that it is very likely an attacker would be able to obtain a large list of names and email addresses.  The best you can really hope for is to slightly obfuscate the data such that nothing would be learned from a casual glance.


Are my passwords saved in Google Chrome safe when I'm logged out?

In cases where a password store key is derived from the account password, it is impossible to get access by force-resetting the account password. When that's happening, the password store is encrypted with a key derived from the password. Decrypting it requires the password; the password isn't just used to tell the OS you have permission to view it (like normal file permissions), it's the only way to decrypt the store, because the decryption key isn't stored anywhere on disk (it's re-derived whenever you enter your password). That's the big difference between encryption and access control: access control can generally be bypassed because it relies on the OS letting you access something or not letting you do it, but encryption cannot because the only way to get the data is by something found only in the user's head.

The OS doesn't know your password: it stores a hash of the password, but it doesn't store the password and doesn't store the key. Someone who gains access to your account in any way except entering your password can't decrypt the password store. That includes resetting the password. If you change it normally, the OS can decrypt the store with your old one (which you either supplied to log in or supplied to change the password) and save it re-encrypted with the new one. If you change it with password reset tools, what the OS does is overwrite the password hash, but it can't decrypt the store to re-encrypt it. It sometimes keeps the old one around in case the user knew their password but had to reset it for some reason (in which case they can enter it in when they next log in to their account to change the encryption key), but the data remains inaccessible until the original password is entered to decrypt it.


Chrome >50: Where can I see the negotiated cipher suite?

Update:
More recent Chrome versions make it both easier and harder.
The bad news: The “Details” link has been removed. Now you have to open the Developer Tools with Crtl+Shift+I or Cmd+Opt+I, or by clicking on the ⋮ Chrome menu > “More tools” > “Developer tools”, and then click on the “Security” tab.
More positively, the information has now been added to the “ Overview” section without reloading, and includes the key exchange group (e.g. the elliptic curve P-256).

another update: in the newest versions [I'm on the 64 bit version 59.0.3071.115] looks like there is a specific security tab to display this info in the Developer Tools:

Original Instructions

Click on the  lock icon in the location bar

Click on the “Details” link next to “Your connection to this site is private.” This opens the Security tab of the Developer Tools.

Reload the page.

The Security thing’s left column goes “ Overview”, “Main Origin”… Click on the next one, “⚫ https://security.stackexchange.com”.
Connection

    Protocol  TLS 1.2
Key Exchange  ECDHE_ECDSA
Cipher Suite  AES_128_GCM

Yay!


Selection of Curve in ECC for openssl 1.0.1?

Short answer: secp256r1 secp384r1 and secp521r1 are all good conservative choices. secp256r1 currently has better compatibility with browsers than the others, for more detail, see this question.

If your clients are up to date (aka modern-ish browsers) then I would recommend curve25519. It was invented by Daniel J. Bernstein (a university prof who's famous in the crypto world) and he was very transparent about how he came up with the random numbers, so there's no chance of government backdoors in that curve. It also has better performance than the NIST P-* curves [wikipedia]

But really, anything supported by openssl is fine unless you are a military organization or a bank, in which case stop posting here and hire a security expert!


SSL communication between a C# Server and an Android Client App

If you don't intend to perform client authentication via SASL or the like, a certificate is needed only for the server. Just embed the public key you generated in the app and use it for certificate pinning.

If get your certificate signed by a CA in Android trust store, you can use Android TLS utilities without any extra step, since the verification will be handled automatically for you. Anyway, pinning appears to be the safest option for an app distributed through the Play store, which will likely communicate with few, selected and known hosts. In fact, it makes MITM much more difficult: having a certificate valid for your domain is no more enough, they need to get your key.


Can I use the same truststore and keystore on the client and the server?

There is no restriction in TLS itself which prevents using the same key pair on both sides of the connection. It is not really a good idea since a private key should be kept private (which it really isn't when shared between client and server) but it should nevertheless work.


To act as a kill switch they must connect.

So the safest way to do it is probably to respond for them: when one of there domain/IP is requested, fake the answer.


There is a standard for GCM. Hopefully, OpenSSL follows the standard correctly. Since:

there is a standard for using GCM in SSL/TLS;
OpenSSL supports GCM in TLS since version 1.0.1 (see the ChangeLog);
GnuTLS also supports GCM in TLS;
OpenSSL and GnuTLS appear to be able to talk to each other;

then chances are that both OpenSSL and GnuTLS implemented GCM properly, i.e. conform to the standard.

If unsure, check with the test vectors published by NIST (search "GCM" in that page).


The biggest risk with this setup is Cross-site request forgery (CSRF). As an example, imaging a site has a URL like http://mysite.com/setTitle?title=Hello which sets the site's title. You only want the admin to access this, not anyone else, and you use IP address controls to enforce this. Now just imagine if the admin is browsing some unrelated site, and that includes an image tag which links to this URL, e.g. http://mysite.com/setTitle?title=Evil What will happen is that the admin'd browser will try to load that link. The web server will see the request coming from the authorised IP address, and allow the title to be changed. Not good! The usual fix for CSRF is to issue a random token to users, which must be included in the request.

Who else uses your IP address? Most home setups have a number of people accessing the internet through the same router, and hence the same IP address. You may not want these other people to have access.

The risk of IP address spoofing is less of an issue. TCP has reasonable protection against this, which stops many attacks. It is still possible in certain circumstances, but if you're just after something simple, I wouldn't worry too much about it.


Length of a stretched gnupg passphrase that is comparable in strength to an unstretched string of 256 random bits

Find a space of 2256 distinct possibilities, and choose your password uniformly at random from that space.  For example:

Pick 40 characters independently uniformly at random from the graphic US-ASCII set, like with tr -cd '[:graph:]' < /dev/urandom | head -c 40.  There are 94 such characters, and so 9440 > 2256 possible passwords this way.  (You can include space too if you want to allow space; then you only need 39 to exceed 2256 possibilities.)
Pick 20 words independently uniformly at random from a 7776-word list, like with diceware.  There are 777620 > 2256 possible passwords this way.  You can choose a word list you like to make things more memorable; there are many options available.

Once you do this, the stretching isn't important any more!  The stretching is only a crutch to lean on if you insist on human-chosen passwords, which are a bad idea anyway.

If you use the password only for GnuPG, and you always use it with salted s2k (which, obviously!), then you can safely turn this down to 2128, e.g. a mere 20 characters or a mere 10 words.  But if there's any danger you might reuse it in an unsalted context you should stay at 2256.


What information do ISPs delete after retention period?

In a nutshell, the duration and scope of data retention is dictated by legal requirements, and then operational/business decisions may come into play. ISPs may or may not be allowed to keep logs for longer than legally necessary but storage and maintenance has a cost. Unless there is value in mining that particular data, the incentive for an ISP to keep logs forever is low.
The most important (and possibly the only) information that the ISP can provide is whose connection was assigned what IP address at a given time. The aim being to identify a customer from an IP address recorded somewhere else (eg in web servers logs).
The ISP probably doesn't have so much insight into your browsing activity. If you use their DNS they may figure out what websites you visited, but many people use a third-party DNS like Google, Quad9 etc. Even if the ISP tapped your whole traffic because you are a "person of interest" most of it would be encrypted anyway (https mostly).
If the police need more details about what you did on some website where your IP address was recorded, then the police would have to subpoena the webhost or whatever. The ISP has only part of the information, which is crucial for investigations but very limited at the same time.
Read the terms and conditions of your ISP and see if there is any mention of what data is logged.


How exposed am I using older Firefox version (56)?

The versions and security fixes are listed here: https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/

While it is not recommended to run older versions with known issues, one way you might be able to get along is to run the old Firefox in a container or virtual machine in order to get some protection for your personal data on your host.


How can malware immediately infect a Windows XP computer as soon as it goes online without any user action?

Even if you are not actively accessing anything, your computer is. Windows is a very talkative OS, and will broadcast all his services all around the network, and depending on the network misconfiguration, to the entire world.

NAT will protect you under certain circumstances, but if your router have UPnP active and allows connection from the internet, it can create a path from the internet direct to your Windows computer, because Windows broadcasted his printer service. Any exploit running against SMB print service can reach it. Again, this depends on a couple variables: OS version and configuration, network topology, router/modem version and configuration, and specifics of the attack. Some combinations of those variables will surely open a port from the internet direct to a vulnerable service on an internal computer.

There are billions of IPv4 addresses, of course, but they aren't attacked by only one actor. It's common for scanning malware to start scanning its own subnet, and after that scan a random one. If any user of your ISP is infected, you will probably be scanned soon by his computer, not by a random computer half the planet away.

And even with routers, its security depends on your ISP settings. In Brazil, a large ISP deployed modems with telnet enabled, and without password. Any botnet targeting modems WILL compromise it, and compromise internal computers without too much trouble.


What exactly are the session injection concerns when using Firebase Signin Links?

TL;DR: Don't bypass the restrictions imposed by firebase on the application you develop. Although by default firebase doesn't allow you to change these values afaik, you have the options to create a custom e-mail template and a flow and "add" the tweaks.
Firebase "verifies" the user before creating a session by something the user know and another thing that user has. In this case e-mail and the link the user received in order.
In traditional approach, this is username and password.
If you put the "e-mail" information in to the object the user supposed to have, you reduce the factors from two to one.
And also if you let user to reuse the same object instead of unique asset that is generated every time the user intentionally request, you further reduce the security.
Take this examples:

Developer generates a sign on link that is reusable and e-mail address embedded. And user goes on and pastes this link somewhere public. In this case anyone clicking on the link will log on as the same user.

Developer generates a sign on link that is only reusable. User pastes the link to a chat application where others can see or guess its e-mail. With minimal effort, others will be able to log on as the same user.

The document just explicitly warns the developers to not bypass or workaround the restrictions imposed by firebase as you mentioned.


Recommened books for learning operation system

This is probably going to be suggested by others, so I'll just throw it out here.

 Andrew S Tanenbaum's "Modern Operating Systems"

I personally have never read it, but others say great things. I have read other books by Tanenbaum and they were good.


There was no Debian 2.30.2 release; there was a Debian 2.0, 2.1, and 2.2 that were released more than 10 years ago.  I'm guessing you are talking about the version of GNOME (your desktop environment) which has nothing to do with authentication.

Most Debian systems use PAM for authentication.  Your password is checked against a salted key-strengthened hash that is stored in /etc/shadow next to your name.

You'll typically see a line in that file (this is not a real password; just dumbpass created for a fake account that's already deleted):

fake:$6$qaPTEvGg$XCMFzng5TQotiK4Whr4a0F/87.h5KK3kTO1R4Ysr6G8Ej42JZaJynYSG1uBWikQwlWhOPNNHOQgMFd6Kt.1rx/:15725:0:99999:7:::

where the account name is fake, followed by the salted-hash of the keystrengthened password in the form $id$salt$encrypted encoded in a base64-like encoding (base64 using the symbols  [a–zA–Z0–9./]), followed by a colon and then some more numbers (these numbers relate to settings about when the password was last changed/needs to be changed/will expire/etc.)  The id=6 above means that I am using SHA512-crypt, which basically does 5000 rounds of SHA-512 salted-hashes before saving my password.   See man 3 crypt and man shadow for more details as well as this page on SHA512-crypt.

Most modern systems (e.g., anything from this century) use stuff similar to this; possibly using MD5-crypt (which still will check against the entire password).

It seems however you are using a very antiquated DES scheme to check against your password that is known to only check against the first 8 characters (bytes) of the password.  From man crypt:

  In the MD5 and SHA implementations the entire key is significant (instead of only the first 8 bytes in DES).

Your salted hash should start with a $1$ (MD5-crypt), $2a$ (bcrypt), $5$ (sha256 crypt), or $6$ (sha512 crypt), and if it doesn't that means you have a DES hash (which is a scheme dating back to the late 1970s and should not be used any time after the late 1990s when it became feasible to break DES in days).

You can begin using a better solution by altering your PAM password settings and then updating your password using the command passwd.  The settings are in /etc/pam.conf or possibly in the directory /etc/pam.d/ in a file named common-password (may vary slightly by distro).  The relevant section of my file looks like:

password    [success=1 default=ignore]  pam_unix.so obscure sha512

This enables pam_unix.so for password authentication, using sha512-crypt as the algorithm to check passwords against.  (obscure forces passwords to pass a couple checks to reject overtly simple passwords -- e.g., words from a dictionary).  Now if pam_unix.so is not find-able on your system it may default back to using DES passwords (you may have to install "libpam-modules" which has pam_unix.so though any reasonable distro will come with this preset up).  Personally, I think this mistake is huge that modern systems could potentially be set up to use DES with raising huge red flags of weakness after each successful login; similar to what happens if you try making certain secure files world-readable.

Additionally there is a very small possibility you found a new bug in crypt/PAM; e.g., possibly if your password contained certain unicode characters in an unexpected encoding with null bytes.  (Note DES passwords not being able to handle unicode properly is one of their known flaws; but again a modern scheme like sha512crypt unicode passwords should be securely handled.)


Are there DNS analysis tools that could detect bad DNS results?

I'm not aware of any tools, and I'm not sure how effective they would be. If you got enough privileges to change the DNS servers of a system, you can probably also disable any anti-malware programs.

If you still want to, you could easily write a script that does the following:

Query for the domain you want to be sure is correct, using the system's DNS servers
Query a trusted DNS server for the same domain
Query a second trusted DNS server for the same domain

From which you can conclude:

If they all give the same IP, it's probably legit.
If the trusted DNS servers give the same IP but yours doesn't, something is wrong
If they all give different IPs, the nameserver of the target domain uses round-robin or split horizon

This is, like with almost everything, not entirely safe. Like I said, malware needs a lot of privileges to do this, it's not unthinkable that it spoofs the IP for trusted servers like OpenDNS or Google's public DNS, making them appear to return the same answer as the malware server.

Probably the only way to ensure you are talking to trusted DNS servers, is by using DNSSEC.


how to verify file signature by client PGP

As per my experience, additional software are required.


What's the diff between blocking a port with a firewall and not starting a service on that port in the first place?

TL;DR

It protects against having to manually configure services to only listen on localhost, as you have to manually allow them network connectivity, and it increases the effort an attacker must exert to recon your box. This means it's an effective tool both against attackers and poor configuration.  Yes, you should run a firewall.

Detail

Ports have 2 main states:

Open (Service is listening)
Closed (There is nothing listening)

You appear to be familiar with the two states - ports default to "closed", switching to "open" if there is a service listening.  It's very fast to enumerate both open and closed ports - the OS will actually send a response saying either "there is a service here" (port is open), or one saying "there is no service here" (port is closed).

If you use a firewall, it provides the option to filter ports.  For filtered ports, the OS does not respond at all.  This means an attacker must invest more time to determine port states, as they have no way to know if the computer didn't send any response, or if the response was lost in transit.

Additionally, if you're running a firewall, you protect yourself against accidentally exposing additional services to the Internet.

I've included a sample scan of my desktop with my firewall off (pay special attention to the number of ports discovered, and how long the scan took):

$ nmap 192.168.1.26

Starting Nmap 6.40 ( http://nmap.org ) at 2015-01-24 21:41 EST
Nmap scan report for TehPwner (192.168.1.26)
Host is up (0.00017s latency).
Not shown: 987 closed ports
PORT      STATE SERVICE
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
902/tcp   open  iss-realsecure
912/tcp   open  apex-mesh
2869/tcp  open  icslap
5357/tcp  open  wsdapi
8081/tcp  open  blackice-icecap
49152/tcp open  unknown
49153/tcp open  unknown
49154/tcp open  unknown
49163/tcp open  unknown
49176/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 2.30 seconds

Now I've enabled my firewall:

$ nmap 192.168.1.26

Starting Nmap 6.40 ( http://nmap.org ) at 2015-01-24 21:42 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn

Nmap done: 1 IP address (0 hosts up) scanned in 3.03 seconds

Once more, skipping the ping probe:

$ nmap 192.168.1.26 -Pn

Starting Nmap 6.40 ( http://nmap.org ) at 2015-01-24 21:42 EST
Nmap scan report for TehPwner (192.168.1.26)
Host is up (0.00090s latency).
Not shown: 996 filtered ports
PORT     STATE SERVICE
902/tcp  open  iss-realsecure
912/tcp  open  apex-mesh
2869/tcp open  icslap
5357/tcp open  wsdapi

Nmap done: 1 IP address (1 host up) scanned in 49.29 seconds


What are some good arguments for having your work send you to e.g. DEFCON or Black Hat

In my opinion, being sent to the conference would...

Keep your skills up to date in a fast moving industry
Bring fresh ideas and perspective back to your company
Allow you to network, e.g. scout new hires
Increase the presence/awareness of your brand
Provide a bonding experience with co-workers

To help ensure success...

Find out what the application process is for your company
Find coworkers who have already gone through this process
Ask your manager how they can be convinced
Read sample letters like this one for insight into business babble

For further research, read the the answers to What value to the business is there in sending non marketing people to trade shows? and the question to better understand how business types think and what their concerns might be.


1) Part of the answer depends a lot on the kind of company you work for. I used to work at a Fortune 100 defense contractor, and I can tell you any decent IT system will red flag unknown encrypted data leaving the company network in a heartbeat. They're not looking for someone accessing blocked sites, but that kind of activity can look a lot like a sophisticated attacker has compromised the company network and is stealing data. That kind of attention will get you terminated.

2) Most companies routinely install monitoring software on company devices. It's cheap, effective at keeping employees inline, and it's a great way to document 'cause for termination' when you want to fire someone. So, you should assume they can see everything on your screen, and log everything you type at any time. All they need is a reason to come looking.

In short, most companies will terminate you pretty fast for pulling something like this. It's not a matter of if you'll get caught, but when. So, you'd better be sure watching youtube (or whatever you're up to) is worth loosing your job over.


Does disabling right click have any impact on security?

Does it make the site any more secure?

No, it doesn't alter anything other than your ability to conveniently save items from a page. Using a browser's developer mode, turning off JS, overriding this with a different script that disables that pop-up, or just grabbing data off the wire after stripping the SSL will all work.

  Is it a good general practice?

This is an ache that the Internet has had to suffer from the height of GeoCities fame when folks didn't want you to "steal" their very poorly composed photos of dandelions and family pets. Dispensing all professionalism and being straight-forward as possible, I might hesitate to convict a person for smacking the responsible party of any modern site using this upside the head with a cast iron skillet. Aside from that it has generally fallen out of favor due to being a combination of ineffective and annoying. For instance, it would also make my spellchecker misbehave.


Secure AWS instance metadata against potential SSRF

Indeed, if you want to restrict access to the instance metadata service -- so that only a specific list of users can query it, you need to have an OS-level control instead of a network-level control.

The reason is simple, users are an OS concept, and packets from different users on a OS reaching out to the instance metadata service would look indistinguishable from each other at the network level.

This documentation from AWS, specify an identical use-case as yours, where they limit access to the instance metadata only to the root user (using PF on BSD).
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide//instancedata-data-retrieval.html#w328aac17c17c25c15c19b1

I'm no expert, but I guess Windows Firewall will perform the same functionality -- where network traffic to the Instance Metadata IP can be denied to your IIS user. You couldn't do this with security groups or NACLs, simply because you'll block the entire meta-data service from all users (including all your agents on the server).


HTML table elements are sent plain text, even if the server connection
  is https.

Completely wrong. Please throw this book away.

For the HTTP server, the whole HTML file is just a file, nothing less or more. The content is irrelevant. Either the whole file is sent encrypted, or the whole file is sent as plaintext.


Where can I find an engineer who can examine an exe and verify its legitimacy?

I wouldn't worry about a non-well-reputed anti-virus software's findings in comparison to other well established anti-virus vendors. Even with the reputable ones, it could be a false-positive. Vendors themselves sets the scan settings in VirusTotal and some may choose aggressive settings like, heuristics.
If you know the source of the app (i.e. the developer/vendor), you can compare the app's signature (MD5, SHA-1, etc) to the official release. You can see them in the Details table of the VirusTotal result. If it matches, then you know it is the same as the official release.
But, this does not solve the trust problem, if you do not trust the developer/vendor. The app could be malicious and seeing all greens on VirusTotal may mean nothing. Anti-virus software works based on 'virus signature'. If it is a new virus, none of the signatures will match. The next step is the heuristics and behavior analytics, and that works only so far and thus seeing all greens may not mean much for a very new virus (or a very rare virus) if it is good in stealth-mode.
It's true that VirusTotal shares samples with their security partners as mentioned by @nobody. If a file is detected by one vendor, all other non-detecting vendors receives the sample. But with so many false-positives, I don't expect a dedicated analyst to take a look at the file flagged by a non-reputable source. (My experience with them over the years is that it's normal to see 1 or 2 red flags from them.). But, if the file raises some flags through their automated internal tools, then an analyst would review. That's my guess though. But this article supports my guess, "The manual detection of viruses gave way to automated methods designed to find as many as 250 000 new malware files each day." Also, you can accomplish the same thing by using your preferred vendor's "submit a sample" link. Here is Microsoft's sample submission for example.
You can also search for these signatures in Google, AlientVault, IBM X Force, CrowdStrike etc. and see if there is any match. I just did this in Google and nothing came up. That suggests, this is either a brand new file or a custom file you made. If it is a custom ZIP, which I suspect, upload the main file (or all suspect executable), get its signature and for search that. You will see much more details (when first see, activites when run in sandbox, etc) in VirusTotal when you do that.
There are companies that specializes in analyzing malware but it will not be cheap.  You can try any of the well known anti-virus companies or an incident response firm like Carbon Black or FireEye and see how much they will charge you for a custom analysis.
If the cost is an issue, you can consider the following

Use CrowdStrike's CrowdInspect tool and see if it will pick anything suspicious on this app while it is being used.

Use AlientVaults free end point scan tool to scan your computer. It uses known IOCS (indicator of compromise) in its database contributed by many companies and individuals (open threat intelligence community)

If you are suspecting it is communicating with a malicious IP (like command and control server) and if that's all you care, you can listen to network requests from this app. If you're well versed in this, you can use free Wireshark tool. If you're not so much into this, then you can use easy to use Microsoft Sysinternal's free ProcMon tool. With ProcMon, just filter for the network event category & just for the process running for this app and monitor which IPs it is going (let it run for a week maybe). ProcMon can resolve the IPs to domain names too if you prefer (useless if resolving to a cloud provider like AWS). But, if this app is running other apps (like browser in headless mode), then you will need to listen all network events for all processes (which can be a tedious task) or first analyze what other processes it accesses to (by letting ProcMon to run with process events selection for let's say for a week). You can have someone do this part with ProcMon or Wireshark for much much less money b/c almost all security professionals and many regular IT people knows how to use these tools but very few knows how to analyze a malware executable and its code (very specialized task).


Server to server encryption: Key rotation over the air. Can it improve security?

With a proper TLS-with-AES session, the time needed for an eavesdropper to "decrypt information" would range in centuries, at least if the "enough resources" are limited to, say, converting the whole mass of Jupiter into energy. At that time I am pretty sure that the involved computers will have turned into a compact mass of rust, so the point is kinda moot. In a nutshell, symmetric encryption is not the weak point of TLS; arguably, properly used encryption has not been the weak point of anything in the last two decades (at least).

Nevertheless, for the truly paranoid who wants to get a warm fuzzy feeling of safety out of ritual cryptographic incantations, you can just negotiate a new handshake over an existing session, at any time you want. Both client and server can initiate that. See the TLS standard, especially sections 7.4.1.1 and 7.4.1.2.


Metasploit Ruby Scripting: Problem with framework.db.creds

Patch is available at https://github.com/rapid7/metasploit-framework/pull/7104. If you are using the Github repo, pull the PR in and test. Otherwise, you will have to wait till the patch is included in the Kali update or MSF Pro/Community versions.


Does it improve security to use obscure port numbers?

If you're already using high entropy passwords or public key authentication, the answer is "not really".  Mostly you're just getting rid of noise in logs.

  I worry about the unintended consequences of deviating from these recommendations.

It depends on what port was picked.  In Linux, by default all ports below 1024 require root access to listen on them.  If you're using a port above 1024, any user account can listen on it if there's not already a process listening.

Why does this matter?  Let's say you chose to set ssh to bind to port 20,000. If someone could stop the SSH process on a server (let's say they somehow found a way to crash the process), and had local access to that server, they could then run their own SSH server on port 20,000 before the service restarted.  Anyone logging in would then be logging in to the bad guys SSH server.

This isn't as big a deal as it used to be, since these days it's only trusted IT staff that are given login access to servers.  But still, it does have the potential for privilege escalation and other nastiness if an attacker gets a foothold on your server.

Other than being below 1024, there's nothing special about the number 22.  Largely it was chosen because SSH was a replacement for telnet at port 23, and 21 was already taken by FTP.  As long as you pick a port below 1024, the port doesn't really matter.

  Is this good practice or not? Should we use well known ports?

I wouldn't say I recommend it.  I also wouldn't advise against it.  As I said, it avoids a lot of noise in log files, but the benefits are largely limited to that.

For anyone interested in the background story on SSH, you can find it at: https://www.ssh.com/ssh/port


What does the android device name reveal?

The device name is constructed as follows on first use:

    // setup our unique device name
    if (TextUtils.isEmpty(SystemProperties.get("net.hostname"))) {
        String id = Settings.Secure.getString(context.getContentResolver(),
                Settings.Secure.ANDROID_ID);
        if (id != null && id.length() > 0) {
            String name = new String("android-").concat(id);
            SystemProperties.set("net.hostname", name);
        }
    }

Where ANDROID_ID is a random 64-bit number.

So essentially the device name is unique and does not change during the lifetime of the device. While it does not reveal anything about the device itself, it might be used to track the device.


Is DKIM needed for emails encrypted with OpenPGP?

DKIM and OpenPGP are orthogonal. DKIM proves that a given email really came from the mail server which is specified in one of the Received: headers of the mail. It does not give any guarantee as to the actual human sender; DKIM focuses on the path which the email took. DKIM could be a great tool against some classes of spam, in that mail servers could bo configured to reject all emails which pretend to come from a given domain but do not sport a valid signature proving that they did go through the domain outgoing server (this can thwart domain impersonating spams).

OpenPGP (for signed messages), on the other hand, does not care at all about what servers a given email went through. OpenPGP signatures are about validating the human sender. OpenPGP does nothing against spam. OpenPGP can also add encryption, for data confidentiality, something which DKIM does not offer at all.

Since OpenPGP and DKIM do not offer the same functionalities, and neither does what the other offers, then it can make sense to use both.


Firefox bug permits stealing encrypted passwords: How is this possible?

If you have no master password set, then the login passwords are always available. If you do have a master password set, then opening the Saved Logins dialog will prompt you for the master password. Without the correct master password, the list of logins will be empty and thus there is no password to copy.

The bug only occurs in this specific condition:

A master password is set.
You have unlocked your logins by entering the master password once this browsing session.

To be clear: if you have a master password set, and have not unlocked your logins this session, your passwords will still be protected and not be available through this bug.

Passwords are stored encrypted on disk, protected by a key derived from the master password. If you start Firefox for the first time, it will usually prompt you only once for your master password when it encounters a login form, or when you open the Saved Logins section. If you dismiss this request, the logins will not be available. If you however enter the password, the decrypted passwords will be available until you quit Firefox.

Normally, when you use the Show Passwords button, or if you right-click a login and chose Copy Password, it will prompt you for the password once again. Due to the bug, the password confirmation prompt was displayed, but the password was already being copied in the background.

The impact is very low in my opinion. Someone with physical access to your unlocked session can already obtain the password in other ways:

Visit the website, for example, https://stackoverflow.com/users/login
Observe that the login is filled in.
Open Developer Tools (F12), go to Console.
Execute: document.querySelector("input[type=password]").value
Observe the password.

Alternatively, you could go to the Network tab in Developer Tools. Press Login and observe the password being recorded. There are plenty of methods to obtain the logins if it is already filled in.

As for the commit that references the bug, the code defect was that an asynchronous call (masterPasswordLogin()) was not waited for. That is why the code to copy the password is already executed before the login prompt was confirmed. The fix is to wait for the prompt to be completed.

The original security advisory from Mozilla only stated that passwords can be copied without entry of the master password. Since then, this security advisory has been updated with the above clarification, and now reads:

  When a master password is set, it is required to be entered again
  before stored passwords can be accessed in the 'Saved Logins' dialog.
  It was found that locally stored passwords can be copied to the
  clipboard thorough the 'copy password' context menu item without
  re-entering the master password if the master password had been
  previously entered in the same session, allowing for potential theft
  of stored passwords.


There are many ways to secure cPanel and WHM. If you can control over the server you can enable to PINs under the security tab. If you have ConfigServer Security & Firewall installed you can limit the logins based on ip address, country or count. If you are a cPanel user, just don't save passwords in the browser. Use a password manager with a generated password for your cPanel account.


Yes, it's possible. Computers Alice and Bob both have one private key and one public key each.

Alice chooses a random token and encrypts it with Bob's public key and its own private key. Bob decrypts the token with its private key and Alice's public key, then reencrypts it with Alice's public key.

Upon receiving the original token from Bob, Alice knows that Bob must know Bob's private key, therefore it must be Bob. And since the token was decrypted with Alice's public key, Bob knows that Alice is in possession of Alice's private key, which means it is Alice.

And since nobody else except Alice and Bob are now privy to the random token that has been exchanged, both Alice and Bob may use it as the key to a symmetric cypher algorithm suitable for exchanging further communication (they might also use again RSA, but it's more expensive computationally):

  ALICE = Alice's public key; bob = Bob's private key

  Alice chooses K

  Alice encrypts with BOB,
  then with alice

                   ----> alice(BOB(K)) ---->

                                                Bob knows ALICE and bob,
                                                so can retrieve K
                   <---- bob(ALICE(K)) <----
                      (or just ALICE(K))
              (or even K, if K need not be secret)

  Alice gets confirmation

                   <---- AES256(K, MESSAGE[0]) ---->
                   <---- AES256(K, MESSAGE[1]) ---->
                   ...
                   <---- AES256(K, MESSAGE[N]) ---->

During such a conversation, K may also get refreshed from time to time.

Real life example (well, sort of)

In this example Alice and Bob are two friends and they both have the OpenSSL utility. They communicate through a public channel (e.g. their Facebook pages) where they can post binary files. OpenSSL actually can produce ASCII files that would be much better for this purpose, but let's keep as near the above as possible (in real real life we'd use some OpenSSL scripts that would automate the whole thing and work much better, or some tool that would wrap OpenSSL to do the same things with an easier interface).

There are some caveats that I'll mark with "VULN". See at bottom.

To begin with, Alice creates a RSA public/private key pair and extracts the public key. Bob does the same (his files will be named bob-*) (VULN-1).

openssl genrsa -out alice-both.pem 1024

openssl rsa -in alice-both.pem -out alice-public.pem -outform PEM -pubout

Now both Alice and Bob publish their public keys on their facebook page. Anyone can read them.

Now Alice wants to exchange a private conversation with Bob, maybe some files. Alice wants to be sure that Bob is cognizant of their source, and she wants Bob the be the only one to be able to read the files.

This can be done using asymmetric encryption only, but it would be too slow and inefficient due to size constraints and computational overhead. So they need to use symmetric encryption, and for this, a shared secret (above, this was called K), that only they know.

They do so by choosing a K, and communicating it over a secure channel. The secure channel is provided by asymmetric encryption over a public channel (facebook).

Bob being a gentleman, it's Alice who chooses a passphrase.

She does so by creating a text file with the passphrase...

echo 'the magic words are Squeamish Ossifrage' > phrase.txt

and encrypting it with Bob's public key downloaded from Bob's facebook page (VULN-2)

    openssl rsautl -encrypt -inkey bob-public.pem -pubin -in phrase.txt -out file1

Now, only Bob can decrypt the file. The problem remains how to make Bob sure that this is from Alice. Alice could cut "file1" in pieces small enough to be encrypted and send them all, but it's not necessary; she can sign the file with her private key.

    openssl dgst -sha256 -sign alice-both.pem -out file1.sign file1

Now Bob receives the two files. He first verifies the signature against Alice's public key (VULN-2 again).

    openssl dgst -sha256  -verify  alice-public.pem -signature file1.sign file1

and he gets "Verified OK" (if anyone else's certificate had been used, for example his one, he would have gotten "Verification Failure").

So, verified against the key published on Alice's facebook page, the "file1" is at least as trustworthy as Alice's facebook account.

Bob proceeds in decrypting with his own private key.

openssl rsautl -decrypt -inkey bob-both.pem -in file1 -out secret

Now Bob knows the secret phrase (it's in "secret") and can encrypt a document using that phrase.

openssl enc -in secret-document.txt -out secret.bin -e -aes256 -k "$( cat secret )"

or, equivalently,

openssl enc -in secret-document.txt -out secret.bin -e -aes256 -k "the magic words are Squeamish Ossifrage"

secret.bin is again posted publicly on Bob's page.

Alice on the other hand just runs the corresponding decoding command

openssl enc -in secret.bin -out plain.txt -d -aes256 -k "$( cat phrase.txt )"

and recovers "plain.txt".

VULN-1: Alice and Bob must be sure that nobody else has access to their private keys. They can lock them with a passphrase that needs to be entered for OpenSSL to access the keys, for example.
VULN-2: if Eve gains access to Alice's facebook page, or can induce Bob's computer to believe that some other computer is actually the Facebook web site, she can trick Bob into downloading Eve's public key believing it's Alice's. If Eve is capable of doing the same to Alice, she can pose with her as Bob. So Alice "talks" to Eve, using a format that Eve can decrypt, and Eve reencrypts it after tampering and sends it along to Bob, both ends being none the wiser. This would be a man-in-the-middle attack. That's why the authenticity of the public keys must be unquestionable.
Since neither Alice nor Bob have reason to use the keys they have published (they own the originals), once gained access to both Facebook pages Eve could replace both keys with others of her own making, and continuously monitor both pages in order to download any newly posted file and replace it with the appropriately decoded-tampered-and-reencrypted version. Since Alice and Bob aren't likely to verify their own files, and they haven't published the files' signatures (and even if they did, they might not notice they've been changed), they won't notice a thing. Not really likely to happen with something as public as a Facebook page, but in other scenarios the key distribution might be at risk. Of course, as soon as someone out of Eve's purview attempts to communicate with Alice or Bob and fails, the game's in the open.


When a web page is displayed in your web browser a local copy of the webpage is stored in your computer. The web browser reads this local copy. You can in fact alter this local copy and it will not have any effect in the copies displayed by other visitors to that web page.

What the plug in is doing is something like that, it alters what you see or type in the local copy of that web page. One way is to display an overlay of the password, another is to change the type of the input from password to text, there may be others but they are all local to your computer.

You may choose to send that information back to the server (by submitting the form) or not, but before you send it (or an automated script does it), it has no effect on the server or in what other users are seeing on the website.


In short, no you cannot convert NTLM to AES. NTLM is a hashing function vs AES, which is an encryption algorithm (see @MikeOunsworth answer for more on this).

To recover the AES version of the password, the Domain needs to be configured to store them as such and you'd recover them by dumping the ntds.dit (Active Directory User Hive backup). Then you can use secretsdump.py or similar tool to extract the AES versions. Now that said, you'll need Domain Admin (or equivalent permissions) to dump ntds.dit (from a Domain Controller), so PTH may not be needed if you have that level of perms, but you could do it nonetheless.

EDIT

Here's what each version looks like when recovered from ntds.dit

WAKANDA$:5136:aad3__LM-HASH__d3b435b54ee:f1e03f8f94__NTLM-HASH__f0c0df:::
WAKANDA$:aes256-cts-hmac-sha1-96:8941c28ac__snip__8a51adf13336b
WAKANDA$:aes128-cts-hmac-sha1-96:cbe71ab9b__snip__2dc21d6
WAKANDA$:des-cbc-md5:576_snip_bcec
WAKANDA$:rc4_hmac:f1e036ef8f__snip__69cf0c0df


Yes, but only if you provide the encryption key/passphrase used to encrypt the data.  Without the key, the data is inaccessible, and the device appears as (essentially) noise.


By reading your question, I think you are talking about log poisoning attacks.

For example, if you have discovered a vulnerability called local file inclusion (LFI), it could be possible to poison the logs that could result in code execution through log poisoning.

Let me give you some more details by showing some (very wrong) code:

<?php
  if (isset($_GET['file'])) {
     include($_GET['file']);
  }
?>

This code file include any file, execute it and display it in the user's browser. Now let's assume for a moment that the PHP open_basedir* is not configured.

https://www.somedomain.tld/index.php?file=contact.php

Now this would load the contact.php file which is located in the same directory as where the web pages served.

Now by changing the filename to something like this:

https://www.somedomain.tld/index.php?file=../../../../../var/log/nginx/access_log

In this scenario, let's assume that the log file is loaded and displayed in the user's browser. In this case it's already bad enough because you can basically load any file that the www-user has read access to.

Log Poisoning

Now let's inject some PHP code in the log file. This can be achieved by doing something like this:

https://www.somedomain.tld/index.php?file=<?php echo phpinfo(); ?>

Since this is an HTTP GET request, this will end up in the log file. This stage is called log file poisoning. Although the above request will most likely display an error, by re-reading the web server's log file, the code will be executed.

Code Execution

Since the web server log file is poisoned with the previously injected PHP code, but loading the web server's log file the following will happen:

PHP reads the log file.
PHP detects the PHP code in the log file.
PHP will parse the PHP code and parse its output to the user's browser, displaying the PHP info.

Where to go from here

Use your imagination where to go from here. Here are few things that come to mind though:

Try exec, passthru to see if you can execute commands (there is a difference beteen code and command execution)
Use the command wget to download a web shell or a reverse shell.

To sum things up:

Log files do not (should not) have the executable bit set.
Read access to log files is enough to execute code after they're poisoned (this requires LFI)
Web server logs are not the only log files that can be poisoned, and email could do the trick too.

= open_basedir is a directory restriction in PHP. When set, only files within the path of the open_basedir can be read.


I interned at JP Morgan last summer. They said their ATM's cameras were on all the time. It may vary depending on the bank though.


Is it considered as a DOS attack if I add too much data to a page so that it doesn't respond at all?

I would definitely call this a DOS attack.  More precisely it is an application layer DOS attack in that it doesn't malformed packets and other network layer denial of service tricks like small window sizes to be effective.  These are hardest to defend against because many DDOS protection products are looking for the network layer attacks.
I think in the DOS lingo, these would be called "heavy" requests as each legitimate request consumes server resources.  This CloudFlare article says it well:

Application layer attacks or layer 7 (L7) DDoS attacks refer to a type
of malicious behavior designed to target the “top” layer in the OSI
model where common internet requests such as HTTP GET and HTTP POST
occur. These layer 7 attacks, in contrast to network layer attacks
such as DNS Amplification, are particularly effective due to their
consumption of server resources in addition to network resources.


First, you should define precisely what kind of attack you are trying to defend against:

Do you fear attackers who spy on the messages exchanged between the sensor and the server, and learn the contents of the messages ?
Do you fear attackers who impersonate the server and talk to the sensor as if they were the server ?
Do you fear attackers who impersonate the sensor, and send fake requests to the server ?
Do you fear attackers who drop, duplicate, replay and reorder messages between client and server ?

A symmetric-only lightweight protocol which covers all of the above -- to some extent -- looks like this:

For any communication channel between the sensor and the server, there are two symmetric keys which both the server and the sensor know, one for data sent by the server to the sensor, and one for data sent by the sensor to the server.
Every message sent by either the server or the sensor is encrypted with AES in EAX mode.
EAX mode requires a non-repeating IV; the sensor and the server will use counters.
Each message contains the IV (counter value) for that message, followed by the AES-EAX encryption of the message.
For each communication channel, the sensor stores the current counter value for the message it sends, and the IV of the last message it received from the server over that channel.
When it sends a new message, the sensor increments its counter (for that channel), stores the new value, and then (only then) uses the new value as IV for AES-EAX.
When it receives a message from the server, the sensor checks that the new message uses an IV which is strictly greater than the last received from the server; the sensor stores that new IV and then (only then) decrypts and processes the message from the server.
The server employs the same techniques than the sensor (counter for the messages it send, saved IV from the last message from the sensor, and so on).

Assuming that counters start at 0, this means that the first message that the sensor will send will use 1 as IV; the second message will use 2, and so on. Similarly for the messages sent by the server. This enables the server and the sensor to detect replayed messages, out-of-order messages, and missing messages; what they should do in such a case is up to you to decide.

On EAX: combining encryption and MAC together with a given key is not completely easy. Reusing the same key for the encryption and the MAC is, theoretically, risky. An authenticated encryption mode such as EAX takes care of the fine details. As a fine bonus, EAX does not need uniformly random, unpredictable IV, as CBC does; it only requires IV values never to be repeated (for a given key), so a counter is fine -- as long as you can store the current IV value in a resilient way, and do it at the right time. Beware of an attacker switching the sensor off in order to force an IV reset !

On keys: I have talked here about bidirectional channels. You need one key per channel direction. This means two keys for the HTTP thing (one for requests, one for responses), and one key for the command channel, assuming it to be unidirectional (commands from the server to the sensor, no response from the sensor). If storing three 128-bit keys is problematic, you can store a single 128-bit key (a "master key") and dynamically rebuild the three keys from that, with a key derivation function. Since you are in a constrained environment, and EAX uses AES only, I suggest using AES for that too: using the master key as key, encrypt three fixed constant values (e.g. "0", "1" and "2") with a single raw AES invocation for each; this will yield three 128-bit blocks which will do fine as your channel keys.

On tamper resistance: I suppose that the sensors will be deployed "on the field", so an attacker may succeed in catching a sensor, opening it, and then trying to recover its logical contents. Unless the sensor is specially hardened against tampering (as a smartcard would be), this means that the attacker will be able to learn the sensor keys, and, from that moment, "emulate" the sensor as seen by the server. At a minimum, every deployed sensor should have its own keys, and the server will have to know the keys of all deployed sensors.


What are the requirements for private keys in Diffie-Hellman key exchange algorithm

IF (that's a big "if") the generator g and the public element from the peer can be assumed to be part of a subgroup of prime order, THEN it suffices for exponents to have size 2t bits, for a "security level" of t bits. In other words, 256 bits are fine.

Now if p is a so-called "strong prime" (i.e. p is prime and (p-1)/2 is also prime), then any integer modulo p (except 0, 1 and p-1) necessarily has order (p-1)/2 or p-1, and a 257-bit exponent is sufficient. In fact, it is overkill because solving discrete logarithm modulo p will be easier than that, academically speaking (but this is all far in the "technologically infeasible" realm anyway).

If you are using Diffie-Hellman with a truly ephemeral DH key pair, to establish a shared secret with a specific peer and never reusing that DH secret for anything else, then you can just assume the DH parameters to be fine, because, by virtue of discarding the private DH key after usage, whatever nasty tricks played by the peer will impact that key exchange only. However, if you plan to reuse the same DH key pair to make of DH instances (e.g. a TLS server with a "DHE_RSA" cipher suite, that renews DH key pairs only when the service is restarted), then you have to be more careful because peers may submit bogus DH public keys to try to extract information from your own DH private key, and use that to attack other connections.


Can a company see your old Google Searches

can they see any old searches made on my phone or personal computer from home?

Depending on the network setup, they could inspect your network traffic, get your login details and use it later. That would require you to install a CA certificate on your phone or personal computer, or to log in ignoring your browser warnings about invalid certificates. But logging private credentials can be considered a crime on some jurisdictions, so I doubt they would ever do that. But if they own the network, they can intercept your communications, steal your credentials, log back and see what you have.

But if you haven't installed any CA certificate on your phone or private computer, they cannot. That's exact the point of certificates: prevent any third party to read or change any of the requests you make.

  Or can can they only see what I’m actively searching while on my work computer?

Your work computer is different, as they usually have jurisdiction over it. If they have an interception proxy (common on enterprise networks), they can see everything. It does not mean they will see, but they have the capability.


What additional mitigations are necessary due to "Continue where I left off"?

If your site is that sensitive, set a max cookie lifetime of 15 or 30 minutes, rather than lifetime of the browser session.  And it's always buyer beware if they are accessing your site from a public location and they don't log out.

This is what I see on any financial site I use, from banks to credit cards to anything else.

Edit: I suppose that's not entirely true.  On some sites, they do allow you to "register your computer"... essentially, allow you to bypass some part of the identity check once (or rather, perform additional identity checks before) you've passed it once from that terminal.  You might be able to use this method to allow longer lived cookies on a registered terminal, if the user chooses to do so.  But when it comes to financial applications, you best bet is always to give the user as little rope as possible with which to hang themselves.  Other types of applications are more forgiving.


When do I need to install root certificate on the client trust store?

Installing the Root CA tells your browser to trust the Root CA, and any certificates signed (directly or indirectly) by the Root CA.
If you don't install the Root CA, then your browser will not trust the Root CA, and therefore it will not trust the Intermediate CA, and therefore it will not trust the Server Certificate.


Spoofing random browser information to defend against fingerprinting

It is not easy to determine if some seemingly random changes are really random or if there is some underlying pattern/bias which might be used to track an individual user. On the other hand it is easy to implement and verify that the fingerprint is the same for all users and can thus not be used for tracking. Thus it is probably more safe to hide the identity of an individual user by making all users look the same.

Apart from that several web applications include the browsers fingerprint into the session cookie to detect session hijacking done from another browser. When the fingerprint randomly changes the session cookie will be invalidated a lot which can cause lots of inconvenience for the user, like the need to re-login all the time or loosing the articles inside a shopping cart etc.

EDIT: based on the recently extended question it looks like that the OP does not like the approach by TOR since it restricts the possibility to personalize the browser, add the extensions one likes etc. This is true but I would argue that the OP is not really aware how tracking and fingerprinting can be done and is done.

Yes, the simple fingerprinting just looks at the request and extracts information like User-Agent etc which could be easily changed. But this kind of fingerprinting gives only a rough idea of the user anyway and cannot be used alone to track specific users. More interesting tracking can be done with behavioral analysis, that is check for installed extensions, check in which social networks the user is logged in and much more. I really recommend to read Technical analysis of client identification mechanisms which covers a lot of different ways to track the user but is not even complete.

Thus, the idea of Tor to look the same is not restricted to make only the request look the same, but also to behave the same. With any extension you add and with any site you log in or simply visit you will change the behavior of the browser and thus look different from others. Randomization of simple features will not help because somebody who is  really interested in tracking you knows which features can easily be faked and disregards these. Behavior instead can not be easily be faked.


Being told my "network" isn't PCI compliant. I don't even have a server! Do I have to comply?

At our office with connect to the internet through our cable modem
  provided to us by Spectrum Business.

  Our Treasurer uses a verifone vx520 card reader to process credit card
  payments. It connects via ethernet. We don't store credit card data.

It sounds like you fall under SAQ B-IP (and you will be amused that the mnemonic is that "SAQ B-for-Brick-and-Mortar"):

  SAQ B-IP has been developed to address requirements applicable to
  merchants who process cardholder data only via standalone,
  PTS-approved point-of-interaction (POI) devices with an IP connection
  to the payment processor

It sounds like someone did an external ASV ("Approved Scanning Vendor") scan on your known IP address and found the cable modem was, unsurprisingly, not up to snuff.

  Am I suppose to do something here? Is any of this applicable to us?

Yes, this is applicable to you, and many other things besides, all of which are outlined in the Self Assessment Questionnaire linked above.  And if your other office systems - desktops, printers, whatever - are also sitting on the same network behind that cable modem, then the requirements of the SAQ apply to those as well.  Things like patching and access controls.

For now, you will need to continue to work with your ISP.  They either need to update the modem, upgrade it, or get it to stop accepting connections from the Internet at large.

To break down those error messages for you:

Part 2b-1. 38173 - SSL Certificate - Signature Verification Failed Vulnerability

There's likely a self-signed certificate on that device, common for things like cable modems that need TLS but don't care about being trusted by random users.  (PCI cares, though, even when users don't).

Part 2b-6. 38628 - SSL/TLS Server supports TLSv1.0

When you go to a secure web site today, the newest you'll see is TLSv1.3, however most websites only support up to TLSv1.2 or TLSv1.1. TLSv1.0 is old, relatively insecure, and PCI declared it unacceptable to use a few years ago.

Part 2b-7. 38601 - SSL/TLS use of weak RC4(Arcfour) cipher (CVE-2013-2566, CVE-2015-2808)

TLS gets to pick from multiple algorithms; over time, weaknesses are found and individual algorithms get retired because of it.  RC4 got retired a few years ago.


Two factor authentication vs. user experience

I would not recommend omitting password. TOTP (what you call 2FA) is usally only 6 digits long, which is not recommended as strong enough. Another problem may be, that someone may have access to the persons phone for a short time. That is not a problem, if they would need password as well. The TOTP code would change quickly, so they can't write it down and wait till they will obtain the password. But it would be a problem if it does not, because they could just log-in immediately.


Are restrictive same origin policies necessary?

The CORS policy prevents a malicious website from gaining access to data on other domains. For example, foo.com should not be able to read the contents of bar.com via an ajax request or similar mechanism. If you set the Access-Control-Allow-Origin header to *, it allows any domain on the internet to send a request to your domain.

By default, when no Access-Control-Allow-Origin header is set, the default SOP applies and requests can only be made from the same domain.

DNS poisoning is irrelevant here, as the purpose of CORS is to prevent the leakage of information to other hosts. If the server uses HTTPS, you will not be able to man-in-the-middle the connection or impersonate the server, which doesn't gain you anything.


Technical security issues with proactively executing a phishing campaign targeting your own users

This depends on the kind of phishing attacks your users regularly fall victim to. If they fall victim to "please email me your credentials", but not to "click this link", you've got some very weird users.

Otherwise, if they fall to both, or if they just fall to crafted links, you can set a local server up and set a phishing site up. This will guarantee that no credentials leave your network, while still allowing the ultimate goal: to figure out who fell for it. This also means that you are a bit more in control as everything happens locally.

However, there are a couple of points that raised an eyebrow:

If some of your users use an external SMTP server, it means that down the line, you either have no SPF record for the domain where the mailboxes are, or you have an overly permissive SPF record. This is a major issue as it makes phishing emails trivial to craft in order to look "good" - all a phisher needs to find is an open relay. Consider adding a restrictive SPF record and telling your users to use your SMTP server (+ TLS or GTFO)
Why do you want to shame your users? Drawing statistics is a much better use of the data. Naming & shaming leads to people being singled out over something relatively trivial (or a mistake we could all make), leads to people leaving for greener pastures.


Which of AES modes are safer and faster for transferring data over the network?

You should always use an AEAD mode if you can, especially over the network. Crypto++ seems to support GCM, which is a good AEAD mode that has seen use in TLS 1.2. (There are others that are just as good, but TLS's "star power" lends GCM a lot of credibility.)

Importantly, AEAD modes authenticate "additional data." This is unencrypted data not included with the message, and is quite useful in network applications, as the additional data can contain a channel identifier of some kind (Either a TLS channel ID, a IP address and port combination, or something else appropriate to your protocol), and/or a timestamp. This prevents replay attacks by making the encrypted data only valid when it's sent over the original channel.


What are the potential consequences of evaluating user input with client side JavaScript?

The eval can't cause anything unusually or exceptionally bad for the server. The server needs to be protected from arbitrary data being sent to it from potentially malicious HTTP(S) clients anyways. However, the eval can be easily abused to temporarily deface the site (only in the user's browser). You may want to implement some kind of filtering on the eval to guard against such pranks.


Can Asymmetric encryption be used instead of modern authentication strategy?

I believe, you want a two-way authentication, when TLS server identifies and authorizes clients based on client certificate information. In fact, it is already implemented and is called mutual TLS authentication. See for "client certificate authentication in TLS" queries. For example, this article provides a good explanation of mutual TLS authentication: https://blog.cloudflare.com/introducing-tls-client-auth/

When properly implemented, there is no much need to implement additional authentication mechanisms as long as you can distinguish uinque clients based on their certificates (e.g. map certificate to a particular user account in users database). Microsoft IIS has a built-in mechanism to authenticate and map client certificates to SAM or Active Directory users and no username/password mechanisms are necessary.


PCI Compliance - Service Provider vs Merchant

Welcome to the strange world of PCI DSS compliance.

The merchant has a contractual relationship with its acquiring/merchant bank (aka acquirer) to comply with PCI DSS. How the merchant demonstrates its compliance with PCI DSS is up to the acquirer, it is based on card brand (Mastercard, AmEx, Visa, Discover, JCB) rules and is dependent on the number of transactions a merchant processes a year. The merchant will either need to provide a self-assessment questionnaire (SAQ) or have an on-site audit from an assessor (QSA) ending with a report on compliance (RoC).

Part of the merchant's compliance requirement is the compliance of its service providers (aka you) - this is PCI DSS requirement 12.8. In their contract with you, they should ask you to comply with the requirements of PCI DSS.

Together you will agree which of the 300 or so PCI DSS requirements are appropriate for you to comply with. And, based on your question, it would probably be those contained in SAQ A or SAQ A-EP.

If the merchant is being asked for a self-assessment questionnaire by their acquirer, they
have two option:

1. Ask you  to self-assess

Based on what you’d agreed with the merchant, you would complete the relative SAQ and give it to them. They may also ask you to have an external assessment - this is between you and the merchant.

You asked if you'd both use the same form of assessment and the answer is probably no. I'm going to speculate that the merchant is outsourcing everything to you, so they will probably complete SAQ-A for their acquirer. However, because you are hosting their website you may (as you say) need to fulfil the requirements in SAQ A or SAQ A-EP depending on which Authorize.net service is selected.

(Technically a service provider can only complete SAQ-D but what you would do if you had agreed with your merchant that the requirements in SAQ A-EP were the appropriate ones would be to complete "SAQ-D for Service Providers" (it is different to the merchant SAQ-D) marking all of the requirements that are not included in SAQ A-EP as "Not Applicable" - this approach is described in PCI SSC FAQ 1331.)

2. Be part of their assessment

Let's say you don't want to provide any evidence in the form of an SAQ or RoC to your merchant customer. The merchant would then have to include you in the scope of their self-assessment. So they would "visit" you and assess whether you were complying with all the relevant requirements. The merchant would then complete the relative SAQ and send it to their acquirer, you would not have to do anything. In this case the merchant would complete either SAQ A or SAQ A-EP for their acquirer.

If you - as a service provider - get fed up of people assessing you, you could have your own external assessment by a QSA, get your own RoC and then just give it to any merchant that asks.

There's one more wrinkle. Some card brands (notably Visa) maintain a list of service providers. If you want to get on their list you would have to enter a contract with the card brand directly which would require you to comply with PCI DSS. This would require you to send evidence of your compliance directly to the card brand, and then the card brand would determine whether an SAQ or RoC was applicable based on the number of transactions you process across all the merchants you are a service provider for.

I know, this is initially confusing but I hope that is useful.


Some things to consider when dealing with TLS as a protocol.

The payload of the communicating packet is encrypted. The 'dst' & 'src' packet attributes are not, which allows for any device within the network route to intercept your communication.
Numerous attack against the SSL & TLS protocol over the years have allowed for the following attack types (not a complete list);

a) cipher down grades - During the initial handshake of the
communication each party (prior to certificate verification) performs
an agreement on the cipher, hashing algorithms and additional
cryptography protections to use during the 'session'. In this
particular scenario if a MITM attack is in progress and weaknesses
exist, the chosen cipher can be negated to a weak cipher allowing for
further decryption/attacks (or as the pros term it 'crypto analysis')
b) weak random number - All crypto relies heavily upon truly random
numbers. Previous exploits here relied upon flaws within random
numbers when private keys are generated. This allowed for easily
factored cipher text attacks.
c) memory leaks - Most people are aware of the 'heart bleed' attack which allowed a specific handshake negotiation to trigger a memory leak of the affected device which lead to exposure of system accounts, private keys and whatever else was in the buffer at the time of the attack.
d) certificate spoofing - While not as common CA signatures on fake TLS certificate attacks have been known to happen. This usually is the result of a certificate authority getting attacked and having their root certificates stolen and used to sign fake certificates leading browsers to believe they are legitimate.

There are many, many more vectors of attack regarding TLS/SSL communications. If you wish to keep abreast of these 'confirmed' flaws go to the source.

That being said there are also mitigation strategies you can employ in your environment as well as protecting yourself, unfortunately it takes some research to do so.

In regards to mitigating flaws within the DNS protocol there are several methods of minimizing the possibility of a MITM scenario.

DNSSEC - Which employs cryptographic signatures and encrypted DNS queries between zones and clients.
Whitelists - Deny by default. Then configure zones to only accept updates from a whitelist of devices.
arptables - A method of filtering layer two protocols such as DNS & DHCP.

While that is also not a comprehensive list of mitigation strategies for a server/client configuration of DNS queries and zone updates it should give you some information with which to start.


What measures can be taken to make a site safe again after a hostile service worker is installed in users' browsers?

From your link:

  Installation is attempted when the downloaded file is found to be new
  — either different to an existing service worker (byte-wise compared),
  or the first service worker encountered for this page/site.

and

  If there is an existing service worker available, the new version is
  installed in the background, but not yet activated — at this point it
  is called the worker in waiting. It is only activated when there are
  no longer any pages loaded that are still using the old service
  worker. As soon as there are no more pages to be loaded, the new
  service worker activates (becoming the active worker). Activation can
  happen sooner using ServiceWorkerGlobalScope.skipWaiting() and
  existing pages can be claimed by the active worker
  using Clients.claim().

It sounds to me that the legitimate site should be able to replace the malicious service worker with a harmless one, once your site is visited again. Of course, you probably can't do anything about it until they come back to your site.

That said, there could be methods that I'm not aware of that allow the malicious service worker to prevent updates.


How to use Burp macros to pass parameters to intruder

This can normally done by macros and session handling rules. As I understand it you have three requests:

Fetch CSRF token
Post user name
Post password

The first step is to reproduce these in your browser, with Burp configured as a proxy.

Then create a Macro with requests 1 and 2. In the Macro Editor, select request 2, and click Configure Item. If the CSRF token is a hidden field, it should have automatically detected this, and in Parameter handling you will see something like "csrf_token - derive from prior response". If not - you may need to configure this manually. You may need to do Configure Item on request 1, and define a custom parameter location. You can then use Test Macro to confirm this is working.

Next, create a Session Handling Rule. Set the scope to cover the URL and path for request 3. Add an action that is Run a Macro, select your macro, and leave this option enabled: "Update current request with parameters matched from final macro response".

Then send request 3 to Repeater. When you click Go, the macro will run, and you should see your request be updated with new token values. If not - use session tracer to work out what is going wrong.

Once it's working in Repeater you can use other tools like Intruder, Scanner, etc.

Your idea about fuzzing both requests in a chain is interesting. I can't think of an easy way to do it, but that would be an interesting extension to write.


All traffic happens within the TOR network, and there is no normal exit-node involved.

There is a node serving as rendevouz point, where your circuit, and the circuit of the hidden service meet. But the messages itself are end-to-end encrypted, so unlike an exit-node(used with an unencrypted protocol such as http), it can't listen in on your communication.

For a detailed description of how TOR hidden services work, check: Tor: Hidden Service Protocol


Hmmmm.

On the one hand you want to store the data inside a file format which is a known malware propagation vector and send it on a round trip to the client, or on the other hand you want to embed this file inside another file which is also a known malware vector. Leaving aside the question of whether the content will actually be editable when embedded in the PDF file, it looks to me like you have increased the attack surface.

Speaking with my programmer hat on, if I want to send and receive tabular data, then (any of the) MS Excel format(s) would be well down my list of choices for a container. In addition to the known dangers of malware, it is horrendously difficult to parse and process compared with CSV, JSON, XML.

OTOH I recognize that for most mortals, trying to edit an XML or JSON file must seem like rocket science (but CSV isn't that much of a pain considering you need them to maintain the appropriate encryption for the return trip). But if its small amounts data then why not just use an online form over HTTPS which solves the problem of how the user manages the clear text as well as the issue of proprietary file formats and the issue of malware injection.

Maybe sharing an online spreadsheet is not an ideal solution.


Can (and should) TLS be strict about the ciphers it supports?

Please don't confuse TLS negotiation with a bazaar were all parties negotiate and renegotiate until they find some common solution. Since every message needs time for delivery that would be much too slow. Thus there is only a single offer by the client which includes all ciphers the client is willing to support, in the order preferred by the client. If the server has support for any of these ciphers it will pick the best based on servers or clients preference. If there is no overlap the negotiation fails permanently.

In your case the server accepts the following ciphers (as determined by this tool):

ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
AES256-SHA256
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA

Since you only offer a single cipher DHE-RSA-AES256-SHA and this cipher is not supported by the server the negotiation fails.


Why is Google Chrome blocking raw SWF playback?

This behavior is apparently related to how Flash Player is a click-to-enable feature in Chrome now (Chrome Help forum discussion on this behavior). If you visit a SWF directly, it will not ask you to click-to-run, it will simply download it instead.

If you were to go to chrome://plugins/ and check "Always allow to run" it would play the SWF as previously normal in the browser directly, without the HTML wrapper. The fact it will not prompt you to enable it does not seem to be a security decision.

  Is there any security reason why the former case should be treated differently from the latter?

All that being said, yes, I think there would be.

Imagine there was a website, say an old forum, which allows you to upload an avatar. It is expected you will upload an image file, but the file type checking is poor, and an attacker uploads a malicious SWF file instead, to perform an XSS attack on the site admins. Now, the HTML being generated for this avatar, might look something like this:

<img src="http://example.com/user/123/avatar.swf" />

That won't run as a SWF, so no HTML for the attacker. So instead the attacker tricks the admins into clicking a link to http://example.com/user/123/avatar.swf where the SWF does load, and that SWF performs the XSS attack as the privileged users, and PWNs the site.

Of course, such a risk is not unique to Flash Player. A similar attack could be performed with JavaScript inside an SVG instead of a SWF.


Does a 'reset password' website facility give away too much information?

You already answered the question youself: The only way to not give away any information is to display a generic "A message has been sent to a@b.c" after requesting a passwort reset, even if there is no account associated with that email. See also this question for additional details.


SQLmap non authorized user, but the url works in browser

The URL works in the browser because your browser sends your cookies for every request you make.

You need to tell sqlmap to send your cookies by adding this option in your command line:

--cookies="JSESSIONID=ID.testsan; JSESSIONIDSSO=12345678"


If code is served by a large Content Delivery Network (CDN),  like Google's CDN, then it is more than likely that you will be hacked through other means.  Large CDNs have a lot of money to spend on security, and a CDN is unlikely to be a weak point in your own infrastructure.

Once a site hits a certain level of popularity, then it needs to serve static content from a CDN. Consider the following post:

Why should I use Google's CDN for jQuery?

The good from a CDN outweighs the extremely unlikely possibility of compromising a well-maintained server that is distributing static content.  That being said,  I've found a major flaw in an Akamai product...


Does hashing a file consider its digital signature as well?

Update
I've just understood what you're actually asking. I'll leave the old answer below, just in case someone needs that.
 The Answer:
The signtool application allows you to specify an option named 'verify'. You don't need to get access to the encrypted hash value, it will verify it for you. It probably isn't possible to do it manually if you prefer. Maybe when you use the verbose mode at the signing time it will show you the hash value, in case you really want to see it.
Signing only the binary sounds like a good idea if there wouldn't be any metadata files/ configuration/ anything that doesn't compile. I didn't use Windows for a while, but maybe you can use makecat instead of signtool, I think it should allow bigger app sizes. Hope this helps.

 The old answer, explaining technical things:
It looks for me like you are trying to understand how digital signatures work and how you can implement the mechanism. If I'm wrong, please rephrase your question and try to explain step by step what you are doing, as for an algorithm pseudo-code. I will try to explain what I think you want to know.
When you sign a document: you can read the document (so it's not encrypted), you just want to make sure it's valid so you look for its signature and stamp. The signature and the stamp tell you if the document is valid/ verified. In the same way, when you use digital signatures, you always send 2 pieces of data: the executable in your case (not hashed, not encrypted, you can "read" it) plus the signature. So you have the executable, you don't have the signature.
To create the signature:

hash the executable. The executable is usually large so it would take a lot of time to encrypt it. Luckily, if you use a good hashing algorithm, there is an infinitesimal probability that 2 files will give the same hash string. So you can be sure enough that the hash represents your executable (even if it's just a meaningless string) and use it instead of using the whole executable further in this process.
generate a pair of private-public key. Your certificate will contain the public key and the private key must be kept secret. The nice thing here is that you can always encrypt with any of the public key or private key and decrypt with the other one. Never in a different way or with a different key. So if you know for sure that the public key belongs to someone (the certificate is trusted), then if they encrypt something with the private key, then you can decrypt it using the public one. If anyone else encrypted the data, because the private key is secret and they don't have access, whatever key they generated they use, you won't be able to decrypt it.
encrypt the hash with the private key generated at step 2. The value obtained here is your signature.

Now that you have both the file and the signature, send them to the other end or use them however you want. Once the information is received on the other end, how do they verify that it's valid? They have the document, they only want to be sure it wasn't changed by someone else. They also have the signature. So they follow the following steps:

decrypt the signature value using the public key (the certificate). If they cannot decrypt the value, then someone forged the signature (they changed that value with another one). If they can decrypt it, then they know the signature is the valid one. After decrypting, they obtain the hash value of the executable (step 1 above, when creating the signature). They know this hash value identifies the valid executable. This is the source of truth.
hash the received document (the executable) with the same algorithm as used when creating the signatures. When using a good hashing algorithm, no matter how many times you will hash the same document, the obtained hash value will always be the same. So if the document was not changed, the hash value will be identical with the one obtained at step 1. If they are not equal, it means that now when you hashed the received document, the hash value was different so the document was modified/ replaced by someone else. So you cannot trust it.
verify if the 2 hashes are equal (if they're not, as explained at step 2, the document is not the true one, it was modified by someone else). If they are equal, you can trust both the document and the signature.

This steps should also answer you how you will have the hash values being equal and how will receive the hash value from the signature value.
One last thing, please use secure algorithms, such as SHA-256 instead of SHA1 at the very least and eventually (not really necessarily) EC instead of RSA.


How to protect files (cron files) frome being executed by everyone?

Are these cron files going to be executed by root or are they going to be executed by a specific user such as apache? Normally I either log into a specific user (bob) and then run "crontab -e" to edit Bob's crontab. For these cron jobs to run, you just need to ensure that bob has execute writes to the script in question. However if these are going to be more administrative scripts for apache or root, then you may want to just put them in "/etc/crontab". From here, you can set how often the script runs and what user should run the script. Then just be sure whatever user you set to run the script has the appropriate rights to execute it. So if only root needs to run it, just chown the file to root only and you can 744 it so only root can execute the file.


Is an authenticated server seeing the plaintext password a serious problem?

As others have pointed out, client-side hashing doesn't really solve the problem, since the server still sees something that can be reused to authenticate (via a pass-the-hash attack). It's still better than passing the plaintext password, since people reuse passwords (but not salted hashes) between sites/services, and even when they don't they often use similar passwords (/password-choosing systems/etc).

BTW, this isn't just a server security problem. TLS interception (by client-side network security devices) is getting annoyingly common, and any device that does interception also has access to the passwords or hashes.

Fortunately, there's a solution: asymmetric password-authenticated key exchange (PAKE) allows authentication without exposing or storing anything password-equivalent on the server (or to an interception device). Secure Remote Password (SRP) is the best-known and most popular PAKE protocol. There's also a new PAKE protocol proposal, called OPAQUE that looks even better (though I want to see the crypto community beat on it for a while before I'd use it). Matthew Green has a good summary of this here.

Unfortunately PAKEs aren't very widely known or used. IMO, this really should be the standard way of doing network authentication.

Oh, and there is one big limitation: if this is implemented in server-supplied JavaScript, someone with sufficient access to it (or a TLS-intercepting box) can modify the JavaScript that's sent to the client to leak the password. There are ways to improve this somewhat (e.g. with subresource integrity), but even without those PAKEs at least narrow the vulnerability.


Should login/refresh authentication routes return new tokens if an existing, valid token is present?

Use Case

Lets say you have two endpoints /secure and /token

Hitting /secure with a valid access_token, returns 200 Success

Hitting /secure with an invalid access_token, returns 401 Unauthorized

Hitting /token with a valid refresh_token, returns a new access_token and refresh_token and this should remain consistent, regardless of wether the access_token is valid or invalid.

Refresh Tokens Lifecycle

It is best to invalidate the previous refresh token. This is because you do not want more refresh tokens then there needs to be. It is very important that the refresh token is stored securely if it is going to remain valid for a long time.

Access Tokens Lifecycle

Usually the lifecycle of the token is determined by its expiration date.

If it was a requirement to invalidate old access tokens, then you would have to persist an identifier for them, and check that each time you received a token.

This removes the stateless nature of using JWT in this way, but eliminates the same user having multiple access tokens, the reuse of a previously blacklisted token, or replay attacks.

Design Concerns

In this architecture, you want a separation of concerns between the access_token and refresh_token, wherein the refresh_token is uses for (re)authentication and the access_token is used for authorization.

This means that if you do blacklist access tokens it should be handled by the /secure endpoint, because only it is in charge of its authorization (who is allowed to do what).

The use case for refresh and access tokens using JWT, avoids the need for cookies, allowing authentication and authorization with different clients: SPAs, Mobile Apps, Web Apps, Desktop Apps, other servers etc. that may not have the use or access to cookies to persist session data.

If you stick strictly to the design pattern, then you would avoid cookies all together. If you use cookies, the the answer to your question is: you probably shouldn't use cookie when hitting /token.

If you use the cookie in /token you could end up not creating a new access token when an old one is about to expire and the call was intentional, or have some complex logic to determine when to generate a new access token. Or even worse, not use the JWT access token to determine its own lifecycle.

Appendix

For checking the time based validity of the JWT access_token:

I recommend you utilize the "exp" claim in the JWT. This would be a good baseline determining factor to expire the tokens. Referenced in Section 4.1.4 of RFC 7519. But if you are putting the token inside of a cookie, you could also have the cookie expire after a certain amount of time

For blacklisting certain access_tokens:

Section 4.1.7 mentions the "jti" claim which could be used for black listing tokens with certain identifiers.


How can I know that whoever called me is my cellphone service provider?

First of all, it's pretty much always the right thing to refuse to reveal private info about yourself or your account to someone who calls you when you aren't expecting the call.

It's easy to spoof an originating call number - I've got a scammer calling me every couple days with the same message, always from a different number.

Could it be a scam?  it's possible but there's not a lot of information to go on.  Unfortunately there's not a lot that either of you could do if it is indeed a scam.  The best thing from your perspective is to generally reply "I don't give out info to people that call me.  Give me your case number and I'll call you back at the number I have on file."  If it is indeed Alpha, they'll be fine with you calling back.  If it's not, they'll realize that you won't bite and may quit bothering you.  (or they may try something else.  they're scammers after all.)


OpenSSH windows 10 user's password not configured

By default OpenSSH does not allow empty passwords, as you can read in manual page for sshd_config.

PermitEmptyPasswords
When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings.  The default is no.

This is reasonable for remote login. Unless you change this option, or set a password for your user, you should not be able to use SSH to log in to your system.


Why isn't a client-side password complexity check considered secure?

You’re assuming that the check is bypassed on purpose. It could be the case that someone is using a browser which fails to handle the script properly or with scripts disabled, possibly even without knowing this.

You seem to have a reason for people to use strong passwords. If you do so, why accept that people can bypass it?

Client-side validation can be helpful from a usability perspective, but if you decide that a minimum password strength is required, you should enforce it by implementing it server-side.