Can the device on the other end of a socket change without me knowing? I have a server application written in C#. I am currently authenticating the client whenever a socket is opened, before sending any other Data. After the client is authenticated I assume it's always the same client using this socket. Is this safe or can another person "take over" the Socket after it's authenticated?

If this is a simple UDP or TCP socket all the information which are needed to take over the connection are visible in plain on any system in the middle. This means a man in the middle could fully take over the connection after it was established or even just put itself inside the connection and forward modified data to the original peer.

But if the application protocol has an internal state which can not be derived by the attacker from interceptable information then such a take over is not possible. This is for example true if SSL/TLS is used on top of TCP. In this case a man in the middle attack is no longer practical. But an attacker on the endpoint itself might for example inject its own code into a running application and thus control what data get transferred over the socket.

Man in the middle attacks are also not possible if the attacker can not sniff the plain UDP or TCP connection. This can be achieved by protecting the communication path at lower layers, for example with IPSec or other VPN technologies. But attacks at the endpoint itself are still possible in these cases too.


ASP.NET SQL Injection I have custom authentication system on my ASP.NET website that can help me to register users from my Windows (Desktop) and mobile (Android) Applications.It means that I don't use ASP.NET Configuration.

I have this code when the user press the login button.

    SqlConnection con = new SqlConnection();
    con.ConnectionString = ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;
    SqlCommand com = new SqlCommand();
    con.Open();
    com.Connection = con;
    com.CommandText = "SELECT * FROM [Users-Users] WHERE (Password=@Password) AND (Username=@Username) ";
    com.Parameters.AddWithValue("Password", System.Web.HttpUtility.HtmlEncode(PasswordTextBox.Text));
    com.Parameters.AddWithValue("Username", System.Web.HttpUtility.HtmlEncode(UsernameTextBox.Text));
    SqlDataReader data = com.ExecuteReader();
    if (data.Read())
    {
        //Logged in successfully here I have redirect options
    }

You can see that I have HTML encoding here that can do these:

    &amp;  → & (ampersand, U+0026)
    &lt;   → < (less-than sign, U+003C)
    &gt;   → > (greater-than sign, U+003E)
    &quot; → " (quotation mark, U+0022)
    &apos; → ' (apostrophe, U+0027)

So can we login without password using Sql Injection? e.g→

username textbox :admin
password textbox :pass" OR 1=1

You are using parameterised queries consistently for all variable values, so there is no SQL injection attack.

However, storing database values in HTML-encoded format is an antipattern. You'll make it difficult to process the data at an SQL level (since 1 db character no longer equals one on-page character), you'll produce inappropriately-encoded output for non-HTML formats (eg sending mail), and you'll fail to properly HTML-encode any data that comes into the database by other means (or which doesn't touch the database at all, eg a Parameter output straight onto the page).

The time to HTML-encode is when you are dropping some text into an HTML page. In ASP.NET templates you get the <%: ... %> tag to do this automatically, as well as attributes of WebForms doing the right thing (caution: not always). HTML-encoding should not be done as an input-processing or database-query-creation step because those places aren't anything to do with HTML.

Also you should of course be storing passwords using a salted hash (ideally a strong one like bcrypt) and not in the clear as implied by the Password=@Password comparison.


How to detect if a system is infected by key logger or not? Assume that you want to login your Gmail account on your friend's laptop and you are doubt if he installed a keylogger on his computer. How you can be sure if there is any key logger installed or not?

I guess it would require too much effort and still you would not be 100% sure.

Have a reliable anti malware with the latest update perform a deep scan to look for it.
If you are very well experience with the OS' processes, take a look to see if any unknown process is currently running.
Check the connected USB devices to the computer. Two keyboards are a indication

What could help you:

Use a system virtual keyboard to type in your password.


Add custom field to certificate Is there a standard way of adding
a custom data field, in my case a mac address, to a certificate. I sign them myself and they are used in a closed environment.

What I would like is a mechanism so that I can specify the
mac address parameter via the commandline when calling "openssl req...",
maybe using the "-subj" line.

Is it possible to write the openssl.cnf in such a way that
a new field is added in the extensions section that can be
set via the commandline option. I.e. if the fieldname is
"mac" then via  -subj ".../mac=0x023445344556..." or some other commandline switch.

Or is there some other way i.e. via environment variables...

You can add custom attributes to certificates, assuming you are using x509v3.

This SO post provides the basics, which is that you need to use a config file, and create an actual attribute.

Your example is adding a field to the DN, which is a different thing.


decrypted signature using CA public key equal to hash of certificate? so here is my test setup, I write something "hello world", created its hash, created signature of hash from private key, then using this openssl command, i can get same hash from which signature was generated

openssl rsautl -verify -inkey pubkey.pem -pubin -keyform PEM -in signature

Next I downloaded stackexchange.com public certificate, extracted signature from certificate, decrypted signature from CA (Let's Encrypt) public key, that is OK but result don't match hash of stackexchange public certificate.
what I'm doing wrong?

The thumbprint is calculated over the entire certificate (TBS and signature), while the signature of a certificate is created against the TBSCertificate structure which is a part of the X.509 certificate.

Ref: RFC5280.

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

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

So you need to compare the hash embedded in the signature with the hash of the TBSCertificate portion.


Can people use AES VPN tunnels to hide their activities from authorities? I have read an article about programmers who use AES VPN tunnels when working remotely with clients from other countries. The article writes that this way their countries are unable to track their activities and to charge tax.

What is the story about AES VPN tunnels? Can someone explain to me in simple words?

The article even writes that this way they can import money without being tracked.

VPN is essentially a way to connect a remote system to a local network, as if it were actually on the local network. This is usually done via L2TP (Layer 2 Tunneling Protocol), which forwards network traffic over UDP packets. The protocol itself does not provide any encryption or authentication, so it is usually ran alongside a security protocol, e.g. SSL or ipsec.

When a VPN is tunneled through SSL, the data will be encrypted in a way that prevents eavesdroppers from reading (or modifying) the conversation. This is essentially the concept you've read about in the article, and it's a popular trick in countries with censorship and oppressive governments, e.g. China.

There are attacks on these security measures, though. It's possible to identify L2TP traffic even when encrypted, using heuristic analysis on packet sizes, timings and flags. This doesn't reveal the encrypted information, but allows governments to make a reasonable estimate that you're trying to circumvent their censorship or other laws. Self-signed certificates can also be broken via man-in-the-middle attacks, since there's no certificate authority to ensure the validity of the certificate.


Preventing MITM for a new SSH daemon Supposed I have a number of HTTPS servers on different networks, would it be safe enough to use them together to verify a new SSH daemon's public key? i.e. if they all return the same fingerprint, is it safe enough to assume there is no MITM attack?
I'm aware of SSH certs, but it gets tough to implement with most shared hosting.
Thanks.

Reusing the same ssh host key on multiple servers is a security risk. If one server is compromised, the attacker can intercept all connections to your servers.

If the servers are administrated by another person, you should ask this person over a trused channel.
Trusted channels are:

Website with HTPPS and a valid certificate. for example github has published the fingerprints on their website: https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints)
telephone
Messanger (signal, whatsapp, ...)

