One great product I like to use is Nessus.

Nessus has plugins available to both import existing nmap scan results and launch nmap scans directly. I like the reporting features of the tool which will output a nice PDF report for you.

See this link for more information.

Another alternative I like to use is the Metasploit framework. While renowned as an exploit framework, my favorite function of Metasploit is actually it's database. I use it to gather the results of my various scans and other activities during a penetration test. You can import nmap and other scans into the framework and view the information in it there. It doesn't have a pretty interface, but it's functional and works well.

Both the tools I mentioned might be a little heavy to use just as a nmap scan viewer. For something a little more lightweight, just share the results in the human readable output in something like Dropbox, not as pretty but just as functional.

You mention features like automatically drawing network maps based on scans. The zenmap GUI utility, usually packaged with the official nmap distribution actually has that feature. I have not used it extensively but you might want to give it a shot.

For comparison of two different scans of the same host, try ndiff, which again comes packaged with the official nmap install.


Why don't you try and let us know ?

From what I understand, it seems like you can ; everything depends on the vpn and AD settings :

if VPN only allow "registered" machines and your PC is not : you can't
if VPN does not restrict "inbound" machines, then I guess you can.
now the most important thing is the AD settings :

if access to a given ressource is limited to specific computer accounts, then, though you could be able to authenticate via VPN, you won't be granted access to that resource ;
if access to a given ressource is granted primarily based on user accounts, then you won't have issues using your home laptop.
add to that numerous other combinations....

Ask you system admin for more information about the company policy and your VPN software settings.

On a more technical level, msdn says :

  When a computer accesses the network, this means that system services running on the computer in the LocalSystem context are accessing the network resources.

Here none of you services running under LocalSystem context has access to your office network...only the VPN software. So unless specific VPN and/or AD settings are in place, you won't be able to access the company network.


The evil twin attack works because with most versions of WPA there is no validation of the AP. When connecting to an AP a system authenticates trusts that the AP is what it says it is. This isn't a good design frankly, however we are stuck with it.

WPA enterprise allows the use of certificates for verification of both AP and connecting system, however it really isn't a viable solution outside of companies which control their infrastructure.


I guess it depends on circumstances.

My worry with what you have described above would be that if you're not directly hitting your public IP space (relying on your firewall set up to drop anything not coming from your DDoS protection service), you're trusting that no vulnerabilities or mis-configurations exist within your firewall.

The set up you describe is assuming that any attacks would be coming through the route visitors take which is by no means certain. You want to assume that attacks will be coming at you via all possible means.

If the external vulnerability scan is designed to test your DDoS protection service, well ok but I'd also make sure to scan the public IP range as well.
I'd also question the wisdom of running a vulnerability scan against a 3d party service, though there might be some mileage in this to confirm things like which TLS cipersuites are supported and so on.

To answer the question directly; I'd want an external vulnerability scan to hit all of my external attack surface. From what you've said it sounds like you're missing some external attack surface to me.


The only way to make "sure" data cannot be regenerated is to use the writing "random data to entire disk" method. The LUKS header is just a "road map" to the data's encryption, loss of it makes it harder but not impossible to reconstitute. All encryption should be equal to the threat level one experiences on a certain machine.


The following anecdote does not have a general value:

In 1999, I took the source code for PGP (not GnuPG, still in its infancy), version 5.5, and compiled it on my machine (which was an Alpha running NetBSD, i.e. a rather "normal" Unix system). PGP's source code had been available for quite some years, and it was often touted as necessarily secure since it was open source.

Of course, I almost immediately encountered bugs. I looked at the source, and it turned out that:

The code was using the char type as if it was unsigned, and, as such, was completely incapable of correctly processing any character beyond the 7-bit ASCII set. It was so throughout the code.
The source code was several hundreds of source files, in more than 30 sub-directories (and sub-directories thereof).

So I came to the conclusion that despite being a high-profile target, with source code open for inspection for several years (the source code had even been printed as a book to work around the US export regulations of that time), nobody actually bothered to look at it (or those who did, did not possess enough knowledge in C to do it correctly).

The code did not make it easy to be audited; auditing code is already a quite boring endeavour that unpaid amateurs are unlikely to tackle on their own accord. It is much more interesting, for the amateur, to rewrite the whole thing from scratch, which is exactly what occurred (with GnuPG).

While I do not believe, generally speaking, in hordes of unnamed amateur reviewers who audit code simply because it is there, there are projects which gather a bit of review, mostly because of people who want to modify the project to suit their needs. Therefore, malicious alterations of security tools are a risky thing. What you will find in all projects, open source or not, security-related or not, are bugs, some of them being exploitable into behaving to the advantage of third parties (i.e. vulnerabilities).

The plausible way to inject a backdoor in open-source security tools is to make an honest-looking implementation or design error, in particular when dealing with PRNG (there have been some allegations, apparently unfounded, of such a backdoor in OpenBSD; see this answer; the backdoor was not there, but everybody took the thing seriously, because it is plausible).

On a pure theoretical basis, external audit can find out all backdoors exactly as much as it can find out all bugs in the audited code -- i.e. it cannot.


Are SSL browser sessions kept alive across requests?

TL;DR: HTTP sessions and SSL sessions are different entities and there is no mapping from one to the other.

Onto the specifics...

  When a client requests an SSL web resource via a browser (ie: a login request) and then follows up with additional requests are all the requests executed in the same SSL session?

Either the server or the client can terminate an SSL connection, but, for performance reasons, existing sessions are reused when possible.

  do servers track session state across these requests solely through cookies which are encrypted over the SSL protocol or is there any functionality provided through SSL where servers know that the initial request came from the same browser as the following requests

Cookies are typically the sole mechanism of session maintenance when communicating with a browser. Alternatives can be session IDs passed as hidden fields or sessions managed by custom JavaScript existing on the page. In fact, clients can multiplex multiple sessions over a single SSL connection. The one exception to multiplexing sessions is when mutual authentication is used. When this occurs, the client is authenticated during the TLS handshake. Establishing identity isn't the same as establishing a session, but they are certainly related.

  If it's just via encrypted cookies what is to prevent someone from spoofing the cookie value somehow and making a request with that spoofed cookie thus impersonating the original user?

You are referring to session hijacking. Some strategies that are used to prevent session hijacking are choosing a difficult to guess session ID (long and random is generally best), only passing the session ID cookie via SSL to prevent network snooping, and not allowing the session ID cookie to be accessed via JavaScript. Unfortunately, despite all of those defenses, Broken Authentication and Session Management continues to be the second most common security flaw according to the OWASP 2013 Top-10.


Possible to use a YubiKey in HSM mode to secure a Windows CA infrastructure?

Technically no, although it depends on what you mean by "secure".

Usually, when using a HSM for a CA, we mean: the CA private key (usually RSA) is generated, stored and used within the HSM, and the HSM will commit honourable suicide rather than letting that key ever exit its entrails. Up to the tamper-resistance of the HSM and how bug-free its firmware is, this ensures that even if the host machine is fully hijacked by an attacker and/or the attacker has physical access to the CA machine, then the attacker will not obtain a copy of the private key. At best he will be able to use the HSM to generate arbitrary signatures, but if the HSM is physically recovered then the attacker can know longer use the private key.

YubiHSM does not do RSA or DSA or any other algorithm relevant to asymmetric cryptography. YubiHSM is symmetric only (AES...). Thus, if you used it for a CA private key, then it would have to be along these lines: the RSA private key would be stored encrypted, and the symmetric key stored in the YubiHSM. However, when the private key would have to be used, it would first be loaded and decrypted in the RAM of the host machine, and that machine would then use its CPU to generate the signature.

