Verifying android application integrity from server side I have android applications (Mobile banking) that connect to my server and do online transactions (via Internet/USSD/SMS), I want to make sure those clients are not tampered with and are the original ones distributed by me.

Keep in mind that not all of my customers download the application via google play, some of them use 3rd party markets or download the apk from elsewhere.

Is there a way I can validate the integrity of the application (using a checksum or a signature) on the server side to make sure its not tampered with. (e.g a trojan is not implanted in the application and then redistributed)

For suggested solutions:

Can they be implemented over all 3 communication channels (SMS/USSD/Internet) or are the solutions proprietary to one/some channels?

(I'm looking exactly for the technique that's been referred to in this page: https://samsclass.info/android/chase.htm) :

  Chase's servers don't check the integrity of their Android app when it
  connects to their servers. It is therefore easy to modify the app,
  adding trojan code that does malicious things. An attacker who can
  trick people into using the trojaned app can exploit them.

  This vulnerability does not affect people who are using the genuine
  app from the Google Play Store. It would only harm people who are
  tricked into installing a modified app from a Web site, email, etc.

Use Android SafetyNet.  This is how Android Pay validates itself.

The basic flow is:

Your server generates a nonce that it sends to the client app.
The app sends a verification request with the nonce via Google Play Services.
SafetyNet verifies that the local device is unmodified and passed the CTS.
A Google-signed response ("attestation") is returned to your app with a pass/fail result and information about your app's APK (hash and sigining certificate).
Your app sends the attestation to your server.
Your server validates the nonce and APK signature, and then submits the attestation to a Google server for verification.  Google checks the attestation signature and tells you if it is genuine.

If this passes, you can be fairly confident that the user is running a genuine version of your app on an unmodified system.  The app should get an attestation when it starts up and send it along to your sever with every transaction request.

Note, however, this means:

Users who have rooted their phone will not pass these checks
Users who have installed custom or third-party ROM/firmware/OS (eg Cyanogen) will not pass these checks
Users who do not have access to Google Play Services (eg Amazon devices, people in China) will not pass these checks

...and therefore will be unable to use your app.  Your company needs to make a business decision as to whether or not these restrictions (and the accompanying upset users) are acceptable.

Finally, realize that this is not an entirely airtight solution.  With root access and perhaps Xposed, it is possible to modify the SafetyNet library to lie to Google's servers, telling them the "right" answers to get a verification pass result that Google signs.  In reality, SafetyNet just moves the goalposts and makes it harder for malicious actors.  Since these checks ultimately have to run on a device out of your control, it is indeed impossible to design an entirely secure system.

Read an excellent analysis of how the internals of SafetyNet work here.


Are there any reasons for using SSL over IPSec? is it recommended  to use both protocols together? In which situation?

There are different layers of secure transport to consider here:

VPNs

SSL VPN (including tunnels)
IPSec VPN

SSL/TLS for individual services

IPSec vs SSL VPNs

Both SSL and IPSec VPNs are good options, both with considerable security pedigree, although they may suit different applications.

IPsec VPNs operate at layer 3 (network), and in a typical deployment give full access to the local network (although access can be locked down via firewalls and some VPN servers support ACLs). This solution is therefore better suited to situations where you want remote clients to behave as if they were locally attached to the network, and is particularly good for site-to-site VPNs. IPSec VPNs also tend to require specific software supplied by the vendor, which is harder to maintain on end-user devices, and restricts usage of the VPN to managed devices.

SSL VPNs are often cited as being the preferred choice for remote access. They operate on layers 5 and 6, and in a typical deployment grant access to specific services based on the user's role, the most convenient of which are browser-based applications. It is usually easier to configure an SSL VPN with more granular control over access permissions, which can provide a more secure environment for remote access in some cases. Furthermore, SSL/TLS is inherently supported by modern devices, and can usually be deployed without the need for specialist client-side software, or with lightweight browser-based clients otherwise. These lightweight clients can often also run local checks to ensure that connecting machines meet certain requirements before they are granted access - a feature that would be much harder to achieve with IPSec.

In both cases one can be configured to achieve similar things as the other - SSL VPNs can be used to simply create a tunnel with full network access, and IPSec VPNs can be locked-down to specific services - however it is widely agreed that they are better suited to the above scenarios.

However, for exactly these reasons, many organisations will use a combination of both; often an IPSec VPN for site-to-site connections and SSL for remote access.

There are a number of references on the subject of SSL vs IPSec (some of these are directly from vendors):

https://supportforums.cisco.com/document/113896/quick-overview-ipsec-and-ssl-vpn-technologies
http://netsecurity.about.com/cs/generalsecurity/a/aa111703.htm
http://www.sonicwall.com/downloads/EB_Why_Switch_from_IPSec_to_SSL_VPN.pdf
http://searchsecurity.techtarget.com/feature/Tunnel-vision-Choosing-a-VPN-SSL-VPN-vs-IPSec-VPN
http://www.networkworld.com/article/2287584/lan-wan/ipsec-vs--ssl-vpns.html

End-to-End Encryption

In some of the above cases, such as IPSec VPNs and SSL VPN tunnels, you may not be getting end-to-end encryption with the actual service you're using. This is where using an additional layer of SSL/TLS comes in handy.

Say you're remote and trying to connect to an internally hosted web application via an IPSec VPN. If you use the HTTP protocol via your browser, your traffic is encrypted whilst it is running through the VPN tunnel itself, but it is then decrypted when it hits the remote VPN endpoint, and travels over the internal network in cleartext. This might be acceptable in some use cases, but in the interest of defence in depth, we ideally want to know that our data cannot be intercepted anywhere between you and the actual service itself. By connecting to this application over HTTPS, you effectively have two layers of security: one between you and the VPN endpoint, and another travelling through that (between you and the web server itself).

Of course, this is not limited to HTTPS - you should equally employ other secure protocols like SSH, FTPS, SMTP with STARTTLS etc etc.


Storing client keys in cloud app I'm using Azure to store customer data. In a specific country, there are multiple partners. Each partner has his clients. The issue is they don't want us to have access to this data. In other words, the only one who can access the data is the partner and the client. So I'm thinking of using a master key for each partner but I'm not if not the best approach.
My idea is to create 2 layers of encryption:

Client App
Azure storage
Partner
Client

encrypt data (only client and partner can opened)
encrypt data with Microsoft encyption
Get the data
Can get his data

At this step I'm blocked in the first step where how can I encrypt the data without storing the encryption key of partner(s).
Do you have any suggestions?

You can use Azure Key Vault in conjunction with Azure Blob Storage enabled with customer-managed key to meet this requirement.  When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Customer-managed keys offer greater flexibility to manage access controls.

The following list explains the numbered steps in the diagram:

An Azure Key Vault admin grants permissions to encryption keys to the managed identity that's associated with the storage account.
An Azure Storage admin configures encryption with a customer-managed key for the storage account.
Azure Storage uses the managed identity that's associated with the storage account to authenticate access to Azure Key Vault via Azure Active Directory.
Azure Storage wraps the account encryption key with the customer key in Azure Key Vault.
For read/write operations, Azure Storage sends requests to Azure Key Vault to unwrap the account encryption key to perform encryption and decryption operations.

https://docs.microsoft.com/en-us/azure/storage/common/customer-managed-keys-overview


Android app using FTP I have done some android programming (self taught). I have started working on an app idea. The idea is pretty much that people with the app installed can post pictures/videos and text which can be seen by everyone with the app.

I have purchased a hosting (working on making my own webpage), which has a lot of disk space, so I thought about using that. It seems pretty easy to add files using some sample FTP code I found online.

My biggest fear is in regards to security. Not as much about the files being put there (because anyone who installs the app will be able to see it anyway) but mostly if they would be able to get the server address, username and password in some way, which would give them access to add and remove other files from the hosting.

Is this a legitimate fear? Is there a danger of that? If yes, what should I look into as an alternative?

EDIT: Sorry if I wasn't very clear. My fear is if they could get their hands on my username and password, which would be somewhere in the java code (and if so, how to avoid this)

Easiest attach vector is to sniff the FTP traffic. As FTP is a plain-text protocol, anyone with a network sniffer or a compromised router, or in an open wifi, will be able to capture app's FTP credentials without even breaking a sweat. So, make sure you use at least SFTP.


Kerberos authentication over the public internet What are the threats to having the KDC accessible via the internet for remote clients?

It's my understanding that the authentication is a challenge/response protocol and that the password is never transmitted. Are brute force attacks the reason this isn't common?

Is this because the kerberos authentication is more valuable than brute forcing an individual ssh or mail account as multiple services on multiple hosts might be compromised at once? Is it because of the attack surface of the KDC itself and that a pinhole firewall is not seen as sufficient barrier to preventing access to this valuable lynchpin for authentication and authorization?

Arguably the reason Kerberos isn't used over the public Internet doesn't have to do with the security of the protocol, or the exposure of the KDC, but rather that it's an authentication model that doesn't fit the needs of most "public Internet" applications.

To quote Wikipedia, Kerberos "provides mutual authentication — both the user and the server verify each other's identity."  That means that the client machine needs to have the necessary keys to vouch for its identity before user authentication takes place.  Distributing those keys for "public Internet" applications isn't practical for several reasons - consider how many PCs access your banking web site, owned by a wide variety of people whose ability to install Windows patches regularly is strained.  It's not like corporate IT will come around and configure Kerberos for them.

Kerberos requires tightly synchronized clocks - not that hard to do in a centrally managed corporate or educational environment, a lot harder when the machines are all owned and managed by completely different people.

One of the advantages of Kerberos is the ability to seamlessly leverage an initial authentication into multiple application accesses.  On the public Internet, the multiple applications rarely have anything to do with each other - my bank, my mail, and my /. account have no call to trust each other or the same set of people.  (This falls into the area of Federated Identity, and there is work in this area, but it doesn't need the same mix of things Kerberos brings to the table).

In short, Kerberos is a heavyweight solution, and public Internet application access control is a lightweight problem.

To answer your actual question directly, no, I don't believe concerns about brute-force attacks or vulnerability of the KDC keeps Kerberos off the Internet.  The protocol has been reasonably well vetted, attacked, fixed, and updated over 20+ years.  The client (machine) authentication piece alone provides tremendous protection against a number of attacks that are expected on a large open network like the Internet.


How to really treat security between peers in WebRTC Recently I've been implementing WebRTC in my project and would like to add security and privacy to the couple. I then decided to search on and found something

  if it is really necessary to impose security, it should be done at the
  application level.

I do not remember if I read this in the API or security sites ..

All right, I encrypt traffic (answer, offer, candidate..) with AES and RSA.

I noticed that the work of my system greatly reduced efficiency, it slowed the time to connect, which is kind of obvious because so many processes at once.

My questions taking into account all these are:

Am I doing right?
Is it really necessary encrypt all ?, may not just be the answer and offer?
Is there anything else I should know?

Technically, encryption always have a performance impact, in todays machines it's negligible.  For best outcome, you could perform the following:

Get the RSA public key of the server side.
Create a symmetric AES key, encrypt it with the RSA public key and send it to the server; the server decrypts it and you have a 'pre shared secret' then.
Encrypt your data with the symmetric key, and decrypt it on the server.

Not to re-invent the wheel, but if you have browsers such as Opera, Chrome or FF, you could use Datagram Transport Layer Security or ZRTP.

In essence, WebRTC creates a new communication channel, and encryption is up to you.  What you encrypt (offer, answer, ...) is basically based on how sensitive the information is, but once a channel is setup (i.e: the AES key is shared), you may as well encrypt everything; again - you'll have a minimal performance impact on modern systems.


How can I do a maintainable and significant risk assessment in an organisation with thousands of assets? The problems I see with the typical risk assessment are as follows:

Maintaining the list of assets updated
Maintaining the status of the treatments updated and the risk level
coherent with that.
Maintaining the dependency of the assets in a way that irrelevant
assets (like a server) have the real risk (due to the fact that that
the server allows a critical process to run).

The problem I see is that when I finish the Excel the results are no longer relevant.

There are many commercial asset management solutions that auto-discover assets and their relationships such as Service Now.

Then the discovery scans run daily or weekly on a schedule to keep it up-to-date.

Of course, nothing is perfect so it has to be put directly into the shoulders of the server and app owners to on a recurring basis and after any change control to update or fix any incorrect data or add missing data in the inventory.

For example:

a project can't go live until all systems, apps, and their relationships are updated
a new pc or server cannot be deployed until it's in the inventory
a system is decommissioned they must remove it from inventory

The risk assessor then should just be given access to the inventory but should not be required to maintain it


vulnerabilities in a machine that detects vulnerability scanners I currently have a machine (set by another person) that has (according to nmap) open ports as:

FreeBSD ftpd 6.00LS where anonymous login is possible
OpenSSH 4.5p1 (FreeBSD 20061110; protocol 2.0)
FreeBSD fingerd
Apache httpd 2.2.6 ((FreeBSD) DAV/2 PHP/4.4.7 with Suhosin-Patch mod_ssl/2.2.6 OpenSSL/0.9.8e)
| http-methods: GET HEAD POST OPTIONS TRACE
cvs pserver
mysql (unauthorized).

The OS is FreeBSD 8.1-release.

I use a VPN to connect to my server, and every time I use vulnerability scanners, the connection freezes. Not sure if this is due to the size of packets, but they do not work. Acunetix web scanner does work, but it is irrelevant with what I am trying to test, as there is no web application on the server. I am assuming that the machine is set to detect vulnerability scanners, so I cannot use vulnerability scanners to check how the machine would be vulnerable.

Is there any vulnerability that a hacker might use to gain the command shell of the system?

Also, would there be any way to gain the command shell of the system using finger (command finger @my-machine-IP-address says access denied.)

Add: what does "MySQL (unauthorized)" mean?

Is there any vulnerability that a hacker might use to gain the command shell of the system?

That depends upon whether any of the software on your system is vulnerable.  We probably cannot answer that for you, and in any case, any answer would be too specific to your particular system to be of relevance to others and too limited in time to be of broad interest.

If you are unable to scan your machine with nmap, I suggest you check whether you have a firewall set up that might be blocking nmap.

For information about how to secure your server, I suggest you search on server hardening on this site.  I think you'll find a good bit of information about how to lock down a server to reduce the likelihood of vulnerability.

P.S. Generally speaking, I would turn off fingerd or configure my firewall to block all connections to it.  Almost no one uses finger these days, so there is not much reason to be running an Internet-facing fingerd server -- it's just unnecessary risk.


Am I generating email link tokens correctly? I am developing a reliable system for token generation and validation used mainly for links in confirmation emails (reset password request, change email flow, activate an account, etc...).

There are a few things that are mandatory:

Token must be unique (even when two generated at the same time) in system (in database)
Token must be one-time use
Token must have expiration
Token cannot be guessable

From that I decided to generate token like this:

token = sha256(user.id + time + uuid(v4) + secret)

This token do not need to carry any expiration information, because it is saved in database with those columns externally.

Does this token meet my requirements above points? If not, how to modify my approach?
If this token meets my requirements, is there a way to simplify it while meeting my goals?

I am asking this, because I know there are some known exploits of those types of one-time use tokens sent to email and I am not sure if I will be safe.

If you are storing all the relevant information (token, expiration time, user) in the database anyway, the only thing you need to make sure about the token is that it is impossible to guess a token.

Your token is impossible to guess if at least one of these two holds:

The secret remains secret. It has to have very high entropy, and never be leaked.
The UUID is generated using a secure random source.

Actually, your system is more complex than it needs to be. Since the token is only used to look up the info in the database, and not validate it, you could just use the UUID and nothing else - no hash, no secret, no other data. Only thing you need to make sure is that the UUID is generated with a secure random source.


Format of finshed message when the cipher selected is "TLS_ECDH_ECDSA_WITH_NULL_SHA" i wanted to understand difference in the "Finished message" when different  cipher site selected with encryption and with out encryption.

I am able to find the format of Finished message when the selected cipher suite includes encryption as below.

when the selected cipher suite is :-"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"

Finished message:- Record layer header+Encryption initialization vector+Encrypted data+Handshake header+Verify data

when the selected cipher suite doesn't have encryption involved :-"TLS_ECDH_ECDSA_WITH_NULL_SHA".
Finished message:- Record layer header+Handshake header+Verify data

please let me know if my understanding is correct ? if not please let me know how the format looks like.

The format of an encrypted record in TLS can depend on the protocol version and (part of) the ciphersuite selected.

Even a null-encryption suite (which only exists through 1.2) still does MAC for message integrity (aka data authentication); for your example this is HMAC-SHA1. See rfc5246 6.2.3.1 (this one is the same in earlier versions); the record consists of: record header 5 bytes specifying handshake, 'content', and MAC (for HMAC-SHA1 20 bytes), where 'content' consists of handshake header 4 bytes specifying finished and verify_data 12 bytes.

The same format is used for stream cipher, except that the content and MAC are (together) encrypted by the configured cipher. However the only stream cipher in TLS was RC4, which is prohibited by rfc 7465 since 2015, so you shouldn't see this format in use. (Some implementations still can support RC4, so you might be able to use it in a test environment.)

For block ciphers using CBC mode in TLS 1.2 and 1.1, see rfc5246 6.2.3.2; the record format is record header followed by an IV and then encryption of the contents (as above) plus HMAC plus padding.
In TLS 1.0 (and SSL3) this is different, see rfc2246 6.2.3.2; instead of the IV being chosen and sent with the message, the initial IV (for the first message) is created in the key derivation, and subsequent messages are chained: the last ciphertext block of one message is used as the IV for the next message. Since the prior message can be seen on the wire, this allows a chosen-plaintext attack originally identified by Rogaway in 2002 and popularized by the 'BEAST' attack in 2011, about which this and related Stacks have numerous Qs. Note the order used in standard TLS, MAC-then-encrypt, is less secure with CBC because it allows a padding oracle, which was very severe in SSL3 (POODLE) and is less so in TLS1.0-1.2 (Lucky13). There is a recent option for 1.2 to use Encrypt-then-MAC, see rfc7366 -- but the easier and more common solution in 1.2 (and the only one in 1.3) is to use AEAD instead.

For AEAD ciphers, new in 1.2, see rfc5246 sec 6.2.3.3; this has the record header, 'explicit' part of the nonce (which in turn depends on the ciphersuite), and the authenticated encryption of content. All currently defined authenticated encryption schemes consist of encrypting content with a stream cipher (AES-CTR or ChaCha20) and appending a MAC (GMAC, CMAC, or Poly1305).

TLS 1.3 changes things. It no longer has ciphersuites of the form you reference; instead the ciphersuite specifies only the data cipher, which is always an AEAD cipher, and the hash used in key-derivation (what earlier versions called PRF); the key-exchange and entity authentication methods are selected separately. Thus 1.3 never has Finished (or anything else after CCS) in a null-encrypted record, nor a stream cipher, nor a CBC cipher. See rfc8446 5.2; now we have record header 5 bytes always specifying 'application data' (23) even for an actual handshake record, followed by the authenticated encryption (as above) of content, the real aka 'inner' record type, and optional/variable padding. In 1.3 the nonce for the AEAD cipher is (always) the record sequence number masked by a value from the key derivation, and is not sent; this is described in 5.3. Also for Finished in particular, in 1.3 verify_data is now a single HMAC (instead of the PRF in 1.0-1.2) of a very similar transcript hash, but is no longer truncated to 12 bytes and now varies with the derivation hash.


PDF files on webserver file system We create PDF files as relevant to a customer's e-mail communication. These PDF's contain some personal information, specific to the client.
The client is emailed a link to the PDF. The link to the PDF contains a 40 byte unique string specific to this communication to ensure uniqueness and to avoid guessing.

Is there any best practice concerning this approach, may the PDF-files be placed on the webserver directly, or should additional steps be taken in order to prevent harvesting or any other attack on our customers privacy?

Would there be an additional security gain in storing the PDF's in a database, instead of placing them directly on the file-system of the webserver (assuming it is properly secured)?

My suggestion would be as follows:

Store the PDFs on a LUKS partition (or GPG full-disk / TrueCrypt full-disk), so that theft of the physical disks should not yield the data.
Run a secondary HTTP server whose sole job it is to serve these files. Configure your file permissions such that only that HTTP server can read the PDFs. This provides minimum attack surface for data theft, and prevents the main HTTP server from reading the files.
Set up single sign-on or something similar to authenticate between the two servers.
Only serve the files over HTTPS, with SSL 2.0 and older disabled, preferably with AES-GCM set as the preferred cipher.

Storing them in the database wouldn't make much sense, since access to the disk would still yield the files.


Is there a danger to client port scanning? Are there any security risks associated with client-side port scanning? Or, more specifically, a "trusted" site (e.g., banking website) loading javascript trying to connect to various localhost ports?

This looks suspicious to me, but seems to be an emerging (or standard?) practice, as referenced in earlier questions here:

Strange Payment Gateway

Also, some Redditors noticed Facebook and banking sites doing this as well:

https://www.reddit.com/r/AskNetsec/comments/4j0nas/why_is_facebook_checking_my_open_ports/

https://www.reddit.com/r/AskNetsec/comments/6825ki/why_is_my_internet_banking_is_scanning_for_vncrdp/

And even cybersecurity researcher Paul Moore sought to sue over this as well:

https://www.cbronline.com/news/halifax-port-scans

https://www.theregister.co.uk/2018/08/07/halifax_bank_ports_scans/

So, what's really going on? Why are they doing this? Can there be security or privacy risks involved?

This answer suggests they may be doing it for some kind of threat detection or anti-fraud process perhaps, but all of this still seems somewhat fishy to me.

Why would a web application try to connect to a port on localhost?

A simple explanation that doesn't involve malicious acting is developmental tasks. Depending on the environment, some developers may install a local, lightweight copy of the backend API on their development machine. This would allow the frontend code to try and connect to localhost and do its things on the developer machine, rather than the production backend.

Why would such a code be in a production app?

It wouldn't be unheard of that someone accidentally pushed code to the wrong branch. I've seen plenty of debug code in production releases. With a big enough codebase and enough developers, someone, somewhere will push some debug code to production, sooner or later.

Are there other explanations?

Yes, certainly. Banks have, depending on the jurisdiction, many obligations they need to fulfill. As you may know, politics is as much about personal image as it is about the actual effect of policies. So some politicians may try to boast that they pushed some regulation that forces banks "to do security stuff", which ends up in regulations like "Banks have to detect if end-users have malware on their computer and warn them".

This sounds good to politicians and other non-tech users, but when these policies then end up in the hands of developers and system administrators, who then have the unfortunate task of implementing these, it quickly turns into a nightmare.

So what do banks usually do in such cases? They buy some software that claims to do exactly that. What does that software do? God knows, but it ticks the checkbox, and that's good enough. What the software actually does isn't important, as long as they can claim it does something. And searching for open ports on the system of the user seems like a good thing to do.

Can this be dangerous for me?

It might have adverse side effects for you. Depending on what the software is set out to do, it may detect legitimate software on your PC as malware and alert the bank that you have malware on your PC. Depending on how the bank is run internally, this might mark you as a "risk user" and give you worse conditions down the line.

Of course, this is very speculative, but it is a risk nonetheless. It also could mess with the software you have on your PC. Simply the act of attempting a new connection could cause your application to react differently, and thus adversely to what you may have intended to do.

Finally, the bank or other website may also detect certain local applications and use this to profile you in different way, such as "Web Developer" or what not. This may be information you consider none of the bank's business.

Is this legal?

I am not a lawyer and I can't answer for the legality of this practice. If you care about your own bank, then I suggest contacting a lawyer in your area. They will certainly be equipped to answer your concerns in regards to your applicable jurisdiction.


Is there any reason to disable paste password on login? Today I logged in to pay my cellphone bill, and I found that the site has disabled paste functionality in password field.

I'm a webdev and I know how to fix this, but for regular user is REALLY annoying having to type a random password like o\&$t~0WE'kL.

I know that is normal to make users write the password when creating an account, but is there any reason to disable pasting passwords during login?

There is no substantial security benefit to disallowing pasted passwords; on the contrary it is likely to weaken security by discouraging the use of password managers to generate and autofill randomized passwords. While some password managers are capable of overriding pasting restrictions, the point still stands that users should not be forced to type their password by hand.

Excerpt from a relevant WIRED article:

  Websites, Please Stop Blocking Password Managers. It’s 2015

  But what’s crazy is that, in 2015, some websites are intentionally
  disabling a feature that would allow you to use stronger passwords
  more easily—and many are doing so because they wrongly argue it makes
  you safer.

  Here’s the problem: Some sites won’t let you paste passwords into
  login screens, forcing you, instead, to type the passwords out. This
  makes it impossible to use certain kinds of password managers that are
  one of the best lines of defense for keeping accounts locked down.


How can I sniff Telegram packets before they get encrypted? How can I sniff packets that are being sent from my computer to their server and from their servers to me using a sniffing app like Wireshark?

Right now when I use Wireshark, they are all encrypted, but obviously I should be able to sniff it considering my computer is the one that is encrypting and decrypting them using keys.

I'm using Windows and want to sniff the desktop version if that makes any difference.

I'm not aware of any off-the-shelf way to accomplish this.  In order for wireshark to decrypt the packets, it would need access to the encryption key which Telegram uses, which it does not have direct access to.  You would need some way of accessing the memory which Telegram uses, figuring out which part of that memory is the encryption key, and then using that key to decrypt the data.  And if you already have access to the memory which Telegram is using, why not just read the data before it was encrypted?


valid intermediate certs not in browser Say an X.509 cert is signed by an intermediate cert that's not in your browser.  Maybe the root certificate is but not the intermediate cert.  At that point it seems like a valid certification path could exist even if your browser doesn't know about it and I guess you'd just be S.O.L?

Seems like maybe there ought to be an extension saying where the issuer cert can be obtained (assuming it's not the root cert) just as how there exist extensions for certificate revocation lists saying where those can be obtained.

It is the server's responsibility to serve up the entire certification chain.  If your web server isn't doing that, it is misconfigured, and you should fix it.

You can use the SSL test service from SSL Labs to test whether your server has SSL properly configured.  Just type in your server's domain name, and it will give you a report indicating whether it has any configuration issues.  You can also use GlobeSSL's SSL tester, if you want a second opinion, though I think SSL Labs' service is more comprehensive.


Buffer overflow due to strlen, strcpy, strcat I'm new to secure code review. I know that strlen will calculates the length until it finds a null character. This is a part of a larger code.

char* executeMount(char* password, char* path, int unmountOrMount)
 {
 char* catString = new char[(strlen("echo|set /p password=") + strlen(password) + strlen(" | runas /user:administrator \"mountvol ") + strlen(path) + 1)];
 strcpy(catString, "echo|set /p password=");
 strcat(catString, password);
 strcat(catString, " | runas /user:administrator \"mountvol ");
 strcat(catString, path);
 //Equivalent command: system("echo|set /p password=" + adminPassword + " | runas /user:administrator mountvol" + path);
 return catString;
 }

Will return catString lead to a buffer overflow?

Strlen will calculate all the strings until it reaches a null terminator. So catString is the total length of all the strings + 1 (for null terminator). strcpy will copy echo|set /p password=" + null terminator. Following strcat will remove the null terminator and concatenate "password" but the subsequent strcat will not remove the null terminator leading to buffer overflow? Is my thinking correct? Is this code vulnerable to any other threat?

You're using C++ (because you couldn't use new char if you weren't); you should really be using std::string here, including as the return value.  You can then dereference .c_str to get a const char * pointer if you need that in your upstream code.

You don't want to just return the std::string.c_str from your function however; the std::string will go out of scope and you'll be invoking undefined behavior.

That avoids having to deal with any of this character-counting stuff.


Can password managers read my secure data? If no, how does sharing work under the hood? All the popular password managers on the market advertise that they have AES-256 grade security. In a nutshell, the user has the master key and the password manager has the cipher-text. So the password manager cannot read any of the user data.
How do password managers have the feature to share passwords between friends and family?
Since password managers only have the cipher-text, when sharing with another person it should have the other person's master key for it to create a new cipher-text (which can be decrypted with the other person’s master key).
The above is achievable either by sharing the data as a plain text or maybe having a temporary sharing key. Even if they have either of the solutions, then editing shouldn't work.
Apps like Dashlane allow sharing with editable options. How is it possible to do that without knowing both parties master key? Are they somehow saving my key without my knowledge?

This could be implemented in a way that the provider has no access to the password. For example, the password can be asymmetrically encrypted. If the password is encrypted using your public key, and it's encrypted using your friend's public key, only you two can read the password. And you can modify and re-encrypt the password using both public keys. The provider can't read the password.
I don't know whether Dashlane or other password managers actually do this, but it's certainly possible.


Disabling downloads in the browser; are there any benefits? I was playing around with the security settings in my browser (IE) after being attacked by malware. I noticed an option to disable downloads. If I were to disable downloads, and re-enable them when necessary, would this provide more protection for my computer against malware (drive-by downloads) from websites?

Short answer: No. Useless.

Detailed answer:

In fact, drive-by download attacks are malware delivery techniques a user may encounter by a simple visit of a website. This simple visit is what is referred to by drive-by download. It is an attack where the user is not intending to download anything at all.

A drive-by download attack may require or not user's interactions. It occurs without the user's consent and knowledge. It takes advantages of the vulnerabilities available in the browser itself as well as the ones available in its plugins or extensions.

Note that in case this attack requires the user's interaction, such interactions are performed  most of the time -if not the only way- by clicking on some pop up windows: whether you click to agree (Ok), disagree (Cancel) or simply leave the window (X) you the attack will be triggered (sometimes you get a series of popup windows)

For instance, CVE-2011-0611 was a 0-day vulnerability up to April 13th, 2011 . It was used to infect the homepage of the Human Right Watch website in UK. The infected page contains a rogue <script src=newsvine.jp2></script> element. This tricks the browser into caching and executing newsvine.jp2 as JavaScript code. It was a drive-by cache attack which is just a case of drive-by download attacks. The caching is successful, but the file cannot be executed as JavaScript because it is actually a renamed malicious executable corresponding to a backdoor from the pincav family.

Another rogue script element found on the infected page is <script src="/includes/googlead.js"></script>, which unlike most drive-by download attacks, loads a local .js file. The JavaScript code in googlead.js creates an iframe that executes the SWF exploit from a domain controlled by the attackers.

We can mention also the famous and successful a drive-by download attack of which no browser was safe as long as they run a vulnerable version of JRE at that time (CVE-2011-3544) leading to thousands of visitors of the Amnesty International's homepage in UK were thus infected by Trojan Spy-XR malware. The attacks continued until June 2011, so later after you asked this question: Google Chrome was not safe of it.

On October 24th, 2013, the famous php.net website has been infecting its visitors by a drive-download attack through a hidden iframe tag.

How to avoid this type of attacks?

There are several ways to avoid such an attack, but they all generally result in a less usable experience on the internet. You can disable all JavaScript and embedded active content from running (or require prompts before they execute). This will prevent downloads without you having to approve the active script. Even the default options of recent browsers are a lot better than they used to be, but are not sufficient to stop all threats.

There isn't a perfect solution, you need to find the balance that works for you between usability and security. You may use some common sense: install only the browser plugins/extensions you really need; do not visit website where such attacks have more probability to be hosted (porn websites ...).  If you want to visit such untrusted web sites then you should consider using more secure options or using a virtual machine to reduce your risk, but if you stay on the respectable parts of the Internet and keep your browser, AV and operating system all patched/up-to-date.


Reasons to encrypt filenames on cloud backup I use a cloud service for my off-site backup, and all my files are encrypted. But I am wondering whether to enable filename encryption or not. Are there any security advantages to be gained by encrypting the filenames as well?

The downside to encrypted filenames is that it leaves the cloud web browser utterly useless.

If filenames are sensitive then encrypt them, if not then don't. Eg. are you happy for staff at your backup service or possibly others (in the case of breach) to see Secret Government Contract bid.docx listed?

That's all it comes down to. A cost/benefit analysis for your particular usage. You should also find out if the client software can restore the original folder structure and filenames upon recovery from backup. Consider if this original information stored encrypted in the cloud and where the decryption key is kept.


Explaining malware avoidance tactics Most "how tos" regarding malware list this:

Install Antivirus software.
Install latest antivirus software.
Run antivirus software regularly.
Install latest operating system.
Install any patches to software.
Don't download random stuff and run it as an application (like .exe files).

I would like to know in a little more detail what all those first steps mean, and what else could be included in this list. For example, LittleSnitch blocks all outgoing and incoming traffic and lets you inspect it first. That would be a good thing to do. Then there is potentially being alerted whenever a script tries to be invoked that you didn't write yourself, or isn't installed from a trusted vendor. I'd like to know what other kinds of things you should do beyond this list to have an ideal security environment in regards to avoiding malware.

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

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

Now, in more detail:

  Install Antivirus software.

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

  Install latest antivirus software.

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

  Run antivirus software regularly.

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

  Install latest operating system.

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

  Install any patches to software.

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

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

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

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

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

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

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


What is the way to know that the endpoint is down if there is an L4 / L7 balancer? I'm writing an API-fuzzer and I want to detect if a sequence cause falling down of an endpoint of some service. Of course I can get 500 response code, but it's may be called from code of an endpoint. And there are any exact way to find out if a server is down?

I don’t know in advance what kind of balancing is on the service side. So I will be glad to know a universal solution, or some particular one.

I don't think is really possible nowadays, when you make a TCP connection to a server, you may thing thats the endpoint, probably that TCP connection is balance to other systems that depending on the policy of the load balancer could be the same physical host or not. This policies sometimes are dynamic and may vary depending on the load, so your HTTP Request could go to different endpoints depending on how is design the backends.


What purpose does Access-Control-Allow-Origin have? I have a misunderstanding regarding CORS' Access-Control-Allow-Origin header.

It's name says "allow" from which I understand that if I make a request from an "Origin" that is not allowed the request should fail.

But I can always change /etc/hosts to have the "Origin" point to my IP address.

For example, for a response that might contain this:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://example.com
Access-Control-Expose-Headers: Access-Control-Allow-Origin,Access-Control-Allow-Credentials

I can always modify /etc/hosts and have:

127.0.0.1   example.com

... and the call will work.

What exactly is this header allowing? Can I use Access-Control-Allow-Origin: * instead of Access-Control-Allow-Origin: http://example.com? What's the difference?

It's name says "allow" from which I understand that if I make a request from an "Origin" that is not allowed the request should fail.

That is right (depending on the request). But disallowing a request is not a property of CORS, it's because of the same origin policy.

CORS isn't really a header meant to secure anything, it's a header meant to weaken the same origin policy and to allow cross origin requests (which may be required by some applications).

It is especially not designed for access control, so you being able to access websites via changing your systems configuration does not affect its security in any way.


Is proper documentation on .xef files available anywhere? WinACE encrypts files (using one of its 8 methods) into a file with the extension .xef. I'd want to see some documentation on this file format but I couldn't find anything...

I'm particularly interested to know:

How the file is stored
Which of the eight encryption algorithms it actually used to create the file
What key it used (128-bit, 160-bit, 256-bit, etc.)

How can that information be retrieved from the file?

According to wikipedia:

  Packing of ACE files is licensed as proprietary information and only available through WinACE, while Unpacking of ACE files is supported by a number of third-party archivers. However, virtually all of them (the ones that support ACE 2.x format) do this by using the proprietary "Unace.dll" from e-merge GmbH.

In the WinACE site you can read that using that .DLL you have:

  The downloadable distribution of UnACE.DLL contains the 32bit .DLL, a list of function calls as well as some function prototypes, structures and constants to include when using the .DLL.

So, perhaps using it you can retrieve those informations.


Why does TLS 1.3 deprecate custom DHE groups? According to the second draft of the TLS 1.3 specification, custom DH groups have been deprecated. As we all know, hardcoded DH groups are vulnerable to a precomputation attack that allows retroactive decryption. Since TLS 1.3 doesn't deprecate DH for key exchange entirely, I imagine this means it will fall back to the standard groups (e.g. Oakley groups). With this in mind, why does TLS 1.3 deprecate custom DH groups? Why not do the opposite and deprecate standard groups instead, or even deprecate all DH key exchange to make way for ECC?

With  TLS 1.2 the server first needed to tell the client within the ServerKeyExchange message about the parameters of the DHE group it supports. Only then the client could act on these. With TLS 1.3 the client chooses instead from a set of named groups from start. Since the client now chooses the groups instead of the server the key exchange can start immediately (all information are known from start) which cuts a full RTT from the handshake, resulting in better performance.

Of course, in theory one could also still have custom groups this way, only that the client defines these groups this time and not the server. I cannot find any specific information why custom groups where removed but it seemed to happen during some interim meeting in mid 2014 based on this message in the TLS mailing list. I cannot find any information about this on the official meeting in 03/2014 nor on the next one in 07/2014.

But, some information in the paper Indiscreet Logs: Persistent Diffie-Hellman Backdoors
in TLS from 2016 might point into the right direction. This paper discusses deniable backdoors using custom DH groups and in VII. Discussion A. Mitigation Strategies various strategies are discussed to prevent such backdoors, like disabling DHE completely or using only known good (named) DH groups similar to what is done with ECC. If fully removing DHE is not an option then having a fixed set of named DHE parameters looks like the easiest way to handle this problem.


Is there any advantages in using a Network Intrusion Detection System, when already having a EDR solution? Does implementing a Network Intrusion Detection System (NIDS) give you any advantages over an Endpoint Detection and Response (EDR) solution?
I've been trying to do research on this, but are struggling to find good sources comparing the two together, or even discussing them within the same context. There seems to be a lot of hype around EDR, but intuitively I would think there would additional advantages in also monitoring traffic before it hits endpoints. Especially considering a scenario where some endpoints within a network doesn't have a EDR-client installed (like IoT devices for example).
Does anyone have some knowledge about this topic? Or know of any good resources I can look into?

I don't think the discussion needs to be about IDS and EDR specifically. The concept you are going for is called "defense-in-depth", or the Reason Model (a.k.a. the Swiss Cheese model).

There is no perfect defense, so layering defenses helps to reduce how successful a threat is at causing loss.
And EDR and NIDS can have different scopes.

If NIDS is just on the perimeter, then you still need EDR for host-to-host threats
If EDR cannot be placed everywhere, then NIDS is required for common defense

It's not about if one is better than the other. There is no "silver bullet". It's about the threats and your risks and finding the optimal controls to counter threats and lower your risks.
So,

Is there any advantages in using a Network Intrusion Detection System,
when already having a EDR solution?

Yes. Quite simply, if the EDR solution does not lower your risks acceptably in your context.


Is it secure to store an rsa private key with aes encrypted in your database? I want to use multiple clients but I don't want different public key for that specific user. So I have to share the private key between all clients that I only have to use one public key. So I thought if it is secure to encrypt the private key with aes of the first client which generates the key with an password and then send it to the server which stores it in the database. And when a user uses another client the encrypted private key in the database is sent to the new client and can be decrypted with the users password so the client can also receive messages with only one public key. Is this a good way to go? I cannot think of another way to use RSA with multiple clients.

Ps: This is for a secure chat system!

If encrypted private key can be requested by an attacker (you didn’t specify any authentication for the request) or your servers are compromised then you’re opening your users to offline attacks. Now the only barrier between attacker and user’s private key is the user’s password.

Generating per-device key pairs is preferable, for example user can deauthorize key pair of a lost device.

If you insist on sharing one key pair I suggest transferring it from client to client within an end to end encrypted channel. This way:

the private key transmission is protected by a much more secure keys generated by DH key agreement. Beware of MITM attacks, they could be discovered by comparing hashes of keys between the devices
the encrypted key is transmitted only once and never stored, unless the attacker is eavesdropping at the moment of transfer
the transfer could be performed directly between the devices through a local network or a cross-nat p2p protocol. This fully excludes your server.


Google DNS query pointing at ISP instead of Google I am not sure if this is actually an issue or not or if I am just being too paranoid, but I noticed this upon arriving home to Alaska recently (location is important as you'll see shortly). In short, I installed a tool called PeerBlock which blocks connections to advertising and malicious servers (and also has a particular dislike for educational, ISP and government servers) while I was away and noticed something strange when I got back. Google and Youtube connections were being blocked by PeerBlock under the basis of it being "Alaska Communications Systems Group, Inc", which is my ISP.

The result was dozens of messages like this in its log, note the time stamp showing how many happen at once:

Now I have seen in the past PeerBlock block various websites for silly reasons simply because of what they use for hosting, so I did not take this without a grain of salt. I decided to look into it a bit more by running the command dig @8.8.8.8 google.com on one of my Linux machines and got the following result:

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13297
;; flags: qr rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             299     IN      A       204.17.140.109
google.com.             299     IN      A       204.17.140.117
google.com.             299     IN      A       204.17.140.102
google.com.             299     IN      A       204.17.140.83
google.com.             299     IN      A       204.17.140.91
google.com.             299     IN      A       204.17.140.87
google.com.             299     IN      A       204.17.140.123
google.com.             299     IN      A       204.17.140.106
google.com.             299     IN      A       204.17.140.113
google.com.             299     IN      A       204.17.140.98
google.com.             299     IN      A       204.17.140.79
google.com.             299     IN      A       204.17.140.121
google.com.             299     IN      A       204.17.140.108
google.com.             299     IN      A       204.17.140.94
google.com.             299     IN      A       204.17.140.93

;; Query time: 118 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Apr 24 13:32:34 AKDT 2016
;; MSG SIZE  rcvd: 279

Note 8.8.8.8 was used as that is the nameserver my main computer uses as well, not the router's or anything.

Now at this point I was a bit concerned, as indeed the IP range 204.17.140.0/24 reported by DiG is owned by ACS as seen here, and I doubt that page has inaccurate information.

I asked some of my friends as well to see if this was a common thing (Google somehow reporting ISP A records like that as it didn't happen where I was from previously), and they all showed that using 8.8.8.8 as well they got actual Google-owned IP ranges.

The odd thing too is that visiting Google by disabling PeerBlock still shows a valid SSL certificate, so I do not think the information I send is being monitored or anything unless there is some way to fake the authenticity of a SSL cert via MITM without having some sort of client side program changing what the browser thinks is valid as far as I know.

Is this something to be concerned about (as mind you, this only happens with Google which is a bit suspicious), or is this a common thing ISPs do? Or perhaps is this just Google taking advantage of the ISP's servers to provide better response times to people living so far away from most servers due to the physical location?

Google has some servers (Edge Nodes) located into ISPs for quicker response, this is what they call the Google Global Cache. They are basically big proxy caches for serving static content (such as YouTube videos).

According to their FAQ, it is «designed for end-user networks with greater than 1Gbps of peak Google traffic»

As you have observed, Alaska Communication Systems seems to have some servers deployed in this way. Given that they have a valid Google https certificate, they seem completely legitimate.


I have to write down credit card information on paper and send it. How can I minimize my risk? I am filling out a form to set up a recurring payment with a local government building. The form requests that I put my credit card number, expiration date, and CVV number, which I'm a little hesitant to do.

How I can minimize my risk of the information being stolen/misused?

My plan:

I was given the option of delivering it in person, faxing it, or sending an email. I will take a picture of the form and send an email
I will request that he not print out the form and store it somewhere.
If he must print it, I will request that he cross out the CVV and expiration date after having validated the card.

Barring not setting up recurring payments, is that the best I can do?

(Given that there isn't an online portal where I can safely enter this information, I assume that requesting that he encrypt the information and store it in a database won't be an option)

They shouldn’t be asking you to write down your CVV number at all. Payment Card Industry security standards prohibit merchants from storing that information, and on paper counts. If they can’t process your card electronically so that the CVV is only ever held in memory then they shouldn’t be using the CVV at all, and accepting the risk that the transaction will be repudiated. You could report them to their payment processor, if you have any way of finding out who that is.


Maximum number of nodes with IPSec? From my understanding, for incoming packets over IPSec, the Security Association (SA) is identified by the SPI field of the ESP header.

Then let's say I have a bunch of nodes where each node wants to be able to talk to each other node using IPSec tunnels (so n nodes, each of which talk to n-1 other nodes). If that is the case, no SPI value can be used for more than one SA and since there are 2 SAs between each pair of nodes, and since SPI is a 32-bit field, is it correct that there can only be ~65535 nodes in such a configuration?

If so, is there a way to have more nodes in such a configuration? The practicality of this "configuration" is a separate matter.

The math...32 bits.

2^32 / 2 != 65535

2^32 = 4,294,967,296
4,294,967,296 / 2 = 2,147,483,648

You don't get IPSec without IP and IP defines a source and destination address in every packet. You'll always have a source/destination with each of our SAs.

That means your limit is 4,294,967,296 or 2,147,483,648 per IP address you communicate with because your software can keep track of the SA assigned to each IP.

@eddie clarified this answer in comments.

@Kasperd points out that it's possible that the limit is actually 2^32 without dividing by two. As pointed out in comments there is no requirement that the SPIs can't be the same in both directions because the receiver can see the peer IP address. So the max could be closer to 4,294,967,296.

You'll also notice that 2^32 is the entire IPv4 space, (discounting which are globally routable) and for this question, you will not run out of SPIs any time soon and I'm pretty sure other limits (memory, bandwidth, etc) will prevent you from exceeding a much smaller threshold.


How can http data be compromised on a secure network? I understand that it is bad to send passwords in plain text over the wire because somebody can look at it and clearly steal your information, and that the solution is to use HTTPS because the information is encrypted between end points.

If you are on an untrusted network where other people can see traffic to/from your machine (via something like wireshark), or the receiver is on an untrusted network, this makes perfect sense.

But if you are on a locked down, secure network and the receiver is also on a locked down (but separate), secure network, what are the ways that someone can get at your unencrypted HTTP traffic?

They can snoop on the traffic between the two secure networks. They can redirect traffic to their own network rather than the secure network.


Trusting the "subject" of an x509 certificate A bit of background. Our organization is working on a document format that will be ingested by our software. We're using the CMS format to verify the integrity (by validating the signature). The CMS message format will contain the chain of the signer, and thus we will also use that to verify trust against the default system keychain (Java's cacerts in our case).

For our first release we'd like to verify that our organization is the one who has signed the document. Our team has looked into certificate pinning. In this case we would include a copy of the x509 certificate that we expect to be the singer and confirm (after we've done the signature validation and trust evaluation) that the signer equals the expected. We decided against it for a couple reasons. The biggest reason is that if a key was compromised or a cert expired we'd have to re-ship our software or make our users make a configuration change (switch the old cert for a new). We'd rather let a public CAs CRL take care of revocation for us.

One idea that we're leaning towards is to verify that the "organization" of the (verified) signers x509 subject is our organization. This seemed like a good compromise between certificate pinning and trusting anyone with a pre-trusted certificate.

In general, is it valid to trust the information that's provided in a certificate's subject if we trust the issuer of the certificate? I.E. Can I be positive that every Certificate Authority included within a non-compromised default trust store (again, Java's cacerts for us) will have verified the the organization that's listed in the subject is the actual organization? Does that extend to other subject fields such as state, local, email, etc? Outside of certificate pinning, is there a paradigm I'm missing that's meant to accomplish this sort of thing?

[Note: In the first wording of the question, there appeared to be some pretty glaring conceptual problems, the re-wording fixed these. I am going to leave this answer here anyway in hopes that it's useful to somebody.]
PKI Fundamentals
I think we need to go back to basics on how Public Key Infrastructure and certificates work. I am going to shamelessly steal a photo of a certificate chain:

In this scenario, User1 would be your document signer, which sign documents using a certificate issued by some Certificate Authority (CA), which could be a self-signed root CA or could be an intermediate CA with a root above it.
Validating a certificate chain
Let's say that I as the client want to validate the signature on a document that User1 signed. The procedure would be this:

Validate the signature on the document: hash the document yourself, and then use the public key in User1's cert to check that your hash matches the one in the signature field.
Validate User1's cert: Ok, I know that the document was signed by the key identified in User1's cert. How do I know that this key actually belongs to User1 and that this isn't a fake cert? Well, this cert is signed by an IssuingCA, so I will validate the signature on User1's cert against the key in the cert for the IssuingCA.
Validate the IssuingCA's cert: Ok, I know that User1's cert was signed by the key identified in the IssuingCA's cert. How do I know that this key actually belongs to the IssuingCA and that this isn't a fake cert? Well, this cert is signed by the RootCA, so I will validate the signature on the IssuingCA's cert against the key in the cert for the RootCA.
Validate the RootCA's cert: Well, since it's this cert is self-signed, there's no way to validate it, so I will check that it matches bit-for-bit (or that its hash matches) one of the certs that I've pinned (aka is in my trust store).

Your Situation
You say:

Our team has looked into certificate pinning but decided against it for a couple reasons. ... We'd rather just validate against the system trust and let a public CAs CRL take care of revocation for us.

Then how, pray tell, are you doing that validation if you haven't pinned the root cert?? How are you validating the signature on the CRL to make sure that it hasn't been faked? What happens if I whip up my own OpenSSL CA on my linux box and issue myself a cert with the identical subject as your cert (ie is bit-for-bit identical to your signing cert except for the public key and signature)? Please tell me that your software would reject it.

Answering your questions

In general, is it valid to trust the information that's provided in a certificate's subject?

Uhh, no. Not unless you've validated the signatures on the certificate all the way back to a root cert that you have pinned.

Is there a way for me to obtain an x509 certificate from a pre-trusted authority that contains information in the subject that has not been validated?

I'm not sure I understand the question. Validated by who? A public Certificate Authority (CA) should verify all information in the Subject and SubjectAltName fields before issuing the cert. If not, then that CA deserves to go out of business. Your client software should also validate the contents of a certificate every time it sees one by tracing the signatures back to a pinned root.

Do we have to verify that the certificate has the "Code Signing Certificate" extend key usage to get that guarantee?

Umm, that depends, is it signing code? ie are the "documents" in question executable software (.exe files, or installers)? If not then you should be checking for the "Digital Signature" extension. (The point of this extension is to make sure that a certificate / key gets used for one thing and one thing only. If a key gets "re-purposed" halfway through its life, this can lead to vulnerabilities).


Why is it hard to prevent scalpers from using bots to buy up lots of concert tickets? The New York Times recently has an article that talks about how scalpers are using bots to programmatically buy up lots of concert tickets, making it harder for ordinary fans to buy up tickets.  For instance, it says that they may buy up more than 60% of tickets to some popular concerts, or up to 200,000 tickets each day (in aggregate).

Why is it hard to stop scalpers from buying up lots of tickets?

The NY Times article talks about how Ticketmaster is trying to stop this by using CAPTCHAs, and how the scalpers are defeating the CAPTCHAs (e.g., through online services that will solve them for less a cent per CAPTCHA).  But why is Ticketmaster focusing on CAPTCHAs as their main line of defense?

For instance, why can't Ticketmaster look at the credit card used to buy the tickets, and place a limit on the number of tickets bought per credit card?  Or, why can't they require confirmation of ownership of a phone number (e.g., text you a code that you enter, or call up your phone and read off a code that you enter into the website, to verify that you own the phone number), and place a limit on the number of tickets bought per phone number?  It seems like there are many other defenses that might be available -- why is this problem so hard?

Phone numbers are easy to come by as are credit card numbers.  Most credit card companies offer 1 time use credit card numbers and phone numbers can be had for less than a couple of bucks per month.  It wouldn't be that hard to setup many SkypeIn or Google Voice numbers for example to get around the phone system issue.

It would make things a little bit more complicated since a person would likely still have to answer the phone, but it's also more expensive to implement and requires making calls out for every ticket purchase.  It also complicates the ticket purchasing experience for customers which would likely be greeted poorly.

There is also the obvious question of how does the activity hurt Ticketmaster?  They are still selling tickets and unless they see a drop off in venues using them, it doesn't really hurt them any, so why should they give up revenue or raise their costs to the venues (their real customers) when they can make a visible pass at trying by introducing Captchas.

Security is about analysing risk and cost and determining the point at which the mitigation of risk is worth the cost.  There doesn't seem to be a very compelling case for them at the moment to invest heavily in making it more difficult since it doesn't directly impact them and with their market position, is unlikely to have a significant impact on them.

From their point of view, the cost of preventing scalping may exceed the cost of letting it happen.


How to secure my website's FTP? When I opened ftp command prompt and typed open mydomain.com, it gave me the following and I think that this is a security vulnerable.

connected to mydomain.com.
220----- Welcome to Pure-FTPd [privsep] [TLS] -----
220- you are user number 1 of 50 allowed.
220- local time is now 13:18. Server port: 21
220- IPv6 connections are also welcome on this server.
220  you will be disconnected after 15 minutes of inactivity.
user <mydomain.com:<none>>:

However, when I tried another websites like open stackexchange.com, it returned nothing.

Can anyone tell me how to apply more security on ftp connections on my server?

You can't secure FTP.  Remove it and replace with a secure alternative like SFTP if you need file transfer.  The way in which you've asked the question implies that you don't have a valid need for it, that it's probably just on by default.

Depending on what you're running, 'rpm -e pure-ftpd' or 'dpkg -r pure-ftpd' might do for you.


How important is a static IP address when authenticating with my server? I am looking to move my business into a small office. I have found somewhere very suitable but unfortunately they cannot provide a static IP address.

Currently, to connect to my server from home I only allow access from my static IP address. Authentication is done through an SSH key so there are no passwords involved. I have Fail2Ban set up on the server to improve SSH security.

My worry is that whilst SSH key-based authentication may be very secure - is it secure enough to leave the SSH port open? I don't know how often the IP will address change but I know it's not static - for arguments sake I'm going to say it changes every day.

Do I need to ensure my new office space can provide a static IP address or can I work around this?

Somebody brute forcing my SSH key is not an issue in my mind, somebody with resources like that (if it is even possible) can easily break into your office.

Listening on a non standard SSH port is something that many people recommend, and it can't hurt. (Probably does not help either.)

The only issue I worry about with a public ssh port is that if there is a security flaw in the SSH server my server could maybe be compromised.
For that reason I have automatic updates turned on. For my "low to medium" value server that is enough, I feel. Because if that ever happens most of the internet will be at risk.

If your server is of higher value you could:

a) Look at setting up one server that listens to connections on an open ssh port and your other servers only listen to connections from that server. (Maybe even over a private network if your host has something like that).

b) Look at setting up a VPN.


Do any organizations use Smart Cards other than the military? The military's Common Access Card (CAC) seems legit. Do other companies/organizations employ their use? If not, why?

UPDATE
What are the pros/cons of smart cards, compared to other methods?

CAC cards themselves are used only by the US Department of Defense. But similar cards are used elsewhere. By 'similar' I mean embedded-chip plastic cards that carry a picture and other secure identity information and that use PKI.

Malaysia's official ID card MyKad (also carries fingerprint)
Many EU countries, including Estonia's official ID card Isikutunnistus
Spain's official ID card (also carries biometrics, not sure what kind)
Belgium's official ID card
as well as Portugal's
The Indian state of Gujarat's driver licenses (also carries fingerprint)

As you can see it tends to be governmental organizations that have traditionally issued other forms of ID that are the ones most strongly adopting CAC-style cards.


Tips if someone else is using "my" username on another site This question isn't about me, though it easily could be, since there are many Barry Carter's out there.

Suppose I find out someone is using my FaceBook (or Twitter or StackExchange or whatever) screenname on another site.

I don't want to stop that person from using "my" screenname, because I realize I don't have a legal right to a given screenname, and it's quite possible that the person came up with the screenname independently.

My question: where can I find a list of "tips" for what to do when this occurs?

An obvious thought I had is to add a disclaimer like this to my own sites/social networking accounts, as well as to any paperwork I send out to someone who doesn't know me (eg, a resume' to a potential employer):

Please note that there are many people with the same name I have (or one that's very similar) on the Internet, and that a Google search for my name may lead to one of these people and not to me.

If you are unsure whether a given page is mine, please ask me, thank you.

Aside from this, is there anything "proactive" I can do to avoid a case of mistaken identity?

EDIT: This is actually affecting me in the reverse direction. I run a website where I list usernames on some less popular social networks, and am getting emails from people saying "I use the name 'johnjjsmith' on twitter, and now, when people search for it, they'll think I'm on 'people-who-hate-babies.com'.

I've added a disclaimer to my own site, but want to send the complainers to a page that politely explains why they don't own their own username, and what they can do to avoid confusion with people on other sites that happen to use the same username.

I could write something myself, but I'm sure this is a known problem with known suggestions?

I would merely take this the other way around: instead of telling people about pages not linking to you, I would merely concentrate on the pages actually linking to you.

Just display a list of official contact pages, everything else will be then assumed to be not you:

Official contacts:

Main website: ...
Blog: ...
Twitter: ...
Facebook: ...

Etc.

As per your recent edit, "I wan't to send the complainers to a page that politely explains why they don't own their own username", this seems to me more likely a law-related question than IT-Security which should most probably find better answer on SE's Law specific website.


Restore session in Firefox Restore session in Firefox

What does this mean, is it related to the session concept which is stored on the web server?

If I stop the computer with my web-app, and then start it again before the timeout set on the session on the server expires, then anybody that starts the computer and clicks "restore session"  could continue in my web-app where I left off.

Is there any way to kill the sessions after I close the browser like in IE and Google Chrome?

You are mixing the "session" as the current identifier of your browser/you in a web application, and the session of the user in her computer, meaning all the tabs opened.

Now for your other questions :

  If I stop the computer with my web-app, and then start it again before
  the timeout set on the session on the server expires, then anybody
  that starts the computer and clicks "restore session" could continue
  in my web-app where I left off.

It depends on how you defined the session duration & expiration. You can define the session to expire when the browser is closed. If done so, the user won't be able to restore the session when he'll reopen it's browser. Now if you defined a duration instead, it depends if the session will have been expired or not.

  Is there any way to kill the sessions after I close the browser like in IE and Google Chrome?

Like I said, just define no expiration date for the cookie session (if you use it like this) to expire when the browser is closed and it will be good.(see Wikipedia for that.)


If the site is not loaded in the frame, is the site vulnerable to click jacking. Came across this question in SE
How does this test prove my application is vulnerable to clickjacking attacks?
I have a follow-up  question and doubt, please help me to clear it.

As per
https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009)

     <title>Clickjack test page</title>

Website is vulnerable to clickjacking!

its says

Result Expected: If you can see both the text "Website is vulnerable to click jacking!" at the
top of the page and your target web page successfully loaded into the frame, then your site is
vulnerable and has no type of protection against Click jacking attacks. Now you can directly
create a "proof of concept" to demonstrate that an attacker could exploit this vulnerability.

So if text is only displayed and the site is not successfully loaded, does that mean the site is not vulnerable ?

For Click jacking to occur the site should be fully loaded in the frame,only then click jacking is possible,which means you can successfully load the attacker's website into the victim's webpage in which he is currently using.

So if text is only displayed and the site is not successfully loaded, does that mean the site is not vulnerable ?

If the text is displayed and the site is not successfully loaded then there is no click jacking vulnerability


Is Bluetooth on cellphone a reliable protocol for encrypted text transmission? I'm developing a solution for secure chat over instant messaging, here is the scenario:

I need to encrypt my message then send it on {Whatsapp, telegram, Wechat,...}, I don't trust any software above, so I use an app on my cellphone to encrypt/decrypt messages, basically it works like a translator.

However, the first idea turns to be naive, because it's really hard to ensure the cellphone itself not to be hacked, for example, the clipboard.

Therefore the current idea is, to use a dedicated cellphone to encrypt and decrypt message, and it transmit/receive messages with my cellphone (the one runs IM apps) over Bluetooth. The goal is to isolate the hardware that possibly contacts the original text, so my cellphone can only read the encrypted messages.

Is Bluetooth here a good solution?

The following picture shows the rough idea. Phone A-1 and B1 should install only the encryption apps, and stay offline for any kinds of connections except the Bluetooth connection with A-2 and B-2.

Is Bluetooth here a good solution?

From the perspective of security it does not matter if the communication channel (Bluetooth) itself is secure since only encrypted messages are transferred anyway in your design. Attacks at the Bluetooth stack on the senders device might be possible though which can compromise the senders device - see for example the Blueborne attack. This might give the attacker access to the messages before encryption.

Additionally, a bug in your encryption application might allow an attacker to hijack your encryption application with corrupted messages and thus also get access to the plain messages. This is actually independent from the communication channel used.

As for non-security properties like reliability or bandwidth: it is possible to create a reliable protocol on top of some unreliable. And for the usual text messages send by a single person the bandwidth should be enough. Even if bandwidth is no longer sufficient (like when sending videos) you can use WiFi - the risk is about the same (i.e. also vulnerable drivers) but the bandwidth is higher.


How can a malware retrive victim data without compromising the malware owner? I was wondering how can malware, for example a keylogger, deliver its data without compromising its owner?

Because as soon as you know you got a malicious program running on your computer you could potentially monitor outgoing connection and maybe trace it back to the attacker.

So are there any other methods, like using dummy email to send data or other stuff?

There are many possible ways to retrieve the data harvested.
Depending on the type of attack (automated / targeted), the intended goal of the attacker and the means available to the attacker. Often, one of these is chosen (this is not an exhaustive list!)

Use a Command & Control system that selectively tells the malware what to do and where to send data.
Start a service (SSH / httpd / netcat / etc) and dump the data through that.
Use a different infected machine as a collection machine.
Use a 'zombie network' to have a network collect the data for you.
Transmit the data through a side-channel (for example use ultrasound and a listening device / recorder)
Use a public 'pastebin' service to directly dump the data in a known location.
Abuse a protocol to transmit the data hidden in plain sight (like requesting specific DNS entries that encode the data transmitted)

There are other means but this should give you some idea how diverse (and therefore nigh impossible to monitor) the methods are to transmit data between 2 places covertly (e.g. what a piece of malware and receiver want to do).


trying bypassing htaccess based basic http authentication I am trying to solve this web challenge which requires to bypass an htaccess based form authentication. after some research i tried to change the request to

GETS /admin/ HTTP/1.1
Host: htaccess.hacking.w3challs.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate

from the original header

GET /admin/ HTTP/1.1
Host: htaccess.hacking.w3challs.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate

using Burp suite, but I am still not able to bypass the authentication form. any tips what's wrong with my approach?

This simply means that the server is not vulnerable in the way you are expecting it to be (using GETS instead of GET to bypass black-listing of HTTP verbs).

I tried passing a path like: http://htaccess.hacking.w3challs.com/?page=/.htaccess
and directory traversal seems to be possible. Try looking for a .htpasswd file somewhere in the directory tree.


Difference between brute-force and dictionary-based in the mitigation process of the IPSs I am working with Bro IDS and CIF ( cyber threat intelligence) using the Intel framework I am testing.

How  can I mitigate   brute-force and dictionary-based attacks? I found that the mitigation with regard to brute-force takes more time compared to dictionary-based. I wonder if there is some difference between the mitigation process between brute-force and dictionary-based attacks for IPSs?

The terminology is not fully universal so I will detail my definitions:

A brute-force attack occurs in a situation where there is some secret value X that the attacker wishes to obtain, and the attacker can "test" whether a given potential value for X is the right one or not. So the attacker tries potential values until he hits the right one.

Such an attack can be online or offline. In an offline attack, the "test" for a potential value is a computation that occurs solely on the attacker's computer. For instance, X is the key for an encryption system, and the attacker has at his disposition a message encrypted with key X, and the attacker knows enough on what the decrypted message should look like to unambiguously detect whether his current guess for X is the right one or not.

When the attacker cannot run an offline attack, he must resort to an online attack: each test involves talking with the defender's systems (e.g. trying to log on the server). The attacker really prefers offline attacks because they are a lot more discreet (everything happens on the attacker's machine, without leaving any trace) and also because he can speed them up by throwing more hardware at the problem.
A dictionary attack is a special-case of a brute-force attack where the secret X is something "human-compatible": this is a value that a human user accepts to memorize and possibly chooses himself; typically, a password. The brute-force attack is then about trying out potential values, i.e. values which are simple enough for the human user to handle in his brain. The set of such values is called the dictionary because what humans choose and keep in their minds is usually words.

There again, dictionary attacks can be offline or online.

An important point to consider here is that when X is chosen by a human in his brain, then not all possible values for X are equiprobable: some words are a lot more likely to have been chosen by the user than others (i.e. a human password is much more often "dragonfly" than "kelxdparf", even though both are sequences of 9 lowercase letters). The dictionary is thus a list of guesses for a brute-force attack, ordered from most to least probable.

There are basically three ways to defeat brute-force attacks:

Make it so that the space of potential values for X is large enough that the attack is doomed from start. E.g. specify that X is a sequence of 128 bits, and generated with a strong PRNG: since a strong PRNG is used, no sequence of 128 bits is more probable than any other, so there is no way for the attacker to optimize his search (there is no order of guesses that is better than others); and the space of possible 128-bit sequence is huge (it has 2128 = 340282366920938463463374607431768211456 elements) so the attacker's probability of hitting the right one within the next century is abysmally low.
Make it so that no offline attack can be performed. This is not necessarily possible; e.g. in the case of a password-encrypted file, the attack context assumes that the attacker got a copy of the encrypted file and tries to crack it, in which case an offline attack is always possible. But if you can arrange for all attacks to be online, then you can apply countermeasures, e.g. refusing to talk to a given requester after 10 wrong guesses. An extreme case is a smart card, that requires a PIN code and locks itself after a few wrong guesses.
If offline attacks cannot be avoided, then make it so that each guess is unavoidably expensive. This is the whole idea of password hashing. The processing of a given input is done through a function with many iterations, such that all usages are slowed. The concept is that taking 10 milliseconds to verify a password instead of 10 microseconds is normally no hardship for a server (because it does not have to do it many times per second anyway), but making each try 1000x more expensive will also make the brute-force attack 1000x more expensive. This is a trade-off: making password processing more expensive tends to imply increased fragility against denial-of-service attacks.

The main difference between "brute-force" and "dictionary" attacks is that when the secret is human-compatible (the dictionary attack context), then this also means that the space of possible values for the secret is awfully small. Human minds are simply not good at all at remembering complex values; there are even worse at making random choices. Thus, when a dictionary attack applies, the first defence method I explained above (extending the space size) is not possible. So you have to resort to one of the two others.

Avoiding offline dictionary attacks means using communication protocols and architectures that never expose anything that could be used as offline test for a potential value for the secret X. This is outside of the scope of IPS. What an IPS can do is to enforce rejection rules for the second method (mitigation of online attacks): a good IPS should be able to detect when many requests come from the same source, and efficiently block them upon entry.

In that sense, there is no real difference, for the IPS, between a dictionary attack and a non-dictionary brute-force attack. At best, we can say that brute-force attacks that are not dictionary attacks should be defeated through using large spaces for secret values (i.e. in cryptographic terms, for symmetric encryption, use 128-bit keys, not 40-bit keys), making IPS irrelevant.


Can Subject Alternative Name(SAN) Certificate install on different Web Server or OS? Let say:

application.house.com   apache tomcat         : physical server
email.house.com         apache tomcat         : virtual
finance.house.com       Oracle Wallet Manager : physical server
document.house.com      apache httpd          : physical server
room.house.com          IIS 7 : windows       : physical server
person.house.com        apache tomcat         : virtual
portal.house.com        apache                : physical server

Assume:  portal.house.com domain will be common subject name for that SAN Certificate and the rest of domains will be in Subject Alternative Name extension.

For Certificate Signing Request(CSR),I will generate a CSR at apache server using openssl included FQDN domain in SAN extension. Is it enough?

Can each domain of every server recognize this type of certificate after that?

Yes.

You can use OpenSSL to convert the certificate into different formats as required by the application / server.

I've seen Apache / Tomcat configured a number of ways. Sometimes with a .pfx, sometimes with .pem files, and sometimes using the Java keystore.

IIS typically uses .pfx files.

With that being said, you want to make sure that your CA allows you to install the certificate on multiple servers without requiring additional compensation to be covered legally.


Could HTTPS redirects to HTTP be blocked in future? Several answers on this site (e.g. 76305) suggest that HTTPS 30x redirects to HTTP aren't a great idea but that the pattern is widespread.

Looking at the choices that the Chrome team have made, it's clear that they consider their role to be proactive in security. It is foreseeable that browsers might start to deprecate, warn or even prevent HTTPS URLs redirecting to HTTP ones.

Is there any evidence of this blocking happening? If so any indications about the likelihood or timeframe?

An application can naturally leak sensitive information,  such as an session token over an insecure channel using a HTTP 302 redirect. But this could happen in an attack,  "hey click on http://authsite.com",  which may make the browser send an HTTP request in the clear.

An application can protect session tokens using the secure cookie flag, which instructs the browser not to send the session token over an insecure channel.

Additionally, there is HTTP-Strict-Transport Security (HSTS),  which will force the client to use HTTPS,  even if there is a careless 302 redirect to HTTP.  HSTS was created in a response to the SSLStrip attack.

All web applications must deal with insecure transmission, and it is a common server-side defect on the internet today.  In the near future,  chrome will use a broken lock icon on webapps that leak sensitive information.


Is storing passwords encrypted with GnuPGP on an anonymous FTP server safe? I would like some advice on a method of storing passwords to a database on my anonymous FTP server.

Basically I have login details for a few trusted users to a database server stored in a text file encrypted with GnuPG. With it being encrypted I assume having it publicly accessed wouldn't affect security as the encryption setup would make it pointless for anyone to try and decrypt it.

Is there any way that anyone could gain access to the passwords stored in the text file without the permissions I have set in GnuPG? Is there anyway data could be leaked in my setup that would give it to someone without the private key?

I think it should be fine but is there anything I'm not seeing?

Risks of Exposing Encrypted Information

  With it being encrypted I assume having it publicly accessed wouldn't affect security as the encryption setup would make it pointless for anyone to try and decrypt it.

Your encrypted information will stay private as long as

the crypto works (no flaws in the underlying mathematical principles are found),
the crypto software (GnuPG) works (no bugs in the implementation of the cryptographic algorithms) and
you don't perform any mistakes (for example uploading the unencrypted version by accident, or revealing the passphrase/key otherwise).

Be aware that an attacker archiving the files might be able to decrypt it well in the future if any of those incidents trigger!

In case of exchanging messages through some unsafe channel, you might (have) to accept this risks. I wouldn't accept them by publishing encrypted files if I could mitigate through additional access restrictions.

  Is there any way that anyone could gain access to the passwords stored in the text file without the permissions I have set in GnuPG? Is there anyway data could be leaked in my setup that would give it to someone without the private key?

To wrap up on this: while cryptography is safe in principle (and at least no known vulnerabilities exist), things might change in future. Not publishing contents will keep this safe. Accidental disclosure of encrypted content is probably the biggest risk (and everybody including "the best" might make a mistake at some time), while access restrictions would at least add another safety net.

Metadata

  Is there anyway data could be leaked in my setup that would give it to someone without the private key?

There is another point to this question: be aware that several metadata is publicly shared, which might be critical or might not be. When you change the files, their size, and if you also store it, even the name. You could mitigate some of those (for example, overprovision file size to hide size changes and not store the file name); but you especially cannot really hide file changes (even if you store faked time stamps, an attacker could simply fetch it in intervals and check for changes), the only option I see is providing "faked" changes every now and then.