If you own the server you can use a local terminal. On a virtual machine, you can use the management interface to open such a terminal. Physical machines (bare matel) server should have some remote management devices like KVM Switches or built in the bios/uefi.
By default OpenSSH stores the keys in /etc/ssh.
Follwing command calculates the SHA256 hash:
for file in /etc/ssh/*.pub; do   ssh-keygen -lf $file; done

Older implementations of openssh generates MD5 fingerprints
for file in /etc/ssh/*.pub; do   ssh-keygen -lf $file -E md5; done

You have multiple keys with different algorithms. Depending on your server and your client, one of those keys are used.
Now you can compare the shown fingerprint from the client with the the calculated fingerprints.


Chain of Trust Extension with TPM2.0 I am looking for a way to implement a trusted boot using a firmware TPM2.0 on Arch Linux. I am using TPM2.0-TSS, and tpm2-tools, however I cannot find a way to do this with tpm2-tools, as I do not believe it allows me to make any changes to the PCRs. I have been looking into tboot, but am a little confused if it will work with my TPM.

Is there any way I can use tpm2-tools to implement a trusted boot? If not, are there any alternative solutions? Any help would be appreciated!

The tpm2-tools does not provide trusted boot by itself. It provides tools to play with the TPM.

What you are looking for is really either DRTM or SRTM (Dynamic, Static Root of Trust for Measurement). As you pointed out, tpm2-tools won't change the PCRs but both SRTM and DRTM have this capability. They feed the PCRs in the TPM.

DRTM is typically the best way to go and this means the tboot software. There's many tutorial to get tboot running. At the end, what you'll be looking for is for PCRs 17 to 20 to be filled.

I suggest reading this answer and kernel.org doc.


Finding date of last network access I have a system that contains highly sensitive data that does not reside on the Internet. However, when I was going through the machine recently, I detected that it had cookies, and temporary internet files stored on it. While I can find the date these were created, I need to be able to obtain the date of last Internet access in a verifiable manner. The machine is Windows XP, and I have full administrative access. I have already looked in the Event Viewer, there was no information there, as such. The last modification date for the Temporary Internet Files folder is a few years ago, so that has not served as an indication either. Is there some resource, or some logs, that Windows has that can tell me when the last connection happened, and if possible, how?

Note: This is not within a corporate network, or any similar internal network.

A simple (possibly verifiable) way to do this is looking for the index.dat files that are present on the machine. Even if the user deletes all the cookies, and deletes all temporary files, and removes most traces of a connection, the index.dat file gets updated to reflect this behavior - and the latest modification date of the file will tell us when it was last used by IE, and thus give the last date Internet was accessed.


How to Verify the Identity of the Caller of a Web Service I have a server which is composed of a page and a web service.  The web service is intended to be used by a Windows Phone mobile application that I will develop myself.

Now, my question is, how do I identify that the web service request is coming from the mobile application I developed?  On normal web applications, one can make use of a combination of certificates and digital signatures to ensure the identity of the caller.

The main problem is that Silverlight does not allow the developer to load the certificates installed on the mobile phone and get the private key to sign the data.  I thought of hardcoding the private key into the application, however this is not secure at all as the application can be easily disassembled and reverse-engineered.

What else can I do to make sure that the web service request came from the mobile application I developed rather than from a normal web application?

You can add an API_key to your authentication process - something that a user needs to request first thing from the server. This initial request can contain device specific information, application specific information and user identity bits. Generated API_key can be a cryptographic hash function of that data.

A server stores all the API_keys and link a key to a user (if you want).

Only requests that have valid certificate and API_key are authenticated. You can then only allow one simultaneous log on with a valid API_key to mitigate API_key sharing.


Password security - how much do non-alphanumeric characters matter? We have a discussion in our company about password security for our application.

Besides the fact, that we use 2 factor authentication (certificates+login/password), we currently enforce passwords with at least 12 characters of length.

Currently there is no enforcement of using non-alphanumeric characters.
And from my perspective there is little to no gain in security, when the user is forced to mix (non)-alphanumeric characters.

From my understanding if you have the alphabet of possible characters, the entropy for 123456789012 and !"§$%&/()=!" should be the same and both passwords should have the "same degree" of security (the choices made from the alphabet differ, but the alphabet is the same).

The only difference would be the information to the attacker, that the first password uses only a subset of the alphabet, which would reduce the entropy.

On the other hand, what makes the first password "insecure" is the fact, that it is really predictable; chances are high for a fast match if a dictionary is used. Given slow hardware and a dictionary, it would really matter chosing one over the other.

But with todays power (GPU/Cloud) for bruteforcing the difference in security is from my point of view neglectable, so that it is valid to say: one is as secure as the other.

tl;dr

Is the difference in security between 123456789012 and !"§$%&/()=!" as passwords nowadays neglectable?

(strong hashing and using salts presumed).

There are two factors here.

Firstly, you are correct, the entropy is the same. What is important is the address space not the utilisation of that space. So as long as users can use symbols etc, that's what's important in the first instance.

However, the second factor is guessability or breakability. Can a password be guessed using rainbow tables? Can a password be brute-forced (e.g. all characters the same). Your example of 123456789012 falls foul of this since it will certainly be in any decent rainbow table because it is simple and common.

So current best practice for passwords is that you allow extended characters but you don't enforce specific rules (which in any case reduce the address space). You encourage longer passcodes - "codes" note, removing the emphasis on "words" - good passcodes may be memorable but are not guessable. And finally, because you are encouraging complexity, you wouldn't be enforcing 30, 60 or even 90d passcode changes. At least for individual ID's, shared/admin ID's may be a little different.

My feeling is that this approach is a good balance of usability and enhanced security. But I think that you should ideally audit passcode databases periodically to hunt down weak passcodes.


Shared wifi security/privacy I live in a building with free WiFi access for all of the 30plus tenants. I've lived here for just over a year, the WiFi password has never changed. I added a WiFi extender to address the deadzone where I'm at in the building which has worked great. I use the building WiFi to surf the net, online banking and online purchases, using my phone and tablet both android OS. Should I be concerned about security/privacy?

You should be concerned only when using non secure connections ie.http
these connections can be sniffed.

what is important is to be aware of various attacks against encrypted connections, basically, ensure you do not accept new SSL certificates if prompted, unless 100% sure.

another important thing is to ensure your software firewall blocks inbound connections, if you're running a service that requires inbound port to be open, ensure software listening on this port is fully updated.

also, keep in mind if your PC/phone is infected already then all of the above doesn't make sense, in which case you should fix that first.


Why does moving my mouse really quickly make recaptcha pass quicker? I've noticed that if I ever get recaptchas on websites if I move my mouse back and forward really quickly then it passes very quickly.

Any idea why/if this is a possible

I am assuming that you are talking about the No Captcha ReCaptcha here. This tick based ReCaptcha works based on javascript and a CSS styling element unlike the form input based conventional CAPTCHA. Google is relying on the fact that most bots doesn't have javascript support and will not be able to fire the ajax request which is usually fired when the user clicks on the check box. It may also be relying on the javascript to capture mouse actions. More mouse actions create more entropy which a bot ideally cannot mimic. This could be the reason why your random mouse movements made an easy pass through the reCAPTCHA.

This is an educated guess.


MASVS 1.12: "Endpoints verify that clients use up-to-date version" In the current OWASP MASVS (as of now v0.9.3) we can find the following requirement for MASVS-L2 in Security Verification Requirements:

  MASVS 1.12:
  "Remote endpoints verify that connecting clients use an up-to-date version of the mobile app."

I'm wondering how central the point about 'endpoint verifying [...] clients' is. For example, if a client does a version check via service call, would this be sufficient in your eyes? (I.e. the client calls a service which tells him the the 'minimal required version', and the client can then force an update if necessary.)

The way I see it, if the client is compromised we can't really trust any info that it sends to the endpoint (such as its version number for a server-side check as proposed by MASVS 1.12). And if the client is not compromised, then it shouldn't matter if the version check is actually done client-side instead of server-side, right?

After talking to some of the authors of the OWASP MASVS document on their slack channel I think the answer boils down to:

It doesn't matter if this check is done client-side or server-side
Its goal simpy is to be able to force users to update off of old versions.
An attacker attacking the app could circumvent/beat this version check in many different ways independent of whether the check is done client-side or server-side.


Is MD5 considered insecure? After all these articles circulating online about md5 exploits, I am considering switching to another hash algorithm. As far as I know it's always been the algorithm of choice among numerous DBAs. Is it that much of a benefit to use MD5 instead of (SHA1, SHA256, SHA384, SHA512), or is it pure performance issue?

What other hash do you recommend (taking into consideration data-bound applications as the platform)? I'm using salted hashes currently (MD5 salted hashes). Please consider both md5 file hashes and password hashes alike.

MD5 for passwords

Using salted md5 for passwords is a bad idea. Not because of MD5's cryptographic weaknesses, but because it's fast. This means that an attacker can try billions of candidate passwords per second on a single GPU.

What you should use are deliberately slow hash constructions, such as scrypt, bcrypt and PBKDF2. Simple salted SHA-2 is not good enough because, like most general purpose hashes, it's fast. Check out How to securely hash passwords? for details on what you should use.

MD5 for file integrity

Using MD5 for file integrity may or may not be a practical problem, depending on your exact usage scenario.

The attacks against MD5 are collision attacks, not pre-image attacks. This means an attacker can produce two files with the same hash, if he has control over both of them. But he can't match the hash of an existing file he didn't influence.

I don't know if the attacks applies to your application, but personally I'd start migrating even if you think it doesn't. It's far too easy to overlook something. Better safe than sorry.

The best solution in this context is SHA-2 (SHA-256) for now. Once SHA-3 gets standardized it will be a good choice too.


Is hijacking a webcam after visiting a website a plausible threat? (I made a throwaway to ask this question, since this situation is pretty embarrassing)

Earlier today I started receiving emails threatening to send embarrassing video of me to all my contacts unless I pay a ransom. When I first saw this message I did briefly panic and consider paying the ransom, but on reflection I'm wondering if this is a plausible threat. I mean, the password they sent as evidence is real, and to my embarrassment I did visit a porn site a week ago because I was bored.

That said, the claimed attack vector seems unlikely to me, and they could have gotten the password from a data breach on an unsecure website (it's a password I use on various forums, not banks or anything). I'm aware of the possibility of keylogging and your webcam being hijacked by a virus, but they're claiming to have done that simply because I visited their website. Is that really possible?

If this is a new attack vector, it seems pretty serious. All an attacker needs is for me to visit a malicious website, not even download anything?

Here is the full email I received:

  I know REDACTED is your passphrase. Lets get right to point. You don't
  know me and you are probably thinking why you are getting this e mail?
  None has compensated me to check about you.

  Well, I actually installed a malware on the xxx streaming (porn) site
  and guess what, you visited this web site to have fun (you know what I
  mean). When you were viewing videos, your web browser started out
  operating as a Remote control Desktop having a keylogger which gave me
  accessibility to your display and also webcam. Right after that, my
  software gathered your complete contacts from your Messenger,
  Facebook, and e-mail account. After that I made a video. 1st part
  displays the video you were watching (you've got a good taste : )),
  and next part displays the recording of your cam, yeah it is u.

  You have got two different choices. We are going to read up on these
  possibilities in aspects:

  First solution is to skip this message. In this instance, I am going
  to send out your video to each one of your contacts and then just
  think concerning the shame that you receive. And as a consequence if
  you happen to be in a loving relationship, exactly how it will affect?

  2nd choice should be to give me $3000. Lets refer to it as a donation.
  Subsequently, I will straight away erase your video. You will resume
  your daily routine like this never took place and you would never hear
  back again from me.

  You will make the payment by Bitcoin (if you don't know this, search
  "how to buy bitcoin" in Google).

  BTC Address: 16u9dNXj1WRTu4aEiXREXjD1afqjELXs1S  [case-sensitive, copy
  & paste it]

  Should you are wondering about going to the law, okay, this e mail
  cannot be traced back to me. I have covered my actions. I am also not
  attempting to demand so much, I wish to be compensated.

  You now have one day in order to make the payment. I have a specific
  pixel in this mail, and now I know that you have read through this e
  mail. If I don't receive the BitCoins, I will definately send your
  video to all of your contacts including relatives, colleagues, and so
  on. However, if I do get paid, I will erase the recording immediately.
  If you need evidence, reply Yes! then I will send out your video to
  your 5 friends. This is the non-negotiable offer and thus please do
  not waste my personal time & yours by responding to this e mail.

Hi this is a scam that has been doing the rounds for a bit now do not worry about it :)

https://www.cert.govt.nz/businesses-and-individuals/recent-threats/webcam-and-password-blackmail-scam/
https://krebsonsecurity.com/2018/07/sextortion-scam-uses-recipients-hacked-passwords/

What has happened is your credentials were leaked in one of the many breaches that occur and scammers are using this personal information to try and make you believe that have embarrassing content.

If you look up your password on https://haveibeenpwned.com/ you will find a breach. Now what the bad guy has done is find a list of email addresses and credentials and is now emailing trying to make a quick buck with no effort.

My advice is change your credentials and ignore it.


Is it possible to detect a keylogger, when placed? Can you detect a keylogger when it is placed? Would it be possible to do that via a keyboard removed event, expecting the keyboard is not removed regularly?
So that you for example get a pop-up/alert every time your keyboard (wired) is unplugged and the end-user has to approve that he/she checked if there was a keylogger placed.

Just check around if you want to find them. There are couple of hardware keylogger types.

Wireless keyboards are more vulnerable because all keystrokes can be catched from air. You can build a device that listens specific channel to catch keystrokes and decrypts it, this kind of devices can be placed anywhere in range.

Standart wired keyborads are more secure because you can detect them easily. Some keyloggers can be placed inside the keyboard if there is a empty place. You need to open the keyboard and find some kind of circuit looks suspicous. Some others can be placed on the line that goes through from your keyboard to your mainboard. That devices can store keystrokes in their memory or transmit them to another device in range. Also there are hardware keyloggers can be plugged in to extension ports such as PCI. You can easily detect them by checking your mainboard.

Generally, if someone put a hardware keylogger somewhere around, they need to take it to read data. However as I say, you can store keystrokes with a hardware keylogger and build it to send keystrokes to another device. That device can be placed in anywhere and also can be sending every keystrokes received instantly. For example if I put a hardware keylogger inside your keyboard or on cord, I can make it transmit a mini-computer in range (such as Raspberry) and that raspberry can send it to my e-mail with Wi-Fi.


Resend encrypted REST GET request to eavesdrop data Bob makes a HTTPS GET request to view his personal info on a dating site via a RESTFul web service. He supplies his api key,secret,timestamp and signature to prove that the request came from him. All the header data are encrypted so Bob is very sure no one can eavesdrop on this request.

Alice is a network administrator. She immediately noticed an encrypted request via her Wireshark tool and tries to view the content, but she only sees the encrypted content, the source IP and destination IP.

If Alice submits the exact same encrypted request via her computer (a few seconds after Bob), will she be able to see Bob's personal info?

Alice's replay request will fail on TLS level because TLS is immune against replay attacks (e.g. look here).

And even if it wasn't: Why the hell would Alice be able to decrypt the response from the server? It would be encrypted by the TLS session key. Just replaying something doesn't give you access to the session key...


Is CacheBleed fixed in LibreSSL? https://ts.data61.csiro.au/projects/TS/cachebleed/

Only thing I can find: http://undeadly.org/cgi?action=article&sid=20160301141941

Q: was CacheBleed fixed in LibreSSL?

CacheBleed fixed in LibreSSL 2.5.0

Added constant-time updates to address CVE-2016-0702

And that CVE-ID is CacheBleed.
Source: OpenBSD "Announce" Mailing list post from 2016-09-28 (Archived here.)


How to export my Protonmail private key? From: https://github.com/scastiel/protonmail-export

  1) Open the ProtonMail app and log out completely. You should now see
  the login screen.

  2) Open the dev tools of your browser, and the Network tab to see all
  network calls.

  3) Enter your username and password and click Login button. You won't
  need to go further.

  4) In the network calls, find the one to “/api/auth”. There may be
  several ones, be sure to pick the one with “POST” request method, not
  the “DELETE” one (which doesn't contain any info anyway).

  5) In this network call, open the Response tab to see raw data
  returned from the server, find the line beginning with "PrivateKey":,
  and copy the rest of the line, from "-----BEGIN PGP PRIVATE KEY to the
  last ", without the trailing comma.

  6) Open the Console tab of the dev tools, type console.log(<PASTE THE COPIED CONTENT HERE>) then press enter.

  7) Copy the result of the command, and put it into a text file, that's
  it you have your private key!

But I am stuck at "6)". The

console.log("-----BEGIN PGP PRIVATE KEY B........----")

part doesn't output anything (the "...." part is of course censored).

So now.. I can format by hand the private key to look like a private key, I can even import it with "seahorse"! I thought I winned the game, but... when I try to:

gpg --encrypt --sign --armor -r foobar@protonmail.ch message.txt

It asks for a GPG key password. I use a password manager, so I copy/paste the MAILBOX password that I use, but here is the catch: it doesn't accepts it!

Question: What am I missing?

I also asked scastiel via mail, posting the answer here if he replies, but maybe someone else knows the solution too.

In step "5)" I can see that there is a line named "KeySalt".. maybe Protonmail introduces salt after the howto from scastiel?

Protonmail support wont help on exporting the private keys.

UPDATE: I wrote "MAILBOX" password, that means I still use Protonmail with two passwords: one for login, and one mailbox pw for the "decryption".

The password for your private key is now the hashed value of your Mailbox Password (if you are using 2 passwords) or of your Login Password (if only using one password). You must now also get the KeySalt value and use bcrypt to get the hash value.

I followed the steps listed here to download my private key password using Firefox:
https://github.com/scastiel/protonmail-export/issues/6

  Login to ProtonMail
  Get the salt value from the same cookie response as the GPG private key:

  Switch to the console tab in the developer options
  Run the following, but replace < LOGIN PASSWORD OR MAILBOX PASSWORD > and < KEYSALT FROM STEP 2 > with their corresponding values:

  password = "<LOGIN PASSWORD OR MAILBOX PASSWORD>";
  salt ="<KEYSALT FROM STEP 2>";
  saltBinary = pmcrypto.binaryStringToArray(pmcrypto.decode_base64(salt));
  keySalt = dcodeIO.bcrypt.encodeBase64(saltBinary, 16);
  bcryptKey = dcodeIO.bcrypt.hashSync(password, '$2y$10$' + keySalt);
  key = bcryptKey.slice(29);
  console.log(key);
  The console output is the password for your private key


What's the security concern of browsers using the HTTP CONNECT method? The XMLHttpRequest spec says that attempted usage of the CONNECT method should throw a security error.

Is there a security issue with client-side JavaScript sending CONNECT requests to servers? It seems it could be somewhat useful to allow browsers to tunnel / open secure TLS sessions to destination servers through a proxy web server.

The CONNECT method leaves the TCP connection at a different state than it originally was; unlike other HTTP request, the CONNECT method is stateful, it is always the last HTTP request that can happen on that TCP connection.

Once the CONNECT request is finished, that connection cannot be used to transfer other XMLHttpRequest, and instead are solely usable for the tunneled protocol. So the browser would have to discard the connection once the tunnel is closed.

Back when XMLHttpRequest was originally written, Javascript didn't have a Socket API (and it still doesn't now; despite the name, Websocket isn't really a true Socket API, it's more like Messaging API because it has automatic message framing and cannot be used to write arbitrary bytes to the underlying socket), so there isn't really a way to use that tunneled connection from Javascript.

Since the browser can no longer use that TCP connection for anything, and since JavaScript cannot use that connection either due to lack of Socket API and a way to reference the connection, the only valid thing that the browser can do after a CONNECT request is to close the connection.

Prohibiting CONNECT limits the scope of XMLHttpRequest API so standard authors and implementers doesn't have to deal with those issues, and XMLHttpRequest can be designed so it only need to deal with stateless requests.


How do I build a secure signing mechanism on top of HMAC Say we have a system with strong shared keys (not passphrases), and we're trying to sign messages sent by the server that will be visible to an attacker. E.g. storing session state in a signed cookie.

Is it safe to use HMAC directly with the shared key? I.e. the function will be determinant and the attacker can just build a collection of [message, MAC] pairs; can he/she compromise the shared key?

If not, is it safe to use hmac_key = HMAC(salt, shared key), where salt is new for every request and sent along with the MAC? Or do I need multiple iterations of this/PBKDF2?

I guess I want to know if using a salted key for HMAC provides any real protection of the key, not just seems more secure.

Technically, HMAC is a MAC, not a signature. Some people get the terminology wrong (in particular Microsoft's documentation) and call HMAC a signature, but things are clearer if you use the right words.

HMAC, when used with a secure hash function (say, SHA-256, but SHA-1 is fine too), is resistant to forgeries; that is, the attacker cannot succeed in computing a valid pair (m,h) where h is the correct HMAC value for message m, even if the attacker has access to many pairs (m',h') (where all m' are distinct from m). In particular, the attacker cannot guess the HMAC key, because obtaining the HMAC key would allow him to create a lot of forgeries.

Salts, and PBKDF2, make sense only if you envision that exhaustive search on the key might work. Salting and slow hashing (PBKDF2 does both) are mitigation measures to make life harder for the attacker in that case. In your scenario, the HMAC key is "strong", i.e. immune to exhaustive search (e.g. it is a sequence of 128 bits obtained from a cryptographically strong random source). Therefore, salts, PBKDF2 or other ritualistic elements won't make it any more secure. HMAC is already fine as it is.

Note that in the case of cookies, several users may collude and exchange their HMACed cookie values. A user could also record a cookie value, and send it back to you afterwards, even if the server sent him a newer cookie value. Depending on your usage context, this may or may not be a problem.


Could one create a vulnerable website on purpose to attack a server of a hosting provider? Is it possible for a vulnerability in one application to be exploited to attack another application on the same server?

So according to the answer to the question above it is possible that when one website on a server is vulnerable to remote execution it implies that all websites hosted on the same server could possibly be compromised.

Therefore I was wondering if one would create a website with this vulnerability on purpose. Then let it be hosted by a hosting provider. Such a hosting provider probably has somewhere around 50 websites hosted on one server.

Could this lead to compromise of all the other websites on this server? If no, how is this prevented? If yes, how could one prevent this?

Discussion on this question has lead to a new question regarding prevention of this thread:
How do hosting providers prevent the compromise of one website from causing the compromise of another one?

You wouldn't need the vulnerable website if you have an account on the shared hosting already. What you need is code execution on the host. A remote code execution vulnerability in one of the hosted websites gives you that, sure. But if you have your own account already, why not just upload whatever code you want to run?

I guess installing a vulnerable application could be a way to try to avoid being held responsible for the attack ("it wasn't me, I was hacked"). But it is not strictly needed.

Companies that offer shared hosting has to try to segregate the different accounts as much as possible. This is not always an easy thing to do. Vulnerabilities in the operative system or server misconfigurations can be exploited to gain access to other accounts. A good hosting provider could make such attacks hard by keeping software up to date and configuring things properly. But cheap is seldom good, and shared hosting is often cheap.


What's the use of adding a challenge to a one time password algorithm? In these YouTube videos Challenge-Respond Mode and  Sign Mode the customer enters a challenge into the CAP device before generating a one time password. Why not just generate the one time password directly?

I think this is to ensure that the response entered into the website is a fresh(ish) one. If the one time password was generated directly then it could be used at any point in the future, the server has no way of checking when it was generated. By providing the challenge to the card it means that the response generated can only be used for the transaction with the matching challenge.

Here's an example of an attack that takes advantage of the fact that a challenge isn't used for all online transaction or logging into your bank account:

  A similar attack could be performed with CAP. The customer, using a
  tampered Chip & PIN terminal, would insert their card and enter
  their PIN as usual. The terminal would then generate the necessary CAP
  responses, and optionally also carry out the legitimate transaction.
  Shortly after, the customer would receive a personalised phone call
  or email, stating that a suspicious transaction had been noticed
  (stating the shop name they just used), asking for their online
  banking credentials. Since Barclays only uses identify and sign mode,
  there is no server-provided freshness or a timestamp, so the
  previously collected responses can be used, provided the customer had
  not logged into online banking in the meantime. With NatWest, which
  uses respond, there is a server-provided nonce, so the fraudulent
  transaction has to be in near real-time, and account credentials would
  need to be collected before the CAP responses were generated. The
  banks could resist this problem by offering separate CAP-only cards,
  but NatWest refused to do so for one of us.

It's taken from Optimised to Fail: Card Readers for Online Banking by Ross Anderson, a paper that talks about the CAP protocol and its various vulnerabilities. His group have many other interesting papers as does their site on Chip and PIN.


Possible to use custom SSL or TCP/IP packets to detect VPN use? What custom TCP/IP packets or other statistics can I use to detect VPN usage?

I understand that this may generate a number of false positives, but my goal is to focus analysis on certain types of traffic.

Possible examples include:

Browser reports geolocation doesn't match expected latency to that site is much higher than expected
Ping with the DF set
Custom packet size + MTU tests
SSL protocol features (spdy? fido?)

I'm mostly interested in using SSL/TCP/IP/ICMP to detect such connections... as opposed to  browser-DNS leaks, flash, or other approaches, but think other people may find it interesting if you have such a non TCP based detection method.

I don't think you can look at connections and, by inspecting the packets, determine that a VPN is in use. VPNs are meant to look like regular connections.

The only solution I know of is one that blacklists IP addresses belonging to known VPN providers. That can be used effectively though it is a bit of an arms race as VPN providers try to get new addresses all the time to encourage the exact type of usage you are trying to prevent. This thread is an example of what happened when Hulu got the user's VPN IPs on a blacklist.

Even if you use a blacklisting service, you won't be able to identify all VPNs, especiallly if users run their own VPN on a VPS.

Sorry that I don't know of any blacklisting services to recommend but you should be able to find them in Google.


Interviews with staff members about privacy and security policies relevant to their positions I am currently working to help a bunch of small pharmacies remain compliant and one of the requirements is: Interviews with staff members about privacy and security policies relevant to their positions.

How do I determine what is relevant to their position or should I just go with a wider range talking about common sense about keep their devices with information secure and protecting client's health information.

Is there a NIST type of document that talks about key points that should be hit?

This is for a URAC compliance.

Compliance areas are:
PHARM Core 13 and Core 15

I don't know URAC, it appears to do with HIPPA based on cursory googling, though I would assume the context of what is trying to be achieved is the same as other sectors (for me finance).

I would say there are three categories that are important:

General Knowledge:

This would be everyone's responsibility. A common reference to this is your information security policy used organization wide, internet control polices, and user training around phishing/social engineering attacks. You can even lump best practices here.

Role Specific knowledge:

These are polices specific around your job and responsibilities. If you work with PII or medical records (IE you're a DBA) do you know the practices for access into the system, what level encryption or hashing is used, what the difference between PII and public information is.

Sector/Government Compliance Policy:

An example of this (for the finance sector) is the ABA, which is company wide training around laws and regulation to provide a check and balances policy. This is usually required by either a group or a government.


How can I keep usernames out of /etc/passwd on LINUX I've been challenged with auditing a systems security on a scenario and giving various areas we have to audit. Most of which were easy to understand and to provide vulnerabilities as well as mitigating them. However One of them is usernames, in which I have no clue whatsoever. I was guided and told to use sudo su and less /etc/passwd to see a list of usernames, easy enough.

The only potential vulnerability is that you can't crack/use a password to gain access to an account if you don't have a username, so what could anyone do to mitigate that? It's had me stumped for weeks.

You could mitigate this by using an external server (perhaps LDAP, Samba, NIS, ..) for user authentication, and either using a network filesystem (NFS, Samba, ..) for home directories, and/or making those based on UID rather than username.

If you decide to implement this, double-check the network authentication doesn't stuff entries into the password file - IIRC, some systems do this.

Although usernames aren't often seen as a risk, it's 50% of the information needed in a user+password/key authentication mechanism - and it's why a well behaved login mechamism will say 'bad username or password' and not 'bad password'.

Another consideration is that in some circumstances, a username maps easily to an email address, so can be used by an attacker to harvest useful data.

A more paranoid consideration is that on a multi-user solution, an authorised user who wants to hack would probably want to work under someone else's login.


Why is it recommended to use accounts without sysop rights for everyday work? Another recommendation I fail to understand.

The explanation is that, if I use admin account and manage to have my computer infected, the malware is able to take control over my entire system. But:

The dreaded days of old Windows systems are long gone: nowadays, Windows has UAC, which effectively makes an admin account behave like a standard account, unless the user explicitly authorizes a program to have administrative privileges;
Unixlike systems have (almost?) forever had sudo and similar facilities;
In my LinuxMint installation, I have to escalate to root privileges (via the aforementioned facilities) almost daily: this is required each time updates are to be installed. And even each time I need to format a USB stick. Logging out to a separate admin account each time that happens would be most tedious;
The above problems can be leveraged by suing t from the standard accouninto the admin account and doing the work from there; but I suppose, if sudoing from the admin account is, for some reason, a problem (as the recommendation not to use the admin account still stands), so can be suing into the admin account from the standard account;
Even if malware gets installed only on my standard account, with no means to escalate to admin privileges, I'm still screwed. It can add itself to autostart, it can encipher my files, it can spy on my files, it can relink shortcuts and disguise itself as a legitimate program (like Firefox) and steal my passwords from there, etc.

Given the existence of UAC and sudo-like facilities; Given the aforementioned concerns; I fail to understand the basis of the recommendation to always use regular accounts for everyday work and not admin accounts. And yet the recommendation stands. (I'm hearing it over and over, last time I read it on Niebezpiecznik.pl, a popular and acclaimed infosec blog, as one of their 10 recommendations for "Average Joes".)

Why does such recommendation stand? What am I failing to understand?

You misunderstand. The recommendation is to use sudo and elevating permissions through the windows built in thingy (where you enter credentials of admin account) instead of using root account or su or admin account by default.

If you use su or root account, you give root permissions to everything you run. If you use sudo, you only give root to apps that need it and hopefully only well trusted apps. This reduces chances of malware getting root access. Even apps that are not malicious by themselves may not be designed to be run as root and have vulnerabilities if they are. A good example of this are web browsers.

On windows, the important thing is UAC does not protect against file permissions. So an app run by admin even without UAC admin privileges may have access to files and folders an app run by normal user would not have access to.


How secure is the Windows Credential Manager? I'm a Lastpass user and many times I thought about switching to the Credential Manager, for auto sync and a certain comfort with the windows environment. The only thing that I'm worried about is its security. I heard that it's quite easy for someone to access these credentials once they've gained access to your computer, is it so?

Should I stick with Lastpass and maybe check in future for eventual improvements?

The Windows Credential Manager is anything but secure. It's "secure" at the user account level, which means that any process that the user ever runs and the user themselves must necessarily be trusted in order to call this system "secure" with a straight face.

The only semi secure way of using the Windows Credential Manager is to store values pre-hashed, then verify those hashes. However, since any elevated process the user runs has full read/write capability on that user's credential store, it simply can't be trusted at all.

Lets think about "secure" in the sense of locking an application locally. Let's take the example of a content filter that locks the settings page to keep the kids from enabling adult content, using the Credential Manager to store custom credentials. The same user, trying to bypass this, can do so easily. A user can visit the Credential Manager in the Control Panel and, though the values show up in asterisks, (*****), they can simply erase the value and replace it. Delete your hash, put in their own they're in.

What's even sillier is that the Control Panel will show asterisks, but if you use code accessing the applicable APIs, you can get the values in plain text. So passwords are not safe, hashes and such you verify to lock something are not safe. It's not safe, it's a piece of garbage and I've struggled for a long time to understand its usefulness, except for Microsoft to apparently have plain text copies of all of your passwords they can sell to the NSA.

Note
I realize there are measures you can take to encrypt contents before storing them, hashing them correctly etc, but my criticism still applies because doing these additional things is creating security, not the Windows Credential Manager. My problem with the Windows Credential Manager is that it advertises that using it through its provided GUI and or API is secure.


Looking for approach to implement attribute based access control (ABAC) We are looking to implement Attribute-Based Access Control. While we are sold on the philosophy, there are two topics that seem to crop up:

Will it lead to significant performance issues? Especially if we seek fine-grained access. I guess I am looking for some structured guidance to strike the right balance.
Are available PEPs capable of implementing XACML? My colleagues who checked IBM and Oracle aren't very comfortable that it is ready for enterprise yet.

Disclaimer: I work for Axiomatics, the leading ABAC/XACML vendor.

I am glad to hear you are sold on the philosophy of ABAC. If you haven't already done so, do check out the following resources (I'll spare you commercial links):

NIST ABAC project page and report.
OASIS' A brief introduction to XACML
A quick intro to ABAC with XACML.
Gerry Gebel's blog (Former VP and Service Director for Burton Group Identity and Privacy Strategies)
Gartner's Predicts 2014: Identity and Access Management

Now, with respect to your questions directly:

Will it lead to significant performance issues- esp if we seek fine-grained access? When you plan for and architect an ABAC solution, the two main points you want to consider and that may impact performance the most are the PEP to PDP communication link (where PEP is the enforcement point that protects your applications and PDP is the decision point that processes authorization requests and evaluates authorization policies) and the PDP to PIP links (where the PIP or policy information point is the bridge to attribute sources e.g. LDAP, databases, web services). Policy evaluation in itself is not expensive at all. Whether access is fine-grained or not will not necessarily impact performance. What will, though, is how you exposed the authorization service (the PDP). If you expose as a SOAP service then you introduce the latency of a SOAP service. If you expose it via a binary protocol e.g. Apache Thrift then the performance is much better. Similarly, if you need to retrieve 10 attributes from 10 different sources and if each source has a long latency then the performance will be poor. But you can always choose to bundle attribute lookups, to consolidate your attribute sources and to cache attribute values. The bottom line is yes ABAC can perform correctly if architected correctly. To give you an example, PayPal uses Attribute-based access control and their performance is fine. Some of the bigger Fortune 50 companies all use ABAC while at the same time having strict performance requirements. The diagram below illustrates all 6 points where you can enhance performance.

how policies are loaded into memory (1)
how policies are evaluated (2): if you build a good policy structure, you can quickly eliminate up to 90% of an authorization policy before you fully evaluate it.
how attribute values are fetched from PIPs (3). This is the main point to consider as previously stated. There are several techniques to reduce the performance impact of this integration
how authorization decisions can be cached on the PEP side (4).
how authorization requests can be bundled together into a multiple decision request: this saves roundtrips between the PEP and the PDP (5)
lastly, and perhaps most importantly, how the PEP and PDP communicate - as previously mentioned. Just choose the protocol that works best for you (embedded, binary, SOAP...)(6)

Are available PEPs capable of implementing XACML? Yes of course there are. Several vendors such as Axiomatics (likely not the big ones like Oracle or IBM) and open source implementations provide PEPs. See as an example this list. There are integrations with off-the-shelf components as well. For instance Fedora provides ones for its OS. There is one for SAP. Axiomatics provides one for SQL databases (Oracle, SQL Server...). One can also protect CMS such as SharePoint and Liferay. Also check out the OpenAZ project.

Have your colleagues only looked into IBM and Oracle? The main players are definitely not those two but rather the smaller vendors and the open-source community.

As Gartner recently stated, ABAC is the way to go. They predict 70% of organizations will adopt ABAC by 2020. Now's a good time to start.


Security risk among shared wifi users I understand that the shared users on a wifi can see each other's HTTP traffic using proper tools. Is it possible for shared users to read HTTPS traffic or encrypted traffic like TOR ?

The referenced duplicate does not explicitly address encrypted traffic by HTTPS and TOR. That httpS encrypted traffic can be accessed and whether or not users that share a WiFi network use WiFi encryption. That part is explained in the referenced 'duplicate'.

Decrypting the accessed httpS or TOR traffic is another topic. It may be interesting to know that banks in Netherlands recently advised against using httpS over public (encrypted or not) WiFi because of MitM /SSL stripping attacks. see https://www.security.nl/posting/389223/Banken%3A+niet+internetbankieren+via+open+wifi-netwerk  (sorry in Netherlands)


Generate password list with specific keywords and length I need to generate a list of passwords to try penetrating into a wi-fi network. I have a pretty big list of keywords and I want to use them to generate as many possible passwords as possible, which will be in a specific range in length.

For example I need a password with keywords "dog", "cat", "bird", "sun", "tree" with length from 4 to 10, so my password list will include passwords like: birdcat, suncat, suncatdog, treebird etc.

I've read the documentation of Crunch tool, but it doesn't look like what I need. Maybe I'm wrong. So I ask you if it is possible to generate such lists and what tools should I use (I use Linux Kali and Mac OS if it is necessary information) and how it can be done?
Thanks

The most precise and flexible mechanism to perform a combinator attack with multiple combination lengths plus length restrictions is probably to combine princeprocessor with the len utility from hashcat-utils:

$ cat list.txt
dog
cat
bird
sun
tree

$ pp64 <list.txt | len 4 10
bird
tree
dogdog
catdog
sundog
dogcat
catcat
suncat
dogsun
catsun
[...]
birdcatcat
treecatcat
birdsuncat
treesuncat
birddogsun
treedogsun
birdcatsun
treecatsun
birdsunsun
treesunsun

You don't mention whether there is a minimum number of elements (words); princeprocessor has options for that as well.

While efficiency isn't as much of an issue for a slow hash like WPA2, pp64 and len are optimized for high speed, and so are also useful for faster hashes as well.


Does Android encryption really prevent law enforcement access? Google recently announced that in Android L encryption would be turned on by default:

  For over three years Android has offered encryption, and keys are not
  stored off of the device, so they cannot be shared with law
  enforcement. As part of our next Android release, encryption will be
  enabled by default out of the box, so you won't even have to think
  about turning it on. (Reported by The Washington Post 18-Sep-2014.)

Currently, if I have an Android phone and I have a Google account associated with that phone, if I forget my phone's PIN I can still get by using my Google account credentials, at least according to Recover Android Device in case of Forgot password/pattern unlock an Android device.

How does turning on encryption by default help protect against law enforcement accessing the device's data if law enforcement can go to Google and get them to reset the user's Google account credentials and thereby get around the PIN? (Let's assume that the device we are considering has a PIN and a Google account associated with it.)

Disk encryption only protects your phone when it is turned off (i.e., it protects data at rest). Once the device is turned on, data is decrytped transparently, and (at least with the current implementation) the decryption key is available on memory.

While Android uses the device unlock PIN/password to derive the disk encryption key, the two are completely separate. The only way someone can change your disk encryption password is if there is a device administrator application installed that allows remote administration (or they have a hidden backdoor you don't know about, but in that case you are already owned). UPDATE: the Google account fallback has been removed in 5.0+.

The article you link seems to be rather old and out of date. In current Android versions, login with Google account is only supported as a fallback to the pattern unlock (not the PIN/password) one, so if you are using PIN/password you are generally OK. Again, this only works if the device is already on, if it is off, they will need the disk encryption password to turn it on (technically to mount the userdata partition).

That said, because the disk encryption password is the same as the unlock password, most people tend to use a simple PIN which is trivial to bruteforce with the current implementation (slightly harder on 4.4 which uses scrypt to derive keys). Android L seems to have improved on this by not deriving the disk encryption password directly from the lockscreen one, but no details are currently available (no source). It does seems that, at least on Nexus devices, the key is hardware-protected (likely TrustZone-based TEE), so bruteforcing should no longer be trivial. (Unless, of course, the TEE is compromised, which has been demonstrated a few times.)

BTW, turning encryption on also helps with factory reset, because even if some data is left on the flash, it will be encrypted and thus mostly useless.


OS login password: How does it work? I am making an application to create a password for a user. I am a bit baffled over how it all works though. Namely I want to be sure that my application will store the correct hash so the user can actually login!

I found this code:

pwhash=$(echo $password | mkpasswd -s -m sha-512)

Now if I run the same password I get two totally different hashes:

$ echo 'test' | mkpasswd -s -m sha-512
$6$QRsW.mu9wC$CSvMrGkfU6.lu14.sNRrZ8Kiyi0zUdlcAH1VBBd.LoTZDmehuoGnsaywm/WD.9GARwINQnp3jJzxQHWlCk3RI0
$ echo 'test' | mkpasswd -s -m sha-512
$6$rN7ishjxd89AjMS$HpN53OoL3m81rPyrKFgpm2Nm2YWJ96nP4gNLu4GO0Jjy9K6lVhB6v7c0L7/998h74oTMGFzLK6w4zku7U3soW0

So this to me shows just how little I know. If the same password generates two different hashes, how can the OS know that I entered the right password in the login screen? What will it compare the entered password hash with?

Also a bit about salt.. the salt is supposed to always be different, so how can the OS know what salt to use for the password at every login attempt?

You get different values because different salts are used. The salt is the second field in the hashed password.

There exist large rainbow tables that make the lookup of hashes of common passwords very cheap. The point of salt is to dramatically increase the cost of precalculating hashes for all commonly used passwords. So salt basically makes a password uncommon. That is, it makes a password so long and random that it is unfeasible to precalculate the hash for all common passwords for all possible salts.

Given that the goal of salt is to prevent successful precalculation attacks, it doesn't need to be a secret, it just needs to be long and random. This allows the salt to be stored in clear-text along with each hashed password. This is fortunate as the salt is needed to validate the password when the user authenticates.

An example of a bad implementation of salt would be to use a single byte. In that scenario an attacker could precalculate all hashes for common passwords for the 256 possible salts. That is expensive but not expensive enough. That salt isn't large enough.

Another example of mis-salting is to use the same salt on every password. That allows an attacker to precalculate a single table that contains the hashes of all common passwords for that one salt. This would be expensive but much cheaper than having to create a table for each password. That's why each password hash has its own salt.

Edit: Salting does not reduce the cost of brute-forcing a single password. Salting just forces you to brute-force passwords instead of precomputing their hashes. You protect against brute-forcing by using a slow hash function and calling it many times on successive output of itself. For example, running bcrypt (which is designed to be slow even with a GPU or other specialized hardware) 1024 times. While PHP stores the number of iterations in the password field, on Linux the number of iterations is configured by the PAM 'rounds' option. Several users here say that the default for their Debian Linux install is 1000 iterations for SHA-512.

Of course, no answer about passwords is complete without a reference to this answer, a detailed explanation about the state of the art for password storage.


Does syncing local data to the cloud count as MFA? Bitwarden uses TOTP as the multi-factor authenticator method for their password manager. Bitwarden stores and syncs your data so you need the master password + TOTP to get access to your account
Assuming we ignore Keychain, Enpass does not have an MFA method. Enpass is, however, stored locally and can be synced by the user on a cloud storage device of their choosing. Does this count as MFA or is it a less secure model (i.e: someone would have to first break into my cloud storage account and then bypass the master password)? I would use google drive as the cloud storage device for the Enpass encrypted database.

No, syncing to cloud isn't MFA. It's syncing. And you are mixing several different things on the same question.
On Bitwarden, you have an account. It's the same as having an email account, or a forum account. To access it, you need credentials and have an option to use TOTP. If you enable TOTP, you have MFA - or 2FA in this case. If you needed password plus TOTP plus magic link sent by email, it would be 3FA.
You log in at Bitwarden and have access to your passwords. And that is different with Enpass.
Enpass, on the other hand, does not have an account per se. You can login there, but that account does not have anything to do with your password database. You can only buy more features with that login. The database is kept locally, encrypted. You can sync online like Bitwarden, but it syncs only an encrypted blob that is useless without the master password.
I am an Enpass user for yers, and I prefer how it works over Bitwarden in this respect.


How can I escape Google? I am unsure how to formulate this question, so please feel free to edit it.

I considered asking on https://android.stackexchange.com/ but feel that this is more security related and more likely to be answered here.

I want, so far as is possible, to avoid Google (or anyone) scanning my emails, tracking location, using me as the product.

I use a laptop running Windows (which I can't change for business reasons); I can use my own (someone else's which I pay for) servers, which might make email more secure. Plus an Android 'phone.

Let us assume that I am willing to eschew all Google products; which, for me is Gmail & Google maps.

Q: if I factory reset my phone, will Google recognize me when I next use it? I presume so, as they have at least a fingerprint of hardware/installed apps/whatever.

In any case, if I use the same SIM card, I image they will tie me to the device.

Q: would a new 'phone help? If I did not get  a new SIM/'phone number?

Q: what if I get both a new SIM card/phone number and a new 'phone number simultaneously?

That might work for a while, I guess, by how do I install new apps? I guess I could make a single use Gmail address, only for app install.

I have never used FaceTweet or even YouTube. Only LinkedIn - and am happy to use that in private mode, via a VPN.

I am willing to make some effort, but not extremis.

Question: can I avoid Google, et al, become "newborn", and remain untracked?  Or are things like tracking cookies too ubiquitous, such that just one slipping through the cracks will pw0n me & I may as well welcome out new Goooglian overlords?

Two initial points to start:

Location tracking

If you don't want to be location-tracked, you cannot carry a smart phone, or flip phone with a cell provider contract.

The phone you carry on high frequency intervals is communicating with cell phone towers, constantly, 24/7, establishing its triangulated position with them and confirming its ability to receive calls and to transmit data. The service provider records this location history and may share it in some aggregated or sampled form with third parties that you have never heard of (along with some you have).

The phone of course has a number of hardware components the IDs for which are included in these communications and are unique, so individual physical phones have individual histories. In terms of associating those histories with specific humans, all providers make it possible for third parties to have business arrangements wherein it becomes possible to associate those IDs with specific customer account data- name, snail mail address, etc.

There are numerous third parties that had previously built out historical databases of names, including spelling variants, and snail mail addresses, and turn those into whole family histories- parents, grandparents, siblings, children- along with neighbors and other coarse location associations. Some of these are participating in more granular cell-based location tracking arrangements.

Third parties are sometimes not supposed to use this data for certain purposes, or to save it for an extended period of time, and in general they can be trusted only to completely fail to not use this data or to not save it for an extended period. From time to time these failures and the resulting exposures are egregious enough that they make the news.

(Note that if you also leave wifi on, the same is happening with hot spot providers, who are under even less obligation to not do whatever they want with the observation that MAC address x:y:z comes into range of hotspot 12345 every Friday night at 11pm, etc.)
Google

If in particular you want to not leave a data footprint with google, you cannot own or use an Android product. The Android OS is in frequent communications with Google servers to convey various sorts of telemetry. This happens independently of whether you are using any Google-branded apps.

I have not studied what happens if you use a third party OS on Android hardware. They are all to a degree based on the upstream Android source. My scepticism is that all traces of interactions with Android server infrastructure, under all edge cases and so forth, had been excised, would be high.

If you do not want to leave a data footprint with Google then you also cannot visit any websites, because nearly all of them use Google Analytics.

So, with that background, the specific questions:

  Q: if I factory reset my phone, will Google recognize me when I next use it? I presume so, as they have at least a fingerprint of hardware/installed apps/whatever.

A: Yes. Phones have unique hardware identifiers. Those identifiers are not changed with a factory reset.

  Q: In any case, if I use the same SIM card, I image they will tie me to the device.

A: There is a difference between the cell service provider- for whom the SIM card services as a unique identifier- and Google- which has its own identity infrastructure based on Gmail accounts. Google servers receiving network traffic that originated from the device then comes to Google from the cell provider egress are able in many cases, though not all, to associate that traffic with a unique account at a cell provider. But Google's identity management is not based on the SIM.

  Q: would a new 'phone help? If I did not get a new SIM/'phone number?

A new phone, in order to use the cell network, needs to be associated with an account, and that account has to have an identifiable owner- either a person with a name, SSN and address, or a business with a name, TIN, and address. So as long as you have a SIM tied to an account in your name with a cell provider, your use of whatever physical phone with that SIM will associate telemetry data with that account.

  Q: what if I get both a new SIM card/phone number and a new 'phone number simultaneously?

See above. One has to think about the concept of "account" in a different way.

  Only LinkedIn - and am happy to use that in private mode, via a VPN.

Neither of these things matters if you are authenticating with LinkedIn. All that's happening in "private" mode is that the permanent cookie LinkedIn wants to save with your browser doesn't get saved. But as long as you authenticate- surprise- they know it's you!

Similarly, VPN makes little difference. Sure, the IP address you seem to be coming from may be the VPN provider's, but many VPN setups are broken and the real IPs are easily leaked. There are also numerous tells in searches and communications on LinkedIn that can inform regarding the location of the account. LinkedIn has relationships with third parties with whom some of this data, at coarse levels of granularity, is shared.

  I am willing to make some effort, but not extremis.

This is the most important point to follow up on. What exactly is the concern with location and other kinds of tracking?

At the end of the day, ad targeting, while unpleasant, in the US at least is largely innocuous.

There are plenty of places around the world where tracking of various kinds is not innocuous, and where there isn't even the pretence to various forms of privacy. But usually the concerns in those cases center more directly on various authorities and less on specific companies.


Is it possible to examine a Huawei device to answer definitively whether or not there is a security risk? There has been a lot of news lately, and in the last few years, about Huawei being a security risk.  Can someone explain what the basis is for the risk, other than speculation?  Is there not a way to examine Huawei devices to see if there is indeed a chip, bootloader, backdoor, etc that could be exploited?  What potential dangers exist in Huawei devices made in China, but not in other devices made in China, like those from Apple?

This article from the MIT Technology Review says that the U.K. has been vetting Huawei gear before deployment. It provides for only a limited level of assurance. The risks are loss of privacy, espionage, and sabotage.
I left the electronics/computer industry years ago but I think the following views are still applicable to the state of the art.
If espionage is intended, the manufacturer can make a device's code hard to access and inspect. A flash memory device might be part of a system-on-chip or system-in-package that obviates the need to present memory lines on the surfaces of the package. This would make code very inconvenient to access. In the extreme you may resort to using a scanning electron microscope (SEM). Courbon et al used a SEM to read a 210 nm flash memory. (The article is not dated but the most recent reference is from 2015 so the paper is at least as recent.) If you can access the code, you may then find that it was obfuscated. Obfuscated code is created when the programmer uses a program to turn the original code into a Rube Goldberg machine. Whether this is effective in hiding backdoors is debatable.
A custom chip can be a mystery. A chip "normal" in every way except identification looks like a mystery. A manufacturer can simply print phony or confusing identification on one or more of the devices on a board. A device can be made to look standard when it is in fact not. If any well funded entity were to invest in hiding or disguising functionality, it would take a huge amount of research to determine the "true circuit" of any single design . Until you know the true circuit, any inspection of the code provides no real assurance.
If you believe you need to go to much trouble to determine the true circuit and inspect code for a backdoor you may be better off just designing and building your own telecommunications equipment. More realistically you would install intrusive oversight in design, manufacturing, support, and updates and perhaps take over corporate governance through the nationalization of a maker.
If you are not going to be intrusive you are implicitly accepting a certain amount of risk and you are perhaps relying on commercial pressures to keep the manufacturer honest.
If updates are disabled, you might conclude that a particular design is not a security risk after a certain amount of effort. You would not know if the effort made is insufficient and that a larger effort is needed. It may not be practical or even safe to disable updates. As soon as the code is updated you do not have any assurance. You may not be aware of the event of an update if the manufacturer tries to be stealthy.


length of a session key in EC? In elliptic curve cryptography what should be the length of session key? Is there a specific metric to choose one, or are they randomly generated?

I was studying one paper about defence against a Sybil attack. In the initial deployment stage of a vehicular ad-hoc network based on roadside unit support they used 16 bytes, but they gave no explanation why.

ECC is less of an encryption algorithm and more of an algorithm construction kit (some pieces not included).

Not all curves are created equal, and key size (both allowable and recommended) are dependent on the curve chosen. See the literature associated with each given curve for details relating for that specific curve.


Secure Session Cookies While looking up methods for creating secure session cookies I came across this publication: A Secure Cookie Protocol. It proposes the following formula for a session cookie:

cookie = user | expiration | data_k | mac

where

| denotes concatenation.
user is the user-name of the client.
expiration is the expiration time of the cookie.
data_k is encrypted data that's associated with the client (such as a session ID or shopping cart information) encrypted using key k.

k is derived from a private server key sk; k = HMAC(user | expiration,
sk).
data_k could be encrypted using AES using the key k.

mac is an HMAC of the cookie to verify the authenticity of the cookie; mac = HMAC(user | expiration | data | session-key, k).

data is the unencrypted data associated with the client.
session-key is the SSL session key.

HMAC is HMAC-MD5 or HMAC-SHA1.

According to the paper, it provides cookie confidentiality, and prevents against replay and volume attacks. To me (being an amateur in security/cryptography) this looks pretty good. How good is this method for session cookies or cookies in general?

Yes, this does look like a pretty good scheme for protecting cookies.

Another more recent scheme in this area is SCS: Secure Cookie Sessions for HTTP, which is a solid scheme, very well thought-out.  I recommend reading the security discussion of that document to get a good sense of what the security threats may be.

To help understand the purpose and role of the cookie scheme you mention, let me back up and provide some context.  It is common that web applications need to maintain session state: i.e., some state whose lifetime is limited to the current session, and that is bound to the current session.  There are two ways to maintain session state:

Store session state on the server. The web server feeds the browser a session cookie: a cookie whose only purpose is to hold a large, unguessable bit-string that serves as the session identifier.  The server keeps a lookup table, with one entry per open session, that maps from the session identifier to all of the session state associated with this session.  This makes it easy for web application code to retrieve and update the session state associated with a particular HTTP/HTTPS request.  Most web application frameworks provide built-in support for storing session state on the server side.

This is the most secure way to store session state.  Because the session state is stored on the server, the client has no direct access to it.  Therefore, there is no way for attackers to read or tamper with session state (or replay old values).  It does require some extra work to keep session state synchronized across all servers, if your web application is distributed across multiple back-end compute nodes.
Store session state on the client.  The other approach is to put session state in a cookie and send the cookie to the browser.  Now each subsequent request from the browser will include the session state.  If the web application wants to modify the session state, it can send an updated cookie to the browser.

If done naively, this is a massive security hole, because it allows a malicious client to view and modify the session state.  The former is a problem if there is any confidential data included in the session state.  The latter is a problem if the server trusts or relies upon the session state in any way (for example, consider if the session state includes the username of the logged-in user, and a bit indicating whether that user is an administrator or not; then a malicious client could bypass the web application's authentication mechanism).

The proposal you mention, and the SCS scheme, are intended to defend against these risks as well as possible.  They can do so in a way that is mostly successful.  However, they cannot prevent a malicious client from deleting the cookie (and thus clearing the session state).  Also, they cannot prevent a malicious client from replaying an older value of the cookie (and thus resetting the session state to an older value), if the older version came from within the same session.  Therefore, the developer of the web application needs to be aware of these risks and take care about what values are stored in session state.

For this reason, storing session state in cookies is a bit riskier than storing it on the server, even if you use one of these cryptographic schemes to protect cookies.  (However, if you are going to store session state in cookies, I definitely recommend you use one of these two schemes to protect the values in the cookies.)

Why would anyone store session state in cookies, given that it can just as easily be stored on the server side?  Most of the time, there is no reason to.  However, in some exceptional cases -- such as a HTTP server that is extremely constrained in the amount of storage it has, or in load-balanced web applications that are distributed across multiple machines without good support for synchronized session state -- there might be justifiable reasons to consider storing session state in cookies, and then using one of these schemes is a good idea.

P.S. A related topic: if you use ASP.NET View State, make sure you configure it to be encrypted and authenticated: i.e., configure ViewStateEncryptionMode to Always and EnableViewStateMac to true; if you use multiple server nodes, generate a strong cryptographic key and configure each server's machineKey to use that key.  Finally, make sure you have an up-to-date version of the ASP.NET framework; older versions had a serious security flaw in the ViewState crypto.


How could mobile developers prevent bypassing certificate pinning with tools such as SSL Kill Switch? I used SSL Kill Switch on some iOS mobile applications to try to bypass certificate pinning and I was successful. I understand that SSL Kill Switch "kills" the certificate validation process on the clients side and this is how it works. However is there any way that developers could somehow prevent this from happening? Is this an indication that the certificate pinning wasn't successfully configured?

From the github readme for the iOS SSL Kill Switch project:

  Once installed on a jailbroken device, iOS SSL Kill Switch patches low-level SSL functions within the Secure Transport API

So your question basically boils down to: "How do I prevent my app from being infected with malware on a rooted / jailbroken device?". In short: you don't. This is why you don't root your device!

There are obfuscation tricks you can do to make this harder; for example write your own in-house SSL / TLS library (terrible, horrible idea, don't do this!), and then include this crypto in your compiled program so that there's no dependency on the OS's crypto libraries. Now you're immune to a hack in the OS's crypto layer, but if the attacker is targeting your app specifically then there's nothing to stop them, so you're not preventing an attack like this, just making it more difficult.

Another trick I've heard of is for the app to try to detect if it's running on a rooted device, and refuse to run if it is. That said, if you google "bypass jailbreak detection" you'll see that there is a constant game of whack-a-mole going on between hackers and developers where the hackers are getting increasingly clever at hiding the jailbreak. I don't recommend playing this game.


Encryption key split into parts and stored in different places Say, I have encrypted data in a database. How wise is it to break a secret encryption key into several parts and save each one in a different place?

Namely:

key1 = get_key1_from_remote_server()
key2 = get_key2_from_env_variable()
key3 = get_key3_from_some_protected_storage()

full_key = key1 + key2 + key3
enc_data = encrypt(data, full_key)

Thus a hacker will have to gain access to all those locations to decrypt data.

Is this more secure than to have a whole key stored in one place?

That depends a lot on your ceremonies. It sounds like your encrypted data is on a computer connected to the internet, isolating the computer would be a better way to increase security. If you are decrypting the data often it is also not that helpful, an adversary could watch you put together the split key and then use this assembled key later.

Secret sharing does cover some of this theory and might show where this idea is used, also shows that instead of just concatenating the spit keys together you should do something a little bit more complicated.


What's this kind of authentication scheme called? In the past I've heard about a scheme to prove your identity online in places like forums, without having to create an account.

When posting, the user would enter a password which is then heavily hashed and displayed publicly along with the post. This way the user can prove his identity between posts without having to create an account with a fixed name and password.

I'm not sure what to Google for. So far I've found the term "commitment scheme" on Wikipedia, but googling further on that, I can't find other places using it (though I'm sure there have to be some).

Does this kind of commitment scheme (publicizing a password hash) have a name?

Displaying a hash of nick and password to identify users is known as Tripcode.

There are different variants of this, sometimes the website operator adds a secret key, sometimes an expensive hash like PBKDF2 or bcrypt is used, sometimes the password is replaced by public key.


capture authorization code programmatically in OAuth 2.0 In a standard OAuth auth code Grant flow, user is redirected to authorization server page where he provides consent to allow the requesting app to perform some actions on his behalf, after which a browser redirects the user to a redirect URI with auth code. Application then exchanges this code with authorization server to get an Access token..

Consider a scenario where user has already given consent or consent is somehow implicit (i.e., user is not required to interact with the authorization server consent page).. in this case, is it acceptable to use an http client with redirection disabled as the user agent instead of browser and capture the Location header of the redirection response from the authorization server ?

Yes, this is fine, as long as the request is done over HTTPS. From a security perspective there's no difference between having your browser do it and having a different application do it.


How to get rid of ad.doubleclick.net malware? I can't get rid of ad.doubleclick.net malware from my PC.

I am using Firefox and it seems that all links that lead to www.googleadservices.com are redirected to https://ad.doubleclick.net/ddm/*** which can't load it self.

So if I click the below link

I get this result:

I tried AdwCleaner from Malwarebytes but it did not find any malware on my PC. I also disabled all add ons. There is no ad.doubleclick software installed on my PC that I could remove.

This problem happens in Firefox aswell as in Chrome (I have only those two to test).

Any suggestions how I can get rid of this?

ad.doubleclick.net is not malware. It’s an advertising link retuned by Google to redirect your browser to the desired site. DoubleClick is Google’s advertising company. They use this referral scheme in order to track your browsing habits (to learn what words you searched for that led you to click on their ad), and for Google to collect a referral bonus for displaying such a good advertisement that you clicked on it. You are just seeing an error because your browser can’t get to their servers.

The error you’re seeing is because you have ad.doubleclick.net blocked in your computer somehow. You may be browsing using a “proxy” that is blocking that address; your router or firewall may be blocking the doubleclick.net domain; you may have blocked doubleclick in your hosts file; you may have installed a DNS ad blocker like pi-hole; or maybe you have installed any number of tools that might block these requests.


Why is Home --> VPN --> Tor worse than Home --> Tor? I've read lot of questions asked on various websites about the pros & cons of using a VPN with Tor. As said on Tails website VPN make the situation worse by introducing a permanent entry guard or permanent exit node.

Let's focus on the permanent entry guard. I feel like saying this is worse implies that my ISP is more trustworthy than the VPN provider. Indeed, one would say my VPN provider can see I'm using Tor and would give me away to authorities if they are forced to. Yes, that is true but my ISP would do the exact same thing and more over in some countries ISP are monitored (France for example).

So I really don't understand why setting up a VPN before Tor is less secure than relying on my ISP ?

EDIT :

Let's assume here the threat is high like a journalist in a non-free press country or one that wants to disclose sensitive informations about states. We could also think about someone doing illegal activities (drugs and arms trafficking..)

He would be using Tails OS from his personal home. (What an idea !)

--> Looking at first answer, does a token-based/BTC VPN would change the answer ?

Preface: I consider this question to be a false dichotomy and an inversion of the burden of proof. One of the core tenets of building secure systems is that you minimise the attack surface, and resist additional components and features wherever possible to keep in line with this. As such, if one cannot identify a strong reason to include a component in the system, and quantify that reason against the threat model, the additional component should not be included. This question is worded in a way that assumes that the VPN provides some benefit, and that removing it is what should be questioned, when in fact the inverse is true: the correct question should be whether adding a VPN layer to Tor provides any tangible benefit. Only when such a benefit has been affirmed should we entertain including it.

What follows is my original answer to the question before I added this preface.

This depends on your threat model, local laws, OS setup, behaviour, and a number of other factors.

For example, let's assume you're a journalist trying to keep your identity quiet because you're studying a police corruption case. If your country's ISPs are protected by common carrier rules (i.e. the messages sent are legally protected in the same way that physical mail is) then transmitting content via the VPN is risky - the VPN provider isn't a common carrier and therefore doesn't have the same legal protection, but certainly does have information about you (billing information).

You've also got the problem that you're adding an additional point of failure. Your security relies upon both the VPN and Tor being safe - compromising one of the two means you're identifiable. Additionally, by connecting to a VPN you usually have routing rules which send LAN traffic through the VPN. This means that non-Tor data (e.g. NetBIOS, WINS discovery packets, DNS, OS / application update queries, etc.) might get sent through that same VPN channel, resulting in a log of your Tor and non-Tor behaviour occurring at the same time through the same endpoint.

The other problem is that commercial VPNs marketing themselves as privacy tools are obvious targets for threat actors. This means that by using the VPN, you might actually end up in a situation where someone has already compromised the server - it's not like you've got annual pentest reports from the VPN provider to take a look at and check they're running sensible and up to date systems. The benefit of Tor, in this regard, is that the communications are decentralised and distributed, which makes it much more difficult to focus attacks and traffic analysis from a logistics perspective.

I'd argue that the benefits of running Tor over a VPN are tenuous at best. The promise of additional privacy or security isn't backed by anything tangible or measurable, aside from the perception that complexity adds security.

Regarding your edit, if the person is using Tails and safely uses Tor, it makes no difference whether you just use Tor or use a VPN with Tor through it really. Which comes down to the crux of it: what does adding a VPN give you? I can't see any case where it provides any additional anonymity, particularly against a nation state, and then you've got the problem that if you're connected to some open WiFi somewhere (e.g. a cafe) you're then potentially tying your identity (from the VPN billing details) to your location, and the fact that you're using a VPN plus Tor. Not ideal if you're a journalist in an oppressive state, or a drugs trafficker trying to keep himself hidden.

Regarding your comment below as to why the VPN might be an addition point of failure, consider that some states would consider you in violation of a law if you simply used Tor. If you only use Tor, it becomes quite difficult to identify who you are if you're using public infrastructure like open WiFi or municiple networks. Once you add the VPN in, you add a direct purchase record back to your name and address. Not ideal.

At the end of the day, designers of secure systems should be resistant to adding additional components and features, due to the additional complexity and potential for unforeseen problems. This means that you should consider what benefit is added by including a VPN in your chain. I can't really see one, aside from a situation where use of Tor would be illegal but use of a VPN to another country would not be illegal (I'm unaware of such a case existing).

One additional potential issue, which I forgot to mention above, is the increase attack surface against the client-side. By adding in a VPN client on top of the Tor client, you've got another piece of software which may contain bugs (e.g. remote code execution).

As an aside, I'd also like to point out that VPNs are not and never were designed to be privacy or anonymity tools. They are marketed as such by people who sell VPN services, but any anonymity or privacy you gain from them is incidental rather than purposeful. They cover but a fraction of the threat landscape in this space; mostly they're only useful as a tool for avoiding ISPs' blocking of certain sites (e.g. torrents). Nobody who is serious about anonymity and privacy, particularly in a situation where their safety, freedom, or even life is on the line, should ever use a VPN as their privacy solution.

Additional edit: There is one very specific circumstance where adding a VPN does provide additional security, and that's when VPN traffic won't draw attention but Tor traffic would. This is the only case where a VPN offers a benefit, at the potential cost of increased identifiability should someone actually take a look at what was sent through the VPN.


Is it okay to widely share the RSA key fingerprint for a host? When you ssh into a remote box for the first time or if the remote host's key fingerprint has changed (from what's stored in your known_hosts file) you get a warning and you are shown the fingerprint of the host's key.

Does it compromise your security if you share the fingerprint publicly (i.e. with potential attackers)?  Or is this a case where it's okay for everyone to know the fingerprint of a server, because ssh is doing something behind the scenes (from my perspective as a simple user) such that the fingerprint can't be spoofed, even if it's known?

Since you can see the fingerprint just by attempting to ssh in to the server using a nonsense account, I assume that means the fingerprint should be okay to be publicly shared (but you know what happens when you assume...).

The server key fingerprint is a hash of the server's public key, which is, by definition, public. Anybody can obtain the server's public key by simply connecting to it, since the server sends its public key in the initial steps of the protocol. In fact, that's just what you do with your SSH client: you connect to the server, the server sends its public key, your SSH client software computes the key hash (the fingerprint) and displays it. At that point, you still have not authenticated yourself, so everything you did, anybody could have done it.

Thus, there is no problem is publishing the key fingerprint because any possible attacker already has it.

Of course, publishing the key fingerprint and using it as a basis for server authentication requires robust publication: an industrious attacker intent on doing Man-in-the-Middle attacks would try to alter the published fingerprint as you see it, so as to induce you into accepting as genuine a fake server key. Thus, if you publish the server's public key on a Web site, make it an HTTPS Web site. (In other words, for this fingerprint, you do not need confidentiality but you need integrity.)