I am not aware of any existing driver (Windows CSP, PKCS#11 driver...) which would make the necessary glue, but, in any case, it would void much of the interest of using a "HSM" since it, by nature, allows the private key to live outside of the tamper-resistant hardware.

YubiHSM is meant to support things like one-time passwords, not X.509 certificate authorities. A cheap alternative to a full HSM would rather be a smart card: that kind of hardware includes cryptographic accelerators which allow for efficient generation, storage and usage of asymmetric key pairs.


How I can read and handle MS Office documents, such as doc/ppt files, securely?

There are a number of ways that you can deal with files that can be malicious depending on the amount of time and expertise that you want to invest. Here are a few ideas and suggestions:

Anti-malware product

This is essentially the bare minimum. Have some form of anti-malware product on your system where you can force a scan of the file and see what it says. This is typically great for known malware families and will give you a good indication

Best practice based on how the file was received

Did you expect to receive the document? Who has it come from? Are you being asked to enable active content when the file opens? Is it in a password-protected archive with the password in the body of the e-mail?
These are all common questions we can ask ourselves when receiving files (especially via e-mail). In many cases, a malicious attachment will be an unexpected / generic e-mail from someone which you weren't expecting.

Use a Sandbox

Sandboxes allow you to see the behaviour of the file without opening it in your environment. These typically do a deeper scan of the file than you will get with on box anti-malware products. There are a number of cloud sandboxes that you can try:

SophosLabs Intelix
Hybrid Analysis
Joe Sandbox

A word of caution here; beware of submitting private files to free-to-use services. If you are not paying for the service, your file will most likely be shared among the community. This is of course great for malware samples, but less so for confidential information.

VirusTotal

Finally, VirusTotal gives a good representation of what the industry as a whole knows about files. You can also upload samples to get them scanned by multiple vendors at once. NOTE: The above caveat about privacy applies.
Here you have to make your own decision, do you believe a file is malicious if 1, 10, 20, 50 vendors mark it as malicious?
As you can probably tell there is no one size fits all answer to this question.


I assume that you're using PGP (as in, any program that implements the OpenPGP standard, such as GnuPG). That's the de facto standard for exchanging encrypted or signed email between people who aren't in the same organization.

When an email has a valid signature, verified against a public key, that proves that the message was sent by someone who has the private key corresponding to this public key. This is only half the battle to know who sent the email: the other half is knowing who the public key belongs to.

If you send your public key to your correspondent, they can verify that it matches the key used to sign the email. You need to do that. You can send it as an attachment to an email, and email software that supports PGP often has an option to make this convenient (something like “attach my public key”). If your email software doesn't have this option, you can use your PGP software to export your public key, for example copy-paste the output of gpg --export JORGE@example.com (replacing JORGE@example.com by the email you used in your key).

That allows your correspondent to verify the signature, but it may or may not satisfy them that you are who you say you are. To satisfy that, you have to allow them to relate that public key with what they already know about you. For example, if they have your phone number, you could tell them to ring you, and then compare your public key's fingerprints — this is a short sequence of digits and letters that is unique to a public key. Your PGP software can display your key's fingerprint (e.g. gpg --fingerprint JORGE@example.com). Another method is to have someone that both of you trust sign your key. That is, Charlie (some guy you both trust) comes and verifies that the key is yours (by whatever means), and then uses PGP to emit a “certificate” that says “this key belongs to Jorge”. Such certificates form a web of trust.

You can upload your key to a key server for convenience, but unless you're part of an organization that uses a key server, that won't do much good. Putting a key on a key server lets everybody know “there's this key, and there's a claim that the key belongs to Jorge”. But it doesn't prove that the claim is true: anybody could upload any key to the key server. You still need a way to relate the key with some identity of yours, i.e. to include your key in a web of trust.


Can a Meta Tag be Spoofed? (Is a Metatag Sufficient to Declare a Page is Protected?)

Anything provided by the client to the server can be altered by the client, including any HTML content/tags.

Look at products like Burp Proxy to give you an idea about the power available to the client. It allows you to manually intercept responses then inspect and edit them before sending. It's a very common tool for hackers (and security pros) to use.


Should Access-Control-Allow-Origin need to be domain specific

Your server side code should read the Origin request header and if it pattern matches one of your domains (http://*.mycompany.com) then you can return Access-Control-Allow-Origin: <domain> where <domain> is the actual Origin given in the request.

So if your request header is

Origin: http://foo.mycompany.com

this will match http://*.mycompany.com

so you set

Access-Control-Allow-Origin: http://foo.mycompany.com

for this response.


Profile applications from traffic analysis

You can use Wireshark to extract conversation statistics from the packet captures.  This information can then be sorted through to determine which ports are used regularly:

This screen is from the Wireshark Statistics->Conversations menu items.  It also has a "Copy" button which will allow you to get this data as CSV; you could then extract destination ports simply:

gawk -F, '{print $4}' convo.csv | sort | uniq -c

or do more complex analysis based on source and destination.  Personally, if I were doing it, I'd load the CSV into a sqlite database for ease of querying seven ways from Sunday.

You can also automate the extraction of the conversation statistics by using tshark to cut your workload - less clicky clicky, more worky worky.


OpenSSL GENERAL_NAME:bad ip address set in [alt_names]

[alt_names]
IP.1 = ec2-5-43-58-857.us-east-2.compute.amazonaws.com

IP.1 expects an IP address, i.e. something like 10.11.12.13. You've given a domain name instead. In this case use DNS.1 not IP.1.


Someone tried to log into my mail - what do I do?

Change your password. Keep a strong password. Change your security question as some one close to you can easily guess the answer and get the access to your account.


Token-based authentication - Securing the token

The "authentication token" works by how the server remembers it.

A generic token is a random string; the server keeps in its database a mapping from emitted tokens to authenticated user names. Old tokens can be removed automatically in order to prevent the server's database from growing indefinitely. Such a token is good enough for security as long as an attacker cannot create a valid token with non-negligible probability, a "valid token" being "a token which is in the database of emitted tokens". It is sufficient that token values have length at least 16 bytes and are produced with a cryptographically strong PRNG (e.g. /dev/urandom, CryptGenRandom(), java.security.SecureRandom... depending on your platform).

It is possible to offload the storage requirement on the clients themselves. In the paragraph above, what "memory" should the server have of a token ? Namely the user name, and the date of production of the token. So, create your tokens like this:

Server has a secret key K (a sequence of, say, 128 bits, produced by a cryptographically secure PRNG).
A token contains the user name (U), the time of issuance (T), and a keyed integrity check computed over U and T (together), keyed with K (by default, use HMAC with SHA-256 or SHA-1).

Thanks to his knowledge of K, the server can verify that a given token, sent back by the user, is one of its owns or not; but the attacker cannot forge such tokens.

The answer you link to looks somewhat like that, except that it talks about encryption instead of MAC, and that's:

confused;
confusing;
potentially insecure;

because encryption is not MAC.


Can my phone be located (e.g. by emergency personnel) when I use a VPN?

Phones can be localized by various means:

GPS sensor
Wireless networks in range: Imagine you drive through a country and for every point on the map you store the wireless networks that you are receiving a signal from. Later when you try to locate yourself, you can query the map with the networks you are currently receiving and find out where on the map you are located. This is actually what google etc. do and how phones can also be approximately located even while being indoors.
Cellphone towers. Your provider always knows to which cellphone tower your phone is connected. This gives a (compared to GPS rough) estimate of your location since the provider knows where its own towers are located. With multiple towers and simple triangulation the estimate can be further improved. With whom the providers share this information I don't know.
Your IP address: There exist geolocation databases for ip addresses, that map an IP address to its most likely geographic position. When you are using VPN, your public IP address changes to that of the end point you are connecting to. In other words, if you login to a german network with VPN, web sites and other online services seeing only your IP address will believe you are located in germany.

The first three methods are completely unaffected by  the use of a VPN connection. And these methods are what the "emergency services" would most likely use to locate you. The fourth method basically helps your online anonymity, but that's about it. Your entry point to the network is still a cellphone tower, your GPS is still functional and your phone can still curate a list of nearby wireless networks, even though you are already connected to one.


You are basically right. In an authentication scheme where there is only one message, from client to server, whatever the client shows "grants access" and, as such, is password-equivalent and can be replayed. If sending the hash of the password works, then the hashed password is password-equivalent. Indeed, what your colleague suggests does not add security; instead, it adds a feeling of security, which is, all other things being equal, a bad thing.

HTTP digest is somewhat better because of the nonce, thus preventing replay attacks. A somewhat similar concept is one-time passwords: this is like HTTP digest, with a counter and/or the current time serving as nonce (see HOTP and TOTP.

Note, though, that even if you have a rock-solid authentication mechanism that could be safely played over plain HTTP, it would still be plain HTTP. An industrious attacker will simply observe the connection, wait for the authentication part to be finished, and then hijack the connection to send his own requests. HTTP Digest was designed at a time when most attackers were assumed to be passive, and it was (wrongly) supposed that active attacks were too hard to pull out. Modern networking has shown this idea not to be true. Therefore, SSL (HTTPS) is needed anyway so that the authentication part is really "authenticating" the communication. And if you have SSL, then Basic authentication (aka "show the password") is fine.

One may even point out that in order to support protocols like HTTP Digest, the server must more or less store the user password in cleartext or with reversible encryption, so that's actually weaker than the normal way of storing hashed passwords.


Is the RSA private key useless without the password?

You seem to be asking for a fundamental understanding of how GPG generates keys, and what the role the password plays in this process. I will give some background, and then answer your direct questions at the end.

The short answer is: each time you need to access your RSA private key, your password is used as a "seed" to re-generate the AES-256 key that you need to decrypt your RSA private key (keep reading for details).

RSA Key Generation

When generating an RSA key, you want it as random as possible, pulling randomness from the operating system's cryptographic random number generator (/dev/random on linux, for example). According to wikipedia/RSA_(cryptosystem):

  A cryptographically strong random number generator, which has been properly seeded with adequate entropy, must be used to generate the primes p and q

Protecting the Key File

As discussed in this question, gpg uses its default symmetric cipher to encrypt the RSA private key before it is saved to a file. Gpg's default symmentric cipher used to be 3DES, but is now AES-256. This is also configurable if you would rather use a different cipher (the linked question has a list of available ciphers).

Role of the Password

In order to use a symmetric cipher like AES-256 to encrypt your RSA private key, you need an AES-256 key. Oh no! Recursion! How do you store that key in a safe way? The answer is: you don't - you generate each time you need it using the password as a seed. Specifically, it uses the PBKDF2 algorithm to stretch your password into a full-length, random-looking AES-256 key. Since this AES-256 key is never saved anywhere, your password is essentially the gate-keeper that unlocks your RSA key.

Why not just stretch the password directly into an RSA key?

I'll throw this here just because it's an obvious question.

Symmetric ciphers like AES-256 or 3DES have no structure or properties for their keys, literally any string of bits of the correct length can be used as a key (256-bits and 168-bits respectively).

For public key ciphers (RSA, Elliptic Curve, new post-quantum ciphers like McEliece, NTRU, etc) the keys needs to have very a specific mathematical structure. For example, with RSA the private key must consist of two primes numbers and several numbers derived from them, so if you stretched your password up to the right length and tried to use that as an RSA key, 99.99...% of the time it would be an invalid RSA key (ie the resulting bits would not be two prime numbers and the related values).

Answering your direct questions:

1.

  And if someone stole a private key but didn't know the password, would all encrypted data still be safe?

I'm assuming you mean "if someone stole the private key file but didn't know the password". Yes, your data is safe. All they have is an encrypted file, they have no way of extracting the private key from that.

However, if they manage to get your decrypted private key (say from a memory dump of your running computer) then you're sunk, the password is only used to protect the private key while it's on disk.

  I'm assuming the main problem is brute forcing that password is trivial compared to brute forcing the private key?

Yes, if an attacker gets their hands on your encrypted key file, it will take them fewer guesses to guess your password than to guess your RSA key directly.

Some numbers

Exact estimates of the number of guesses required to break RSA-n, where n is 1024, 2048, 4096, etc, is hard to find, keylength.com is probably the closest you'll get, so take the numbers below with a huge grain of salt.

Let's say that a 1024-bit RSA key gives you (according to keylength.com) 72 bits of security, meaning that an attacker would have to make, on average, 272 guesses to crack your RSA key. By comparison, a 12-character password using numbers, uppers and lowers gives 71.4 bits of security [link to calc] (an attacker has to do ~271.4 guesses) - assuming that it's completely randomly generated, if it's full of dictionary words then it's much much weaker than 71.4 bits.

A 32-character password using all 95 printable ascii characters gives you ~ 210 bits of security [link to calc], almost as much as a fully-random AES-256 bit key. While an RSA-8192 key only gives 136 bits of security, so with a long enough and random enough password, your password can actually be stronger than the RSA key it's protecting (really?!).


Is the private key the only entropy in a X509 certificate?

As described in RFC 5280, a certificate has the following overall structure:

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

The three elements are the "to-be-signed", an identifier for the signature algorithm, and the signature. If you want to be able to regenerate the exact same certificate, then all three elements must be rebuilt identically.

Most certificate in circulation use RSA "v1.5" signatures, as described in PKCS#1. That signature algorithm is deterministic, so if you use the same private key, same algorithm parameters (the companion hash function), and same input (the to-be-signed), then you will get the same signature. The same does NOT hold for the newer, fancier "PSS" signature scheme described in PKCS#1; that one is randomized and you will get a distinct signature value each time. Similarly, if the key type is DSA or ECDSA, then the corresponding signature scheme is randomized, unless you use a specific deterministic implementation (which is possible but not a given).

Assuming that you use a deterministic signature scheme, then the question reduces to reproducing the same to-be-signed contents. The to-be-signed contains the following:

TBSCertificate  ::=  SEQUENCE  {
    version         [0]  EXPLICIT Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,
    issuer               Name,
    validity             Validity,
    subject              Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3
    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3
    extensions      [3]  EXPLICIT Extensions OPTIONAL
                         -- If present, version MUST be v3
    }

Most libraries that create "self-signed certificates" will introduce variations in the serialNumber (since the serial number is supposed to be unique, it will often be randomly generated) and validity fields. The validity contains the two dates that delimit the time range of certificate validity; usually, a library that creates a self-signed certificate will use the current date and time for the first date, and, thus, won't use the same value if the certificate is recreated at a later time.

Extensions are, by definition, open-ended, and may contain various random elements as well.

Self-signed certificates, by definition, are NOT certificates; they live outside of the certificate validation process, and that process is the only reason why certificates actually exist. A self-signed certificate is a name and a public key, encoded together into what superficially looks like a certificate out of a mixture of quick and dirty reuse of existing code, long-standing Tradition, and historical confusion. Such a "certificate" is self-signed because there is a non-optional field for a signature, but that signature is meaningless.

Therefore, in a self-signed certificate, most if not all "extensions" will be ignored, and so will be some other fields such as the serial number. You can probably (depending on what your server-to-server protocol requires in these "certificates") fill the fields with dummy, fixed values that will make your protocol happy, and can be refilled identically later on. However, not all existing support libraries will allow that; you may have to rewrite your own certificate encoder (which is doable but at the price of your sanity).


How does a client use the Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service?

CEP is the service that non-domain clients use to gather all the certificate template information from the domain, since LDAP is not an option and DCOM is difficult to safeguard.  CES is the retrieval of the certificates.   This can be done by instructing non domain members to create an enrollment policy on their user certificate store, or if applicable computer certificate store.  It can use multiple authentication schemes such as Windows Integrated (kerberos), X.509 certificates, or username and password.   If you are trying to deploy computer certificates to non-domain clients, take care with the X.509 certificate option since they likely won't have a client authentication certificate for the computer store from your internal PKI when they go to retrieve their first cert.   By using CES and also CEP you can keep ldap and dcom out of the scenario and just use HTTPS.  This makes it alot easier to secure as well as use.  You can not use CES without CEP since the template and user information needs to be retrieved from AD.


How does a NG Firewall do application visibility and classification of TLS traffic without TLS interception and how reliable is this

They do it on Certificate basis. They check the data on the certificate exchange between server an client, and base on that, they now if you are trying to access to dropbox, outlook, or any other page. The CN or SAN of Dropbox is www.dropbox.com, so they now you are trying to access it.

In other cases, application control in Youtube, browsing, etc.,is problematic, because is signed with a wildcard: *.google.com. This makes Fws unable to differentiate between browsing or youtube. In the case of gmail, it has its own CN/SAN as gmail.google.com. I don't now if FWs have implemented a parallel mechanism to detect youtube, but not too long ago they were unable.
Regards.


Email for the second factor in 2FA systems

By definition, 2FA is if you authenticate users based on two of the following:

Something you know (like a password)
Something you have (like a key)
Something you are (biometrics)

I see that people often argue in which category e-mail should belong. Although many argue that it belongs in the "Something you have" category, I think that it should rather belong to the "Something you know" category because it is most often just protected by a password. Therefore, password+email OTP is not really 2FA. And also, could a person be using the same password for his e-mail as for the system logon?

Using password + mobile phone OTP would be real 2FA (Something you know + Something you have)


The address you show is a link-local address (fe80::/10). Those appear on any network and are non-routable. That means they are for local communication on your LAN only. They are commonly used for things like neighbor discovery, auto-configuration mDNS and streaming from one device to another (i.e. Apple TV).

Link-local addresses are somewhat similar to APIPA (169.254.0.0/16) addresses in IPv4.

If you're looking for private addresses then you want the ULA range: fc00::/7. The first half of that range (fc00::/8) is still reserved, but the second half (fd00::/8) is commonly used on home networks and also on other networks that are not connected to the internet.


Depending on the application you are using, you could enable libpam access and using the password stored on /etc/shadow for authorization, for example.
If this isn't possible or is too complex, you could salt and hash the password using Bcrypt, and saving both the salt and hash on the text file. Even if an attacker finds the file, he will not be able to login unless he can alter the file and add his own password to it.


memorable word and answers to security questions when resetting password?

You should send the password reset link (or code) to a predefined email address (or phone number). This is the only protection in this scenario.

So called "security questions" are not "less secure" they are totally insecure and if used incorrectly they decrease security as discussed here Do security questions subvert passwords?. The only reason to use them might be preventing bots from proceeding through password reset page.

Regarding your second question: asking users to reset them each time will likely only increase burden on your help desk, because after third password + "security question" reset users might start putting things that they cannot easily remember and will look for other ways of contacting your company.

In addition (I know you are considering this requirement only for "forgotten password" option), if you'd require users to perform too much manual processing when changing passwords, you might turn down more security-conscious users who use password managers to automatically update their passwords.


I'm assuming data is entered by some sort of front end, with a list of fields?

For arguments sake I'll assume 4 fields. In the first field do this:

''',(SELECT @@version), (SELECT @@version), (SELECT @@version))--

In the other fields put anything you want because they're commented out by the double dash anyway. This should return the server version to you in the second column of the data.

Edited to Add: You may need a space and another dash at the end. (So -- -)


How does a client (like SSLLabs) know all the cipher suites a server supports if the server doesn’t send its list of supported cipher suites?

In TLS the client announces what kind of ciphers it supports inside the ClientHello and the server picks a cipher from these which is supported on the server too. While one cannot query the server ciphers directly from the client side one can simply take all known ciphers, construct a ClientHello with each of these and check how the server reacts to this ClientHello - i.e. if the server is accepting the cipher or not.

By intelligently combining multiple ciphers in the ClientHello one can speed up this process and also determine which ciphers the server prefers against others (i.e. cipher order).  And that's exactly what SSLLabs is doing for determining the ciphers and also for getting supported SSL/TLS protocol versions and other features of the server.

  Also, I noticed that SSLLabs only sends one request to the server.

If you look into the access log of your web server you'll see only HTTP(S) requests. But, most tests done by the SSLLabs scanner don't result in a completed HTTP request. Instead they already stop in the middle of a TLS handshake. These requests will not be shown in the access log of the web server but you'll see them if you are doing a packet capture.


Is a pure-JS raw RSA implementation secure for transferring information?

It should be secure if used correctly, however, using raw RSA correctly is a difficult task. Because it is easy to make a critical mistake, using low level primitives is discouraged and considered bad practice. You should get a high level library with simple API if possible.

If you can't, make sure you read up on RSA padding and all the peculiarities of RSA, such as it being dangerous to encrypt the same message with many RSA public keys.


Differ between encrypted and unecrypted FTP (21) without login

Plain FTP

[root@mainserver ~]# telnet **** 21
Trying 10.0.0.10...
Connected to ****.
Escape character is '^]'.
220 **** FTP server ready.
AUTH TLS
504 AUTH: security mechanism 'TLS' not supported.

FTPS

[root@mainserver ~]# telnet **** 21
Trying 10.0.0.10...
Connected to ****.
Escape character is '^]'.
220 **** FTP server ready.
AUTH TLS
234 AUTH SSL command successful.

SFTP

[root@mainserver ~]# telnet **** 22
Trying 10.0.0.4...
Connected to ****.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4
NO COMMAND AVAILABLE
Protocol mismatch.
Connection closed by foreign host.

The command AUTH TLS can be done before authentication.

Plain FTP servers can't AUTH TLS, FTPS servers can, and SFTP can be identified by port and ssh version.

Do note that you can connect to FTPS server insecurely because ftps is just ftp with some encryption commands. We can tell if the server is forcing to use AUTH TLS, thus can assume users will only use FTPS.

But if it accept both, then we can only assume the users will use both FTP and FTPS.


where to get more information about Malware

Many antivirus software suppliers provide a public accessible database of malware.
There you can find detailed information about the type, impact and family of a particular malware.

Examples:

https://www.avira.com/en/support-virus-lab (Avira)
https://www.microsoft.com/en-us/wdsi/threats (Microsoft)

In addition to that, you can upload malware to Virustotal for a detailed summary of the malware's behavior.


vuln Cross-origin resource sharing: arbitrary origin trusted

https://xrmtfgxgjkzw.com is just an example generated by Burp. What it is in fact saying is that any website on the internet that the user is visiting can grab content from your site (possibly private to a user) if they are also logged into it.

Scenario is as follows:

Bob logs into your site, example.com.
Bob gets an email from the attacker saying he can look at some cool cat pictures at https://xrmtfgxgjkzw.com.
Bob clicks and views said cat pictures.
Whilst the attacker site is displaying the images to Bob, it makes some background AJAX requests to https://example.com/user/messages and reads Bob's private inbox on your site.
Because the Access-Control-Allow-Origin and Access-Control-Allow-Credentials CORS headers are are set, the Same Origin Policy is not applied and allows https://xrmtfgxgjkzw.com to read the responses.

Note that the above is only a vulnerability if the headers are output on sensitive pages (i.e. those containing private user data), or pages that output secret tokens, including anti-CSRF tokens.

If there is no need to allow arbitrary origins, then you should only output the Access-Control-Allow-Origin header for origins your site trusts. If your site is self contained, then there is no need to allow any origins at all.

WordPress contains a JSON handler at /wp-json/oembed/1.0/embed?url= which is used when a link to a WordPress article is embedded in a 3rd party domain by the user (e.g. in a Facebook post). This is standard functionality of WordPress and doesn't allow access to any confidential data, however it would be better if they didn't output the Access-Control-Allow-Credentials header if not needed in case there are some undiscovered or undisclosed bugs in the handler. My best guess is this is so that authenticated content can be embedded in 3rd party domains. As the link is deemed to be secret, this prevents any random domain from requesting it. Some details here regarding oEmbed.


Connect with a WPA2 hash instead of cracking it

With WPA2, the hash of the WPA2 key is never sent over the network.  Instead, the client derives an encryption key from the password, then the access point is able to verify that the client is in possession of the password cryptographically using the key derived from the password and nonces/ephemeral keys to prevent replay attacks. See https://superuser.com/questions/1068126/router-wifi-password-encryption-types-and-why-do-they-matter for more information.


Cardholder data segmentation for PCI compliance (3.2)

Here are the basic do's and dont's for PCI-DSS:

Regardless of segmentation you are not allowed to store the CVV data. The effectiveness of this code is limited to the ability to keep it out of the hands of criminals, which is why it is prohibited by PCI Standards from being stored. For merchants who charge customers on a recurring basis, the CVV code can be used with the initial transaction but cannot be stored for future transactions.

Now you have an argument, but consider there is a breach in your company and the CVV numbers are obtained and used together with card numbers collected in a breach from company B, then guess who will be held accountable as they did not adhere to the PCI-DSS standard.

The rules for PCI-DSS are not only there to give you guidance on how to store information but also serve as a way of off-loading risk from the card acquirers to the merchants.  Maybe you might think that it's not fair, but in case of PCI-DSS: "The rules are the rules". The only way you would be able to avoid this risk is  by having a QSA sign off on your implementation and explicitly have your architecture where you store the CVV as part of the audit report (to be fair I highly doubt any QSA will sign off on that).


Is Kali-Linux operating system is free from virus and worms?

While I would caution you against using any exploit tools behind the firewall of a domain that you want to keep safe, Kali Linux is run by the guys who offer the Offensive Security Certified Professional certification (a very well respected certification in the Pen Test scene, that I am planning on attempting once I get a few more years of experience under my belt).  So, the official download from them should be fine.

To answer your Windows question, no, not all of the features on modern Windows OS will work on Kali-Linux, as it is a striped down Linux OS and there are differences.  I highly recommend that you just buy a cheap laptop off of NewEgg and install Kali over it, or run it as a Virtual Machine on your Windows box.


A short paragraph from another answer I have here pretty much covers this, though not in much detail:

The amount of protection offered by implementing a password in any system will always vary in direct proportion to the password complexity, and the effort taken to protect that password. Wireless networks are no exception.

Where a strong hashing mechanism is in use, longer and more complex passwords will almost invariably put you in a better security posture.  I strongly suggest you read some of the other passwords questions we have here.  One of particular interest is:

XKCD #936: Short complex password, or long dictionary passphrase?

It should be noted though, that a WPA2 network's PSK is only effective where WPS is either disabled or unsupported on the AP.  Recent side-channel attacks allow an attacker to break WPS in a relatively short time, and gather the WPA2 PSK directly from the AP without having to actually crack the PSK itself.


How can I exploit a XSS vulnerability which doesn't allow me to type  symbols and puts my input in double quotes?

Yes, this filter can be bypassed by playing around with special replacement patterns.

$'$`alert(1)//

The output of the payload above will look like something along these lines:

</script><script>let a = "</script><script>let a = alert(1)//"</script>

If you are interested in learning more about similar bypass techniques, I highly recommend giving http://prompt.ml/ a go.


database of URLs used by penetration tools

In all of your examples, those URIs can (or, well, should) generally be reached by every penetration testing tool. Most tools such as web application security scanners (and often even web application security proxies) implement a crawler (sometimes called a spider).

Crawlers perform link extraction. Link extraction can be benchmarked using a tool such as WIVET. Some tools perform automated form submission, or utilize fault injection. You can sometimes signature penetration testing tools based on this latter information. As an example, Burp Suite submits forms that often contain the name Peter Wiener.

Don't underestimate the power of adversaries to deny or deceive you. Identifying advesary weapons is a common military practice called TECHINT. It could be that an adversary wants you to think that he or she is running a certain tool when they are not -- and it could be that they are noticing that defenses are changing to block their specific tool, so an adversary response would typically be to change things up, i.e., use different tools.

UPDATE (after questioner's comments on why and well as looking at his list again):

Based on the roller-ui URI attack, this is based on an exploit for Apache Roller that relies on OGNL injection (CVE-2013-4212). The exploit was written for Metasploit, but based on some of the other attacks, such as the Solr select check, I can't conclude that Metasploit was used against your website. It looks like it may be a custom tool. Strangely, the JBoss jmx-console/HtmlAdaptor vulnerability appears to be CVE-2007-1157, but that's a strange check for CSRF when compared to the others which are geared towards remote code execution.

SECOND UPDATE -- based on the following two blog posts, I can conclude that Acunetix does check for /solr/select, /server-info and /Account/Register.aspx?ReturnUrl :

https://drjohnstechtalk.com/blog/2012/08/dos-attack-from-south-korea/
https://www.soldierx.com/bbs/201307/Acunetix-5031240223


Is it secure to use similar password over different accounts?

This is an interesting question. A general rule in cryptography is that creating any patterns in keys or passwords is a bad idea, because patterns weaken the system. For example in your case say you log into 10 websites using a base password of myb@s5PW, and add a password suffix on the end. Maybe for stack exchange you use myb@s5PWstEX, for blog site a you use mhb@s5PWblSI, etc. Or maybe you use aamyb@s5PW and bbmyb@s5PW instead. Either there is a discernible pattern, even if there's only one password known.

Let us say that Stack Exchange was hacked (unknown zero day vulnerability, nothing they could do about it), and all user passwords were gained, including yours. I'm sure that somewhere someone is putting this information into a database, so that DB will then have your username with a password next to it. Say then the blog site was hacked the same way, then there would be two passwords linked to your username with an easily understood pattern. If someone wanted to hack one of your other accounts all they'd have to do is make educated guesses based on the pattern. You could make this more difficult by making your patterns more complex, but it's so easy to brute-force all combinations of myb@s5PW that no amount of complexity isn't going to make that strong. If fact it wouldn't be a stretch for an attacker to figure out your pattern even with one example, if they were looking for it that is, but it's unlikely one would try unless they were targeting you specifically.

So from a pure code-breaking perspective it's a bad idea, but like so many other things in security that's not the only factor. The fact is that most people use the same password for multiple sites with no variation at all, so a hacker who gains the password for one site will in many cases get access to loads of other sites. Why would a hacker go through the trouble of looking for patterns when they potentially have millions of user accounts to tap with no work whatsoever? Only if they are targeting you specifically would you need to worry about that.

Add to that the issue of remembering multiple complex passwords. Unless you are Rain Man you would never be able to memorize 40 strong passwords, so having a base password system that makes sense to you but would take some work to figure out is a workable solution for today's authentication issues.

As as for keeping them all straight write them down, and keep them in a locked desk at work or in a locked drawer in your home. Seriously, the vast majority of people who are trying to gain your passwords are probably halfway across the world from you, who is going to break into your home or work to gain the passwords to your stack exchange account!

This is an approach based on someone with an average level of risk. If you do know someone who might break into your home in order to gain your passwords then using any sort of pattern in your passwords is a bad idea.


How should I encrypt an image if I want it to be maintained as an image?

I can't find a cryptographically secure way to encrypt ints to ints with a given passphrase

Most encryption algorithms, both symmetric and assymetric use integers. The problem is usually converting other datatypes to int.

If you were to encrypt it, and put it back as an image, it would look like this:

I think what you're looking for is steganography:

Whith this you can hide any file (images too) inside an image.
The image will still be viewable but hide data in small color offsets.

Here are some open source tools to do this.

http://sourceforge.net/projects/steghide/files/

http://sourceforge.net/projects/crypture/

http://sourceforge.net/projects/openstego/files/

But this is just the hiding part,
encrypting can be done on a unix system with GPG:

gpg --output doc.gpg --symmetric doc


I had to do exactly this same migration some months ago on a production database.
We did that in two steps.

we added an extra password column that would contain the PKDBF2 hash in Crypt format
then we modified the login logic so that when a user logged in (and we received their plaintext password), if the PKDBF2 field was not NULL, the routine would verify against that. Otherwise, it would check against the old hash column, and - if the plaintext hash matched - insert the information into the PKDBF2 field.

Our users did not notice anything. After maybe a week we also sent a mailing to customers that had not an updated PKDBF2 hash requesting they log in, and update their information while they were at it.
What was noticed was that we also added updated password  strength checks (if your password was not strong enough, or its hash had leaked and was available on online databases, a warning would be given and a password change was strongly suggested. If the password was not policy compliant, the change was not an option). Due to a mistake, the checks were added later, so the most assiduous users were able to slip by a potentially unsecure password. Nonetheless, they got hit with the update at the next mandatory password change six months later... the last ones are being processed now, I think.
After, if I recall correctly, six or seven weeks, at the end of July, about 70% of our customers were updated. At that point the logic was changed again and the old hash was disabled, the column dropped. People trying to log received a message that their password was not correct, or had been obsoleted, and they needed to apply for the "Recover password" button.
Then about 10% of customers, more or less, turned out to be "dead" -- they are currently scheduled for removal in accordance with privacy regulations. Those with no business recorded were deleted immediately.


Prevent Brute force attacks on WordPress with SSHguard

Does indeed all one has to do to protect WordPress login from brute force attacks is to add this location block be to the global /etc/nginx/nginx.conf (inside the server block there)?

More or less.

You add the line to nginx.conf which indicates that every time someone tries to access a url that looks like the login page, the request gets logged to disk. SSHguard is going to monitor and analyze the log file continuously and presumably update iptables if the number of hits to that page from a specific IP exceeds a certain threshold.

XML-RPC as implemented in Wordpress can only be described using strings of obscenities. It's critical to a lot of third-party plugins so disabling it will break those, but leaving it enabled will also open you up to additional bruteforce authentication attempts. If you're using Jetpack or similar I'd recommend you add /xmlrpc\.php to nginx.conf as well and tweak SSHguard so it monitors page requests there too.

One problem you'll quickly come up against after doing all this is that only the laziest of attackers bruteforce from a consistent IP address. You'll quickly find a misappropriated IoT/botnet bruteforcing you from a variety of IP addresses over time to circumvent your defenses, but it's a worthwhile step to at least stop basic attacks.


Not out-of-the-box. I know of no Android or iOS device running a bash shell. Some people might, on their rooted devices, but that will be only a few.


Your question seems to be answered on Apple Stack Exchange. Note that the patch mentioned there seems to be no longer maintained, so it may have security issues if you do not backport fixes. A more up-to-date patch (supporting OpenSSH 7.6 as of this answer) is available on GitHub.* This particular obfuscated protocol is explained in more detail on its site. Judging by a quick read of the patch, this particular obfuscation seems to add a random length of padding to packets and encrypt the handshake using a preshared key stored in the configuration file of both the client and server. It is not particularly advanced, but will likely hamper automated protocol detection.

There are other ways to obfuscate SSH traffic as well. You could create an obfuscated VPN tunnel between the client and server and connect with SSH through that. I explained in another answer how to prevent OpenVPN traffic from being detected as such. You could use the techniques outlined in it (static keys and obfsproxy) to create a tunnel through which SSH can run. You need only a basic understanding of networking to bring up a virtual interface for the tunnels and assign a local IP to it so you can connect using your SSH utility. You can also use obfsproxy directly on SSH.

It's important to remember that, while protocol obfuscation can make automated detection or censorship more difficult, it does little to prevent an intelligent analyst with access to traffic dumps from realizing that the traffic is OpenSSH traffic. There is not much you can do to protect against such a threat while maintaining usability. All obfuscation does is raise the bar for detection.

* Applying a patch requires you know how to compile software from source code. You download the source code for the exact version targeted by the patch, and use a command to apply the patch, such as the patch utility.


What XSS attacks doesn't "Reflective XSS Protection" defeat?

There are three major types of XSS:

Reflected XSS
Stored XSS (aka persistent XSS)
Dom-based XSS (aka client-side XSS)

Reflective XSS protection only protects against the first, but does not protect against stored XSS or Dom-based XSS.

Also, reflective XSS protection can often be bypassed.  It does not protect against all reflected XSS attacks.  It's a mitigation, not a strong defense.  Therefore, you shouldn't rely upon it for security: you still need to fix every XSS vulnerability you find.


Best practices for HSM's used by test and production systems

Yes.

Sharing the same HSM(s) across multiple environments (e.g. dev, test, pre-prod, production) is the corporate equivalent of using the same password on multiple web sites.

Many large corporations periodically copy their production data into their QA/test environments.  These lower environments typically have much less stringent data access controls in place.  This means that if the same HSMs are in use in both locations, the data that had been properly protected in the production environment could possibly be improperly accessed in a non-production environment and then leaked to the outside world (or "exfiltrated", for those of you using Google to find this).  So the defense against this is to ensure that there is no possible way in which the non-production systems can access the keys that the production systems used to protect the data.  Which means separate HSM infrastructures for production and non-production.

And from a PCI perspective, if you can simply say to your auditors that your non-production environments simply have no way to access the keys used to protect the production data, that would save you more than the cost of the additional HSMs.


ModSecurity Block based on ARGS_NAMES starting character

These rules seems to work  on 2.8

SecRule ARGS_GET_NAMES "^(#.*)$" "id:193,log,deny,msg:'Block ARGS Name with hash GET'"

SecRule ARGS_POST_NAMES "^(#.*)$" "id:192,log,deny,msg:'Block ARGS Name with hash POST',logdata:'%{tx.httpbl_msg}',setvar:tx.httpbl_msg=$"

SecRule REQUEST_COOKIES_NAMES "^(#.*)$" "id:194,log,deny,msg:'Block ARGS Name with hash COOKIE'"

But better solution https://twitter.com/CoreRuleSet

SecRule ARGS_NAMES|REQUEST_COOKIES_NAMES "@beginswith #" "id:123,phase:2,block,msg:'SA-CORE-2018-002'"


Isn't a reverse TLS (reverse) proxy a security risk?

In most cases in which a reverse proxy is deployed, the network behind it is assumed to be secure, in which case the fact that there is technically a man-in-the-middle is of no consequence.

However, some providers that use a reverse proxy do choose to secure the traffic behind the proxy using an IPSEC tunnel between the proxy and the content server(s). That way, the processing overhead of managing certificates, handling termination, and blocking unwanted traffic can still be done on the proxy server at the edge of the network, but a network compromise will still reveal no information.


Should I let the client send both the session and the user ID?

You are right that you need to make sure that your session ID's can not be brute forced. The trick is to make the session ID long and random (and when I say random, I mean securely random). If the session ID comes together with a user ID it would be harder to brute force, since the attacker would need to guess ID's for one user at a time. That means the session ID could be somewhat shorter. But since it doesn't cost you anything to have a long session ID, there is no need to try to shorten it.

If you use 64 bit session ID's and have a billion users, an attacker would have to make on average 264/109 * 1/2 ≈ 1010 guesses before she gets one right. Without causing any performance problems you could double it and use 128 bit session ID's, and you will have a ridiculous margin.

So, there is no harm in sending the user ID together with the session ID. But if you use long enough session ID's, there isn't really a need. If you do opt for the user ID solution, remember this:

Obviously, you need to actually check the user ID server side, and not blindly trust the client.
Assume the hacker knows all user ID's. That means that the session ID still needs to be long and random.


You didn't mention specifically whether you're referring to an online or offline brute force attack, but seeing as you mentioned medusa I'll assume online.

You also haven't said what protocol you're trying to brute force over or what application you're trying to log into. Eg. web app over HTTP, RDP, FTP?

  Is this visiable for administrators

Definitely. It's not certain that they log it but most HTTP servers store access logs and most login systems also record failed login attempts in some way.

  Or is it just seen as a milions tries to log in to the particular
  server and not as a threat?

No one would legitimately make millions of log-in attempts. If anyone did happen to look at the logs and notice it they'd certainly assume it was a threat.

  Can simple antivirus with firewall like lets say Avira detect this
  kind of penetration attempts?

Can't speak specifically for Avira but there's a chance your attack may also be seen as a DoS if the volume is high enough. Also, it's common for online applications to run an IDS (intrusion detection system) or a WAF (web application firewall) which would be more likely to detect things like this.

  Do you actually think that anyone is looking at the login attempt logs
  or are they just ignored by the administrators or do they even exist
  on a regular server?

As an example, HTTP access, SSH login attempts, etc. will be logged on just about every server. Whether anyone looks at them depends highly on who's running it. You can assume that most large scale systems will have considerable log monitoring in place.

There's also software that watches log files for failed password attempts and bans them automatically, such as fail2ban.

I think you've also discounted application level controls against brute forcing - any well designed login system will lock you out after a certain number of password failures.

Even in the case of an offline attack there's ways of detecting it, such as a honey pot account or honey words that will hopefully lead the attacker to log into an isolated account and alert you before they can log into a real account.


How to successfully report DoS attack coming from a big ISP?

ICANN has a good article on this. Read it.

But because you seem to only be under attack from a specific ISP, I can tell you some more.

Most people have dynamic IP addresses. This means that their IP changes after at most 24 hours. So everything you banned more than 24 hours ago shouldn't be banned any more because for every given IP banned more thin 24 hours ago, now someone else has the the banned IP and can't access your service even though they didn't do anything wrong. So your policy doesn't make sense.

A better approach would be to ban all IP address blocks of the ISP you have trouble with. Then no one using that ISP can access your service and you don't have to worry about the DDoS attacks.

However, a smarter approach is to ban dynamically and for a short period of time. Enforcing a ban forever hurts others and makes your list of banned IP addresses very long, therefore it takes a long time to compare the IP address a request came from to your list.


Which protocols exist for end-to-end encrypted group chat?

Let me try to sum up what the landscape of end-to-end encrypted messaging protocols for group chat looks like:

Protocols like PGP have been around for some time and offer "group messaging" by simply encrypting the content with a randomly generated symmetric key and then encrypting that key asymmetrically with the public keys of each of the recipients. These protocols only sends the encrypted content once but encrypts the encryption key to each of the members of the group. Note that similarly to PGP, this approach does not provide any perfect forward secrecy, deniability or conversation integrity (and thus no transcript consistency).
OTR was introduced to address some of the shortcomings of PGP, improving on perfect forward secrecy, conversation integrity and deniability. Ian Goldberg, the author of OTR also wrote a paper on a multi-party variant of the protocol, named mpOTR. mpOTR was designed with the XMPP transport in mind and inherently synchronous in its design, meaning that each group member is expected to be online at any time to negotiate new keying material. The described protocol does not provide in-session perfect forward secrecy and has not been largely deployed. N+1Sec is a similar protocol with some improvements. Note that these protocols have a lot of algorithmic complexity and tend to scale badly, especially when you add latency into the mix.
Then you have a whole class of protocols, that we simply call N times protocols because they are just sending each message . These protocols have the advantage of reusing an existing one-to-one protocol, which is really convenient when you already have a channel that gives you nice features such as asynchronous perfect forward secrecy. The group structure is not a cryptographic concept in this case, losing on the cryptographic guarantees but lowering algorithmic complexity. The Open Whisper Systems blog has a great post about why Signal does this instead of mpOTR-style messaging. This class of protocols violates your second requirement since they are what we call “client-side fan-out” where the client encrypts and sends out all of the different messages.
There exists an optimisation on Signal's which was adopted by WhatsApp and that you can find in their whitepaper called Sender Keys that has “server-side fan-out”. It uses N times on setup, but after the first message, each member of the group can send a single messages to the group. This protocol has perfect forward secrecy by using a hash ratchet (but does not provide perfect future secrecy). Transcript consistency is enforced by the server-side (because server-side fan-out), but not from a cryptographic perspective.

These are the types of protocols that I've seen being implemented. There are challenges, both in usability and crypto research on how to combine asynchronosity with perfect future secrecy and transcript consistency in the group setting.

If you want a protocol that answers both of your requirements, I think something like the Sender Keys variant of the Signal protocol is what you're looking for.


Is Great Cannon essentially a JavaScript injection attack?

What the report shows is not the uniqueness of the attack vector, but the systemization of the attack vector as a part of a national defence strategy.

  GC is an in-path system, capable of not only injecting traffic but
  also directly suppressing traffic, acting as a full
  “man-in-the-middle” for targeted flows.

...

  In addition, in contrast to the GFW, the GC only examines individual
  packets in determining whether to take action, which avoids the
  computational costs of TCP bytestream reassembly.  The GC also
  maintains a flow cache of connections that it uses to ignore recent
  connections it has deemed no longer requiring examination.

The issue, then, is the nationwide scope and reach for targeted, active response to websites with undesirable content.


Is there any way to scan a host with nmap without arp respond?

Nmap by default performs ARP scan at the discovery stage but if you want to disable it explicitly then you have to specify --disable-arp-ping. As you said that You have specified -Pn then it's for sure that port scanning will be done and Host is up should be reported.

Please also tell your Nmap's version so that we can help you even more.


Is HSTS header any useful without a recognized certificate?

HSTS will not work with typical self-signed certificates, i.e. where the issuer is the certificate itself. But it will work with certificates issued by any CA provided that this CA is added as trusted to the browser. This means also that some private CA can be used to create the certificate in question as long as this private CA is added as trusted to the browsers.


Is it normal to receive working SMS verification code from strange number Facebook

Yes, it's normal. Facebook will use local SMS gateways when possible, because it's cheaper and faster. Using a California-based SMS gateway to send SMS to Algeria would be way more expensive than using an Algerian gateway.
Spelling errors are the strange part, because those messages aren't meant to be typed, but sent by a computer program. Maybe they are correct and you think it's a mistake. As a non-English native speaker, I sometimes think a word is incorrect but I am mistaken, it could be the case here.


RC4 has been deprecated, and is unlikely to ever be used again. There's no reason to go back and improve an old cipher when we have newer alternatives like AES, and in RC4's current state it should not be used. Some sites do continue to have it as a supported cipher suite. However, if you are using an updated version of Chrome, Firefox, or IE 11, then you will be unable to connect to the server via RC4 because they have all removed support for the cipher.

Sources:
https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/
https://blogs.windows.com/msedgedev/2016/08/09/rc4-now-deprecated/#5weuUm0EqMr6WIE8.97
https://codereview.chromium.org/2030263002


Is there a way to make a WEP-secured AP uncrackable?

There is no method to make WEP uncrackable, or at least secure. So I suggest buying a new router that suports WPA2.


SSH: Security of Pubkey Authentication vs Password

Security is not an absolute, a property possessed and evaluated in a vacuum.  Rather, when you ask am I secure? the first response is against what threat model.  You write:

  I'm mostly only concerned about remote attacks from those who don't
  know we have little worth stealing.

Fair enough, that's a good clarification.  In that context, let's examine your other questions.

  For sure the pubkey is very long, so a brute force attack is nearly
  impossible, but, with a long password with strength enforcement (12+
  chars, requiring all classes), isn't the likelihood of a brute force
  attack succeeding already sufficiently remote?

You skate over the question of how you compel such complex passwords; there are a number of ways to change the password on a modern UNIX system, and you've assumed you can intercept all of them.  One failure, one weak password, and your system is penetrated.  But the main reason to prefer passwords in this context is that we see a large number of automated password guessers on the internet today.  I am not aware of any attacks that currently try random private keys, and (barring further discoveries of systematic weak key generation) I don't expect to see any.  Using keypairs moves you away from the attackers, and thus the attacks; there are bandwidth and CPU gains from this, as well as security ones.

  With regard to key loggers potentially getting installed on a users
  remote machine, why is that a greater danger than the pubkey being
  lifted off of their hard drive?

To me, the issue with key loggers relates mostly to third-party machines, eg those in cybercafes.  With password authentication, any user can log in from any machine, and some will; sooner or later, they will do this from a machine which is not trustworthy.  It is possible to do this with public keys also, but to do so requires some skill, which is often accompanied by an improved risk awareness.  Moreover, we see keyloggers in the wild; I don't think we've yet seen much malware that looks for keypairs on temporary local storage, then watches the network stream to see the remote endpoint(s) against which the keypair is used.

  Another thing I've heard mentioned are concerns about a compromised
  server stealing the users password.

None of this is happening in isolation.  Password theft is useful to attackers because people often use the same password elsewhere.  If your users really are required to have a 12-character password with strong requirements on choice, it is likely that at least some of them regard this as their "super sekrit" password, suitable for all the systems they're on that need a very strong one; your security is now only as strong as the worst-maintained system which is in that pool for all your users, and I for one am not wildly to keen to trust everyone else (which is why my own servers require keypair or hardware token + password for remote logins).

There are other secondary issues, eg keypairs being used in a transitive agent model, where logins from one remote system to another can be handled without sending private material "down the wire" to either, but hopefully the above analysis gives you some food for thought.


Lessons learned and misconceptions regarding encryption and cryptology

Don't roll your own crypto.

Don't invent your own encryption algorithm or protocol; that is extremely error-prone.  As Bruce Schneier likes to say,

  "Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break".

Crypto algorithms are very intricate and need intensive vetting to be sure they are secure; if you invent your own, you won't get that, and it's very easy to end up with something insecure without realizing it.

Instead, use a standard cryptographic algorithm and protocol.  Odds are that someone else has encountered your problem before and designed an appropriate algorithm for that purpose.

Your best case is to use a high-level well-vetted scheme: for communication security, use TLS (or SSL); for data at rest, use GPG (or PGP).  If you can't do that, use a high-level crypto library, like cryptlib, GPGME, Keyczar, or NaCL, instead of a low-level one, like OpenSSL, CryptoAPI, JCE, etc..  Thanks to Nate Lawson for this suggestion.


Password guessing: Is it more effective to try many passwords against a few accounts or a few (very common) passwords against many accounts?

There are huge advantages to having access to any account on a system, even if you'd like access to a specific account. I will not detail methods to hide a system wide user base password attack here, however it's possible. Then, a direct attack against a specific account can be done. A random account on a system allows:

Access to any internal information like a user directory, phone numbers, email or snail mail addresses, etc.
If corporate, employee relationships (manager - direct reports), departments names, high level managers.
If corporate, internal servers (email, bug database, source code, employee facing financial systems, call centers, etc.).
If corporate, password may be useful for VPN login and subsequent network mapping.
Access to system or internal servers may allow code injection into the server (not possible without an account). For example, XSS attack or SQL injection attack. Some code injections may lay traps for users when logging in or accessing a system. Other code injections may break system security and provide access to backend databases.
Some poorly secured systems are subject to deep linking attacks (hacking url to skip over application security) and depend upon friendliness of user base to not hack URL. An outside attacker with access to an account may find these holes.
Surveillance of any specific accounts to attack (username, personal information useful for password guessing, phishing of managers, underlings, assistants).
Knowledge of internal systems, data and employees creates incredible potential for a wide range of phishing attacks on all employees including electronic, telephone and physical (vendors, contractors) and may allow granting of new credentials (user account) possibly with very high access privileges.

A single internal account on any system can prove extremely valuable in the hands of a knowledgable, creative and dedicated attacker.

If 99% of accounts have fantastic password security, and 1% lousy, attacking a handful of accounts would most likely miss the easily penetrated ones. Sweeping them all will more than likely catch something at which point attacker gets to try all of the above.


Encryption in Linux: covenience and security

Use your operating system's native encryption mechanism unless you have a good reason not to. The native feature has better integration with the rest of the system, which means easier administration, less risk of misconfiguration and less risk of programming errors, all of which add to better presumptions of security.

This means: under Windows, use Bitlocker. Under Linux, use Dm-crypt via LUKS for whole-disk encryption, and Ecryptfs for home directory encryption.

This was true even before the security of Truecrypt was seriously cast in doubt by the project homepage being modified to recommend not using it.


unexpected thumbprint when connecting via remote desktop - what now?

This was due to a reboot being required, after something has happened to cause the OS certificate to change, in order for the new certificate thumbprint to show up in the output of the Amazon CLI ec2-get-console-output command.


Forgotten password or reset link, which is more secure to email?

It's far simpler to get access to the existing corpus of email than to get access to the incoming stream.  For example, getting a couple of minutes of access to someone's system allows easy searching through their email.  So, for the case where an attacker has access to old mail, but not to the stream of new, incoming, mail:

You are relying on the user either changing their password after they receive it (unlikely, given that you've told them what it is), or deleting (permanently, not archiving or moving to a 'trash' folder, also unlikely) the reminder message.

If this doesn't happen, then if I get access to the user's email account some time later, then a (limited time/limited use, perhaps even limited such that the attacker cannot easily use it) reset link is not going to be any use to me, but having the (most likely still valid) password certainly is.

In addition, by sending me the plain-text password, you are demonstrating that you have this stored somewhere accessible.  In most cases, there is no need for this, because you don't need to encrypt the password (and salt/pepper), you only need to hash it.  If it's encrypted, then anyone with access to the database and the decryption key (e.g. probably most of the staff, or anyone that steals the code along with the database) is able to get the plain-text password.  If it's hashed, then you'd have to get it before the hashing takes place (e.g. during a login session).

Furthermore, although people shouldn't, it's very common to use the same password (or very similar passwords) on multiple sites.  That means that rather than providing a way to get into only one account, you're providing a way to get into many.

For the other case, where the attacker has access to all incoming mail (potentially even the ability to remove incoming mail before the user sees it), neither of these are secure.  The email account is high-risk, because if you have that sort of access, then you can likely go to every site that the user has an account with, and generate a password reset.  To avoid this, you need to use something other than (or as well as) your email account to get access, such as two-factor authentication.

Note that even in the latter case, a reset link is still superior: if the attacker changes the user's password via a reset link, then when the user tries to log in, they'll find out that something is wrong (too late, but at least they know).  If you're just providing the password, then the user has no idea that the attacker has silently gained access.


Nobody's yet explicitly mentioned that there's potential for SQL injection. The user string needs proper validation to ensure that its present and contains just a valid username.


Will same-site cookies be sufficent protection against CSRF and XSS?

First, a definition from Chrome:

Same-site cookies (née "First-Party-Only" (née "First-Party")) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain.

So what does this protect against?
CSRF?
Same-site cookies can effectively prevent CSRF attacks. Why?
If you set the session cookie as same site, it will only be sent if a request emanates from your site. So a standard CSRF attack where the attacker lures the victim to the site http://malicious.com that posts a request to http://bank.com/transfer.php?amount=10000&receiver=evil_hacker will not work. Since malicious.com is not the same site as bank.com, the browser will not send the session cookie, and transfer.php will execute as if the victim was not logged in.
This is very similar to how setting a X-Csrf-Token HTTP header protects you from CSRF - again there is something that is only sent if the request emanates from your domain. The same-site property turns your session cookie into a CSRF-token.
So problem solved? Well, sort of. There are some caveats:

This will only work for browsers that implement this feature. So far, very few do. Unless you want to throw everybody who uses a slightly older browser under the bus, you will still need to implement an old fashioned CSRF-token.
If you need more fine-grained control, this will not be enough. If you run a system that displays untrusted user content, like a forum, you don't want requests originating from user posts to be treated as valid. If someone posts a link to http://myforum.com/?action=delete_everything you don't want that to delete anything just because a user clicks it. With a traditional CSRF-token, you can control exactly when it is used. With a same-site cookie, you can not.
The same old caveats as for old fashioned CSRF protections still apply. If you have an XSS vulnerability, no CSRF protection in this world will save you.

With that said, the same-site cookie is still a good thing that should be used together with traditional defenses as defense in depth.
XSS and XSSI?
The same-site cookie does nothing to protect you from ordinary XSS attacks. If a hacker manages to fool your site to echo out script from the URL on your site, it will be executed as coming from your origin (after all, it is), and thus session cookies will still be sent with all requests the injected script makes to your domain.
If you read the quote in your post carefully, you will see it says XSSI with an I at the end, and not XSS. The I stands for inclusion, and XSSI is related to, but different from, XSS. Here is a good explanation of XSSI and how it differs from XSS:

XSSI is a form of XSS that takes advantage of the fact that browsers don't prevent webpages from including resources like images and scripts, which are hosted on other domains and servers. [...] For example, if Bank ABC's site has a script that reads a user's private account information, a hacker could include that script in their own malicious site (www.fraudulentbank.com) to pull information from Bank ABC's servers whenever a client of Bank ABC visits the hacker's site.

Same-site cookies protects you from XSSI, since a session cookie would not be sent with the request for the script and it would thus not return any sensitive information. However, for ordinary XSS it makes no difference.


Unix execute permission can be easily bypassed. Is it superfluous, or what's the intention behind it?

There's an even easier way to bypass the "execute" permission: copy the program into a directory you own and set the "execute" bit.

The "execute" permission isn't a security measure.  Security is provided at a lower level, with the operating system restricting specific actions.  This is done because, on many Unix-like systems (especially in the days of Ritchie and Thompson), it's assumed that the user is able to create their own programs.  In such a situation, using the "execute" permission as a security measure is pointless, as the user can simply create their own copy of a sensitive program.

As a concrete example, running fdisk as an unprivileged user to try to scramble the hard drive's partition table:

$ /sbin/fdisk /dev/sda

Welcome to fdisk (util-linux 2.24.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

...

Changed type of partition 'Linux' to 'Hidden NTFS WinRE'.

Command (m for help): w
fdisk: failed to write disklabel: Bad file descriptor

That last line is fdisk trying to get a "write" file descriptor for the hard drive and failing, because the user I'm running it as doesn't have permission to do that.

The purpose of the "execute" permission is two-fold: 1) to tell the operating system which files are programs, and 2) to tell the user which programs they can run.  Both of these are advisory rather than mandatory: you can create a perfectly functional operating system without the permission, but it improves the user experience.

As R.. points out, there's one particular case where the "execute" permission is used for security: when a program also has the "setuid" bit set.  In this case, the "execute" permission can be used to restrict who is permitted to run the program.  Any method of bypassing the "execute" permission will also strip the "setuid" status, so there's no security risk here.


Best practices communicating links in email

A policy I've seen used by some banks and government agencies in the Netherlands is never to include any links in mails, but just to refer to "our website" or "our webportal".

The main idea here is that they're explicitly telling customers never to click on any links in emails (supposedly) coming from them. This way they hope to reduce the chance of people visiting links mentioned in phishing mails and entering their credentials there.

People are always forced to enter the URL of the webpage in their browser (or use bookmarks), which can be a bit of a drawback looking at it from an UX perspective, but it can work as a security measure.

Unfortunately, I have no idea how effective this is, and thus if it's a useful strategy.


How can an admin choose which Snort rules to enable?

You just asked the most decisive question that has huge impact on detection.
It is a tedious (rather very interesting) and ongoing full time job to best fine tune IDS, especially in large networks.

General rules

Very important. Know your environment very well! There is no excuse
this requirement.  You have to know what you are protecting, network
ranges, application, how the application run , and are developed on -
including web server types (iis, apache etc.), operating systems (Linux, windows, Cisco
stuff etc.), technology (asp, php, java etc.), other products (erp,
databases etc.), and most importantly what type of data (ssn, bank info, PII etc.).
Study and compile a list of all the above information, and
appropriate network segments they reside in. It will give you a clear map of what signatures you really need, if all your web servers are running IIS with ASP .net then there is no need of php signatures. If you are a bank then you want most data leak signatures turned on, You will have to make this categorization and sorting of types of rules you need.
Leave the standard signatures like port scan, malicious activity, major worm/viruses etc.  active on IDS, they always help.
Improve and update the list regularly, track changes in the
environment, new added software/application to upto date signature
list, and then select any new signature updates.


Why does this buffer overflow have payload &system-&exit-&BINSH

This is a class of attack known as return-to-libc which is a method of bypassing DEP.This works by calling existing functions in a shared library that you know is executable. In this case, the exploit calls the system() function.

Functions are passed parameters on the stack. By controlling the stack, you can control what functions are passed into the system() call. In this case, you tell system() to call whatever is in the environmental variable which you set to /bin/sh. Essentially, you are calling system(/bin/sh) which spawns a shell. Boom, exploited.


Using EnCase to recover InPrivate browsing history

There are various differences in the implementation of inprivate browsing for IE based on which version of IE you are using. IE 8 inprivate browsing was was supposed to be quite good, whereas IE 9 reportedly had many issues.

Encase is just a piece of software that can do advanced forensics. Since It can read deleted files off the drive (depending on the circumstances) and since IE inprivate browsing writes files to disk, it is possible to recover these using a piece of software such as EnCase. then its simply a matter of creating the forensic timeline to piece together the information your after from the extracted files.

There's a few relevant links i've found here and also here


TDE - Encrypting different rows with different keys

It doesn't really matter to you how it's encrypted in the database.  Database encryption is "transparent", meaning that you don't see the encryption mechanisms when you access the data through an authorized connection.  You don't get to see or specify which key is used for which table or row; that's all secured inside the engine.

So if you truly need each company's info to be encrypted its own unique key, you'll have to encrypt the data in your application before writing it to your database.  That quickly gets you into complex key management issues.

Since you haven't mentioned "why" you would want this, I'm assuming it's to isolate queries so that only authorized users can view or edit the data for a particular company. It means you'll have to build a mechanism to hand out the proper keys to authenticated users, so that the salespeople can edit only their own accounts, view their region's accounts, etc.  You'll have to securely store and retrieve those keys, and transmit them to the encryption service. You'll have to rotate those keys according to your company's key management policies.  You'll need to have a way to edit key ownership so that when an employee leaves their accounts can be reassigned to other people.  You may even need to build an audit reporting mechanism.  It's a very complex task to build a usable key management system.

But all this seems like it could be avoided if you lay out your actual requirements.  Are you really trying to restrict access to certain rows to certain users?  Look at Oracle's existing Access Controls, which can already perform that level of control for you.  You wouldn't need to use custom encryption at all if you can use their built-in functionality to restrict access.


Akamai Technologies, Inc. currently publishes it's IP ranges under these 14 ASNs (limiting the list to US based operations):

AS36183, AS35994, AS35993, AS30675, AS23455, AS23454, AS22207, AS20189, AS18717, AS18680, AS17334, AS16702, AS16625, AS12222

The list of IP ranges goes into the thousands though (roughly 4000 of them), so I suggest you rather define firewall rules based on reverse DNS lookups, if that's possible on your equipment, or compile an import list by using the approach I describe in the answer to the question "How to get info on company , company owned sites etc…?".

Problem is, these ASNs and IP ranges might constantly change, and you'll have to keep your list updated on regular basis.

Alternatively, you could extract only IP ranges (IPv4 and/or IPv6) published under the ASN your network is assigned to, hopefully limiting that list to a more manageable number of ranges.

Edit to add: You say in the comments to your question that rDNS is out of the question for being insecure. You're spot on with that, as these records a reverse DNS lookup is checking against can be all too easily spoofed. There is one way to check this however that might mean it's also possible to automate your firewall filters without resorting to ridiculously long IP range lists: Forward-confirmed reverse DNS Look-up.

I wouldn't know if your firewall appliance is actually capable of doing this check, so that might be a no-go, but if it does, what it will do is take the client's IP that is connecting, do a reverse DNS lookup and then query the DNS name returned against A or AAAA records. If the list returned includes client IP, then the FCrDNS was successful, otherwise it wasn't. See this question of mine for a bit more explanation on how this FCrDNS might be used and what it's good for.


Does a domain name ever leave my local system if the matching IP is defined in my hosts file?

Does the client ever send the actual domain name in a request, when accessing the website, or does it exclusively use the IP address?

The hostname is included in the HTTP request (HTTP is the protocol spoken when accessing a web site). E.g. access to http://www.example.org/foo results in:

 GET /foo HTTP/1.1
 Host: www.example.org

Additionally the hostname is send in plain inside the TLS ClientHello when accessing a site with HTTPS (only with SNI but that's what all modern browsers do).


Is server hardening with grsecurity really necessary on the CentOS 6.3 environment?

grsecurity (a.k.a. grsec) isn't really a program - it's a hardening suite for Linux.

It includes the following:

A fully comprehensive Role-Based Access Security (RBAC) system.
grsec-hardened kernel patches.
Enhanced PaX implementation.
chroot restrictions (misc features to prevent malware from escaping a chroot jail)
General system security improvements.

These features are designed to prevent shellcode from being successful on the system. The restrictions in chroot and other system features help prevent untrusted processes (e.g. httpd) from performing tasks they shouldn't.

Here's a few examples of practical improvements:

Prevention of ptrace and other IPC mechanisms between processes that shouldn't be talking to each other.
Forensics capabilities via /proc/[pid]/ipaddr
httpd can be placed in chroot jail with highly restrictive permissions (no kill, no pid/sid set, sysctl writes, etc. outside of chroot)
Full fine-grained auditing of processes, users, groups and other entities.
Ability to completely hide kernel-mode processes from user-mode.

The most difficult and powerful part of configuring grsec is the RBAC system. It relies on you to properly and fully configure the privileges and abilities of certain processes. By default, this is a fairly restrictive set. This can often crash and kill certain processes, often with no obvious reason. However, if you tune it correctly, it's an incredible security measure.

It's great for high security scenarios, and I highly suggest installing grsec with RBAC disabled first to give it a go. Set up a proper chroot for your services (httpd at least, preferably SQL / mail daemons too) so that the entire system won't get pwned due to a vulnerability in a single daemon.

There's way too much to cover in a single answer, so I suggest you read through the grsec wikibook.

As to whether you need it - it depends. It's complex to configure (includes a kernel recompile from source, plus a lot of auto-training and manual config editing) and will take a significant amount of time to fully set up, but the result is that you gain a huge amount of resistance against remote code execution vulnerabilities in service daemons and the kernel itself. Figure out how much time you want to dedicate to protecting yourself from such attacks, and go from there.


Understanding sqlite3 sanitization in python

This is making a prepared statement. It won't sanitize the inputs. At a low level, it's probably using the sqlite c api, and it would look something like:
stmnt = sqlite3_prepare("INSERT INTO table (e1, e2) VALUES(?, ?)")
sqlite3_bind_int(stmnt,0,V1)
sqlite3_bind_blob(stmnt,1,V1)
while((row = sqlite3_step(stmnt) != SQLITE_DONE){
    //do something with the rows
    ...
}

This is just pseudo-code but you get the idea. You can see the values being bound don't need to be sanitized because they aren't concatenated with the string. The sqlite c api is described here.


How to make the first request which used to create account safe?

Client-side hashing can be combined with server-side hashing if you want, but server-side hashing (using a slow, salted hash, typically one of - in descending order of strength/modernity) argon2, scrypt, bcrypt, or PBKDF2 - is essential. You can re-hash something that was already hashed on the client. However, if you were to just take the hashed password from the client and use it directly, not only would the hash probably not be as good (it's complicated to handle giving a user the right salt securely, among other problems), but the hash itself becomes password-equivalent; an attacker wouldn't even need to know what the original password was, if they captured the hash (either from the network, if you messed up your TLS somehow, or - more likely - just out of your auth database) they could just send it to the server and log in as the user.

It sounds like you're trying to roll your own authentication system without much understanding of the security risks around authentication. Is there some reason you can't just use an existing library? Many of them aren't great, but if you were seriously considering either only-client-side hashing or believe that a password passed over HTTPS is "insecure" in any way that a salt helps with, then almost any well-established auth framework will (no offense intended) be better than you would create. Don't re-invent the wheel without reason.