Is it legal to "use" security vulnerabilities I understand that the answer to questions like this depend on country, but I'd like to get an idea what the usual approach to cases like this are.

Heres the case:
I found a security hole in one of the governments services.
The flaw makes it possible for anyone to download documents that would normally require authorization from the affected service.
I did some tests and made a script that downloads a bunch of stuff from there to test what kind of security issue it actually was.
I have absolutely no intention to use this data for illegal purposes.
I also let them know about it and it should get fixed soon.

Now the questions are:
Is the cursive part illegal?
Would it be illegal for me to store the data and not delete it?
Would it be illegal to publish the data? (I assume yes)

If the cursive part is illegal, how can anyone find and let service provider know about security issue as telling about it reveals that you've used the hole to do something (in this case just to confirm that it exists)?

I did some tests and made a script that downloads a bunch of stuff
  from there to test what kind of security issue it actually was.

In most jurisdictions it is illegal to access a computer system without permission. The fact that it has security issues does not change that. See Computer Fraud and Abuse Act.

  "If the cursive part is illegal, how can anyone find and let service
  provider know about security issue as telling about it reveals that
  you've used the hole to do something (in this case just to confirm
  that it exists)?"

You can only look for security issues in the system if you are authorised to do so. Some vendors will publish bug bounties or responsible disclosure guidelines which allow such testing by public.


Online banking on wpa & wpa2 enterprise I could use two wifi connections, both with WPA & WPA2 Enterprise security, automatic PEAP and MSCHAPv2, one of them with certificate, the other without; both require user/pwd and are on a university campus.

Would any one of them be considered safe enough to do online banking on it? What other data are needed to better evaluate the question, if any? if not, what sort of risks am I getting exposed to?

Edit1: connection uses https, and let's consider as safe ethernet cable from the same university.

Edit2: Suppose I look at the certificate through Firefox on Linux: then is it enought that it is emitted by the same entity that I see say at home, or should I compare it more carefully?

Because the actual connection to the bank is probably secured with TLS (https), which is mandatory in most legislations for banks now, it does not depend on the authentication and encryption of the wifi you are on; your information will be secure even over an open wifi.

However, as those are university networks, it might be the case that they use a TLS-Proxy to inspect the https-traffic for malware or exfiltration. If they do that, your TLS-connection is not with your bank but rather with the proxy of your university, which is a man in the middle.

This is useful because webmailing uses https as well and cannot be checked for viruses that could otherwise be checked for and blocked in an enterprise network.

You can check that with the ssl obervatory or checking what certificate you get from within that network and from home and comparing those.

A good hint would be if you installed a CA certificate for your university.

On the other hand, banking sites, at least the common ones, are usually on a white list for TLS proxies because of exactly the problems that this could entail.


Binary to ASCII encoding for making files non executable Isn't it a good idea to transfer eg an .wav file, which can carry malware inside
(header, data etc.), to ASCII text file via hexdump? I would have achieved a non-executable format. It is still executable with a text editor but the malware can't cause any harm/execution because .wav and with it the malware code is transferred to Hex values/ASCII.

If I am correct, the .txt format doesn't have a header or are complicated like eg the .wav format, so there is no place for the malware.

Purpose: to have a worst case scenario backup so you can always attach the storage media to host, if all binaries are gone, without worrying of possible OS background events that potentially execute the malware code.
ASCII text file which carries the hex values can always be transferred back to binary in let's say a test environment (besides the OS is clean and don't do any other changes) with working only with copies to find the malware.

I am a little bit confused about this, and I can't find much information about that specifically talks about the same kind of purpose or possible vulnerabilities.

I think you're mixing up a few things here.

First, you're right: a wav file contains binary data, which may include malware instructions in its header/data.
But a text file also contains binary data.

What make you think that a text file is more secure than a wav file?

On disk, they are both some random byte stream preceded by some 4 bytes header, and are in no ways interpreted by the OS.

