What are the MitM implications of a stolen client-side private key? Many VoIP handsets support client-side SSL authentication for auto-provisioning.  Unfortunately, some devices must be programmed with their client-side keys. (Keys generated on low-entropy devices are poor, but lets not argue that detail).

For this question, we have three players:

The device (a phone)
The server (some client-side authenticated HTTPS server)
Eve, who has intercepted or otherwise stolen the client's key.

If a client-side private key is intercepted by Eve during the initial key install, then certainly Eve can impersonate the client.

To further strengthen Eve's position, assume the device accepts any self-signed certificate presented by the provisioning server (some devices do not have a way to program custom CA's).  Also assume that Eve can redirect all connections through herself.

Given this, can Eve leverage a full MitM attack, something like the following:

Device{Client Key} =>  {CA2}Eve{Client Key} => {CA1}Server

I believe the answer is yes and that the only way to prevent a MitM is for the device to validate the server's certificate through a trusted CA.  Please confirm or refute. I am interested in technical details here.

If the client accepts any certificate as a valid server's certificate, then an active attacker can impersonate the server when talking to the client.

If the attacker can steal a copy of the client's private key then he can impersonate the client when talking to the server.

If both conditions hold, then the attacker can run a successful Man-in-the-Middle attack, by definition: a MitM attack is nothing more than simultaneous double impersonation. The attacker poses as the client when talking to the server, and as the server when talking to the client; he relays traffic in both direction, inspecting and modifying data at will.

If the client can make sure that it uses the genuine server's certificate (either through validation from a known trusted root CA, or maybe because the client remembers the server's certificate from a previous connection), then the client will reject the impersonation attempt, and the MitM won't work. The attacker, who has stolen the client's private key, will still be able to replace the client, e.g. hijacking incoming calls, but that won't be a true MitM (the attacker will have to imitate the voice of the normal client's owner).