They are interpreted by a file reader, the software you use to view your file (in the two example you're giving, text and music files are not meant to be able to execute some additionnal instructions, and should only have their content read).

The file format can't contain any vulnerability because it all depends on how the data is understood by the software.

If the software executing your file has some security issues (ex: a buffer overflow exploit) then it could be exploited to execute instructions located at the right place in the file.

What you're proposing is like a very basic encryption system, which only alter the entropy of your file.


Separate third-party cookies for each website Instead of blocking third-party cookies (which might be useful), why don't browsers allow them, but keep all cookies separate for each address-bar website?

For example, if a third-party website sets a cookie while the user is viewing a page on a certain website, then that cookie would only be visible to the third-party website when the user is visiting the same website.

This way, third-party cookies could still be set (as they may have legitimate uses), but tracking cookies would stop working.

Primarily because it would break things. For example, Facebook Like buttons would stop working because it wouldn't be able to check which Facebook account you are logged into. There are workaround where it shows a pop-up instead, but this is kind of ugly, and it also wouldn't be able to work as a passive page control (e.g. show number of number of likes and display comments).

Also, there is little advantage with additional complexity of maintaining a separate set of cookies depending on what the outer page origin is. I can't imagine a scenario where a 3rd party cookie would just need to keep track of the anonymous user when they are visiting a certain site. If this is required, then the outer site could simply pass a token to the 3rd party object.

If you want the additional privacy this would bring then you should simply disable third party cookies - this would effectively have the same result as you've suggested.


Is it secure to have only https binding in IIS? I have an API that I want to be accessible only by HTTPS. I know I can use URL-rewrite to force a redirect, but don't want to install additional modules. I was wondering whether only providing an HTTPS binding would be a secure solution (in a way that HTTP connection would not be allowed).

Is it possible to somehow trick the server into accepting HTTP request with this kind of setup?

It is not possible to "trick" the server, but there are a couple of caveats here.

First, it is still possible to set up another site in IIS with a binding that will accept HTTP requests, so you need to be aware of the configuration of any other sites hosted on this server.

Second, this configuration means that if people attempt to visit the site directly or otherwise over the HTTP protocol, they'll simply get an error.  Depending on your use case, this may be fine, and it's certainly the least complex option.  If you have people accessing the site via a browser however, it's probably not. If it isn't you can (as you already know) set up an HTTP binding and redirect.  This has the added advantage of preventing other sites from binding HTTP to this IP/host name, reducing the likelihood that a second site will erroneously serve the site over HTTP.


how should I protect url parameter in JPQL query for reset password flow I am implementing a web app with reset password flow. Here is what I've done to try to make it secure.

Put in the email address in forgotten password form.
Regardless of whether the customer exists, the application reports an email sent, this avoids giving away the existence of an email address.
I generate a secure random string, then bcrypt it and use that as an access token with validity of 1 day.
Customer clicks link back which has a token parameter, I check the customer table and allow them onto the reset password form if the token is valid.
In that form I put the token value, not the id of the customer being reset which avoids exposing the id.

Now first question is, is this secure enough?

But my main question is related to Hibernate and parameters - my query is like "Select c from customer where c.token = ?1 and c.activeDate > DATe_NOW". I pass in the raw token parameter value.

In JPA/Hibernate or JPQL, is there any risk of an injection attack by modifying the token parameter when I'm using positional parameters like this in the query?

I'm not quite sure what you are referring to when you say you are using "Hibernate" (NHibernate?)

Either way - usually when you see the pattern of replacing a parameter with a ? it suggests that you are working with a parameterized query.  If it is using parameterized queries then you will be protected from SQL Injection in your situation.

If you can clarify which technology you are using I can give a clearer answer.


Can I initially hash passwords with SHA instead of hashing them with bcrypt to decouple requests from slow crypto functions? I'm using bcrypt for some web service requests that hash multiple passwords. The problem is that these web service requests can take minutes to complete due to bcrypt. Not very user friendly.

My question is the following: Can I hash these passwords with SHA and persist them to the database, then have a decoupled queued worker come along and properly hash these passwords with bcrypt?

That way eventually these passwords will be hashed with bcrypt but the user doesn't have a painful experience in the process.

Currently, I'm using the .NET library BCrypt.Net.

Bcrypt is run many times to intentionally slow it down. Perhaps you need to adjust the number of rounds of bcrypt you are running? This answer has some information on it.

While what you propose may work, I can't say that implementing a variant of standard password handling is a good idea. While I have specific concerns, such as the SHA hash staying in the DB too long and the security of the encrypted queue, I generally don't see the need to vary from the standard. If it's taking too long, reduce the number of rounds used for execution. If it's inexplicably slow, figure out why. Don't just decide that you can do better than decades of security best practices. It's not likely to turn out well.

Perhaps you want to post another question (likely on StackOverflow) asking about help with finding the performance problem. That seems a much better idea.

Sorry that I can't agree with your proposal...


How to prepare FATCA data transmission files with open source tools Here is the context: to transmit FATCA data to US IRS service the IDES protocol defines the following steps

sign the XML Payload.xml file with enveloping signature, SHA-256 with RSA private key, as Payload-signed.xml.
pack the signed XML Payload-signed.xml file into a zip file Payload.zip
generate a single-usage 32 bytes key for AES-256
encrypt the Zip archive Payload.zip with AES-256 as Payload
encrypt the AES with RSA public key for exchange as Key
bundle encrypted AES key Key and encrypted zip file Payload in a Zip archive

How to implement this process with existing open source tools (with preference for Linux platform) ?

Remark: this project demonstrates how to do it with .Net

Here is the process I have designed with available Linux tools. Care to all file names (case sensitive) and replace MyOrgGIIN with your organisation's GIIN identifier.

There is high risk that quotation marks and comas are present in your FATCA XML file. Expunge these characters from the XML file to avoid failure at submission (and some others like hash and double dash, read this PDF for details).
Include your ftc:FATCA_OECD XML structure into an enveloping signature template specifying expected cipher and hash methods (Payload.xml):

<?xml version="1.0" encoding="utf-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference URI="#FATCA">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
      <DigestValue></DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue></SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509SubjectName></X509SubjectName>
      <X509Certificate></X509Certificate>
    </X509Data>
  </KeyInfo>
  <Object Id="FATCA">
    <ftc:FATCA_OECD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="urn:oecd:ties:fatca:v1" xmlns:ftc="urn:oecd:ties:fatca:v1"
      xmlns:iso="urn:oecd:ties:isofatcatypes:v1"
      xmlns:sfa="urn:oecd:ties:stffatcatypes:v1" version="1.1">

      [... your data ...]

    </ftc:FATCA_OECD>
  </Object>
</Signature>

Generate XML signature in prepared template with xmlsec1, it will fill empty nodes:

xmlsec1 --sign --output MyOrgGIIN_Payload.xml --pkcs12 myorg_ssl_certificate.p12 --pwd pkcs12password Playload.xml

Compress signed XML payload as zip archive

zip MyOrgGIIN_Payload.zip MyOrgGIIN_Payload.xml

Generate a single usage 32 bytes key

dd if=/dev/random of=mySingleUsageAesKey bs=8 count=4

Display the 32 bytes as hexadecimal sequence (64 characters)

xxd -c 32 -p mySingleUsageAesKey

Encrypt your Payload.zip file with AES-256 passing your hexadecimal key as -K option

openssl aes-256-ecb -nosalt -K HexaSequenceForMySingleUsageAesKey -in MyOrgGIIN_Payload.zip -out MyOrgGIIN_Payload

Encrypt the AES key with IRS RSA public key

openssl rsautl -encrypt -certin -inkey IRSpublickey.cer -in mySingleUsageAesKey -out 000000.00000.TA.840_Key

Generate a timestamp with date "+%Y%m%d%H%M%S%2NZ"
Create metadata file using this timestamp from IDES site as MyOrgGIIN_Metadata.xml
Pack your metadata, encrypted payload and encrypted AES key in transmission data archive

zip TIMESTAMP_MyOrgGIIN.zip MyOrgGIIN_Metadata.xml MyOrgGIIN_Payload 000000.00000.TA.840_Key

Now submit and react to errors notification.


Authenticating With OWASP ZAP Script I am currently working on a python script that will automate zap for me so I do not have to go in and manually fuzz the fields or crawl pages. The part I am stuck on is that my script currently can only crawl the web login main page. How do I go about getting it to login from my script and start crawling other pages on the web app?

I was testing the example script from the OWASP github repo:

#!/usr/bin/env python3

import time
from pprint import pprint
from zapv2 import ZAPv2

target = 'http://127.0.0.1' # Replace this with your target URL or IP
# Change to match the API key set in ZAP under tools menu, options, API tab. or use None if the API key is disabled.
apikey = 'Place your API KEY HERE'

class OwaspZap(object):

    def Api_Connect(self):
        zap = ZAPv2(apikey=apikey)
        print('[+]Accessing target {}'.format(target))
        zap.urlopen(target)
        time.sleep(2)

    def Spider_Crawl(self):
        zap = ZAPv2(apikey=apikey)
        print('Spidering target {}'.format(target))
        scanid = zap.spider.scan(target)
        # Give the Spider a chance to start
        time.sleep(2)
        while(int(zap.spider.status(scanid)) < 100):
            #This will loop until the spider has finished
            print('Spider progress %: {}'.format(zap.spider.status(scanid)))
            time.sleep(2)
        print('Spider crawl completed')

    def Passive_Scan(self):
        zap = ZAPv2(apikey=apikey)
        while(int(zap.pscan.records_to_scan) > 0):
            print('Records to passive scan : {}'.format(zap.pscan.records_to_scan))
            time.sleep(2)
        print('Passive Scan completed')

    def Active_Scan(self):
        zap = ZAPv2(apikey=apikey)
        print('Active Scanning target {}'.format(target))
        scanid = zap.ascan.scan(target)
        while(int(zap.ascan.status(scanid)) < 100):
                # Loop until the scanner has finished
            print('Scan progress %: {}'.format(zap.ascan.status(scanid)))
            time.sleep(5)
        print('Active Scan completed')

    def Show_Results(self):
        zap = ZAPv2(apikey=apikey)
        # Reports the results
        print('Hosts: {}'.format(', '.join(zap.core.hosts)))
        print('Alerts: ')
        pprint(zap.core.alerts())

zapp = OwaspZap()
zapp.Api_Connect()
zapp.Spider_Crawl()
zapp.Passive_Scan()
zapp.Active_Scan()
zapp.Show_Results()

It all depends on how your application authenticated users. ZAP can handle pretty much any type of authentication, but configuring it can be non trivial. We are actively working on improving this.
Have a look at this tutorial video.
If your app uses a standard login form then see here.

I'd recommend getting authentication working with the ZAP desktop first (as this makes debugging much easier) and once thats working translating the same steps to your script.
For more help ask on the ZAP User Group.


Why exactly is this MySQL query vulnerable to SQL injections? This is the query:

$mysqli->query("UPDATE `users` SET `user_age` = '$my_age', `user_sex` = '$my_gender', `user_description` = '$my_description'
            , `user_sound` = $my_sound, `country` = '$my_country', `region` = '$my_region', `custom1` = '$mycust1', `custom2` = '$mycust2' WHERE `user_name` = '$me'");

What makes it vulnerable is the $my_sound variable which isn't wrapped in the apostrophe ('). I've looked up many times on google but couldn't find much intel related to why SQL injections are doable when a variable in a query isn't wrapped in (')s.

How would an attacker exploit this query?

Generally, SQL Injections happens when an unsanitized variable is used within a query, regardless of whether there is an apostrophe or not.

In PHP you want to use prepared statements. This will transform your query into:

$sql = "UPDATE `users` SET
        `user_age` = ?,
        `user_sex` = ?,
        `user_description` = ?,
        `user_sound` = ?,
        `country` = ?,
        `region` = ?,
        `custom1` = ?,
        `custom2` = ?
    WHERE `user_name` = ?";

// Prepare the statement
$statement = $mysqli->prepare($sql);

// Bind your variables to the question marks in the SQL.
// bind_param keeps variables bound, so if you prepare a statement, bind the params
// then change the value of the variable bound, then the new value will be used.
// The first parameter determines what type of value, 's' is a string, 'i' is a interger
$statement->bind_param("sssisssss", $my_age, $my_gender, $my_description, $my_sound, $my_country, $my_region, $mycust1, $mycust2, $me);

$statement->execute();

Note that you don't need apostrophies when using prepared statements, the s type definition in bind_param will add them for you when escaping the value.


Windows Server 2019: Add CHACHA20-POLY1305 ciphersuites for IIS Is there a way to add/enable ECDHE-ECDSA-CHACHA20-POLY1305 and ECDHE-RSA-CHACHA20-POLY1305 ciphersuites on Windows Server 2019 (Build 1809 or later) for HTTPS configuration of IIS webserver?
According to the TLS Cipher Suites in Windows 10 v1809 (unfortunately, this page does not explicitly mentions Windows Server 2019 OS) there is no support of these ciphersuites on Windows by default.
Executing the following PowerShell command
Enable-TlsCipherSuite -Name ECDHE-ECDSA-CHACHA20-POLY1305
Enable-TlsCipherSuite -Name ECDHE-RSA-CHACHA20-POLY1305

Added CHACHA20-POLY1305 ciphersuites as "empty" ciphersuites (output below is a result of Get-TlsCipherSuite PowerShell command)
KeyType               : 0
Certificate           :
MaximumExchangeLength : 0
MinimumExchangeLength : 0
Exchange              :
HashLength            : 0
Hash                  :
CipherBlockLength     : 0
CipherLength          : 0
BaseCipherSuite       : 0
CipherSuite           : 0
Cipher                :
Name                  : TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Protocols             : {}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 0
MinimumExchangeLength : 0
Exchange              :
HashLength            : 0
Hash                  :
CipherBlockLength     : 0
CipherLength          : 0
BaseCipherSuite       : 0
CipherSuite           : 0
Cipher                :
Name                  : TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
Protocols             : {}

Below are snippets from the Microsoft Security blog post Taking Transport Layer Security (TLS) to the next level with TLS 1.3 (published August 20, 2020).

Transport Layer Security (TLS) 1.3 is now enabled by default on Windows 10 Insider Preview builds, starting with Build 20170...

TLS 1.3 now uses just 3 cipher suites, all with perfect forward secrecy (PFS), authenticated encryption and additional data (AEAD), and modern algorithms...

We highly recommend for developers to start testing TLS 1.3 in their applications and services. The streamlined list of supported cipher suites reduces complexity and guarantees certain security properties, such as forward secrecy (FS). These are the supported cipher suites in Windows TLS stack (Note: TLS_CHACHA20_POLY1305_SHA256 is disabled by default):

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

The protocol enables encryption earlier in the handshake, providing better confidentiality and preventing interference from poorly designed middle boxes. TLS 1.3 encrypts the client certificate, so client identity remains private and renegotiation is not required for secure client authentication.

TLS 1.3 is enabled by default in IIS/HTTP.SYS.

TLS 1.3 support will also be added to .NET beginning with version 5.0.

For more information about TLS 1.3, refer to the Microsoft TLS 1.3 support reference.


SSLstrip attack on HTTPS request Can an SSLstrip attack take place even if the client types https:// instead of http:// ?

I have read that an attacker can monitor for HTTP requests and redirect them to HTTPS. But I am curious to know whether HTTPS requests can also be exploited.

No, that is not possible. In case the user types 'https://', the secure tunnel is generated, and SSLStrip cannot interfere anymore.

SSLStrip works by intercepting HTTPS redirects sent from the server. SSLstrip then sets up a HTTPS connection with the server (the server thus thinks everything is ok), but keeps an HTTP connection with the victim. SSLStrip can only capture these HTTPS redirects if they are sent to the browser using plain HTTP. Otherwise, SSLStrip would be able to 'break into' the SSL tunnel, which it doesn't.

HSTS is an implementation that could be used to tell the browser to always connect via HTTPS (and thus to not rely on https redirects from the server anymore).


For 2FA, is one method better (more secure) than another? There are a variety of options available for 2FA - LastPass, for example, offers all of the following options:

LastPass Authenticator
Duo Security Authentication
Google Authenticator
Yubikey Multifactor Authentication
RSA SecurID
Sesame Multifactor Authentication

... and so on. I've heard of other 2FA options too - SMS, SmartCard, TOTP (not sure exactly what that is), and so on.

As near as I can tell, it seems like the main distinction is between hardware-based solutions (e.g., Yubikey) and software-based solutions (e.g., the various 'Authenticator' smartphone apps).

From an information security POV, does one of these options offer a higher level of security? Put another way, for the average user, what's the most secure form of 2FA available?

Generally speaking, all of these security products are solid enough for casual end-users. When it comes to end-users, most of the vulnerabilities come from the way the person uses it, not from weakness in the method itself. For example, do you leave your RSA SecureID card where your kids have easy access to it? If you use a code generating app, then does your phone have a strong password lock on it?

As mentioned by @SteffenUllrich, if you happen to get spyware on your mobile device with root access - which is more common than you might expect (see StageFright and drive-by downloads) then your SMS, email, and maybe even app based methods could be compromised.

I think that if you've careful about how you use it, and have good security practices on your devices, then any of these methods are fine for the average end-user worried about drive-by (ie non-targeted) password cracking from database leaks. If you want to go the extra mile and sacrifice some convenience, then I suppose the ordering would be SMS/email < app/OTP/TOTP < hardware token.

Now, if you're not an "average" end-user, but a high-value target that nation state actors are trying to break into, then everything changes. For example, if you've made enemies with the US government's NSA then they can sniff any code sent to you over SMS or email, and can likely sniff the packets of the first-time setup of the Google Authenticator app (or, you know, just ask Google for the code). In this case, hardware tokens really are king because they are entirely "out of band" (ie nothing sensitive ever crosses the internet).

Just for completeness, here is a copy of the tag wiki from the multi-factor tag (which I wrote).

You can break 2FA methods into three broad categories:

Something you know - information, like a password, or your mother's maiden name, or a public key stored in a key file.
Something you have - usually a physical object like the phone that can receive SMS at your number, or a One-Time-Password (OTP) token or public-key enabled smart card / USB stick:

Something you are: aka "biometric" like fingerprints, iris, voice, typing rhythm, etc.

The reason for splitting auth methods into these categories is that each one requires a very different kind of theft in order for a hacker to acquire it.

If you are required to provide a proof of identity from more than one of the above catogories, then it is properly "Two Factor Authentication", or "Multi-Factor Authentication". If you are providing multiple items from the same category, then it's called "Multi-Step Authentication", which is obviously weaker than multi-factor.


Microsoft password email reset link leads to different url? ...I am really annoyed and unsettled by the password reset email I just received from Microsoft.

What should I think of this? My email client correctly told me that the underlying url is not the same as advertised...

I prepared a nice screenshot but can't post it because of missing reputation...

The text of the email is:

 View this email in your browser

   Reset your Microsoft Online Services password   Microsoft
   We've received a request to reset the password for your user@domain.onmicrosoft.com Microsoft Online Services account.

Click the link below and then follow the instructions in your web browser.

Reset your password now

If clicking the link didn't work, copy the following URL and paste it into your browser window.

https://prs-scu.passwordreset.microsoftonline.com/Default.aspx?o=EJbpn[...]

If you did not initiate this request, please contact support.

   Microsoft Corporation | One Microsoft Way Redmond, WA 98052-6399
This message was sent from an unmonitored email address. Please do not reply to this message.
Privacy | Legal
   Microsoft

And the links named prs-scu.passwordreset.microsoftonline.com... actually leads to http://click.email.microsoftonline.com/?qs=bc7f[...]

Edit, I gained image pasting rights, so here is the screenshot:

I'm the Program Manager in charge of the password reset experience for Microsoft Online Services and wanted to clear up a few of the things you are seeing.  First of all, thanks for your feedback; we're always looking to improve our service, and comments like these really do help us to make things better over time.

The root DNS entry for our service is passwordreset.microsoftonline.com.  This DNS entry sits in front of a load balancer which directs traffic to region-specific datacenters which have different DNS records, hence the prs-scu subdomain (as an aside, as you perform your password reset, we also use this load balancer to ensure that your session is highly available in case of a datacenter-specific issue).

Now, when we send the email to your account to reset your password, we dispatch that email through a shared email service that is owned by a different team at Microsoft.  This is the same email service we use to send notification emails and informational emails for Office 365 as a whole.

The reason you see a different link in the href portion of the URL (e.g. click.email.microsoftonline vs. passwordreset.microsoftonline) is because the service we use to dispatch our emails puts a redirect in front of every outgoing URL to prevent phishing attacks.  We chose to include the plaintext version of the url in the body to address the case in which a user's email client does not handle HTML properly.

If you'd like to discuss this further, or what else we can do to improve your experience in the future, please feel free to contact me at asteen@microsoft.com.


Using AD authentication in a publicly accessible webapp I am sys admin working with a development team who is extending a publically accessible .net web app that currently uses forms authentication with usernames/passwords (hashed) stored in a sql database. The developers would like to move from crystal reports to SRSS and they tell me that AD authentication is a requirement for credentials to be shared betwen SRSS and the webapp. Their proposal is to have the webapp create/modify AD accounts in a AD domain setup specifically for this purpose. The webapp and SRSS servers will be in the same domain. The domain credentials used to create/modify the user will be stored in the web config and an API will be called with the credentials.

I don’t like the idea but I am having a hard time persuading them not to use this architecture. Are there any PCI controls or controls in similarly respected control frameworks that prohibit this architecture? Or am I making a mountain out of an ant hill?

Besides the very basic rule of "don't store credentials in configuration files"...

I'm not entirely sure what the development team was thinking, but you can use Forms Authentication with SSRS: http://technet.microsoft.com/en-us/library/ms152899.aspx.

It is a pretty hairy design, especially if its designed to continue using SQL to store the users.  Now, migrating to using AD for all users, and letting the currently logged in user access SSRS with the given token is a pretty standard architecture.  That way you don't ever store credentials.


concern about including credit card form in iframe using dynamically generated url I'm looking at including a credit card form in a page via iFrame but the form app needs parameters passed from the AngularJS app in the parent page in order to complete the transaction.

My concern is that since the iFrame URL (loading the card form app) is dynamically generated, is it vulnerable to an attacker who could hijack the iFrame and point it to an alternative form for skimming the card details?

If this is a legitimate concern, is there a recognised way to prevent such an attack without a full redirect away from the page to an external payment app?

X-FRAME-OPTIONS to your rescue!

If you want to load a page from one app to an iFrame on another use the "ALLOW-FROM uri" setting.

Good Reads:

The X-Frame-Options response header
Clickjacking Defense Cheat Sheet


How to be sure that downloaded file is correct? Last week I read a lot about security. I have a basic understanding how public keys or private keys works. But I still have a lot of questions I can't find an answer. Right now I'm interested in checking an executable file I downloaded. Let's assume I sign a file, send it to user, but some bad guy in the middle change my file to malware. So when the user double clicks downloaded exe, how can he be sure that he actually launches a correct file and not a virus?

Upd.: Assume that the user of my program is a housewife and she doesn't know anything about command line and she will not download special GUI programs for checksum comparison. And at the same time I, as a developer, want to be sure that she runs my program but not corrupted. How?

Any self-verification mechanism included in the executable file could be replaced or removed by the attacker who intercepts the file. Therefore, we must leave signature verification to a system external to the downloaded executable, for example, the operating system.

There are three possible outcomes such a verification system can produce:

The signature is definitely valid (the signature and data match)
The signature is definitely not valid (the signature and data do not match)
There is no signature provided (the executable is not signed)

In Windows, you may have seen pop-up confirmation windows like this when you try to run an executable:

Here, the executable has been signed and Windows has both

verified the signature on the executable, and
verified the identity of the public verifying key's owner, using a chain of trust based on one of the operating system's trusted certificate authorities.

We know with cryptographic certainty that an entity named WinZip Computing signed this executable, exactly as it exists right now on our hard drive. That's case #1, above.