Note that if the attacker does not have a copy of the client's private key, and the server validates the client's public key in some way (e.g. the server remembers the client's public key after an initial configuration step), then the attacker will not be able to impersonate the client. Client authentication in SSL is such that even if the attacker impersonates the server, he cannot reuse the messages from a gullible client to fool the true server. Technically, the client uses his private key to sign a "challenge" which is a hash value computed over everything client and server have sent each other so far, and this includes the server's certificate; so, in case of MitM, the client will sign messages containing the attacker's public key (the fake server certificate sent by the attacker), not the certificate sent by the true server, and the signature will not match what the true server expects.

Therefore, if either the client can make sure that it uses the true server's certificate, or the server can make sure that it uses the true client's certificate, or both, then a complete MitM attempts must fail. However, even without a MitM, impersonation (an "half-MitM") is still possible:

If the attacker steals the server's private key, or the client fails to validate the server's certificate, then the attacker can impersonate the server.
If the attacker steals the client's private key, or the server fails to validate the client's certificate, then the attacker can impersonate the client.

Finally, if the attacker has a copy of the server's private key, and the SSL/TLS cipher suite is one of the non-DHE RSA suites, then the attacker can decrypt all the data after purely passive interception, and can also hijack the connection at any point after the handshake, which allows, again, a MitM. The same does not hold for a stolen client's private key; in SSL/TLS, the client certificate and private key are used only for authentication, not for the key exchange, and have no influence whatsoever on the resulting secret used for actual data encryption.


Computer began downloading hundreds of blobs then froze While my mother was trying to sign into her bank account, the download bar in Chrome filled up with hundreds of downloads. Her computer then froze so she restarted it and it seemed to work fine, and only 2 of the hundreds of files actually got downloaded. I looked back at the her history in Chrome and all she had open was her Gmail and Yahoo email accounts, the bank's website, and this IP address http://206.189.198.183 which she didn't open. I wasn't there when the downloads happened, but she says the page was one of those "Warning, you have a virus!" ones. I know she didn't click anything on it yet somehow the downloads all started by themselves and when she was trying to sign in to her bank account.

I also looked at the downloads in Chrome and all of those links look like this, just with different numbers and letters: blob:http://206.189.198.183/e0d7ab8b-b68a-4092-895a-15c69131bb88

I made sure she didn't click either of the two files that got downloaded and deleted them immediately.

I did a whois lookup and the IP address comes from California, but her bank is a local one in Arizona.

What can I do to secure her computer? How can I prevent fishy IP addresses like this from downloading a bunch of crap on her computer?

That site is employing something called Download Bomb. It just starts thousands of downloads at once to freeze the browser, scaring people with a fake virus warning. It only freezes the browser, and don't have any lasting effects or harms the computer in any way.

It's ironic that it affects Firefox, Chrome, Opera, Brave and Vivaldi, but does not affect Edge or Internet Explorer.

What to do? Press CtrlShiftEsc (or right click on the task bar and open Task Manager) and kill the browser processes. Disconnect from the network so the site cannot load its scripts, and reopen the browser. Close the affected tab and reconnect to the network.

Google and Mozilla are aware of the problem, and a fix is on the way.


How to maintain security and trust with a PGP keypair for a team or group of people? I've seen many instances where a company or organization generates and uses a PGP keypair for a team or group of people. Most likely they all have a copy of the private and public keys on their individual machines or sign on to central server and use the gpg utility there (all knowing the shared secret key password).

What happens when one member of the team leaves the company? What if they go rogue upon departure? Assume that they copied the secret/key to their personal USB thumbdrive before you revoked access to the central server or watched them delete their keypair.

It would be extremely inconvenient and impractical to revoke and reissue the "team" PGP key every time someone left the company (image a team of 10+ people).

What do companies currently do? Do they just ignore the possibility an ex-team member will act with malice?

For a realistic scenario, let's talk explicitly about a security@example.com mailbox with PGP key "Example Inc. Security Team" <security@example.com> (0xAAF00F00) where Bob, Alice, and Charlie (the team) have access to the mailbox, and PGP public/private keypair.

The mailbox and PGP key is for receiving reports of high-severity security vulnerabilities to Example Inc. and the team leverages encryption and message signing for correspondence with security researchers.

The setup you described is not ideal. It would be better to implement a certificate authority and setup everyone with their own private-public keypairs. There are schemes where you would then grant access to a shared resource using ACLs at the application level or by having a symmetric key which is used for access and encrypted with each person's public key. You would then change these shared keys for any affected resource when someone leaves.

  For a realistic scenario, let's talk explicitly about a
  security@example.com mailbox with PGP key "Example Inc. Security Team"
   (0xAAF00F00) where Bob, Alice, and Charlie (the
  team) have access to the mailbox, and PGP public/private keypair.

In your scenario, the shared keypair is not relevant. Even if they have their own keys, once its decrypted they have it. If you have an encrypted document and you have the key, and you leave with both it would not matter either because unlike with a paper document in a filing cabinet its trivial to make copies. If I leave the company, why do I still have access to the mailserver? If I do not have access and I still have the decryption key, I would have to break in and presumably defeat some other layers of security to even gain access to first decrypt it.

I would not recommend sharing the mailbox like this in general because there would be no accountability for who sent out an email or who read an email because they are technically sharing the identity. Better to have the message fed into a system with RBAC. Maybe you would them implement an HSM solution combined with certs/keys for access to the system and the decryption is owned by the system not the users.

Security needs to be applied in layers. Do not permit the thumb drives, make them log in through Citrix with all printing and copy and paste disabled, make it so the only way to get a copy of the data is by taking a picture (you could physically prohibit cell phones and cameras). The concern here is really the ability to copy digital data. You could implement some DRM based solutions potentially to address this as well, but DRM can be defeated and it doesn't prevent copying or screen caping.


Is JWT in cookies with any CSRF solution just as vulnerable to XSS as JWT in localStorage? I've read that JWT tokens shouldn't be stored in localStroage because XSS attacks can read them.  The proposed solution is to store JWT tokens in HTTPOnly cookies and use anti-CSRF w/ double-submit cookies.  OWASP says all CSRF solutions are vulnerable to XSS.  If that's the case, then is JWT in HTTPOnly cookies with CSRF just as vulnerable to XSS?  If so, why even bother w/ CSRF and just store your JWT in localStorage?

I've read that JWT tokens shouldn't be stored in localStroage because XSS attacks can read them.

True. If you store information in your JWT and don't want an attacker to read it via XSS, storing them in a httpOnly cookie is a good idea.

  The proposed solution is to store JWT tokens in HTTPOnly cookies and use CSRF w/ double-submit cookies.

I think you are confusing two things here. Storing the tokens in a httpOnly cookie is already the solution to them not being read.

CSRF is a different matter, and it cannot be used to read out data. It can however be used to perform actions on a website for a user that that user did not intent. One solution to this is the double submit cookies pattern.

  OWASP says all CSRF solutions are vulnerable to XSS.

Yes, pretty much.

  If that's the case, then is JWT in HTTPOnly cookies with CSRF just as vulnerable to XSS?

The thing is that you cannot use an anti-CSRF token that is stored in a httpOnly cookie with the double submit cookies pattern.

You need client-side access to the token, as it would otherwise not be possible to insert the token into the form.

So to make this work, you would need to make your cookie not httpOnly or store the token somewhere else in addition to the cookie, eg in the local storage.

Either way, an attacker can bypass your CSRF protection once they gained XSS.

  If so, why even bother w/ CSRF and just store your JWT in localStorage?

You should store your JWT in a httpOnly cookie if you want to hide it's content from an attacker even if there is an XSS vulnerability. If you don't care, or if you need to access the information yourself, localStorage works just as well.


How different are Lynis and Wazuh solutions? It seems both Cisofy's Lynis and Wazuh's OSSEC share a lot of functionalities. I'm completely newbie on both tools and yet I need to pick one (or both) to help achieve PCI DSS Compliance. Any thoughts?

As the author of Lynis, I suggest using both as they both focus on a different aspect of information security.

OSSEC and Wazuh are focused on monitoring files and the status of the system. Lynis helps you with understanding what can be done on a system to improve/increase its security defenses. OSSEC or Wazuh would be run continuously, where you would Lynis daily (cronjob) and ad-hoc while doing system hardening.

If you are interested in learning more about security tools (who doesn't?), I suggest using the Linux Security Expert project. It is a project I founded to review and explain tools and security concepts. See Lynis (Wazuh is to be reviewed).


CSRF in microservice architecture What should be proper way to implement CSRF protection in microservice architecture? Where services are stateless.

To put CSRF verification on system entry? e.g. Gateway

With this option I can't guarantee that customer gateway will do this.
Or on each microservice?

Here we can guarantee that services will be build by some spec.
Problem is service to service communication.
Does in that case service need to pass CSRF token to another service
or some header API key? Because some services are reachable from the Gateway, and directly from another service.

TL;DR: handle CSRF on the same place (gateway or a service behind it) where you handle authentication. Or don't use cookies for authentication tokens.
Long version
In a stateless design most common approach for CSRF protection is double submit cookie. Even though the server does not have a state or session, a security session is present on the client side. It is very important to implement double submit cookie in a way that it is tied to this security session and not to do it naively. Please see this paper for more details.
One approach to achieve this is to include CSRF token inside authentication cookie and make authentication cookie httpOnly. This way an attacker on a compromised subdomain will be forced to overwrite both authentication cookie and CSRF token which he can't do since he can't fake authentication cookies. Even if he has a valid authentication cookie (his own for example), this will change authenticated user and thus defeat the purpose of CSRF in the first place. Also, overwriting the cookie is not enough to defeat CSRF since client application is not reading CSRF token from the cookie itself (it is httpOnly) but it is given a CSRF token on a successful authentication.
Steps needed to implement this approach can be found here. Even though the answer on that link is about JWT, the same approach is valid for any token format you use for authentication.
In stateless microservice architecture the best approach is to handle CSRF on the same place where you handle authentication be it on gateway or some other service behind it since you will need to handle authentication on every request and the CSRF token is (if you implement my advice above) tied to the authentication. Any other option option will complicate things further and possibly break CSRF protection altogether. For example:

You are processing authentication on a gateway or other service but can't change the way authentication is performed and thus can't add CSRF protection at that place. In this case you will need to extract CSRF token out of the auth token and forward it to target service along with CSRF header for processing. This implies you will need to do CSRF protection in each and every service which is not a good thing. You can't guarantee each service will perform this check. Also, you will need to worry about inter service communication. Disabling CSRF protection with a presence of a certain header is possible but might be a security risk in itself.
You are not performing authentication on a gateway or you don't have a gateway, client credentials (authentication token/cookie) are forwarded to every service in chain of request and each service needs to handle it's own authentication/CSRF protection. Same as above, you can't guarantee each service will do it but the approach for handling CSRF is outlined above.

One other approach to handle CSRF is not to have cookies for authentication tokens and instead use headers for passing authentication tokens around. In case of an XSS vulnerability, this will make it easier for authentication token to be stolen though. An article about this dilemma can be found here.


Is allow_url_fopen always a security risk? Is allow_url_fopen always a security risk or only when you let others to insert URL?
like when you want to set video stream links from your another server, and the only way to add new URL is from your Admin area, and the only person who have access that area is you.
so have we any security risk in this situation?

For those who want to answer: please keep in mind that i have read about hundreds of blog post and questions about allow_url_fopen, and everyone keep saying that use cURL instead; i know what is the cURL and i know how to use that, and it's not the exactly same thing so forget that.

i don't ask about alternatives, i just want to know the answer of my own question.

It is a security risk in the sense, that it is incredibly tricky to get right. A small mistake you may have no idea you made could compromise you. That being said, if you do actually get it correct, it should not be a security risk on its own.

I would compare it for example to Content Security Policy Header (CSP). If you don't make any mistake that would allow XSS attack, then CSP is not needed, but it is very hard to get right. So using CSP is very good to make sure and increases security a lot.


What boxed solutions exist for taking care of Authentication? Mostly focused around websites The Internet is generally plagued by websites that break basic rules of security, then there's a middle tier where website try to secure passwords... but they do it incorrectly. And finally, there's websites that do security correctly and are generally secure, but may be vulnerable to attacks not directly on the password but the authentication process itself.

Please note, I'm asking strictly about the authentication part. User management, rights management, baning accounts, and so forth are not part of this question, but if you have a solution that comes with these things that's an amazing bonus, but not what I'm asking.

What boxed solutions exist that allow us to wrap authentication around pages/content, and are not vulnerable to things easily read up in OWASP: they hash passwords correctly, they send Diffie-Hellman cookies (or something like that) rather than the hash of the password as a cookie. They follow RSA PKCS specs.

What exists? This problem is getting solved every day again and again, and I honestly haven't heard of many efforts to offer one stand-alone auth solution for websites, just lots of guides out there telling you "use someone else's solution." Where are those solutions?

One way to outsource authentication is to use OAuth, OpenID, Facebook Connect and others. That way you don't have to take care of users passwords.

To protect specific pages (which would be authorization/rights management), there are multiple solutions. Most web frameworks have some sort of authentication/authorization solutions (for example Djangos auth module).

A more "enterprisy" solution in Java/.NET is Spring Security. It has a lot of functionality, but doesn't do a lot of things out of the box without configuration. There are most likely others like Spring around.

So if you are looking for a simple way to add authentication to a website, use something like OAuth. If you are already using a web framework, it will most likely already offer that functionality. And in the enterprise world there is Spring.


Why aren't TCP sockets encrypted by default? I've been wondering this for as long as I've been programming, Why aren't TCP sockets encrypted by default? Everyone always says that using raw sockets is dangerous as all packets sent are susceptible to packet sniffing.

So why didn't the original implementation of TCP sockets include a basic form of encrypion. What I've noticed so far, is that most languages either don't provide a built in implementation which forces you to use a third party library or make it so hard for 'noobies' to implement SSL over all sockets, that most don't even bother to do so in the first place.

Even simple self signed certificates would suffice for the most basic form of protection, which could be abstracted away for new developers.

Modern networking follows the Seven-layer OSI model which is successful due to the principle of separation of concerns.

  The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.

TCP/IP is layer 4 ("Transport")

  The transport layer provides the functional and procedural means of transferring variable-length data sequences from a source to a destination host via one or more networks, while maintaining the quality of service functions.

SSL/TLS is layer 6 ("Presentation")

  This layer provides independence from data representation (e.g., encryption) by translating between application and network formats. The presentation layer transforms data into the form that the application accepts. This layer formats and encrypts data to be sent across a network. It is sometimes called the syntax layer.

In other words, it is a conscious design choice.

Also, TCP predates SSL by several decades.  To wit, SLL keeps changing because weaknesses are found; meanwhile, TCP has remained mostly the same.  The OSI model allows easier adoption of changes by keeping some things constant while varying others.  If we built encryption into TCP, then it would be a far less stable protocol.


OpenSSL GENERAL_NAME:bad ip address set in [alt_names] I am getting this error in my device:
javax.net.ssl.SSLException: hostname in certificate didn't match: <ec2-5-43-58-857.us-east-2.compute.amazonaws.com> != <na>

So I did some research and found I could set alternative IP address in an OpenSSL config and then generate new keys/certs.
This is my config
[ubuntu@ip-172-31-25-95 ~] 2020-10-09 14:19:07$ cat san.cfg
[req]
default_bits  = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
countryName = XX
stateOrProvinceName = N/A
localityName = N/A
organizationName = Self-signed certificate
commonName = 120.0.0.1: Self-signed certificate
[req_ext]
subjectAltName = @alt_names
[v3_req]
subjectAltName = @alt_names
[alt_names]
IP.1 = ec2-5-43-58-857.us-east-2.compute.amazonaws.com

But when I run:
sudo openssl req -x509 -days 36500 -newkey rsa:2048 -keyout ./key_elastic.pem -out ./cert_elastic.pem -config ./san.cfg

I get this error:
140515677422016:error:220A4076:X509 V3 routines:a2i_GENERAL_NAME:bad ip address:../crypto/x509v3/v3_alt.c:457:value=ec2-5-43-58-857.us-east-2.compute.amazonaws.com
140515677422016:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=subjectAltName, value=@alt_names

Mind you, everything was working fine until I switched to an elastic IP address for server. I made new keys they same way I did before. But then I got the first device error I mentions at the top of the post.

[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.


Is OpenVPN With No Client Certificates Encrypted? We recently installed a pfSense based firewall which with little fuss generated an OpenVPN installer that contains no client side certificates.  Most members of our team have used OpenVPN in some capacity or another over the last 10 years and have always had client side certificates as part of the installation.  As a result a debate has ensued questioning if the tunnel is encrypted if there is no client side certificates.  After quite a lot of searching we cannot come to a definitive conclusion.

We recognize the value of client side certificates, but for just for purposes of knowledge with account and password based authentication and no client certificates is OpenVPN an unencrypted tunnel?

We did use Wireshark and generate some simple UDP traffic with netcat and it appeared encrypted, but for the nay-sayers this was not enough evidence.  The docs do not clearly state that the tunnel is always encrypted although they do discuss not using client side certificates and even mention that since 2.0 secure exchange of account and password data is available without client side certificates.

Is there citable documentation that supports a conclusion?

Client certificates are not used for encryption in OpenVPN. These are "only" used for authentication of the client, i.e. that only clients which provide a trusted certificate can use the VPN.


Database password encryption compromised A company has a database with user's passwords encrypted. An attacker compromised the password encryption now it needs to be changed.
In this situation does the company needs to change the encryption key or Is there another way to prevent it.
Note: The services active at all times.

As a fundamental of security engineering/incident management, if your system is compromised, You must rebuild your system. Because now attacker has enough details about your system. Even if you change encryption key, algorithm, password he still be able to attack again. Because you don't know how he compromise  password.
If you change password or key, still he will be able to access it because i assume that you have no idea about attack. What you know is result.
Identify vulnerability and try to resolve that particular issue.
Therefore rebuilding your system is required with additional security controls. Don't try to achieve security by obscurity.


Cryptography: Encrypting with password without storing it I'm working on a desktop application where we handle sensitive data and we want to encrypt local files with a password that we ask the user when he opens the application. On most similar project, we see that people store a hash of the password so they can verify that the password is valid before trying to decrypt everything. That exposes a security problem, because the hash can easily be extracted and brute-forced externally.
What we want to do is putting a static text at the beginning of the file to decrypt, And when the user enters the password, the application tries to decrypt that stamp and if it can, it would mean the password is valid and then he could proceed to decrypt the rest of the file.
Is it safe? Since I haven't seen this anywhere, I'm not sure if I overlooked something that could make this system vulnerable.
EDIT:
I wanted to revisit this question since I learned a lot about cryptography since then.
Obviously, the right answer is "Don't do it yourself, use a library for that made from someone that knows what they're doing."
Basically, the question was about how to verify if password was good before trying to decrypt an big file with it. The basic scheme I would recommend today for this is to generate a random key, use it to encrypt the file, and then key-wrap it using a key generated with a strong KDF(Like Argon2, Scrypt, BCrypt or PBKDF2) and an AEAD (like ChaCha20Poly1305, AES-GCM, or if you trust more recent algorithms you can use something like Deoxys-II or Ascon). This way, the password can be changed without re-encrypting the file and your code can check somewhat easily is the password is valid. This is somewhat similar to how KeePass and other password managers do, except they generally use a "regular" cipher + an HMAC instead of an AEAD.
TL; DR: Crypto is complicated, use a library.

Try using something like PBKDF2 to turn the password into a key, with which you encrypt the file.  PBKDF2 provides salting and iteration configuration to make it more difficult to brute force.


HTTPS site not being captured by BURP I am testing a website, basically mapping the site using burpsuite. But there is one link(https) that I can not process while the proxy on firefox is enabled. It asks me for certificates and when I ensure that I understand the risks and click on "add exception" the "confirm exception" icon doesnt seem to work,it just stays there. And Thus I can't seem to visit the link using burp.

I know it's a noobish question but the fact is that I am stuck here. Please guide me.

Essentially, you add your Burp certificate to your trusted certificates list. This can be done by loading Burp, proxying a browser through it, and then visiting http://burp/. You should see a page which has a few links across the top, one of which is "CA Certificate". Clicking this will give you a download of a file called "cacert.der".

You can then install this either for a specific browser, or for the whole system - I suggest using a specific browser or browser profile for Burp, but it's up to the individual user. For Firefox, the certificate can be installed by going to Options->Advanced->View Certificates, then "import". For Windows, double clicking the certificate will allow you to install it. There is also an automatic configuration tool for Firefox called "Plug-n-hack", available from the same Burp loaded page, which automatically installs the certificate and configures the proxy settings.


How many hostnames can be supported by a wildcard ssl certificate? Is there any limit? How many hostnames can be supported by a wildcard ssl certificate? Is there any limit ?

There are two distinct things here. One is about the number of hostnames that you can put in a certificate. The other is the notion of "wildcard names".

In the Subject Alt Names extension, you can put "alternate names" of type dNSName. Each of them is an "acceptable server name" (i.e. clients will accept the certificate for a server that purportedly uses that name). The ASN.1 notation for the extension is the following:

   SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

See the "MAX" ? It means "no limit". You can put as many names as you want in a certificate.

Well, since we are talking about DER encoding, the total length of the certificate must not exceed 702223880805592151456759840151962786569522257399338504974336254522393264865238137237142489540654437582500444843247630303354647534431314931612685275935445798350655833690880801860555545317367555154113605281582053784524026102900245630757473088050106395169337932361665227499793929447186391815763110662594625664 bytes, and each name will take a dozen bytes or so (at least). But existing libraries and protocols are likely to enforce stricter limitations. For instance, if the certificate is to be used in SSL/TLS (e.g. a certificate for a Web server that does HTTPS), then the certificate MUST fit within 16 megabytes (its length is encoded in a three-byte field, as per the SSL/TLS protocol). Thus, you can have a maximum of about one million alternate names in a certificate.

Then, each of the name may be a wildcard name, meaning that it contains the "*" character. The "*" will match any sequence of characters except dots. Existing browsers, there again, enforce other constraints, in particular:

There shall be only one "*" character in the name (so no "*.*.stackexchange.com", to take an actual case).
The "*" must appear as first character, not elsewhere (so no "meta.*.stackexchange.com", to continue on that real-life situation).
The "*" must stand for a complete name component (hence "*.example.com" but not "*foo.example.com").

A name component is limited to 63 characters, and the characters must be only letters (case insensitive), digits and the minus sign ("-"), so there are about 3764-2 = 23169162752708970943114627382699355445603465075569066753527132965271355336698663689946873706000418559 possible names matching a wildcard name (the "-2" is because the empty string is not a valid name component)(there are other restrictions, e.g. not beginning with a minus sign, but clients tend not to enforce these).

Since you can have a million alternate names in a certificate, multiply that number by one million, and you will have the maximum number of host names that match your "wildcard certificate". It ought to be enough for most purposes.

Take note of a common confusion. We say "wildcard certificate" but that is a misnomer. What is meant is "certificate such that at least one of the contained names is a wildcard name".

For a real-life example, have a look at Google's certificate (connect to https://www.google.com/, then ask your browser to show the certificate). Right now, the returned certificate contains no less than 49 alternate names which are the following:

*.google.com
*.android.com
*.appengine.google.com
*.cloud.google.com
*.google-analytics.com
*.google.ca
*.google.cl
*.google.co.in
*.google.co.jp
*.google.co.uk
*.google.com.ar
*.google.com.au
*.google.com.br
*.google.com.co
*.google.com.mx
*.google.com.tr
*.google.com.vn
*.google.de
*.google.es
*.google.fr
*.google.hu
*.google.it
*.google.nl
*.google.pl
*.google.pt
*.googleadapis.com
*.googleapis.cn
*.googlecommerce.com
*.googlevideo.com
*.gstatic.cn
*.gstatic.com
*.gvt1.com
*.gvt2.com
*.urchin.com
*.url.google.com
*.youtube-nocookie.com
*.youtube.com
*.youtubeeducation.com
*.ytimg.com
android.com
g.co
goo.gl
google-analytics.com
google.com
googlecommerce.com
urchin.com
youtu.be
youtube.com
youtubeeducation.com

Notice that 39 of these names are "wildcard". With the numbers above, this means that this certificate can potentially match no less than 903597347355649866781470467925274862378535137947193603387558185645582858131247883907928074534016323811 distinct host names. And that's Google -- one can expect that their certificate "works everywhere".


HTTP session fixation According to wikipedia, Mallory the attacker gets her own SID and then forces Alice to visit a site with the SID.  Why wouldn't Mallory just take Alice's SID, if she could MITM Mallory?  Also, is this attack without MITM only susceptible to SID in query string?

Mallory doesn't want Alice's session id.  Mallory wants Alice to perform actions as herself, but while the website thinks she's Mallory.  Like use her credit card to buy something she thinks she'll get, but which will actually be credited to Mallory.

There are several vectors for this attack. The one you mention, cookie-less sessions with the session id in the URL is one.  Mallory having control of a sub-domain and being able to write cookies for a parent domain is another.


How to tell if a SSL cert is 128 bit or 256 bit? My cert is:

Key Length = 2048
Signature algorithm = SHA256 + RSA

So is it a 256  bit SSL cert?

So is it a 256bit SSL cert?

No. There are several aspects which are relevant for a certificate:

the type of the key, usually RSA or ECC
the size of the key. The strength of the key depends both on the type and the size, i.e. the commonly used 2048 bit RSA and 256 bit ECC keys are  roughly equivalent
the signature algorithm, i.e. SHA-256 + RSA

When talking only about "this is a XXX bit cert" one refers to the key size. So  in your example this would be a 2048 bit certificate or more specific a certificate with a 2048 bit RSA key. And this certificate was signed by the issuer with with the issuers RSA key and a SHA-256 hash over the certificate.

Another important factor is the strength of the symmetric encryption of the data, i.e. the algorithm and its key size. But this is independent from the strength of the certificate and thus outside of this question. But any claims by a CA that their certificates are good for 256 bit encryption are just marketing, because this can be done with any certificate.


Why am I allowed to access protected Windows files when I boot Ubuntu from USB? How come I'm allowed to reboot a computer that I don't own, put in a USB, boot ubuntu from it and then access all files stored on the drives available (even critical files such as system files on C drive in Windows)?

Isn't there a way to prevent people from doing this, without putting up a password on the BIOS?

The file and folder/directory permissions on an operating system are managed and enforced by... you guessed it right, that operating system (OS). When the operating system is taken out of the picture (booting a different operating system), then those permissions become meaningless.

One way to think of it: You hire a big bodyguard (OS) to protect your house. You give him a list (permissions) of the allowed guests (users) and which areas (files and folders) they're allowed to visit. How useful are those lists when the bodyguard is asleep (not booting from that OS)?

Generally, it is assumed that once an attacker has physical access to your system, they own your system. Even a BIOS password won't help you in this case. One way to solve this problem is using full-disk encryption using software such as TrueCrypt, Bitlocker, and others.

The problem, in your case, is that you'll have to setup a password (or key) to be inputted whenever you reboot the system. Weigh in your options and decide.


Call recording PCI-DSS issues For a non-automated payment card entry system, if a caller is providing a payment card details over the phone to a call centre employee who confirms the number to the caller, does that mean the organisation is non-PCI DSS compliant?

Automated payment card entry system that typically include call recording and masking the bit where the caller says the number. Assuming this satisfies the PCI-DSS compliance, is there a way an attacker can steal the payment card data?

Readers may wish to see this question first, as it's a simpler presentation.  Or go to the source, which is the PCI SSC Information Supplement: Protecting Telephone-based Payment Card Data

  For a non-automated payment card entry system, if a caller is
  providing a payment card details over the phone to a call centre
  employee who confirms the number to the caller, does that mean the
  organisation is non-PCI DSS compliant?

If the call is recorded, here are the PCI DSS compliance requirements:

The recording must be "encrypted using strong cryptography, or otherwise rendered unusable."  So the card number - the PAN - may be recorded, but the recording must be encrypted.
Some parts of the call, however, may not be recorded: it is "prohibited to use any form of digital audio recording (using formats such as WAV, MP3, etc.) for storing CAV2, CVC2, CVV2 or CID codes after authorization."

If the call is not recorded, then the PCI DSS does not apply (to the call - if the human call center employee is typing the card number they hear into a computer, the DSS starts applying there).

  Automated payment card entry system that typically include call
  recording and masking the bit where the caller says the number.
  Assuming this satisfies the PCI-DSS compliance, is there a way an
  attacker can steal the payment card data?

If the PAN portion of the recording is stored encrypted, then an attacker would have to compromise that encryption control.  That's certainly not impossible, but it represents a significant barrier that has to be overcome.

If the PAN portion of the recording is masked, that may be impossible to compromise.

If you PCI compliant, the CVV isn't on the recording, which would be impossible to compromise.

For all of these scenarios, the call center employee is going to enter the card data into a system for processing.  Everything else being equal, the attacker is going to focus on the processing end of the chain, not the call end - voice is analog and messy, but processing systems are juicy and digital.  And that's where the rest of the DSS kicks in...


Limits of deep packet inspection wrt tunnels? Multitun is a tunnel that encrypts connections and sends them bulk over a web socket, which is a web standard.  So firewalls that ensure the expected protocol is running on the allowed port, will just pass it through as being compliant with HTML.  Is there anything a firewall or filtering system can do to detect this kind of tunnel, that adheres to standards and utilizes a protocol generally allowed through by the organization?  Is detecting such a thing feasible?

The detection of such type of tunnels is little bit difficult since they are using well known protocol which is generally allowed through the firewalls. Detection of such type of tunnels requires machine learning techniques but there is a chance of getting FPs.

Tool Fingerprinting:

There are various tool that tunnels data over well known protocols like iodine, dnscat, ptunnel. Fingerprinting these tool is an idea to detect the tunnel. Detecting these tools requires the knowledge of protocols for that refers RFCs, learn every aspect of the protocol and apply it to detect the tunnel. Now create a environment with this tool and capture the traffic using any ethereal tools(wireshark, tcpdump etc) and analyze the traffic. You will definitely find some patterns which will be unique to the tool. I'm telling this because I've detected above mentioned tools and more using this method because writing machine learning code requires more efforts.

The drawback of detecting tunnel using pattern is, you must have to check the updates when there is any for the tool but what I've seen the pattern is always same for all the tools.


MD5 security concerns in download verification The MD5 hashing algorithm is known to be vulnerable to collisions for a number of years now, see its Wikipedia entry. Still, I see that in many places throughout the web, MD5 is used to verify download integrity, e.g., the Ubuntu images. CMake's ExternalData()C feature description even says:

  Note that the hashes are used only for unique data identification and download verification. This is not security software.

It seems that an attacker could append malicious data to a download, and then append a little more to provoke a hash collision.

Why do security concerns about MD5 not impact its popularity as download verification? Why have SHA1 (or similarly safe algorithms) not become the standard?

I prefer CIC's comment-answer, but the way I have always viewed it is that collisions aren't always useful.

Maybe two text strings can have a collision and if they fit in a password input field, that's a problem.

But what are the odds of useful malicious code, that actually works, being injected into another program and generating the same checksum? Probably absurdly small.

You'd need a wonder-computer to take the legit software + malicious code, and figure out what kind of garbage data needs to be added to the file in order to create the same checksum and filesize and all of that.

This of course assumes the hash is preimage resistant. The wonder-computer being something that not only make the infeasible feasible, but also finding a collision that has both functional legit software + malicious code.

So in that regard, not really a security concern.


What is the best protocol for an organisation to make phone calls to clients, where the client is required to verify their identity? I've experienced a couple of times, an organisation has called me, but they require me verify who I am with security questions.

Most recently, this was my credit card company who left a voice message with a number to call re: possible fraud on my account.

The obvious security risk here, is that it could be a scammer, who is then going to use those details gain access to my account.

In these scenarios, having a modicum of security conscientiousness, what I do is acknowledge the call, request a ticket number if there is one, and look their phone number up on the website, and call back that way.

In my credit card example - the number they'd given me wasn't listed, so I called their general helpline and requested to be transferred.

I think from a end user/consumer's point of view, this is the right protocol.

The question is - what should the organisations themselves be doing to encourage good security? It seems like a very bad habit to teach their customers - to reveal identifying information to people who call them.

The best way is to make it trivially easy for a customer to get to the right place through the number on their card, on their statement, on your website; more, to make it impossible for a bank department to have a number not listed on the bank website.

You can do this via a reference number, a code word, (eg, "please call us back on the number on your card, and say "fraud" as soon as our messages start.")  You need to ensure that when the customer calls in this way, they get to the right place.

You also need to train customer service reps to respect the customer's choice to call back.  Far too often, CSRs will denigrate or undercut the desire to return a call.  They might suggest that caller ID is trustworthy or even tricky to spoof.  It is not.

When I was at Microsoft, we studied this pattern, which is where an organization acts the same way a fraudster does, and results in people being unable to form a model of secure behavior.  We called this pattern "scammicry" for the mimicry of a scam.

There are additional tools you can use, including biometric voice authentication, asking questions which don't expose the answerer to identity theft, such as knowledge of recent transactions, so that calls from the bank are not so worrisome.  (Note that if there are a small number of recent transactions, then a scammer who calls can get those, and then authenticate to the bank.)


Why is encryption (or signing) of long lines in E-Mails with PGP problematic? I am using Thunderbird with Enigmail and OpenPGP to encrypt and/or sign E-Mails. On many occasions Enigmail complains that I have too long lines in the mail and asks how it should wrap them.

However this doesn't seem to follow any logical trends. Sometimes it complains, sometimes it doesn't.

My question however: What does it matter in the first place how long a line is? A line break isn't something terribly different than the letter A (ok, it's a CR and a LF in most cases) but the encryption algorithm sees just bytes anyways.

I wasn't able to find any explaination whatsoever about this in the documentation as well.

Can someone explain why line breaks are problematic for signing/encrypting with PGP?

I can not make it  simpler than this:

  Essentially, the trouble happens when Enigmail attaches an inline PGP
  signature to an email in Thunderbird's HTML message composer. The HTML
  composer is a different component than the plain-text composer, and it
  performs some "clean up" on the message body after the user hits send.
  That is an obvious recipe for trouble, since it occurs after the
  signature was computed over the message. Any alterations, including
  those that are invisible to the user (such as white-space changes or
  replacing special characters with HTML character codes) will alter the
  hash value of the message, which is the element of the signature that
  is encrypted by the sender's private key.

  In this case, the alteration that happens to the message body is
  automatic line-wrapping. Thunderbird's line-wrapping for HTML messages
  breaks lines that exceed 79 characters (or whatever the value of the
  mailnews.wraplength preference is set to), so not every message is
  affected. In an attempt to avert this trouble, Enigmail performs its
  own line-wrapping on the message body just before generating the
  signature, at mailnews.wraplength - 2.

  Nevertheless, there are invariably some situations when a single
  "word" is longer than 77 characters; the simplest example is a lengthy
  URL. In these situations, the automatic line-wrapping Thunderbird
  performs after Enigmail has processed the message splits the long line
  at the mailnews.wraplength point when it is sent, therefore the
  signature no longer validates when the email recipient's PGP client
  checks it.


Is it typical to create both x509 and OpenPGP key pairs? I'm looking into increasing my use of signed and encrypted "things" - LibreOffice Documents, Off-the-record chat, PDFs, emails, etc. I'm finding that some things only support x509 format-certificates, and others only support OpenPGP format-certificates.

I also like that OpenPGP is not CA-dependent, and dislike that the CA model is vulnerable to government interference. However, the CA model is convenient in certain use cases (e.g. Emailing a signed PDF to an old, wizened academic who knows nothing about encryption).

I thought about creating a Frankensteinian x509/OpenPGP hybrid from the same key pair, but I'm not sure if it's worth the trouble.

So I think the question is: Is it advisable to own and maintain two key pairs - one in x.509 format, and the other in OpenPGP?

For all practical purposes, X.509 certificates and OpenPGP key pairs live in separate worlds. You need an X.509 certificate in order to interoperate with people/systems who use X.509 certificates. You need an OpenPGP key pair to exchange secured emails with people who use OpenPGP. If you want to do both then you need both.

One key idea is that such keys make no sense. In a way. An X.509 certificate, or a signed OpenPGP public key (same concept), binds a public key to an identity. What is your identity ? If you look at it closely, you will find that you have several. Legally, you are a citizen (or subject) of some country, and one of the monopolies of central governments is to define identities of people who are under its nominal scope. But that government is not the one who issues your X.509 certificate, let alone signs your OpenPGP key. Furthermore, I strongly doubt that your official ID card / passport / driving license / whatever would bear the name "scuzzy-delta".

In fact, with OpenPGP's Web of Trust, your identity is community-driven: you have as name whatever value other people found convincing. It depends on the community, and you perfectly could have several such identities (many people have a "personal email address" and a "business email address"). As for X.509 certificates, your identity there is procedure-driven: it is whatever is implicitly verified by the process by which the CA "ascertains your identity" (some CA, for some certificates, only check that you control an email address).

Under these conditions, it makes little sense to maintain an X.509 certificate and/or an OpenPGP key pair "generically". You should have keys for a purpose. For instance, you may want an OpenPGP key pair so that people can exchange encrypted emails with your "scuzy-delta" persona. Or an X.509 certificate with the name and address that you would agree to show to old wizened academics (or, for that matter, to your mother). Or maybe a certificate whose purpose is to authenticate your connections with some VPN.


How to locally monitor outgoing internet traffic? I have a cable internet connection that goes to a ASA firewall and then into my local network where i have several machines including many VM's on a ESXI server.

I am looking for a way to monitor mainly my internet traffic to see the most visited websites and the host that visited these sites.  I am not able to put any agents or modify the settings on the devices connecting but I do control the wifi and and ASA.

If you are not interested in the actual content, but only the websites visited by machine, then a local, filtering/monitoring DNS server is the tool you are looking for (probably in combination with fixed IP addresses per machine, using the DHCP server of your router). For the VM's, you want to make sure, they get their individual IP addresses.

There are many options out there, some free and open source ones too. A local DNS server can:

Log the websites visited
Log the DNS queries by machine (with source IP)
Have "user accounts" by IP. With fixed IP addresses, this allows to track usage by machine.
Do filtering (not what asked, but my be useful)

Note: Product recommendations are off-topic, so I will not give them. Google for "local DNS filtering device", but then do not use the filter feature of these products.


Doesn't plaintextoffenders.com just provide attackers with a good list of sites to attack for passwords? On the face of it, PTO seems like a good idea in educating people about password security.

On the other hand, if I were an attacker, PTO would be the first place I would start if I wanted to start collecting a list of plaintext passwords.

Not really.

Knowing that example.com is a plaintext offender doesn't help me much in mass-compromising accounts for that website. I could try to compromise their peering-router to sniff all their outgoing emails, but that would be quite difficult, because that router is likely to be properly secured. Trying to attack their website itself is likely more promising.

The more plausible attack scenarios which become possible through plaintext offenders target the individual user and all websites they use, not all users of the individual service. When an attacker could read the mail communication of a private user (much more plausible than with a professionally administrated system), they can obtain their login credentials for all plaintext-offending services they register to. That means an attacker would rather be interested in finding vulnerable users so they can get logins for random websites, not finding a vulnerable website to get logins from random users.

Besides, finding out which sites are PTOs is trivial: You just have to register an account and you know. Fully automatic account registration is something spammers got frighteningly efficient at.


Is it a security vulnerability if the addresses of university students are exposed? I am sorry for my lack of knowledge in this matter.

My university (basically an international university in the UK that has students from different countries) has a website which requires the students to login before they can access their examination results. These results also include their Name and Address.

But by inspecting the network transaction, I found out that it went to a page that directly takes student registration number in the URL and displays the examination result related to that. This page can be accessed without logging in to the student account and without any hassle, it gave me the examination result that exposed the student name and address. I tried multiple registration numbers similar to mine and all were processed easily.

Another problem is that these registration numbers are in fixed length, only contain numbers and are in ascending order. So for example if a valid registration number is 000001 then the next one would be 000002 and so on.

So in my opinion an attacker can easily create an automated program that could generate these registration numbers, randomly or in order, and get the names and addresses of hundreds of students.

My questions are:

Is it universally approved practice for universities to expose the names and addresses of students?
Is it universally approved practice for universities that strong security related to name and address is not important?
Is it a severe attack and do I have to report it to them? Or can it simply be ignored?

Update:

I received the reply from the university and they have now fixed it. Thanks to all of you.

I am sorry for my lack of knowledge in this matter.

You shouldn't be.

  Is it universally approved practice for universities to expose the name and addresses of students?

As pointed out in comments, it depends on your local laws and regulations. You should certainly check it once. But the way you describe the application(changing the URL to get the details, including the result), it sounds like a bug, which should certainly be reported.

  Is it universally approved practice for universities that strong security related to name and address is not important?

No, be it a university or a big MNC or a small enterprise, or your own personal account, security is ALWAYS important.

  Is it a severe attack and do I have to report it to them? Or it can be simply ignored?

Yes, you have to report it to the university, as soon as possible. It should not be ignored.

EDIT: As pointed out in comments, there are some universities which do allow students' addresses to be made public.


ecryptfs - relationship between passphrase and sig-cache.txt I have previously used TrueCrypt for creating encrypted directories on servers.
I am now trying ecryptfs due to the end of development announcement in May.

I see that when I encrypt a directory and filenames with ecryptfs (with a different passphrase from the user account passphrase), it places a key signature in /root/.ecryptfs/sig-cache.txt.

My understanding is that this is derived and salted from the passphrase and then used for mounting the directory.

I have read that this key is potentially vulnerable to a dictionary attack although that would be practically impossible with a strong passphrase, but what stops you from mounting/decrypting the files with knowledge of just this key?

What stops you from mounting/decrypting the files with knowledge of
  just this key?

The sig-cache.txt is only a signature of the file encryption key.  This means that it is not used at all to decrypt the encrypted volume.  It is only used to verify that the encryption key stored has not been modified or changed.  This is to ensure that the correct key is being used for decryption before actually attempting to decrypt any data.  If only this signature is known it cannot be used to generate the file encryption key in any way.

The ArchLinux Wiki gives an example of how to add a passphrase, and you can see that caching a signature of an encryption key is optional.

However, if an attacker is at the point where they can see this file then it's possible that they are already in a position to request the encryption key from the kernel.  As root access would be necessary for both of these actions.


Snort rule for syn flood attacks - Limiting number of alerts So I have a snort rule that detects syn flood attacks that looks like this:

alert tcp any any -> $HOME_NET 80 (msg:”SYN Flood - SSH"; flags:S;
flow: stateless; detection_filter: track by_dst, count 40, seconds 10;
GID:1; sid:10000002; rev:001; classtype:attempted-dos;)

The problem is, when I trigger it using tcpreplay on vm2 (With a Ddos.pcapng file):

sudo tcpreplay -i interface /home/Practicak/DDoS.pcapng

When listening on my VM1, I get a lot of alerts when listening with the snort rule active. E.G. 100s of Syn Flood Detected alerts.

How can I limit this so that I only get few / 1 alert for each Syn Flood that is initiated? I.E. using the TCPReplay with the pcap file.. & is this good practice to display less alerts?

Thanks

You can use thresholds (that were replaced with event_filters) to do this:

/etc/snort/threshold.conf

event_filter gen_id 1, sig_id 10000002, type limit, track by_src, count 1, seconds 3600

This will generate max. 1 alert per 1 hour for your rule


Is this PHP contact form secure? Can you please tell me whether the following PHP contact form is secure? (It gets used with AJAX.)

<?php
$email_to = "myaddress@email.com";

$email_subject = "My subject";

$name = $_POST["name"];
$email = $_POST["email"];
$message = $_POST["message"];

$error_message = "";

$email_message = "Form details below.\n\n";

function clean_string($string) {
  $bad = array("content-type","bcc:","to:","cc:","href");
  return filter_var(str_replace($bad, "", $string), FILTER_SANITIZE_EMAIL);
}

$email_message .= "Name: ".clean_string($name)."\n";
$email_message .= "Email: ".clean_string($email)."\n";
$email_message .= "Message: ".clean_string($message)."\n";

// create email headers

$headers = "From: myaddress@email.com\r\n".
           "Reply-To: myaddress@email.com\r\n".
           "X-Mailer: PHP/" . phpversion();

@mail($email_to, $email_subject, $email_message, $headers);

?>

I think it's secure -- but I'm not certain it's what you want.

Assuming you have control over the $email_to, $email_subject, and $headers variables (as it appears you do in the code), you're definitely targeting the variables that could make you vulnerable to script injection -- $name, $email, and $message.

That said, it appears that the filter_var command (which, I will confess, I've not used before) will strip, rather than convert, text that doesn't correspond to its filter. And since you are applying the FILTER_SANITIZE_EMAIL filter to things that are not, in fact, e-mail (i.e., name and message), you may lose content that you want.

I think the htmlentities command is a better fit for what you need.


pubring.gpg and pubring.gpg~ at install - why? I've just installed GPG Suit and have pubring.gpg and pubring.gpg~ in ~/.gnupg.  Why?  Thank you.

~  cd .gnupg/
~/.gnupg  ls -a
.
..
gpg-agent.conf
gpg.conf
pubring.gpg
pubring.gpg~
secring.gpg
trustdb.gpg

The tilde is a common suffix for file backups.

This file is a backup of your public keys, used by GPG to avoid corrupting your keys when you modify them.

You can safely delete it, but it will be recreated the next time you use the program to modify the pubring.

Source.


Does Opera Android track me? I used to think that this browser is safe and does not track me. Then I did little experiment - i went to specific webpage on Opera and next day I found ads for it on Facebook app. How did it happen? Does Opera send my history for ad companies?

Every single browser tracks every single user!
They need telemetry and analytics for a better understanding of the user's habits.
Actually, I think if you conduct the same experiment with a different browser, you will probably get the same result. Facebook, Google, and all the "others" have what it's called "activity trackers" which means that they can track you even if you're not using directly their services (typically, Facebook will track you even if you are not on Facebook).
Technically this could be done via the "like" button, for example, any website that offers a "share", "like" or whatever feature specific to Facebook, lets Facebook track you!
More generally, every one (Facebook, Google,...) use also what's called  "Web beacon" or "tracking pixel" which is:

An HTML code snippet that is loaded when a user visits a website or opens an email. It is useful for tracking user behavior and conversions. With a tracking pixel, advertisers can acquire data for online marketing, web analysis, or email marketing. With log file analysis, long data evaluation, or using appropriate analytical tools, this data can be used for different purposes, for example retargeting.

This said, and to answer your question, the fact that you were tracked, is probably more related to the web page you visited and not to the browser you used.


What is the difference in security between a VPN- and a SSL-connection? I would like to design a client-server application where the server is placed on Internet. I assume that I could set up the client-server connection using VPN (is it using IPSec?) or using a SSL connection (possibly https). What are the differences between VPN/IPsec and SSL/https for securing a client server connection over Internet?

VPN means "Virtual Private Network". It is a generic concept which designates a part of a bigger network (e.g. the Internet at large) which is logically isolated from the bigger network through non-hardware means (that's what "virtual" means): it is not that we are using distinct cables and switches; rather, isolation is performed through use of cryptography.

SSL (now known as TLS) is a technology which takes a bidirectional transport medium and provides a secured bidirectional medium. It requires the underlying transport medium to be "mostly reliable" (when not attacked, data bytes are transferred in due order, with no loss and no repetition). SSL provides confidentiality, integrity (active alterations are reliably detected), and some authentication (usually server authentication, possibly mutual client-server authentication if using certificates on both sides).

So VPN and SSL are not from the same level. A VPN implementation requires some cryptography at some point. Some VPN implementations actually use SSL, resulting in a layered system: the VPN transfers IP packets (of the virtual network) by serializing them on a SSL connection, which itself uses TCP as a transport medium, which is built over IP packets (on the physical unprotected network). IPsec is another technology which is more deeply integrated in the packets, which suppresses some of those layers, and is thus a bit more efficient (less bandwidth overhead). On the other hand, IPsec must be managed quite deep within the operating system network code, while a SSL-based VPN only needs some way to hijack incoming and outgoing traffic; the rest can be down in user-level software.

As I understand your question, you have an application where some machines must communicate over the Internet. You have some security requirements, and are thinking about either using SSL (over TCP over IP) or possibly HTTPS (which is HTTP-over-SSL-over-TCP-over-IP), or setting up a VPN between client and server and using "plain" TCP in that private network (the point of the VPN is that is gives you a secure network where you need not worry anymore about confidentiality). With SSL, your connection code must be aware of the security; from a programming point of view, you do not open a SSL connection as if it was "just a socket". Some libraries make it relatively simple, but still, you must manage security at application level. A VPN, on the other hand, is configured at operating system level, so the security is not between your application on the client and your application on the server, but between the client operating system and the server operating system: that's not the same security model, although in many situations the difference turns out not to be relevant.

In practice, a VPN means that some configuration step is needed on the client operating system. It is quite invasive. Using two VPN-based applications on the same client may be problematic (security-wise, because the client then acts as a bridge which links together two VPN which should nominally be isolated from each other, and also in practice, because of collisions in address space). If the client is a customer, having him configure a VPN properly looks like an impossible task. However, a VPN means that applications need not be aware of security, so this makes it much easier to integrate third-party software within your application.


Heartbleed and Facebook logins on (once) vulnerable sites Users have been advised to consult a list of sites affected by heartbleed and to change their passwords on those sites once they are no longer vulnerable. Facebook appears to have been unaffected; but many affected sites use Facebook logins.

What should users do about affected sites where they use Facebook to log in?

Sites that use Facebook logins should never have access to your username/password.  The Facebook API connects the user directly to Facebook, authenticates the user, and then passes that authentication back to the website that you're on.

If something different is going on, that website is probably behaving maliciously (think, emulating the facebook login process like a phishing site, in which case your facebook login would already be compromised).  In this case, there's a fairly narrow attack surface opened up by HeartBleed... if that site's private key is compromised, and the session where you sent your user/pass to them was previously captured by the attacker, then they would be able to decrypt your communication.  I'm gonna put odds on this one as pretty low.  Otherwise, if they are unpatched and you send your facebook user/pass to them again, then an attacker could grab it if they are attacking reasonably close to that moment.

I'm not gonna suggest that such a scenario doesn't exist anywhere on the web, but any site that you typically would want to access that uses a Facebook login never had access to your user/pass to begin with, because the API specifically protects against that scenario.


Attribute Certificates and Access Management I recently came across Attribute Certificates (RFC 5755), which can be used as a means for authorisation.

I like the idea but I have spent a lot of time searching for information how this works in a real life. I understand the purpose of attribute certificates but I don't see how this can be used.

For example, I have a web application. How can I use attribute certificates for access management in web application? There must be something in the authorisation layer of a web application that can work with attribute certificates. How is this achieved? I am not able to find any examples in real web applications.

Also, are there any access management tools that supports attribute certificates, that can provide attribute certificates together with attribute authority? I can find PERMIS project but it seems to be obsolete and not useful anymore.

I would like to see real application of attribute certificates for access management not theory or possible use cases.

In real real life, attribute certificates don't work. Nobody really supports them. One reason for that is that certificates are, by definition, an asynchronous distribution method for information: a certificate binds some values together (for a "normal" certificate, this is a name and a public key; for an attribute certificate, the holder name is bound to the attribute values) and the binding is verifiable without talking to a central online repository. This is what the cryptographic signature on the certificate is about: to allow for offline or at least semi-offline verification.

The flip side of offline verification is that there is no way to immediately cancel a certificate. There is revocation, but it is asynchronous in nature: when a certificate is revoked, this becomes effective within a few hours or days (depending on how often CRL are produced). Asynchronism is exactly what you do not want for authorization: if you want to block somebody because of suspected malicious activity, you want to do it now, not next week.

It is possible to make synchronous revocation by making all clients obtain fresh revocation information everytime, by talking to an OCSP server, but this voids the reason why you wanted a certificate in the first place. The whole point of using certificates is to avoid having to talk to an online server every time you need some authorization information.

So, basically, certificates and authorization do not mix well. This makes RFC 5755 attribute certificates for authorization quite useless. Correspondingly, they are not much used.


What is the relationship between Windows BitLocker and Hasleo BitLocker Anywhere? Whilst researching alternatives to BitLocker which work on Windows 10 Home, I came across a product called "BitLocker Anywhere" from Hasleo. Since they use such similar names I was trying to figure out if they are related.

Is this a completely separate and competing product (and if so, how did they get away with such an obvious trademark infringement?) or is it actually the same software somehow repackaged?

Looks like other have had your same question and discussed it on Reddit

The summary was that it's likely a hack to get BitLocker working in Windows 10 Home, which doesn't normally allow for BitLocker, but that it's not really trustable because they are infringing on the trademark (unless they pay MS some royalties to use the name).


Are there any uses of having a non-deterministic salt value for hashes? So I've been toying with the idea of having non-deterministic salt values for hashes.

Let me explain what I mean:

Basically, I applied some properties from Bitcoin including a "difficulty" (ie, hashed value must begin with a certain number of 0 bits) and came up with something that could be used for password hashes.

My algorithm:

string hashstring=password;
for(int i = 0; i < int.MaxValue; i++)
{
    var hash = Hash(hashstring);
    hashstring = Convert.ToBase64String(hash);
    if(MeetsDifficulty(hash, difficulty))
    {
        Console.WriteLine("i: "+i);
        return hashstring;
    }
}

password in this case, is something like password+salt where salt is a standard cyrptographic random salt stored with the hash. However, as you can see, there is also an i value for how many times it must be hashed, which is not stored along with the hash.

In this way, you must hash the password a number of times until you find something that meets the required difficulty level. This is easy to verify, but does require time because it's unknown exactly how many times the value must be hashed.

There are some interesting properties of this mechanism:

An incorrect password is slightly undetectable. The only way to know it's incorrect is if you know the difficulty level and you find a hash which meets it, but doesn't match the hash
It's probably quite hard to compute any of this in parallel?
In theory, it's completely unknown how long it will take to verify or compute a hash (other than probabilities)
Bruteforce would probably be hard because each password attempted may result in extremely large amounts of hashes needed to verify it to the difficulty

However, I can't really come up with a good use for these properties. Is there any good things to apply such a scheme to or is there anything that uses such a scheme?

Also, are there any potential weaknesses to this hashing scheme?

For my testing, I used SHA256 as the hashing algorithm, and it got quite slow after a difficulty of about 20 bits of zeros. However, this could easily be replaced with using scrypt, bcrypt, or SHA512

Also, one more idea is that you could possibly construct "quick" to verify hashes, but only when given the correct password. (by changing the salt if, say, you've already hashed the value X times and you want to target only hashing the value Y times to verify it when given a correct password)

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

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

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

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


How to correctly implement AES in a backup application I am writing a back-up application which should have the feature of encrypting the back-up. It must encrypt file data, paths and filenames. The application is being written in C# (.NET). Target is Windows systems, but potentially also other platforms under Mono.

It seems that AES should be used with an instance of the RijndaelManaged class. The encryption and decryption functions can be given an IV, a secret key, and of course the data.

The user will get to input a password or passphrase of any length. They'll be advised to choose something reasonable, like between 8 and 50 characters. The password will be stored in some form of hash. I'm not sure yet if this will be scrypt or bcrypt or something. Even though the back-up can be decrypted with this, at least the original password will not be known.

Any expansion needed to get a key that AES can work with is done by AES itself, right? Or do I need to expand the input (with some secure function?) to a key length that AES accepts myself?
Both the IV and Key must be the same during encryption and decryption in order to succesfully decrypt the data. The key is always the same. What should the IV be?
I am guessing that the IV could be an incrementing number, which would make the encryption still look random even when the data and key are identical, so that it leaks as little information as possible. Is this assumption right? Does that mean that a good IV would be the file ID (they all get a unique number, or at least that could be generated)?
A metafile is kept which maps path and file IDs to the original path and filename. For example path 1, file 3 could expand to C:\Windows\explorer.exe. This metafile will probably be plaintext, only the values (path and filenames) will be encrypted. What should the IV be for the values? Their numeric id? Or a random value that is stored somewhere in plaintext? Or can I use a fixed (hardcoded) IV?
Is there anything I should know when running (or attempting to run) the application in Mono? Can I rely on any sources of pseudo-randomness to have enough entropy?
Does AES provide integrity by default, or do I need to store a MAC (or something) of each encrypted piece of data (metadata and file data)?

If you know the answer to any of these questions, any help is much appreciated!

First and foremost; you should not be implementing your own crypto schemes. Yes, you're using AES, but AES is a cryptographic primitive. Try to find an existing, well tested and reviewed solution. You are probably not a trained cryptographer, and as such will likely make mistakes. In light of that disclaimer, here's what I can remember about AES:

If I remember correctly, you'll need to do some work to get the key to be either 128, 192 or 256b. Usually in the form of hashing, but I'd have to check this.
The IV should be cryptographically random.
Generate a unique IV for each new encryption, and store it somewhere.
Pass, the OS should be able to provide reasonable entropy -- Linux usually has /dev/random for this purpose.
AES does not provide any integrity checking by itself; as such, you'll have to implement your own integrity checking.


Can we control the SSL version for ClientHello Can we control the SSL version for ClientHello (like passing the lesser version then maximum supported)?

I am using Java client to connect to App server. Currently my client is supporting TLSv1.0 and App server is supporting SSLV3, TLSV1.1 and TLSv1.2 but TLSv1.0 has been disabled due to its vulnerability to BEAST attack.

So I wanted to connect to App server via SSLv3 instead of TLSV1.0

Can I achieve the same with Java Client?

Yes. At least in Firefox (I'm running 26.0).  Open a tab to about:config.  Filter for tls.version  and set the min/max appropriately. Here's the breakdown of the meaning of the values.

You can also mess with the accepted cipher suites via options (filter about:config for: security.ssl3).

You can test your browser SSL/TLS options by visiting: HowsMySSL.com

Good luck.

(Of course, if, instead, you're looking for a general/OpenSSL answer, the API documentation is your friend. :-D )


How to act on company-wide malware infestation A colleague left and I have been entrusted with the security of the company. Checking an initial status I found that the machines are infested with viruses and there are multiple port scans and brute force attacks that are showing on the firewall between all the machines of the company towards other LAN machines. This problem is on servers and client computers.

I am overwhelmed by 900 daily alerts that I am unable to handle, and I need to give a solution to the problem.

I have previous experience with antivirus consoles, but I don’t know how to manage this infestation problem that seems that our current antivirus "Endpoint protection" can’t handle.

Any ideas of how to get out of this headache?

Two things come to mind.

Isolate as much of your network as you can into zones and tackle each zone on its own. Set up firewall rules to prevent any incoming connections to any device that is not expecting it. Start with the machines that contain your most precious info.

And by "handle it", I mean nuke each machine and rebuild from known good backups.

Get help. You might need to pay for extra hands.


Are people trying to hack my website? On my website I added a little function, that logs IP, client/browser information, path, and a time stamp.

Today I checked my database, and I had a lot of weird requests.

Here are a few of them:

Does anybody else have similar issues, and should I be worried?

You don't need to be worried, unless your setup is insecure.

The first requests search for a proxy judge such as http://azenv.net/. The second table shows vulnerability scanners searching for incorrectly configured or outdated applications. This is quite normal "noise" and effects almost any dedicated server IP.

You could try to block them, but there are so many that it's not worth the effort. Just make sure that any login page has a reasonable limit on the maximum login attempts in a given time and that your software is uptodate. Also things like phpmyadmin shouldn't be publicly accessible.


What is so important about 'clicking'? Why do we need to be careful when 'clicking' things? In other words, why do most security breaches involve clicking? Why doesn't simply loading something already constitute an issue? Why is the act of clicking the barrier between safety and risk?

In general, in order for there to be a problem on your computer,

some piece of executable code (instructions) needs to get downloaded to your computer,
and then it needs to get executed.

(Of course problems on other people's computers can hurt you in a great many ways, and a problem on your co-worker's computer can easily segue into a problem on your computer if, for example, that co-worker is in charge of pushing OS updates out to the whole team.)

Part #1 happens all the time.

Depending how your email is set up, I may be able to put arbitrary files on your machine just by sending you an email. This is less common these days, but it's still a valid example.

Every time you view a website, your browser downloads many files from that remote server so it can show them to you. That's what a website is.

Part #2 takes some work or luck.

So far in the two examples I've given (email and websites), your computer may not have executed any of the malicious instructions I'm sending you (but it probably has, I'll explain).

In the case of an email, the files (attachments) are completely inert until you tell your computer to do something with them. Typically, if you click on an attachment in an email, your computer will assume that you want to view that file, so it will ask your operating system for a program that can display files of that type (signified by the .xyz extension), and then it will tell that program to open the file. At this point the only thing keeping me from executing code on your machine is the program that was chosen to open the file, and I have some control over what program that is.

For websites, in practice, most people have their web-browsers set up to automatically executed any JavaScript included in websites the user visits. That's great for me, if I can get you to visit my website. I have a couple good options:

I can email you a link. If you click it, your computer will assume you want to view that website, and will use your browser to load it up. JavaScript on that page will get executed.
I can put links to my malicious website all over the internet, either by buying ad-space, or by having bots or sweatshop workers post links on various web-forums (including social media).

I may also be able to get someone else's website to run my code, either by hacking that website somehow, or by embedding my code in an advertisement. Both of these happen, they're just a step more difficult.

In short, "don't click stuff" is the stupidest accurate security advice possible.

If you never "click" anything (or equivalently activate it some way the doesn't use your mouse), then your computer won't do anything, which is safe. the threat-model that "don't click stuff" is supposed to protect against is people being tricked into executing code they didn't mean to on their computers.

Email attachments, links from emails, and online advertisements are the mainstream ways that such attacks occur. A lot of work has gone into making these types of attacks harder to pull off:

Email servers will typically screen attachments or even links to try to detect if they're malicious.
Both the programs on your computer that might be charged with opening an email attachment, and the OS that administrates them, have gotten better over the decades at sand-boxing processes and safely handing the files they read from.
Ad networks are still a common malware vector, and you should use an ad-blocker for that reasons alone, but they have gotten better than they used to be. Most of the big networks now do some level of vetting of the ads themselves, so it's harder to push malware or malware-links over them.
Our web-browsers have gotten better at limiting what code on websites is allowed to do. For example it used to normal to have your browser set up to run Flash programs or Java programs; these days it's basically unheard of because everyone knows it's dangerous.

TLDR: "Don't click stuff" is just shorthand for "People online will lie to you to get you to run their malware".


How to calculate cryptographic checksum using 3DES-outer-CBC mode I want to calculate a cryptographic checksum using 3DES in outer CBC mode. As I know (and tried Googling also ) 3DES is an encryption algorithm, I'm not getting getting any information about how it can be used to calculate a checksum. Or may be I am missing some link here. Please correct me if I am wrong.
I need this to form over-the-air SMS.

3DES in outer CBC mode DES-EDE3-CBC (Page 6; here details in the application of ipsec/esp). Here's a code snippet for 3DES in outer CBC mode in a related application.

What you'll most likely have to do is to encrypt a message m using DES-EDE3-CBC and then throw away all but the last block of ciphertext (CBC-MAC). The iv is typically fixed at 0.


How to exploit a  output that filters brackets but nothing else (Explaining broadly as to not disclose any website information accidentally) I've found a website that has an area to input text, and that text is sent through a PUT request and output into <p> tags.

As far as I know, the request only filters angle brackets, and no other characters are filtered. Also, the <p> tags parse unicode, but don't run it.

Is there any way to exploit this? XSS doesn't seem to be an option with the bracket filter, but it seems like, since it is unfiltered, there should be some way to exploit it.

If you're wondering, the PUT request is token-protected, so I can't bypass the filter with it.

Without any special preconditions (unusual codecs, etc.), <p>$XSS</p> is only vulnerable to XSS if opening angle brackets are allowed.

Without creating a tag, you can't inject content that's meaningful to your browser's HTML parser. Everything else, including fancy unicode, is just treated as plain data. However, you could make guesses about how the server prosseses the data to still achieve XSS. E.g., maybe the server converts ＜ (FULLWIDTH LESS-THAN SIGN U+FF1C) to an actual angle bracket on the way, or maybe &lt; is converted back to < for some odd reason - I've encountered that in the wild, but there is no indication that these tricks would work in your case.

  XSS doesn't seem to be an option with the bracket filter, but it seems like, since it is unfiltered, there should be some way to exploit it.

What other client-side vulnerabilities do you expect to encounter here? Besides XSS, keeping Unicode characters is often required for localization and doesn't cause any obvious security problems when printed in an HTML body.

That said, allowing arbitrary Unicode can be quite annoying (PoC: ก็็็็็็็็็็็็็็็็็็็็&) which is why many social websites (e.g. Facebook, Twitter) limit allowed characters. Here is how it renders in Firefox:


On the days of stateless firewalls, was there any reason for using firewall in the place of router? The first generation of firewalls was only simple layer 3 device with multiple interfaces and access list applied in/out direction on the interface, during the same era the routers was supporting also the stateless access lists, so on that days what is the point of using the firewall in the place of the router while they almost give the same security benefits

The first generation of firewalls was only simple layer 3 device

I don't think this is true. Contrary to routers the first generation of packet filter firewalls already worked at layer 4, i.e. they could filter TCP and UDP traffic by port number already and thus selectively allow access to specific services like SMTP (port 25) or HTTP (port 80).

The most important difference between these stateless packet filter firewalls and the current stateful versions is that stateful has the concept of connections while stateless had not. This means especially that with a stateful firewall it is possible to accept incoming packets matching outgoing connections while with stateless firewalls this is not possible.

Because of this a stateless firewall offers not a lot protection for hosts which work as a client, i.e. which are the source of outgoing connections. But it is useful for hosts which only work as a server, i.e. where only connections from outside gets accepted on selected ports. And even today it can make sense to not always track the state for such incoming connections because state tracking needs more resources both in memory and processing time.


Where do I securely store the key for a system where the source is visible? I have a customer with an Access database (ugh!) in which credit cards are stored in plaintext (yikes!), so amongst other changes I'm doing in the app, I'm applying some encryption in there.

I've used Rijndael as the algorithm of choice, but I'm struggling to find the correct approach to storing the encryption/decryption key, since an access database is inherently source-visible. How can I provide decent security on this one to prevent someone grabbing the database (by local access - this machine is NOT Internet connected) ? I feel I'm most of the way there, but missing this vital piece of the jigsaw

[NOTE: Originally posted on crypto.stackexchange.com but they suggested its better suited here]

[UPDATE] For clarification, this is a purely Access system, no web front end.  I've split the database into front-end and back-end components, both in Access.  The machine(s) that it will be on are right in the shop front - it's the system they use to take customer bookings and/or renewals (and it's the latter that is their given reason for storing credit card details).

How can I provide decent security on this one to prevent someone grabbing the database (by local access - this machine is NOT Internet connected) ?

There is a lot you can do, but most of it is not directly database programming. Because most of this is not programming, it might be out of scope for you. I don't know what you were hired to do or what your background is. If this is out of scope or you don't feel comforatble implementing it, then let your client know your security concerns and recommend they hire a specalist.

Hash the credit card numbers.

This depends on the purpose of the stored credit card numbers. If the number are only used to uniqely identify a customer or purchase then you don't actually need the credit card number, just a value that maps unqiuely to the credit card number. If this is the case then replaces the credit card number with a hash of the credit card number. Some hash algorithms: SHA1, MD5, RIPEMD-128/256.

Delete the credit card number.

If at some point the credit card number is no longer needed, but the rest of the data in the row is, clear the credit card field. If you need to retain some indication of the card, but not for charging, then keep the last four digits.

Break the database into pieces.

If you do not need to access the whole thing at the same time, break the database into pieces you need to access at the same time. If the entries are independent then break it into equal sized pieces. This will limit the damage if one piece gets lost or stolen. Try to load as few pieces at a time as is reasonable. If your application has only a few pieces accessible at a time this will slow down an unauthroized user.

Store the keys off the machine.

There are a few ways to do this. One method is using a cryptographic token. There are USB devices, smart card devices, and software tokens. Software tokens can be stored on any removable media (CD-ROM, DVD, USB flah drive, etc). If you do break your database up into pieces, your might consider using different keys for some pieces, especially if some are used less frequently than others.

'Salt' your key

A salt is a random number typically used with hashed password entries to make it difficult for an attacker who accesses a password database to quickly find all the passwords in the database. PBKDF2 is a cryptographic algorithm which uses a salt and a password to generate a key. Generate a salt (random number) for each row and store the salt in plaintext in the row. Use PBKDF2 or another suitable key generation algorithm to generate a key for then row and encrypt the credit card data using the generated key. The purpose is to make the attacker read the database and generate a new key to decrypt each credit card number.

Limit network access to the system.

You say the machine is not internet connected but I suspect it is still on an internal network. Use the firewall on the system to restrice network access to two or three other systems. If the system needs to connect to more than two or three other systems then you may need to think about moving the database to a different system or making a dedicated system for the database.

Limit user access to the system.

Configure the security policy to allow only a few critical users to logon to the machine. If more than eight people need access to the machine, again that should be a signal that the database should be move to another system or it's own dedicated system. My quick though on eight users: System Administrater, System Administrator alternate, Security Administrator, Security Administrator alternate, Database administrator, Database administrator alternate, Application Developer, Application Developer alternate.

Limit physical access to the system.

This is just the good old fashioned locked door. If it need to be in an area shared with other system try to make it systems that allow access to the same users. If all that is available is a closet or cabinet, just make sure that it has a unique key. A lot of office locks and furnite share common keys.

Limit what users have physical access to the system.

Just because they need to access the machine don't mean they need physical access to the system. Choose who you give keys to, and instruct them not to make copies or lend it to anyone else.


where to store the salt for "crypto_pwhash" in a web application with no local storage I am developing a web application which stores encrypted data on a server. I want to derive the encryption key as well as the login key from a single user password, so I want to use libsodiums crypto_pwhash to generate a long enough key, that I can split in two. The idea is that the server cannot decrypt the encrypted data.

To use this function it needs a salt. I understand that the salt may not be secret, but it must be stored somewhere.

If I store it in the server, it must be retrieved before authentication (because it is needed to derive the login key). So this would allow for testing if a username exists without knowing its login key. I am unsure if that would be a security risk.
Could I derive the salt some other way? What if I would just hash the username? Or the password itself? Or would I run into the risk of not having enough entropy?

The required property of a salt is to be unique, cause it make impossible to use dictionary table for reverse hash of all user with the same table.

The other usefull property is to be impredictable so attacker can't pre calculate dictionary table before obtening the salt.(scenario where this is usefull : the attacker detect a security problem he can use to obtain password hash, he generate a table for the username he want to access then when he obtain the password he can use it before you can react to the attack)

random salt give the two property.

Using site name + username give you the first property.

password give you nothing cause when generating a entry in your dictionary table you know the password (the one you are hashing).

If you store it on the server you can respond to request with invalid username by an random number of the same size of your random hash(this is only obscurity and absolutly no security)