That's how a security-conscious user can verify that something is definitely unmodified since its original publication. Similarly, the operating system can detect case #2 very easily: it attempts to verify the signature and finds a mismatch instead of a match. In that case, the operating system can sternly tell the user not to run the software because it is incredibly untrustworthy.

However, you want to know how to prevent a user from running something that has undergone arbitrary modifications. It's easy for an attacker to generate case #3 (no signature): simply replace your signed executable with an unsigned modified executable.

In this case, it's up to the user (or a very strict policy on the operating system) to decide never to run any software that does not have a signature. The user must expect a signature for your software and be alarmed at its absence (or otherwise always expect the worst and be deeply mistrustful of any unsigned software). There is no general way to distinguish between software that "should" have a signature but doesn't and software that simply was never given a signature at all (e.g. because the publisher just couldn't be bothered to do it). An attack cannot fake a modified executable so that it matches your signature, but they can produce a modified executable with no signature at all.

Of course, if your transmission method provides integrity (as TLS does) you can be sure that the executable that arrives on the client's computer is the same as the one sent from the server. If you control the server and distribute using TLS (e.g., through HTTPS), you (the distributor) can be sure that your clients are receiving your original software. If you also sign your software, the security conscious users can be sure they are running your original software, but this does nothing for security-unaware users, who don't understand the significance of a cryptographic signature.


Why is there no option for separate sudo password? This has bugged me for some years now. I had a small webserver and I used ssh to log in remotely. I noticed that from the very first day there were brute force attacks to my ssh.

This made me think about security and I realised that if a system has users in sudoers, a successful ssh attack to such user account is game over immediately. Why is there no option to set a different password for sudo? I can't be the first person who thought of that, right?

First, not all attacks require to know the password. Many attacks against services (or daemons) target vulnerabilities in code and end in executing code on behalf of a user without knowing the password. In that case, the default sudo configuration adds security by requiring the knowledge of the password.

Another example in a multi-user environment is when a user leaves his terminal unattended (you and I know that it is bad and never do it ourselves, but...) an attacker can execute commands on behalf of the user but still cannot use sudo.

Finally, as you speak of ssh, the common use is to only use a (RSA) key for user authentication. That way, the ssh connection never use the password, which is only used for a direct local connection or to gain root access via sudo. It can even be forced by disabling the use of the password in sshd configuration. In the case of a remote server, the local user password is then indeed only used to gain root access.

But the real answer to your question is the option does exist! The /etc/sudoers file can be used to declare the boolean flag rootpw. If this flag is set, the password shall be the password for root instead of the password for the current user.

If the sudoers contains the line:

Defaults rootpw

then you will be asked for the root password. This flag is off by default and is seldom used because it is not really sudo philosophy but su one: if you do know the password for root, you can directly use su by-passing all additional sudo controls.

sudo is indeed a highly versatile command, and you really should read man sudoers


How to discover technologies? When I audit a service I come across the problem I have to figure out what is the product a website is using, to search for possible vulnerabilities afterwards.

What I do is to look for server responses using a proxy like Burp, or taking a look to the source code, but there are cases I have skipped a technology, because I didn't know the name was in the code, or maybe a certain product has a default login page, or some features in the code, that, if you don't have experience and have encounter them first, it is impossible to figure out what the product is.

How to do that in a proper way? How to automatize this task?

During the analysis of a host you have to distinguish between two different approaches: Identification of products (e.g. Apache/IIS) and identification of technologies (e.g. PHP/ASP). The identification of these is similar in methodology but differs in technological details.

Many products announce themselves in welcome-banners, about sections and help mechanisms. Using and browsing an application with open eyes allows such an enumeration.

Some applications/technologies have specific optical characteristics. For example the HTML source of popular CMS is having a typical structure and is using repeating JS file names or CSS classes. Analysing these is called application fingerprinting.

There are some dedicated implementations for automated fingerprinting available. For example httprint and HTTPrecon for Webserver and HTTP header. There are other tools for other technologies too. Nmap is providing the argument -sV to enable version detection for different services/protocols based on fingerprinting techniques. This works very well.

Check out the OWASP according chapters for additional details and examples regarding web analysis.


How android WebView can be exploited and how to secure my app from WebView vulnerability? I heard that WebView vulnerability is active in Android versions before 4.2. I read that it is fixed by Google in their newer updates from 4.2. What I want to know is a brief description of the WebView vulnerability, like, how an attacker can use this vulnerability and any solution to fix this by myself in my app if it is possible to secure my Android app from this vulnerability.

The primary vulnerabilties involved in the WebView component are Insecure Direct Object References, SQL Injection, and Cross-Site Scripting (XSS).

While all three are potentially huge risks, the XSS vulnerability potential can be used to gain access to shared preference files using the file:/// command or can utilize smsJSInterface.launchSMSActivity to send unwanted SMS messages from the phone, in addition to stealing credentials or providing a false front to the HTML, CSS, Javascript, or other browser-level behavior.

If you turn off the setJavaScriptEnabled as follows, adversaries will not be able to run any Javascript in order to perform XSS attacks:

myWebView.getSettings().setJavaScriptEnabled(false);

Or, if you can't do this, be sure that each context is escaped properly by using an XSS filter component such as the OWASP Java Encoder Project.

You can see what data is available to each WebView by using the sqlite3 command-line tool or a SQLite3-compatable browser to view the /app/-packagename-/db/webview.db file. Of course, any input that makes its way into the SQLite3 database or that performs a query or other string operation against it can become a potential insertion point for SQL injection -- albeit in some cases a network MITM scenario may be required.

Some examples of insecure direct object references can be found in these penetration testing tutorials against the HerdFinancial app which is a part of the OWASP GoatDroid Project:

http://jit6ndrakumar.blogspot.com/2014/07/android-app-pentesting-part3.html
http://jit6ndrakumar.blogspot.com/2014/07/android-app-pentesting-part4.html


Unable to get John the Ripper to crack PDF password I am new to Kali Linux and JTR but am playing around trying to crack a PDF file. I set the PDF Password to test so it's a known password on my own file. For whatever reason JTR appears to finish cracking the file but returns (?)
What am I doing wrong, is JTR only able to crack document view passwords not document edit passwords for PDFs?
This is my file hash from running pdf2john:
root@kali:/usr/share/john# cat ~/Desktop/newcrack.hash
$pdf$5*6*256*-1052*1*16*2bd413a2a376d44b8bf88bd6946d0fe6*127*6539386315f0a6efb9af1af2ec0ddc97286e63f6e8f0f90cc55cd728d58e7c2b038470eb183135c033035d9f00c20bbd00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000*127*17a60bd7d6d2598f18d49e8b79d39b4a01fdab4e0f8a39a5638d751a969537537d34a956b5a58d112cc1332b9e84f81600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000*32*6d1958871a16b03631acbd5d7d252c84d7c144a120dee6ce4d234553c1602b04*32*53e87e7cf2aeb4799558586ef310e26c1af5640ce9ad4d4d676f2307958c5dd6

I then run john on the hash using the crackstation.txt file which is a 16GB flat file wordlist:
root@kali:/usr/share/john# john --wordlist=/root/Desktop/crackstation.txt ~/Desktop/newcrack.hash
Using default input encoding: UTF-8
Loaded 1 password hash (PDF [MD5 SHA2 RC4/AES 32/64])
Cost 1 (revision) is 6 for all loaded hashes
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
                 (?)
1g 0:00:00:00 DONE (2020-08-30 00:20) 5.882g/s 376.4p/s 376.4c/s 376.4C/s ..```.....
Use the "--show --format=PDF" options to display all of the cracked passwords reliably
Session completed

When showing the password it looks like it's blank but I set it to test so it should be able to crack it.
root@kali:/usr/share/john# john --show ~/Desktop/newcrack.hash
?:

1 password hash cracked, 0 left

It seems like JTR is assuming the password is blank, returns immediately, and reports the password hash was cracked however the show command does not show any password.
Can anyone tell me what I am doing wrong here?

Update: I ran a few tests and figured out that John The Ripper does not appear to remove PDF "Permissions Protected" passwords. I password protected the same document two different ways then ran JTR on the hash. First I password protected for "Document Open" using the test password. I entered that into JTR and it worked! It cracked it no problem. I then removed the "Document Open" password and added a Permissions Password of test. JTR will NOT crack that, it simply returns NULL every time. So my only conclusion is that JTR does not work on Permissions Passwords. Someone please correct me if I'm wrong. I could not find any documentation on this.

To quote the output from your first command:

Use the --show --format=PDF options to display all of the cracked
passwords reliably

You weren't using the --format=PDF with your --show.


Can someone know my geolocation by replying to Whatsapp message? Is there any way a malicious actor could know my geolocation by replying to a Whatsapp message I have sent? Will being connected with a user allow me to see their geolocation, or would I have to reply to a message sent by another user before they could see this?

No you cannot gain the geolocation from a message you have sent someone via what’s app directly.

You can gain this if the message then proceeds to get you to do something else, such as open an app/link which then sends the receiver the location information (varying degrees of accuracy such as IP or GPS depending on app capabilities).


How do I ensure my USB drive isn't infected? I was advised recently by someone on here to reinstall my OS after being infected by belombrea dot com. However, in order to reinstall I needed to download Windows 10 on a USB drive. Now I'm afraid the USB drive itself might be infected. Thanks

Given that the website in question seems to be related to adware, I highly doubt that the hardware/firmware of your USB drive itself would be targeted. That is a much more elaborate attack than a persistent browser redirect, and may have to be tailored to your specific type of drive.

As mentioned in comments, if you still do not trust it, a new USB drive is not a big investment.


start point into cryptography and encryption Recently I am growing passion for security/encryption/cryptography. I follow some famous people in this domain on twitter and read articles over the web. However, this topic seems deep and every time I read something new I kind of get information overload.

I believe the reason for this is that I do not have my basis correct in this. What is the best way to get deeper in this ? Is there any beginners book for it to set a foot ? I would appreciate any starting point that would guide me to the right direction and I would pick things from there.

One possible path into cryptography is through implementation. Take some standard function or set of functions, e.g. the SHA family of hash functions. From the standard, produce your own code; the standard includes some test vectors that will help you verify that your implementation is correct. Then compare your code with existing libraries, e.g. OpenSSL, Crypto++ and sphlib; benchmark your code and see what you could do to make your code run faster and/or smoother. Though obtaining a fast hash function implementation is not extremely useful by itself (since fast implementations are already freely available), the exercise will grant you precise and deep knowledge of how these functions work, and that will be a strong asset to understand research papers about them.

Hash functions are a nice starting point since they tend to be accurately specified, and they use no key. Once you have mastered a few hash function, try HMAC. Then proceed to symmetric encryption (especially RC4, DES and 3DES, and AES). At that point you will have some notions of the internal working of some symmetric cipher, and, maybe more importantly, you will know how to read and understand algorithm specifications.

Further steps will be to dabble in asymmetric crypto, basically RSA. Asymmetric cryptography requires some mathematics; you may want to have a look at the Handbook of Applied Cryptography, which is freely available and is a good reference book (this book has no relation whatsoever with the "Applied Cryptography" from Bruce Schneier -- the latter is an oft-cited introduction book, but much less useful as a reference). If you want to implement your own RSA, using a programming language or library that provides big-integer arithmetics will make things simpler (e.g. Java with java.math.BigInteger, C#/.NET 4.0 with System.Numerics.BigInteger, or some external library like GMP). Alternatively, go ahead and write your own big integer code (there again, a healthy exercise); for that, you will want to read chapter 14 of the Handbook.

Once you have done hash functions, HMAC, symmetric encryption and RSA, you can proceed to write your own SSL/TLS library, beginning with TLS 1.0. Writing a TLS client that can connect to and interoperate with existing TLS server will given you intimate knowledge of the SSL/TLS handshake, and you will be able to understand all the research about known attacks on SSL and how they are fixed (e.g. BEAST, Poodle,...). Use this answer as a reading guide about TLS.

Implementation is not the only way to learn cryptography, but it works.


I've heard that salt is not meant to be secret, but what if I made it secret? Possible Duplicate:
  Password Hashing add salt + pepper or is salt enough?
  How to store salt?

Ok I have been studying a lot about password hashing lately. And I have a few questions. So I will explain what I know (if I have gone wrong anywhere along the way, please correct me so I may learn) so I can show you where my confusion lies.

So the reason why I want to hash my users passwords is so that if a hacker gets a hold of the database, he can't just use their emails and type in their passwords to steal their money. It also makes it so any admins cannot see what their passwords are. So the bottom line is to keep my users safe.

Using just a hash like MD5 is not good enough because rainbow tables can be used to figure out what their password is immediately and fast computers can just crack those anyways regardless of salting or not.

But it is important to use salt when hashing to make sure rainbow tables cannot be used and forces hackers to have to brute force their way into finding out the password. So when we are storing the salt, lets say by appending it to the hash, <hash>_<salt> it doesn't matter if its in plaintext because hackers are forced to brute force the hash.

So now onto my questions.

1. Why don't I encrypt the salt from my code and then store the encrypted salt in the database?

It seems like if I did this, then it would be impossible for a hacker to ever brute force and get the password because they would assume the salt is plaintext when really it is not. So they would try and try and never come up with the password. But this leads to my second question.

2. How can a hacker tell what kind of hashing algorithm I used when looking at the database?

If I hashed my password using bcrypt and then hashed that using scrypt and on and on, it seems like the only way to be able to figure out the order of hashing is to be able to see my code.

Ok in order to help explain myself better, let's make up a scenario. A hacker uses some form of SQL Injection to print my entire users list, getting 1000 rows of emails with hashed passwords. These passwords I appended my salt which has been encrypted with my key that's only kept in the code. How would the hacker even know that the salt is encrypted? And if he somehow discerned that it was encrypted he wouldn't be able to decrypt the salt unless he had the key. Which the only way to get the key is if he had access to my code. If he had access to my code, then at that point, he would see exactly how I hashed and salted my passwords so he could easily duplicate the process whether or not he had my key anyways and then start brute forcing to get the passwords. So it seems like doing something like encrypting the salt would stop any hacker who didn't have access to the code from ever figuring out the passwords. Is this not true? If not, please explain it to me in detail. =D

Lets assume a hacker got ahold of your database.

Lets analyse what happens when you store the encrypted salt into your database.  The hashing function that utilizes the encrypted salt won't be able to use the salt until it is decrypted.  So your code would request the encrypted salt and would need to be decrypted with a key.  We can assume this key is in the code.

Since the hacker has your database, they will have the encrypted salt.  Now they really only need the key.  In your example, the key is stored in the code.  Normal salts are going to be stored in the code as well.  You really don't add any security at all here since the hacker can simply decrypt salt by getting the key from the code just as if they were have to got the salt from the code.

Most hashing function are going to have enough entropy that you can't analyze the string to figure out which hash function was used.  However you can visually see that different hashes contain a different amount and type of characters, which will give you a better clue on which is being used.

If a hacker were to get your database, getting your code may be just as easy.  The purpose of a salt is so it can't be subject to a rainbow table attack.  But of course they would be able to generate a rainbow table but it may take too much time to do so.


CSR Signing simulation Tried a lot get my test csr signed from root CA(trial versions option), somehow i am not getting it dues to some of their internal check. Few questions that cropped up

Can i somehow signed that myself ?(its only for learning purpose)
any CA who can sign it on trial basis(which worked for some one)

went through many posts/blogs but couldn't find the answers

post1
post2

UPDATE on next Question

While downloading the certificate, it popped up saying "creating a private key” with passphrase.
    1. Why it’s asking to create a private key? What is its use? (say PK1)
    2. While creating the CSR, i already had the private key (SAY PK2). Are PK1 and PK2 same?
    3. Someone from CA can also get it, like i did, so how it’s not vulnerable to attack?

I completed the wizard, and downloaded the certificate with PK1.

I referred all the possible below links but not getting above answers.

post3
post4

Trial certs
There are several CAs that will generate short-lived trial certificates for you.
Here's one:
https://www.instantssl.com/free-ssl-certificate.html

Short certs
And there are some CAs that will generate longer lived free certificates for you.
StartCOM/StartSSL has been doing this for several years.

https://www.startssl.com/
StartCom on Wikipedia
Instructions on DigitalOcean

Own CA
There are several tutorials online about how to roll your own CA with OpenSSL.

DataCenterOverlords.com: Creating Your Own SSL Certificate Authority (and Dumping Self Signed Certs) (Archived here.)
TLDP.org: [http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/c118.html] (SSL Certificates HOWTO)

I prefer Ivan Ristic's booklet: "OpenSSL cookbook". (Subsection called "Creating a Private Certification Authority" (Bottom third of page.)


How secure would this method be considered for password storage Ok I am currently storing the passwords in most secure way I could think of. With use of Encryption and Hash. The passwords are first generated by user as plain-text with minimum length of 6 alpha-numeric characters up-to 24 char alpha-numeric.

After the passwords plain-text value are ran against MCRYPT. Primarily the TWO_FISH cipher with random IV in ECB mode. Ones that is done the Encrypted plain-text is binded to Hash function which also add's SALT via $saltVar = dechex(mt_rand(0, 2147483647)) . dechex(mt_rand(0, 2147483647));

One's everything is in place the SALT + Encrypted password are hashed via SHA-256 and then re-hashed next 15536 rounds. Creating a relatively secure password.

In my personal opinion this is sufficient way of securing the data, since in part there are no key's being used there is no way of decrypting this, other then running it again with user inputed plain-text password and creating a temporary calculated hash of the password string, after which the string can be matched to the string in the database.

I would never use this for any other data, but for password I belive this is sufficient. However I would still like some profesional critisism, as to whatever my way of protecting the password plain-text is secure or not, and or maybe how I can improve what I already have if its just fine. And while I am at it, would you recomand using TWO_FISH or swapping it for SEARPENT?

Thanks in advance.

It's generally a bad idea to invent your own security algorithms. As you've already said, you don't know if this is secure. You may believe so, and maybe you even find somebody who agrees with you. But that doesn't really mean much.

There are established solutions like bcrypt which have proven themselves both theoretically and practically over a course of many years. We can be pretty confident that those are in fact secure. So why not take advantage of this and use bcrypt?

Regarding your own algorithm:

First of all, I don't see why you would limit the user to only 6 to 24 alphanumeric characters. This makes it impossible to strengthen the password with special characters or use a long passphrase.

The mt_rand() function produces weak random numbers from low-entropy sources like the server time and the process ID. The PHP manual explicitly points that out. A total of 8 bytes also isn't too much.

I cannot comment on whether your hashing scheme is sound, but given that stock PCs can calculate billions of SHA-256 hashes per second, 16,000 rounds again aren't much.


What documentation can I ask a vendor for to show HIPAA compliance Over the past year, several vendors I've contracted with have claimed hipaa compliance.  I have asked them for documentation of their compliance and I've never seen any.  I would expect an audit signed off on by a third party, or a checklist showing the status of security controls.  I know there isn't a merit badge to sew into your lapel or anything, but I have to document that the vendors are what they say they are.  Is there anything specific I can ask them for?

I would ask for exactly what you've suggested you expect to see.   An audit report would be ideal, a compliance policy listing the controls that are in place would be minimally sufficient.

If it's something that you consider to be significantly important to your business, then make it a requirement for them to provide this documentation before you can sign a contract with them.

Additionally, regardless of what the documentation is, I'd want to actually talk to somebody responsible for overseeing and maintaining compliance.   Get them to walk through the documentation they've provided, and answer any questions that you have, and you'll end up with a much better understanding of exactly how much they care about compliance, how much effort they put into it, and how well equipped they are to define, implement and maintain strong controls.  A document can say anything.  The words of the people responsible, however, are where the real story will be told.


Can any website secured using TLS can be impersonated using a rogue certificate issued by a rogue CA? Any website secured using TLS can be impersonated using a rogue certificate issued by a rogue CA. This is irrespective of which CA issued the website’s true certificate and of any property of that certificate.

  — Marc Stevens et al. 2009

Is this still true?

I understand one purpose of Certificate Transparency is to eventually detect rogue CAs in the long run. But is there any protection against the immediate attack?

There is potential protection in the form of certificate pinning.  This can be done in an application, and some browsers (hopefully all in the future) support it in the form of certificate pinning.   Certificate pinning can take two forms, first, you can submit the fingerprint for your certificate to the browser vendors (Google and Mozilla, currently) to be included in the browser itself.   Secondly, you can add the pins to an HSTS header, which will tell browsers that have visited your site in the past if the cert they're now seeing is kosher or not.

Because certificate pinning happens at the individual certificate level, it mitigates the threat of certificates signed by malicious or compromised roots.


Email hacking/masking prevention Can someone please explain to me how its possible that someone hacks a server and uses its email to send emails from a address thats not listed on the server and how to prevent it.

When I look at the mail queue there are emails there from and to yahoo.com accounts, how does this happen and how can I prevent this. Running centos 6, interworx and qmail if that helps.

This is the nature of how email works, unfortunately.

There is nothing preventing you or I from sending an email from any address we choose, this is by design. What we can tell though is the IP address the email originated from in the mail headers, and this will give us an idea of where the original message came from.

In the old internet, most mail servers were run as open relays. This means that to send an email from yahoo.com to google.com, you could use any open relay you found on the internet. If the IP got banned, its okay because it isn't your IP, and you could just change relays.

Now, with most modern mail servers, this isn't really an option. SMTP servers will only relay a message if you are authenticated, preventing random internet users from abusing your services. The server would accept unauthenticated mail only for users on that particular mail server.

Due to this change, spammers now need to completely compromise mail servers in order to abuse them.

If an attacker compromises your server, there isn't much you can do to stop them from sending emails short of blocking outbound port 25 on the firewall. If you need to run a legitimate mail server, then this becomes a problem as you would be denying legit email from being sent.

Also, I would check your IP against any blacklists. It may have ended up on some lists and you would then need to submit a delist request, including how you resolved the issue.


Question mark not allowed in password Recently I came up with a password requirement rules as follows:

The password must

be 8-16 characters
contain at least one number
contain at least one lower case letter
contain at least one upper case letter
contain at least one of these special characters:
"@#$%^+=*_.?"
cannot start with a "?"
cannot have the same character repeated more than 2 times in a row (e.g "aa")

Everything except can not start with a "?", is acceptable. Does anyone know a special reason for this requirement?

In SQL, prepared statements often use the ? as a placeholder. If they used parameterised queries but did not sanitise the inputs, then starting the password with a ? could confuse their code and result in an error.

This does not mean that this requirement is justified. It means that they know that they have insecure/buggy code and are forcing the users to enter their passwords in a certain way instead of fixing their code.


Can an attacker make in-app-purchases of my products in their app? My iOS app needs to store a pre-shared secret. It cannot embedded within the App Bundle itself because it could be extracted by statically analysing the bundle.

Apple's In-App-Purchase system allows an app to make a request to Apple. iOS should verify the authenticity of the app (as all apps are signed) - I realize that I could use this system to verify that the app is mine (and not an imposter trying to get the secret).

My app would make an IAP request to Apple, Apple then generates a cryptographically signed receipt and gives it back to my app, who then passes the receipt to my server which verifies Apple's signature and issues a new per-app-instance secret and returns it to the client (for storage in the iPhone Secure Enclave) where no other app can read it.

This system would break if an attacker could send their own receipts to my service. I understand the receipt contains the App Package/Bundle name which Apple asserts is correct, but I don't know how I would protect against an attacker performing a kind-of replay attack where they would get my app to make the IAP so the receipt is valid, but capture the receipt, pause my app process, then send the recipe from their app to my service (thus getting the secret).

What's a good solution to this problem, and could a jailbroken phone allow another app to masquerade itself as my app to Apple for IAPs?

Your scenario where an attacker exchanges a valid receipt for secret data can be mitigated if instead of the server sending the secret in reply to a receipt, it delivers the secret to your app through other means. Apple's Push Notification services are a good solution, as they tie your server to your own apps (no other apps can receive your notifications, and your server can't send notifications to other developer's apps even if it wanted to, because the client certificate it uses to talk to Apple only allows it to send messages addressed to your own apps).

When your requests the secret data from the server, it sends the receipt as well as its unique device token that allows you to send push notifications back to it. The server then sends the secret data as a push notification. If size is an issue it can send a secret key that fits in the notification's payload, and the app then downloads the actual secret data by presenting that key in a subsequent request. An imposter app would not be able to receive the push notification because even if it submits its own token, Apple will not allow your server to send a notification to that app since it's from a different developer.

Finally, one question comes to mind, why are you doing this? If the secret data contains info about other users, then this is your main problem. Instead of trying to protect that secret data (which you can't from someone who has physical access to the device), just make sure that data doesn't contain anything sensitive about other people, and let the user do whatever they want with their data. If it's for DRM, keep in mind that tons of people have tried and failed, and no matter how smart you are, you cannot do the impossible. Why not focus your efforts on delivering an awesome experience to encourage people to pay instead of copying your content?


Listing technologies/languages in LinkedIn Project History a Security Issue? In my LinkedIn Profile, when I list my past projects as a Software Developer, I think it to be beneficial to list the technologies/languages used.

My question is, does this impose a security risk/threat in any way?

No, not really. In most cases it's not difficult to work out the language/tech used for a particular site or application anyway. Doing your best to hide it would just be security through obscurity. Maybe people will find it a little easier to ID the language/tech used in your projects if you tell them, but they'd find it anyway.


My ISP using a transparent proxy I found that my internet service provider uses a transparent proxy on some sites and apps like Google, Whatsapp, etc. I know they use it to save bandwidth but my question here is if they are able to spy easily or not?

If HTTP is used, yes they can spy on you. If HTTPS is used, no they will not be able to spy on you. The transparent proxy is normally run on port 80 (HTTP) only, since it does not work with HTTPS.

The transparent proxy only caches content which is common to most users. e.g. logo.png, favicon.ico. Since every user is going to load the same site logo, it is a waste of bandwidth to download it from Google/Whatsapp repeatedly. Websites usually use headers to indicate that the content is "cache-able". Cache-Control: max-age=3600 indicates that the content is valid for 1 hour, hence your ISP only needs to retrieve the latest copy once every hour.

However, your personal mailbox or conversation list will never be cached. This is because it is unique to you, so there is no benefit from caching it. Hence, websites normally do not add cache headers to the response. If the website uses POST to retrieve this data, according to HTTP 1.1 RFC 2616 S. 13.10, the cache should be invalidated. If the website uses GET request, the URL is likely to be unique, e.g. http://example.com/getmessage.php?uid=123456, since every user has a different UID, it is pointless to cache such responses.


Should the requirement of admin privileges be extended? Seeing this comic from xkcd.com made me thinking:

Is extending the requirement of admin privileges to things such as connecting to the internet, running the web browser, reading browser and other software config files, etc, be something operating system developers and maintainers should be looking forward nowadays?

Or is it the other way around - is it really necessary, in a desktop environment, to have a separate root account nowadays?

I understand the main reason for having a separate admin account isn't to protect your data from being stolen, but preventing software (and other users) from messing with stuff they shouldn't. But shouldn't that protection be extended? Or, on the other hand, wouldn't making programs run under a different, non-admin account or with different privileges instead of making the user log into one be more user-friendly?

The underlying idea of the comic is that separation of user accounts has been designed for mainframes: big computers, shared by many users. In that model, the potential attackers are other users. Account separation is then about protecting users from other users; only the god-like admin account can access everything on the machine, and the administrator has the duty of using his powers to strike down users who try to escape the boundaries of their accounts. System administrators consistently love this model, if only for its inherent ego flattering effect.

However, personal computers are not handled like that. They have a single user who expects to have admin powers on his system. More importantly, the attackers and defenders have changed. The attackers are now remote entities -- non-users from the outside, who will try to enter the machine through various vulnerabilities, in the loose sense of the term (this includes virus on USB keys, hostile scripts on Web pages, remote holes in network stacks...). The assets which the user tries to defend mostly reduce to their "elements of online identities", in particular the set of browser cookies, and their natural extension, the passwords typed by the user.

The comic points out, in a graphical way, that a separate administrator account does absolutely nothing to protect these assets. It does not harm, but it has no added value.

What should OS do ? Actually, not much -- it's more a question of what Web browsers should do. Increasingly, the Web browser is the operating system, and what we think of as the OS might have to be renamed "collection of hardware drivers". That's the idea which, for instance, Chrome OS tries to fully explore.

Account separation in mainframes was a damage containment feature. Its purpose is to prevent propagation of evil, and allow the sysadmin to smite at the infidels and trample them into oblivion, namely suppression of account. The gangrenous limb is not saved, but it is severed so that the rest of the organism remains safe, to some extent. How does this translate to the way personal computers are really used ? Remember that what is to protect is, primarily, the set of browser cookies. Damage containment then calls for domain-based sandboxing.

Indeed, cookies are already domain-separated: a server from a given domain may obtain the stored cookies for that domain, and for none other. Similarly, scripts and other browser languages are constrained by the same origin policy which is again domain-based. CSRF, XSS and all the related acronyms in which security practitioners revel are still about the crossing of the domain boundary. This really points at a security model in which each target domain is its own world, and a given browser instance should be contained in a box which allows access to that domain only (only machines in that domain, only cookies from that domain). If one browser instance gets subverted, then, hopefully, the sandbox mechanism will prevent subversion of other browser instances: if your browser-for-Facebook is hacked, your gmail account is still safe.

There is still contention for shared resources. Even if we can get the user to mentally separate his usage modes into separate browser instances (this can be more or less automatic, e.g. by having each set of tabs relative to a single domain to be managed by its own sandboxed process), the user still has a unique screen, keyboard, brain, pair of eyes and set of fingers. USB keys are a good example of problems: the user thinks of them as "files", not as "files for my Facebook-related tasks". The user will make files from USB keys available system-wide.

Moreover, users really love cross-site behaviours. E.g. they really want blog sites to feature Facebook buttons which do Facebook-related things right on the blog site. Real task separation is a constraint. This is similar to pressure doors in submarines: even when the doors are kept open, you still notice them and you still have to think about them when deciding where objects and men should go.

To sum up, having a separate account for system administration is not really needed in modern personal computers. You still need one, not because of any real gain in security (the sysadmin account does not protect that which is important to protect), but because current operating systems are still organized that way, and going against it may break too many things. It is mostly a matter of Tradition, as always.

What you need, if you want to mitigate effects of break-ins, is to apply separation of tasks, which is quite orthogonal to the separation of process that operating systems enforce; indeed, the Web browser is a typical example of a single process which spans several tasks, and this is incarnated by the cookie storage vault, which keeps all your dearest secrets in a single place.

And, of course, internal separation is still mitigation: how to survive breaches while keeping overall losses low. It is better if breaches are not permitted to occur in the first place... which again translates the problem elsewhere. In the submarine analogy, pressure doors are fine, but avoiding enemy torpedoes is finer.


Is there a tool to rate browser TLS/SSL configuration? I am looking for a tool to rate the configuration of SSL/TLS settings in the browser. I have found a few sites that enumerate supported ciphers and the preferences but none of them seem to provide judgement for what should be enabled and what should be disabled. In fact most of the sites I have stumbled across merely show what is supported and do not show what is not supported.

Essentially I am looking for an SSL Labs for the client not for servers. Any pointers?

How's My SSL? (new)
ssllabs-clienttest; very basic yet.
SSL Cipher Suite Details /  https://cc.dcsec.uni-hannover.de/


integrity and consistency This confuses me sometimes, I just need to know what is meant by integrity and consistency just in simple terms or in computer security.

will it be wrong to say:- someone who gain an unauthorised access to a computer and then modify files is violating integrity? if correct, how about consistency?

Thanks

Integrity means that the data is correct.

Consistency means that the data format is correct, or that the data is correct in relation to other data. This term isn't much used in Information Security, you'll find it in Computer Science in general.

For instance, accessing a database without authorization and changing a DOB from 1/1/1980 to 2/2/1980 would violate integrity.  Changing a DOB to 13/13/1980, or deleting a user so that other data (e.g. bills) references to NULL would violate consistency.


Is there a widely used protocol which builds on AES/GCM, and defines serialization formats of A, IV, C and T together? note: Title edited to make the answer more useful to a wider audience

I'm reading  source code for encrypting files with AES GCM and see the following binary output.

     AdditionalAuthData  IV            Encrypted Data          Tag (16 bytes)
     --------------------_____________------------------..... ----------------------------
byte 012345678901234567890123456789012345678901234567890.....   42  ........  57

Where the

AES key is secureRandom and 16, 24, or 32 bytes  (Aside: is random sufficient? the code I'm seeing isn't secureRandom)
IV is a non repeating value.  Can be random or increment per usage

Size is no smaller than 96 bits (12 bytes by NIST standard)

Tag/mac bit size equals 128

I want to be able to decrypt these files on a variety of devices.  What changes to the parameters above should be done to ensure broad compatibility across devices?

Specifically, what should the length and contents of AdditionalAuthData be?

Is this the common layout for AES GCM encrypted data? (variable length cleartext, IV, followed by encrypted data)?

"Additional authenticated data" is whatever you wish it to be. GCM is an authenticated encryption mode in which the inputs are:

a key K suitable for AES (128, 192 or 256 bits);
a 96-bit IV;
some plaintext data P whose length is at most 239-256 bits (i.e. about 68.7 gigabytes);
some additional data A whose length is at most 264 bits (i.e. about 2.3 millions of terabytes).

From these inputs, AES/GCM produces:

a ciphertext C;
an authentication tag T.

For decryption, you need these as inputs:

the key K;
the IV;
the ciphertext C;
the authentication tag T;
and the additional authenticated data A (pay attention ! That's the tricky point).

Then AES/GCM decryption will produce either P (the plaintext), or complain loudly in case one of the parameters has been altered (i.e. the provided K, IV, C, T or A does not match that which was used or obtained during the encryption).

So what does that mean ? That means that an AE system, like AES/GCM, offers the following services:

It ensures confidentiality of P: adversaries who do not know K cannot guess anything about the contents of P, when they see only the other values (IV, A, C and T).
It ensures integrity of P and A: adversaries who do not know K cannot alter the IV, A, C and T values such that the decryption algorithm does not complain. So if the decryption works, then there is a good guarantee that the A and resultant P are identical to what they were when encrypting.

Nowhere in the standard is it specified how the various values should be concatenated, wrapped, or otherwise serialized for transmission. How C, IV, T and A are known to the receiver is completely out of scope, and is up to whatever protocol is using AES/GCM. The values needs not necessarily be transmitted. For instance, if you consider TLS 1.2 (and GCM-specific details): the IV is partially transmitted, and partially inferred (4 bytes from the handshake, 8 bytes with each record); the additional authentication data A is partially transmitted and partially inferred (concatenation of the record sequence number, protocol version and plaintext length); C and T are transmistted in the record body.

Any given protocol which uses GCM may or may not have need for the "additional authenticated data"; this is a feature of GCM: it can ensure integrity over more than the data which was also encrypted. Since both sender and receiver must know the same "additional authenticated data" for the decryption algorithm to succeed, that additional data may have to be transmitted, although it could also, in any protocol (as in the case of TLS), be inferred from context. In any case, that data cannot be recovered from the ciphertext C even with knowledge of the key, which is why it is called "additional".

Therefore, your first question makes no sense. AES/GCM output is not a sequence of bytes accumulating A, IV, C and T. AES/GCM produces two sequences of bits, C and T. Your question should be: is there a widely used protocol which builds on AES/GCM, and defines serialization formats for transmission of A, IV, C and T together ? And the answer to that question is: to my knowledge, no. There are some protocols, but nothing which qualifies as "widely used". In particular, in most cases, at least parts of A will be inferred from context, not transmitted, and the same could apply to parts or all of the IV. This makes it unlikely that a general purpose format emerges and is actually used everywhere.

The answer to your second question (length and contents of A) is: "whatever floats your boat". You don't encrypt and/or authenticate in abstracto, just for the sake of it. You encrypt and authenticate as part of an overall protocol used in a given context which dictates what should be encrypted and what should be authenticated (as is done in TLS).

As for your question about "whether random is sufficient" for the key, then the only possible comment is: I must respectfully ask, Sir, that you drop this keyboard and stop trying to do cryptography. Lest I should use violence.


Is disk encryption (e. g. LUKS) reversed when having an encrypted disk image inside an encrypted partition with the same encryption password? Let's assume one has created an encrypted partition, e. g. with the LUKS standard. Then one creates a (virtual) disk image, e. g. for use by a virtual machine, containing an encrypted partition created by the same method and using the same encryption password. The disk image is stored inside the outer encrypted partition. I assume that a symmetric encryption is used.
Is it possible that the parts of the real disk which are occupied by the encrypted partion of the inside disk image are visible in plain text (or something close to that) as if no encryption was used (due to applying the same symmetric encryption method twice)?
If yes, in which particular configuration?

No. LUKS uses cryptography the right way so this isn't a risk. What you describe would only be a problem if both encryption layers did something really dumb, like both being naked AES-CTR with an unsalted hash of the password as the key.


How to force GPG to use a Keycard when it is available I have a yubikey (with PGP smartcard function) with my PGP key on it. I did not replace the private key on my main PC with a stub key as keytocard does by default, so I still can use the PGP key with a passphrase without using the yubikey.

But when the full private key is still in the keyring, gpg does not use the yubikey when it is present. Can I force gpg to use it when it is plugged in while using my passphrase to unlock the key on the PC when the keycard is not available?

I do not believe there is a way to do it, because the key record in GnuPG keyring needs to indicate that the key is on the card -- only then gpg will try to connect to it. You can make a full recursive copy of your gnupg directory into another location (e.g. $HOME/.gnupg-backup) and then perform keytocard. This will delete the key from your $HOME/.gnupg main dir, but if for some reason you need to resort to the local copy of your key, you can set an environment variable export GNUPGHOME=$HOME/.gnupg-backup to force gnupg to use the backup location containing the private key.


Question about credentials.json file I have a python script that connects to google drive and upload some files automatically.

The first time the application runs, it asks for a google account to use in its behalf to upload files to that drive.

However, I had to configure a project for this application in google api, and then download the corresponding credentials.json file. I've read the question posted here, and I humbly think this is not the same case, because in my case the application is a python script that you copy in your machine in order to run it.

The question is: is it safe to upload the credentials.json file to github??? The credentials.json file is something like this:

"installed":
    {"client_id":"NUMBERS-AND-DIGITS.apps.googleusercontent.com",
    "project_id":"INVENTED-PROJECT-ID",
    "auth_uri":"https://accounts.google.com/o/oauth2/auth",
    "token_uri":"https://oauth2.googleapis.com/token",
    "auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs",
    "client_secret":"A-VERY-SECRET-CLIENT-ID",
    "redirect_uris":
        ["urn:ietf:wg:oauth:2.0:oob",
        "http://localhost"]
    }
}

Edit: Some have suggested that is the same question of other, but in my case I am not revealing my credentials. Moreover, the first time the application run, asks for a google account and ask for permission to upload files to that account's drive.

I think I have the answer. The credentials.json file has the authorization to use the API. For create an application that uses the google api's you need two things: the first one is to request google for permission to use that apis. You might be charged for that use. The second is the usage per se: in that case, the application request a gmail account to upload files.

That's why you have a client-secret: the authorization to consume the API, and secondly, the gmail account in which you are uploading the files.


Does naming sensitive things discreetly provide protection? I had a job where a manager said he liked naming servers after places because if they were named descriptively e.g. "passwords database server" they become obvious targets. I sort of generalized this concept and when I'm writing code I avoid naming variables things like "password". Does this help security or does this confuse people who I should be working with?

Giving non-obvious names to things is akin to security through obscurity which is usually frowned upon in these parts. Problem with that kind of security is not that it does not work; indeed, it has some value, which was demonstrated many times through History (e.g. that's why a tank is called "tank" and not "armored chariot"). But you cannot quantify security through obscurity. You cannot know "how much" security it buys you; and, in particular, you cannot know whether it works at all (and though it often works well, it also often fails spectacularly).

Therefore, when thinking about risk management, the value of non-standard names must be considered low. This would not be a problem if it could be done "for free"; but non-standard names have a huge hidden cost: if they confuse attackers, they are likely to confuse sysadmins too. It will siphon out thinking time and resources, and will increase reaction latency if trouble arises.

Really, in IT security and in IT in general, descriptive names are a must-have.


Certficate pinning: should I pin the leaf or intermediate? I'm following this article : Android Security: SSL Pinning to implement certificate pinning in Android using OkHttp.

As our app clients do not update their app regulary I don't want to take the risk by using our server certification (Leaf certification) which will expire in about a month.

  ** Warning: Certificate Pinning is Dangerous!**

  limits your server team’s abilities to update their TLS certificates.
  By pinning certificates, you take on additional operational complexity
  and limit your ability to migrate between certificate authorities. Do
  not use certificate pinning without the blessing of your server’s TLS
  administrator!Pinning certificates

In the above article, the author did use two approaches. In the first one he used the leaf and intermediate certification, but in the second one he only used the leaf certification.

Is it possible to use the leaf and the intermediate and when the leaf gets updated my app will still work?

Is it OK to only use intermediate pinning?

You can pin leaf, intermediate CA, or root CA. All will work, but each comes with a usability / security tradeoff depending on the details of your setup.
The article you link actually gives a fairly good run-down of the differences:

Leaf certificate. By pinning against your leaf certificate you are guaranteeing with close to 100% certainty that this is your certificate and thus the chain is valid. Leaf certificates tend to have a short expiry time and if, for instance, the SSL certificates are re-issued because the private key is compromised your app will be bricked until you can push an update out. Of course the same may also be true if you frequently cycle your certificates.
Intermediate certificate. By pinning against the intermediate certificate you are trusting that intermediate certificate authority to not mis-issue a certificate for your server(s). This also has the advantage that as long as you stick to the same certificate provider then any changes to your leaf certificates will work without having to update your app.
Root certificate. By pinning against the root certificate you are trusting the root certificate authority as well as any intermediaries they trust not to mis-issue certificates. Often the root and intermediate authorities are the same company in which case there’s not much difference in the number of people you are trusting, however that’s not always the case.

In addition to what the article mentions, I'll say that then you pin a cert, you are removing the CA's ability to revoke that cert because your app trusts that cert implicely and will never go looking for status info for it. By that logic, pinning a CA (intermediate or root) has the advantage that when your leaf cert expires, gets hacked because you accidentally publish the private key on github, or whatever, you can easily ask the CA to revoke it and issue you a new one. Your app will keep working.
Personally, I would avoid pinning a leaf because you're essentially removing the parts that make a cert a cert: revocation and chaining to a trust root. You might as well do openssl genrsa and pin the public key in your app because you're not really getting any benefit from it being a cert.
That said, when you pin a CA, your app will trust any certificate issued by that CA, possibly to other people. You may be ok with that, maybe because it's your private corporate CA, or you may need to implement extra certificate validation logic to ensure that the cert chains to a pinned CA and the name matches what your app expects (and convince yourself that the CA would never in good faith issue a cert with that name to anyone who isn't you).

Summary: Pinning the leaf, intermediate CA, or root CA are all acceptable practice with some slight pros and cons. Do whatever makes sense for your app.


How self signed certificate works in https connection establishment OS/Browser have Public Keys of all trusted CAs. Eg mozilla foundation have a list of 50+ trusted CA means that mainly the public key is already present in the browser.

Now....some site say TrustedDomain.com sends a CSR request to one of the CA with all the required info such as
{
Domain Name
IP
Physical Office Address
Its Own PublicKey
}

Refer the above as Block1. CA uses its Own Private Key to sign the "Block1" E(Block1, PRiKey-CA) = k

Endpoint sends a page request for TrustedDomain.com and gets the "k" . It uses Public Key of CA which available to everyone to decrypt K
This verifies that the Connection is trusted as if decrypted using the CA public key it has to be come from CA and its genuine.

After this Endpoint initiates connection to Trusted domain using Trusted domains publickey to encrypt the data and Trusted domain opens it using its own private key, a secure channel is created after that they switches to symmetric encryption for actual data transfer.

Now

Say A website is using a self signed certificate. we are trying to open this site using HTTPS.
Now as per my understanding the site will use its own Private key to sign its [Domain,IP, own Public Key] etc say blockB

Now the question is when we send a request to this site we get a certificate error. Now we have the option to install this certificate. Jus want to know as we donot have the PublicKey of this self signed website How it opens the blockB to get the publickey?

can someone explain/give some pointer how this cert info is carried in Packet Level?

The certificate contains the public key.

How the certificate is carried depends of HTTPS/HTTP2.


Server SSH fingerprint verification when authenticating with private key Assume I passed on my public key to a service provider for them to set up a "new" server and configure it for private key authentication (instead of root password).
Is the server fingerprint verification during my initial connection to the server still necessary and/or helpful against MITM or any other attack?
I realize that verifying the server's fingerprint initially when using password authentication is absolutely sensible. But I don't understand the SSH protocols well enough to see, if this still makes sense if I never use a password at all.
Wouldn't a successful first-time authentication with my key imply that the server has my public key and is, therefore, the right one? Or is there still a way to perform a MITM attack in such a scenario? Is there any qualitative difference between this scenario and a first-time authentication with a password?

To transfer your public key to the server with "ssh-copy-id" you have to connect to the remote ssh server. If you establish the connection for the first time, the fingerprint must be verified.
This is the point, where you are most vulnerable, because the fingerprint is not known.
To mitigate this problem, the server admin should publish the fingerprint on a trusted source. This could be a website with https or as "sshfp-record" dns with dnssec.
If you can upload your public key through a web interface, your public key is already known, but you have the problem, that the server is not known to you.
A full mitm attack is not possible, but an attacker can intercept your connection and trick you in a fake shell. When you are entering passwords, the attacker can log them in plaintext and reuse them for authentication, if your server allows password authentication.
So, public key authentication does not protect you against ssh mitm attacks, if you don't check the fingerprint.
If you are interested in ssh mitm attacks and want to learn more about them, there are some tools available. https://github.com/ssh-mitm/ssh-mitm is able to intercept public key authentication. (I'm the author of this tool)