Prevent SQL injections on the old PHP website using software A friend of mine works for a company which owns a 15-ish years old website written in PHP using Apache/MySQL/home brew CMS and outdated hosting on OS Debian 8 "jessie". SSH allows passwords (with no fail2ban or similar) plus both their "admin" page and phpMyAdmin are exposed, accessible and they do not use rate-limiter or any other brute-force preventing techniques or software. Oh, yes, and website is vulnerable to SQL injections too. So, all together it is a security disaster. On the top of that, as I learned from Apache logs, they got some attention from malicious users and, obviously, it is just a matter of time when they gonna be hacked.

Due to the recent COVID-19 issues their company is trying to keep a business going and didn't layoff anyone, but they don't have a budget to re-write a website (yet). Their goal is to survive thru those tough times, mitigate as many issues as possible without touching PHP code and later re-write a website. That's why solutions from here, here or here are not gonna work for them.

So, he asked me about some temporary ideas/solutions which they can use next 6-9 months and I suggested to:

Hide their admin page by renaming it from "admin.php" to a random name like "002cff74-84fd-4451-8014-a0d4ea669426.php"
Move to a cloud VPS

it is cheaper than their current hosting
it has a newer OS with security patches
they can control SSH, phpMyAdmin and use fail2ban and/or other software if needed

However, SQL injections are still on the list and I'm not familiar with Apache/PHP to give more advices - I use both nginx/nodejs and IIS/.NET.

Here is my question:
What would be the best way to temporary mitigate SQL injections without changing an application code?

Should I suggest to use .htaccess to filter queries? Should he use a proxy to do the same? Is there any other relatively inexpensive way to do that?  Any help appreciated.

You will not be able to do much without one of the two:

change code
export the entire site in HTML

SQL Injection usually cannot be prevented on old code unless you rewrite it. Yes, there are WAF (Web Application Firewall) around, and they can mitigate the majority of the attacks, but if something escapes the WAF, the site is fully exposed.

Migrating to a cloud provider changes nothing on the security. An insecure home-hosted website is insecure if hosted on Amazon, on Google, on a darkweb provider. If the provider have some security plug-in, you may be a little less insecure. But vulnerable anyway.

If the site is a CMS, you can create a local mirror of the site in HTML (ask around for HTML Spiders), and host this one. There will be some missing functionality (search comes to mind), but it will be online, and invulnerable to SQL Injection. Other downside is that every time you change anything on the CMS side, you must re-mirror and re-export the files.

But I would recommend to edit the code. If you grep -R mysql_query /path/of/the/cms you can have an idea of how much you will have to change, and I believe it would be faster to change the code than to keep exporting the site all the time.


Steps after getting hit with malware or browser exploits on Xubuntu Well, today I was browsing the internet and I suddenly got redirected to a chinese hosted malware site and firefox started going crazy. I checked the url on virustotal with my phone and it found other reports where it was a malware hosting and browser redirect site. I turned off my router and modem and then turned my computer off and booted a live CD to wipe the drive with gparted.

I have everything backed up and can easily do that without a issue. I figured, why take a chance? I use Linux but browser exploits are still a problem and I don't always use noscript.

When something like that happens what else should I do on a linux computer? Is wiping the drive enough? Is rebooting my network devices a good idea as well or does that not matter? I also know about eternal storage devices being infected but I had nothing plugged in.

Wiping your system and restoring from trusted media is definitely a good idea. At that point your system should be safe. However, I'd also suggest rotating your passwords on online services as well as using new passwords when you reinstall Linux. If you have ssh keys in use it wouldn't be a bad idea to rotate them as well. It may seem a little excessive but it's the only way to be sure you won't have repercussions from this later.


Is use of HttpServletRequest.getQueryString() for a response header vulnerable to response splitting? I've been told that using HttpServletRequest.getQueryString() in a response header makes my application susceptible to HTTP response splitting attacks, but I just don't see how.

It's clear in the case of getParameter(String), which decodes percent-encoded values, but getQueryString() does not do that. From the documentation:

  The value is not decoded by the container.

Source code snippet illustrating what I'm doing:

String path = "some_url";

String qs = req.getQueryString();
if (qs != null)
    path += "?" + qs;

// response instanceof HttpServletResponse
response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY);
response.setHeader("Location", path);

I tried to reproduce the issue, and I just get the percent-encoded newlines echoed back to me in the response. When I change the code to getParameter(…), it works as expected (except that my container is nice enough to strip the newlines from the header value, but in theory at least it works). This similar question on Stack Overflow asks the same, and a comment to the answer pointing out that getQueryString() does not decode got no response.

Am I missing something here? Or is the advice I got wrong?

The general pattern of using data that comes from the user without sanitizing it is a source of vulnerabilities. Typical things like XSS and SQLi. In this case you are taking the input from the user and directly making it a header. This could lead to response splitting, header injection, and maybe another problem or two (eg: CSRF may be possible if you can inject Javascript). But you state that:

  my container is nice enough to strip the newlines from the header value

so this is preventing actual exploit.

I suspect that even if you were to filter the input such as:

path += "?" + sanitize(qs);

for an appropriate sanitize function (say from OWASP's AntiSamy project) that your static analyzer will continue to give you this finding. So, in the end, you're going to be marking this finding as a false positive (Not an issue if you're using Fortify). The only question is whether you should include a code change before marking the finding as a false positive.

My take is that if the API explicitly says that it is responsible for secure handling of newlines and other special characters, then no action is needed on your part. When I look at the Javadoc for HttpServletResponse.setHeader, I see no mention of how special characters will be handled. So, unless the spec explicitly states a secure handling of this (I don't think it does but I didn't look this up in the Servlet spec), I would recommend sanitizing the input and rerunning the static scanner. If, as I expect, it continues to report this issue, then mark it a false positive and rest assured that all is well.

The reason I feel that you should only trust this behavior if it is specified in the spec is that that is the only behavior that is guaranteed. A new version of your Servlet container or another container altogether might change this behavior. It is very unlikely you would detect such a change though it would lead your site vulnerable.


How can a webpage scan my local, internal network from the Internet? http://webkay.robinlinus.com/

It was on Reddit.  In the middle is a Scan My Computer button.  Yeah, I clicked it.  It already knew my internal IP anyway without my permission.  But I was never prompted to allow or disallow what it is doing.  I am using Chrome.

How does this work?  I am guessing from reading it is WebRTC, but this was finding other computers on the network.  That was something that I needed to understand to defeat.

How can I turn this off?

EDIT:  I have read this, Why is my internal IP address (private) visible from the Internet?

but the scanning was most important to me here.

On the application layer, your browser has no notion of internal and external IP addresses. So any website can simply tell your browser to request a resource from your internal network. This wouldn't get blocked since for the browser it's just an ordinary cross-origin request. Note that the requesting site won't be able to read anything, it could just conclude that something is there.

For example, a website could try to find out if your router has a web interface at 192.168.1.1 by using a snippet like this:

<img src="http://192.168.1.1/favicon.ico" onload="alert('Yay')" onerror="alert('No')">`

Similarly, a website can make you request resources from internal IP addresses (and at almost arbitrary ports) and measure the response times to conclude that there is a service running: E.g., if a request to http://localhost:8080 has a short response time, you might be running a local proxy or similar.

If you cascade such requests, you can somewhat make the browser conduct a  basic network scan and infer about existing IPs, hostnames and services.

This idea is also used for actual attacks. Even if your router interface isn't accessible from outside, an external attacker could execute an attack like the recent Netgear router arbitrary code execution exploit by tricking you into visiting a prepared website that makes you conduct the attack yourself by issuing a specially crafted request to the router interface. (Essentially a CSRF attack on the intranet.)

One way to mitigate the risk of intranet access is the ABE (Application Boundaries Enforcer) module of the NoScript extension that can be configured to block particular hosts.

Can an attacker really not read any content?

Often they can read the content of an intranet site by conducting a DNS rebinding attack. Say, your router interface is accessible at 192.168.1.1/info.cgi. In a DNS rebinding attack, the attacker makes you visit  attacker.com which they first point to their own server's IP, load some Javascript, and then point it to 192.168.1.1. When the Javascript then requests attacker.com/info.cgi, it's instead resolved to you router interface and the script is able to read the response content. This doesn't violate the same-origin policy because all requests are on the same origin (the domain attacker.com), although the DNS entry switches in the background. (As a countermeasure, sites should verify that the Host header contains either the IP or the intranet name. But lots of routers don't do that.)


How to Insert data into a table with sqlmap using its sql-query command I'm using sqlmap on a test site and I wanted to modify some of the data inside of a table. Using the switch --sql-query.

What is the correct syntax?
example: is it --sql-query="My_query_here"?
or maybe it's --sql-query='myqueryhere'?

How would I be able to modify multiple rows of data?
example: Say I wanted to replace all data with the words. Game Over

Is it possible to drop in a shell?

Most databases do not allow you to just insert data using SQL Injection (Unless of course you are already in an insert query and even then you usually can't control the table name).  You can't simply stack queries,  that is only allowed in Microsoft SQL Server, PostgreSQL and comic books.  You can use a sub-select or union select to access data from another table, and SQLMap is doing this behind the scenes.

SQLMap's real strength is in data exfiltration.  If you want something more complex,  like a multi-staged attack that gives you a shell,  then you need to write an exploit.  Take off the training wheels and be man (or woman).


Removing a Redirect Virus from Fedora Linux Despite several attempts listed below certain websites are getting redirected to a certain ad website automatically, out of the blue on linux. When some website starts redirecting to this ad website is not predictable but once it happens it happens again and again. Here is what I did:

Removed all browser plugins, browser directories and the browsers
themselves but after a little respite it came back.
Changed the user account, it wasn't seen for sometime but then it
came there too.
Scanned the computer with two anti-viruses and two rootkit scanners
but they turned up nothing.
Not using a router but an Android portable hotspot, which was scanned
by anti-virus and i got nothing there.
Formatted the system and did a complete re-install and it is still
happening.

Is it a virus running on another computer or is it just hidden somehow? What is this thing and where is it located?

Here are some of the steps I would take:

1) Run Burpsuite as a proxy server, intercept the calls, and analyze whether or not there is a specific page you are visiting that is causing this.

2) Uninstall any browser plugins you may be using

3) Remove and reinstall the browser(s)

The extreme measure would be to dig into your files and find where the redirects are coming from. For example, let's say one of the sites you are seeing is called www.HappyGoLucky.com, you could open a terminal and try the brutish method of finding where (in what files) is this site stored at:

find . | xargs grep -i happygo

But that would only find the domain if it hasn't been encoded (base64) or wrapped around some obfuscation.


Passwords/Account Security: How secure is "too secure"? I am now onto the stage of developing the back end system, where we are able to view/modify all client information, their customer information, and so forth.

I am looking into requiring the use of two-factor auth via Authentication Apps (NOT SMS) (already implemented), and if this is unavailable, requiring the use of a very, very strong password and limiting it to a certain amount of days before it needs changing, plus blocking most common passwords.

I have a number of "common password lists", obtained from a Github repo, found here: https://github.com/danielmiessler/SecLists/tree/master/Passwords.

I am looking at using the 100,000 password list as I believe it offers the best without going too far, but I need your opinions on if you'd use the 1/10k or million list.

Finally, looking ahead, I am looking at only allowing full access to data if the account is logged in via a company vpn, and if not, give them a dumbed-down version which doesn't let them go quite in depth.

When it comes to auto generating a secure password for the user using some kind of JS/Backend script, I don't think these are ever the answer. This is because, they are not going to remember the password, only save it into their browser. The minute they attempt to login somewhere where their password isn't saved, you can guarantee their account will receive a reset password request.
This can result in a dropped use for that session, or if it gets too much for them, a lack of use for the entire account for the foreseeable.

For staff at this level, I have also disabled the option of email based password reset and require that they do it internally, to ensure that weeks of security implementations and hours of explaining that my Sec SE thread isn't off topic doesn't go to waste over a password to an email address set 10 years ago.

The information that our own staff can view includes ALL customer information AND their customer information like full contact details, full home address, bank account sort code/account number, the ability to charge their card (we don't store their CC info, just a PP/Stripe Key) even down to spending habits, plus other bits.

What are your ideas on implementing the strongest possible way that a user's account of this level can be secured, not just through passwords but other means, without annoying the user?

You need to balance security with usability.

The latest NIST guidelines on passwords say that you should not enforce periodic password changes for the sake of it and you should not impose excessive password complexity rules. The guide suggests they can result in passwords that are actually less secure, you can read a summary here NIST password summary

It does suggest that preventing the most common passwords is best practice and for that my impression is that the top 100,000 should be good enough, I think the top million is excessive. users will become frustrated if they get to the 4000th password attempt when trying to register.

this nice infographic from Intel shows why length is more important than complexityIntel password infographic

Two factor authentication definitely improves security  but be aware of current thinking around using SMS due to insecurities in the SS7 routing protocols and consider alternatives like authenticator apps
ARS Technica 2FA/SS7


GnuPG inner workings (encryption scheme, mode of operation, ciphers) I have some questions concerning how GnuPG operates when encrypting and signing messages.

By default:

Which cipher and mode-of-operation is used for symmetric encryption?
What encryption scheme is used for the encryption of the session key?
Which hash function and signature scheme is used in a signed message?

GnuPG implements the OpenPGP standard which contains most of the answers you are looking after. Namely:

Symmetric encryption uses CFB mode (with full-block feedback). Supported block ciphers are IDEA, CAST5, 3DES, Blowfish, AES and Twofish. Other algorithms may be supported in the future.
The session key is encrypted with the recipient's public key, using whatever algorithm is appropriate for the used key type. OpenPGP supports RSA and ElGamal. There is room for other algorithms but the standard mandates only these two.
Signatures use an algorithm which depends on the signer's key type; the standard describes formats for RSA and DSA. There again, there is room for other future algorithms. The hash function used with the signature algorithm can be MD5, RIPEMD-160, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512.

See section 9 for the lists of supported algorithms.

GnuPG implements most of the above; some of the algorithms may be absent, depending on how it was compiled. Most recent pre-compiled GnuPG packages will lack support for the IDEA block cipher (because it was patented until quite recently), but will include support for the block cipher Camellia in addition to the standard ones (despite the fact that Camellia is patented, but available under a royalty-free license).


Increasing fail2ban ban time with each attempt I haven't really found any way to do this - I have seen a few issues on the github dealing with it but nothing in the wiki indicating it exists.

Right now I have a problem, a set of 3 IP addresses are clobbering my SSHD. It's secure, no big deal - but I'm waking up to 10-15 email from fail2ban from these jerks. I've sent emails to their abuse line to no avail - the ISP seems to support this behavior?

What I have tried is adding the IP address to ufw with DENY ALL. Since the IP address still shows up in my logs even though they are banned fail2ban still go nuts.

Is there a way to have an exponentially increasing ban time so I don't have to get my inbox blown up?

As Schroeder has suggested, if you don't want to alter the fail2ban alerting then the best way is to simply ignore the IP address entirely. What you're looking to do is more complex than you need to make it. Simply ignoring the IP is probably the most efficient way of doing this.
This article should show you briefly how to set it up, but as already mentioned it's just a case of using ignoreip then specifying the IP(s) you want to ignore.
An example of this would be the following ignoreip = 192.168.0.1/24 in this example it would ignore the range 192.168.0.1 - 192.168.0.254 I think this would perfectly suit what you're trying to achieve as you've said you've got 3 specific IPs so just replace my example with the addresses you're trying to block, obviously if it's only 3 IPs and not a whole range, don't block a whole range or you could run into issues if any legitimate clients have an IP in that range.


Virtual network for malware analysis I'm attempting to do some analysis work on a malware sample but I'm running into a wall. I can't get the malware to execute correctly and talk to its C2 server. In my lab I have a Windows machine that executes the malware, a pfSense router that only has LAN, and an additional Linux host on the same subnet as the Windows machine that runs INetSim (a fake web server). On my windows host I normally use Mandiant apateDNS which responds to all DNS queries with my INetSim address, however I believe that this malware is detecting that an not executing as a result, so what I need is to configure my pfSense router to tunnel all requests to the INetSim box and I'm not sure how to go about that.

What makes you believe it is not executing properly? Many variants of malware have checks and balances that disable full execution if certain programmed parameters are not met for example:

Check if I am virtualized if so don't run
Check to see if I have true Internet connectivity if not don't run
Check to see if I can exploit anything on this machine for proper
privileges

In the first, you could edit out any traces of VMWare, Virtualbox, etc. In the second, this can become tricky. If you browse over to Virustotal and check samples, you will see many make what appear to be absurd connections to legitimate sites (e.g., ping 8.8.8.8 or 8.8.4.4). It may work like this:

InfectedHost --> do something --> legitimate site
InfectedHost --> check value of what I just did
InfectedHost --> does value match pre-programming? If not die

When using DNS you need to be cautious as well. Once upon a three years ago, I was analyzing a variant of SDBot. The variant would put "windowsupdate.com" in the host file pointed at a bogus address. It could make a beacon connection:

InfectedHost --> windowsupdate.com
InfectedHost --> give me this update (would never work but return a 404)

The 404 is what would trigger the C&C functionality. My suggestion is to analyze all of the activity and give it what it wants. On the worse case, create a snapshot/ghost of your image. Let it run in a true isolated network for a minute or so. Freeze it, analyze the traffic, and go from there. Keep in mind, it's all in the programming, so you may need to disassemble it in IDA as well. The instances of SDBot I analyzed would never begin immediate connections, they'd wait till different times, scattered hours, hours after an infection.


Are there any known vulnerabilities in the official Gmail app for Android where opening an email (with no attachments) could infect the phone? Title says it all. Are there any known instances of exploits/vulnerabilities in the official Gmail app for Android that could allow a malicious email to install unwanted software on the phone when the user opens the email?

In particular:

the phone is configured to block installation of apps from third-party sources
no attachments are opened or downloaded

Searched for any articles or reports on this topic and couldn't find anything conclusive. What's the risk?

Are there any known instances of exploits/vulnerabilities in the official Gmail app for Android that could allow a malicious email to install unwanted software on the phone when the user opens the email?

Probably not publicly. Such an exploit would probably be fairly valuable, so either the discoverer would cash in on one of Google's bug bounties, or it's being used in secret. If one were ever publicly revealed, presumably Google would fix it.

  In particular: -the phone is configured to block installation of apps from third-party sources -no attachments are opened or downloaded

That will help protect people foolish enough to click a malicious link and then install an app they randomly received in an email. Against a proper exploit, such a setting is almost certainly irrelevant.

  What's the risk?

Probably about the same as can be expected from any comparable app published by a major and competent company.


Sharing passwords and credentials between founders and employees What's the best way to share passwords and credentials from the business's various accounts in a secure manner?

For example, email doesn't work because if someone gets into one of your employee's email accounts, then they'll have access to all your company's accounts.

I assume what you're looking to achieve here is a scenario where you have something like support@mycompany.com or maybe if you're a very early stage company mail@company.com.

I would honestly suggest that the best approach is not to share passwords at all. For most hosting providers, basic email is not that expensive until you want to scale to having gigabyte accounts etc. I would give each employee their own email address. You can do one of two things - make your generic accounts (where any employee could respond to the query) either inboxes (not in my opinion the best way forward) you all have access to (be sure you know how to recover the password in the event of a disgruntled employee changing it) or you could set that account up to forward the email to all the necessary employees. If you're a small team, that might do for coordinating replies.

The company I work for doesn't actually use email for support. We give our customers some access to our support ticket system (see this list of ticket systems) although we could have configured email submission of tickets too. Either way, when our clients have an issue, they create a ticket and everyone can see them. We also get to assign these to people, so the right developer actually handles the query. If you're handling customer queries like this it might be as well to use such a system if you can as it not only negates the need for sharing inboxes, but allows you much better organisation of your enquiry responses. Hosting such a system isn't that expensive either.

Generally, the best approach to follow with access control is to only give people access to what they need. You are absolutely right to consider what happens if an attacker compromises the account, but what happens if the employee decides to do a little industrial espionage for a competitor? As a start-up your business needs careful protection. So there is a secondary issue to giving out accounts - getting them back again. Make sure you have in place two things:

That you as the business owner have the ability to technically recover whatever you need to quickly. For example, access to your office server you can simply as an administrator disable the account, so you're covered.
Or where that isn't possible, that a condition of getting your last pay-cheque from you is the hand-over of all company assets including arranging hand-over of all passwords like Administrator accounts, passwords to routers and network attached devices i.e. anything the user administers for you and that doesn't have an easy reset mechanism you can use. I would, if I were you, ensure this happens before the last day.

The last thing you want, as a business, for your employee who left because it didn't work out to change the root password on your web server and lock everybody out, especially if they leave a nice rude message on your home page and you have to wait for tech support from your hosting company to take it down.

I'm sure listening to "security types" sounds paranoid and scary, but the truth is, you don't need bank vault security here, just some sensible practises so that should an attacker or employee target you, you have some defensive measures in place such that your business keeps going and the damage is minor.

Edit: I realise you didn't say you are doing development specifically, but that doesn't prevent you using a small scale lite version of a CRM, either.


Is Amazon Prime DRM able to scan a LAN for devices and services? My company has signed up for Amazon Prime to watch some videos. They were asked to enable Amazon Prime DRM. Will this open up a security hole in our LAN?

I am worried that they could start scanning everything. I can't find any real information about what Amazon Prime DRM does or how it actually works.

My understanding is the DRM element needs to be able to make an outbound connection and allow a returning reply. I do not believe this causes any more of a vulnerability than any other similar service.


Connecting to server with Proxy vs VPN Suppose I have a server and no-one can hack into my local area network. I want to Remote Desktop into my server from Internet. Exposing RDP is the most foolish thing I did do once and the server was brought down within days. I have configured IKEv2 now to get a local IP, but am regularly facing error 809, which goes away as soon as I restart Remote Access on Windows server. Now, my question is if I use RDP over proxy, am still vulnerable to attacks?

A proxy server and VPN server roles are different on your scenario.

A VPN creates a new network interface that is on the same LAN as the VPN server, allows you to connect from the internet and use the network as if you were on the local network. In this case, you enable RDP only for the internal network and still can connect.

A proxy server is the reverse. It allows you, from the local network, to reach sites on the internet. It protects the internal network from attacks, by providing only one gateway to the internet and usually employing security measures, like filters, blacklists, scanners, and so on.

Mixing both does not make much sense. Unless the network you are currently connected have a forced proxy, it's not needed. And if you have to, a proper configured VPN will work even behind a proxy.

If the proxy is not trusted, it could MitM the VPN connection, decrypting the connection from the server and client, and changing/recording/replaying data. So if you have to use a proxy, pay attention to any VPN messages telling about mismatched fingerprints, invalid certificates and other security warnings. Other than that, it will work.


Is there a common standard for digitally signing via smart cards? Am I right that "minidrivers" which are specific to different national or regional smart cards (eg PIV/CAC, Brazil, Estonia, Sweden, France, etc) are needed for digital signatures (RSA)?

Can the right minidriver be installed automatically upon insertion of a smart card? That is, install multiple mini-drivers on the PC and the right one is automatically used depending on the smart card that is inserted.

Does the CCID standard for USB Smart Cards provides a common signing API for apps?

I'm trying to make a single software app that will work with multiple cards for signing.

Minidrivers abstract the actual smart cards so that applications can all talk to them using a common interface. Your app doesn't even need to know nor care about which smartcard it's talking to, or whether it's really a smartcard or a big networked HSM, assuming it accesses the card through the standard interface and not talk directly to the card. Here's a good example from Microsoft themselves, as you can see the RsaCryptoServiceProvider can be used the same way no matter which card is behind it, because the minidriver provides a Cryptographic Service Provider that abstracts the card.

The right minidriver should automatically be installed via Windows Update, assuming the manufacturer submitted their minidriver there. I'm not sure which manufacturers bothered to do this in practice though. But yes, in theory nothing prevents you from bundling a lot of minidrivers with you app and installing them in advance.

CCID is a standard to talk to USB smart card readers, its sole job is to relay APDUs (commands) between the computer and the smart card reader. Basically the minidriver translates from high-level crypto functions into low-level APDUs (which are card-specific) and then passes them on to the reader via CCID.


Does a PGP signature provide integrity verification? Many websites including OpenSSL's website provide downloads along with MD5/SHA1 checksums sometimes in addition to PGP signatures for the files.

Simply put, do PGP signatures provide file integrity verification in addition to file identity verification? I would assume so. If I've verified a file's PGP signature, are the MD5 and SHA1 sums of the file more or less irrelevant, as I've already verified integrity?

If this is true, do PGP signatures provide better file integrity verification than other hash methods?

Signatures and Fingerprints

  Simply put, do PGP signatures provide file integrity verification in addition to file identity verification?

Yes, they do: but without further investigation, they only verify whether a given key was used to sign; not whom it belongs to (read on below)!

  If I've verified a file's PGP signature, are the MD5 and SHA1 sums of the file more or less irrelevant, as I've already verified integrity?

Yes, unless you haven't been able to verify the ownership of the key, but the other person provided you with the correct fingerprints in a secure channel (by meeting, (video) phone call, ...).

  If I've verified a file's PGP signature, are the MD5 and SHA1 sums of the file more or less irrelevant, as I've already verified integrity?

In fact, OpenPGP also uses hashing algorithms like these (whereas it hopefully shouldn't use MD5 any more, which is considered too weak our days). But digital signing adds information on who signed the software (if verified correctly).

Verifying Key Ownership

Unless you directly signed the software issuer's key, all you know is somebody signed the software. There is no primary certificate authority in OpenPGP, everybody can add a key with arbitrary names, it is up to you to decide which to put trust in. This is usually done by meeting and exchanging the key's fingerprints, but depending on your level of paranoia you might be fine with verifying the key fingerprint against some they put on their website (which then should be transmitted SSL-encrypted together with a reasonable certificate, of course).

Then, there is the concept of the web of trust, which allows to build trust paths from you to the issuer without meeting him directly, by trusting others in-between that together form a chain of certifications (this can actually be compared to the intermediate certificate authorities of X.509). A very short explanation can be found in this answer: What is the exact meaning of this gpg output regarding trust?.


Sending OAuth refresh token in email? We are building a mobile app that will use OAuth2 to authentication the users via the grant_type "password" (two-legged setup). So basically the user just sends the username and password, receives an access_token and a refresh_token.

The access token has a short lifetime and the refresh token is one-time use. So as soon as the access token expires, the user sends the refresh token to receive a new access and refresh token. So a pretty basic setup I guess...

However, we would also allow the user to authenticate via email, i.e. the user enters his email in the app and just click "send authentication email". He receives an email with an authentication link that opens the app and authenticate the user.

My idea is that the app generates a guid and sends that to the server. The server encodes the guid as a claim into a new refresh token which is then emailed to the user. The user clicks the link and uses the refresh token to receive a new access token and the user is the authenticated without having to enter any password.

I'm not that familiar with OAuth and security in general and we're using standard components to implement the authentication.
So my question is:

Are there any security issues with this this approach?

tl;dr
Are there security issues with your approach?
Difficult to say, as it is not clear from the question which token you are sending in the mail. You should read my long answer to understand my concerns. But, in short: if you send the guid, then yes, there is an issue (see the 'implementation' part of my answer. If, on the other hand, you send the refresh token: then there probably is no security issue.

Preface
As pointed out by @CBHacking:

the intended use of OAuth2 refresh tokens is for persistent access; an app gets a refresh token, and as long as it has a valid refresh token and the session is not invalidated on the server, the app is authenticated. The access token is short-lived but, if you're using refresh tokens at all, you expect the client to remain authenticated for a long time

Anyway, it does not really matter. If you want to use the refresh token only once, then you are free to do so.
An example of the implementation you want to achieve
I'm not sure if you already know it, but Slack has actually the sign-in experience that you are describing. You can test it yourself by creating an account and install their mobile app, or just see how it works here. Their link looks like this:
https://slack.com/z-app-0000000000-0000000000-AAAAAAAAAA (I've replaced numbers with 0's and letters with A's). I assume that their link is built-up as follows (note: I don't know if this is true, it's an assumption):

First part: user id
Second part: time
Third part: unique token

Clicking this link will redirect you to somewhere like this:
slack://login/XXXXXXXXX/xoxo-0000000000-24characterlongtoken
So, another token is created which is then used to open the application.
Implementation
Your guid implementation seems a bit overengineered for the following reasons:

Why make use of an app-generated guid, if you could just as well directly send a 'magic link' to the mailaddress of the user from the server? Your security lies with the security of the user's access to the mailbox, not with the guid (which is not secure anyway). I agree that you need some kind of token, more about that later.
You mention that this guid is then encoded in the refreshtoken as a claim. I assume you mean adding it to the protectedticket of the user (the refreshtoken itself does not contain claims, in contrast to the access token).
And then, I am a bit lost in your implementation. You mention that you send the refresh token to the user, but really a refresh token is only a reference to a protected ticket in your database. So you then use this refresh token to retrieve the guid. And then what? You see, the guid is of no use in this set-up. The only token that matters in this set-up is the refresh token.

Just send a token
Sidenote, I make use of the following notations:

access token: the access token as described by oauth
refresh token: the refresh token as described by oauth
unique token: any token that is unique. If you want to use the refresh token for this, it's your choice. I give other options at the end of this answer.

So, you actually provided your own answer. We get rid of the guid and do it as follows:

The user requests a magic link on the application.
On the server, you check if the emailaddress is known, if so, create a unique token for this user and send it in a mail (link to an endpoint that can verify the unique token). You probably also should send some kind of user identifier.
When the user clicks the link, you verify the unique token (for that user) and issue a new access token and refresh token.

Now, as mentioned before, a refresh token really is considered a long-lived token. In some implementations, this token even never expires. To prevent access, you should revoke it instead. Therefore, it does not really make sense that you would use a refresh token as a unique token in the email.
Even better would be to create a unique token that is uniquely tied to the user. This depends on your implementation, but in .NET you could for example use GenerateUserTokenAsync. When using this, you don't even need to store the token in database, when the login request comes in, you can just call VerifyUserTokenAsync and you are sure that the user is the person you sent the mail to.
If you want to create a custom unique token instead, you should of course link it somehow to your user in the database. You could generate such a cryptographically secure unique token yourself. Depending on your programming language, the implementation differs. Google for it, and you will get answers.


Appropriate password requirements for a login (OpenID) service/provider/delegate/thing This is with regards* to Stack Exchange's upcoming OpenID provider (and in particular, discussion about password requirements).

Currently, password requirements are:

Must contain 3 of: lower case character, upper case character, number, special character**.
Cannot contain any public account field.
Must have at least 8 unique characters.

The rational for the first two I believe is obvious.  The last one is to force a certain minimum password entropy, but in a way that can actually be explained to an end user.

I considered a password expiration policy, but discounted it as too intrusive.  Users will often use this service as if it were part of the affiliate site, and forcing them to periodically visit it rather than the affiliate site breaks that illusion.

So my question is, are these appropriate password requirements for an OpenID provider; especially one like this which aims for tight integration with 3rd party sites?

*And AviD's suggested it.
**Special character is defined as a non-word, non-digit character.

The proposed restrictions are harmful.  These restrictions are overkill.  They are bad for usability.  As a result, I think they will harm users' security more than they help.

Usability is where it's at.  In my opinion, right now the #1 most important factor affecting password security is usability: the extent to which users use the mechanism in a way that is secure.  To a first-order approximation, everything you should do should be aimed at increasing usability and increasing the likelihood that users will behave securely.  Every time you have a design decision, you should ask yourself: which option is more likely to cause users to behave securely?

I would expect that the complex restrictions you have articulated are, on balance, harmful to the user's security.  I think they will decrease security more than they will increase it.  Here are my arguments:

Frustration. One risk is that users will get frustrated or annoyed, give up, and shift to some other OpenID provider that is less securely administered than SO is -- or just stick with their current SO, instead of adopting SO's OpenID provider.  That is a net loss for the user's security.
Making it hard to memorize. If you have unique restrictions that are specific to SO's OpenID provider, this means that the user will have to pick a unique password for your site.  This may sound like a positive, but it could equally well be a negative.  If the user already has a high-entropy secret, they likely can't use that one, because odds are it won't satisfy SO's restrictions.  I suspect this fact increases the likelihood that the user will be forced to write down their SO password somewhere rather than memorizing it.
Automated password generators. People are, generally speaking, bad at picking unguessable password.  To address this, some folks use tools to generate their password for them.  Some have even advocated that these tools should be more integrated into everyone's browser and used widely.  Right now the biggest barrier to use of automated password generation lies with sites that pick their own special set of restrictions on password.  Thus, your proposed set of restrictions will make it hard for people to use automated password generators.  That's bad; you want to encourage people to use automated password generators, because automatically generated passwords will be more secure.  And you don't want to create barriers to integrated password generators.

So what should you be doing?  I have two pieces of high-level advice:

Start with a threat model.  Don't just start making up restrictions and security schemes that sound good.  Instead, start by thinking about the threat model.  What do you think are the most likely ways that security will fail?  Then, when you come up with a new idea, rather than immediately implementing it because it sounds good, analyze how it will affect each of those likely failure modes.  Does it, on the whole, significantly reduce the likelihood of the most-likely failure modes?  Just as there's no point strengthening the strongest link in a chain, there's often little point in securing against a threat that's not actually very likely.

I notice that the question describes a security mechanism, but it doesn't describe the threat model, and it doesn't contain analysis.  It doesn't state exactly what attack it is aimed at defeating.  In the security design space, this is a "bad smell" which often indicates that perhaps more thought may be appropriate.

For an example of this kind of analysis, you might read this analysis.  The paper argues that about 20 bits of entropy are sufficient for web passwords, as long as the password verification software is architected reasonably, and argues that there is little benefit to passwords with higher entropy.  See the paper for the detailed analysis.  The paper's conclusion states "We conclude that forcing users to choose strong passwords appears misguided"; see the paper for why.
Cost-benefit analysis. It is important to assess the costs and benefits of the mechanism, and make sure that the costs are justified by the benefits.  In this case, the costs are user annoyance.  The security benefits of these restrictions, compared to some less strict restrictions, are unclear and probably minor.

I encourage you to read Cormac Herley's economic analysis of password security.  He points out that the advice that security experts give users about passwords is irrational: the costs to users of following that advice (e.g., their time wasted in selecting, memorizing, managing and entering complex passwords) likely exceeds the benefits (in reduced security breaches) by a large margin.  He argues that any restriction which consumes more than a few minutes of the user's time per year is almost certainly a net loss, and in practice I suspect it probably needs to be at least an order of magnitude lower than that.  Someone asked for data; he has it.

On a related note, Cormac Herley has also performed a study of the password policies on 75 different websites.  He found a broad range of restrictions.  He also found that the degree of restrictiveness is not correlated to the security sensitivity of the site, and suggests that "the sites with the most restrictive password policies do not have greater security concerns, they are simply better insulated from the consequences of poor usability."  This should make one think twice about the suggestion that stricter password restrictions are better.

If you're looking for more concrete steps you could take to protect your users and increase the likelihood that they pick secure passwords, here are a few ideas you could consider:

Include a password strength bar. On the form where the user has to pick a password, include some Javascript to provide a dynamically updated bar that shows how strong the user's password is.  You can go with red, yellow, green for insecure, borderline, good.
Include a pre-generated password suggestion.  On the form where the user has to pick a password, you could randomly generate a password for them and suggest they use it.  Maybe some will use it!
Help users avoid popular passwords. One recent research paper proposes an interesting idea: they suggest that users should be able to choose any password they want, as long as not too many other users have previously chosen it.  Then, they describe how to enforce this policy, without storing passwords in cleartext on the server.
Use secure, persistent cookies for user authentication. If you reduce the frequency at which users will have to type in passwords, maybe users will be more willing to pick complex passwords of their own accord, and maybe users will be less likely to be fooled by phishing attacks.  I suggest that your site set a secure, persistent cookie on the user's browser when the user first logs in.  On future visits, if you detect that cookie, immediately treat the user as authenticated and redirect them onto their final destination, with no user interaction required, so that users are logged in without having to type their password.
Focus more on the password verification step. Why do we want users to pick high-entropy passwords in the first place?  What are the attacks we are concerned about?  One kind of attack is a targeted attack, where the attacker has a particular username in mind and wants to break into that user's account.  Another kind of attack is a broad attack, where the attacker has a ton of usernames and wants to find one, any one, whose password he can guess.  What's the biggest threat for the SO OpenID provider?  I suspect the one you should worry most about is targeted attacks, because I suspect an attacker is more likely to be motivated to try to break into a moderator or high-ranked user than an average user.

Stopping targeted attacks. There are effective ways to prevent targeted attacks on a single user's passphrase.  One very simple way is to keep a count of how many incorrect passwords have been entered in the past day or so.  If this count goes above some threshold, then you switch to "oh shit, I might be under attack" mode.  In that mode, you can require the user to enter a CAPTCHA along with each password, or you can add a delay after each attempt, or rate-limit login attempts, or you can force the user to solve a proof-of-work challenge (e.g., serve the user some Javascript code and force them to do 20 seconds of computation before you'll accept the next password guess), or some subset of these.  There are many possible schemes.
Stopping broad attacks. If you want to defend against broadscale attacks, e.g., where the attacker tries one password guess against each of tens of thousands of accounts, you'll need different defenses.  But there are also schemes for dealing with this problem as well.  One potential countermeasure is to keep track of the overall rate of incorrect passwords, and enter "I might be under attack" mode when this rate starts to get high.

There is a rich literature on defending against these kinds of attacks.  Overall, I think you'd be better off making it harder for attackers to mount password-guessing attacks (e.g., making them run slower), rather than imposing additional restrictions on user passwords.  I think there's more bang-for-the-buck there.


What is the difference between claims, attributes, and roles? Many questions have already been asked about Claims-based authentication and the differences with other approaches:
Role-based vs Claims-based
Explain claims-based authentication
Now, my favorite answer is one given on stackoverflow: Using claims-based authentication.

However, after reading through them, my question is not solved. The question I have is twofold:

Is there a difference between claims and attributes (ABAC)?
If we may look at a 'role' as being a claim, what is the particular advantage of claims-based authorization over role-based authorization? (note: I'm using authorization instead of authentication here, as I feel it is not really about authentication).

To elaborate my question further, I will give three examples of how I see claims-based, role-based, and attribute-based authorization. Disclaimer: I am not sure if these examples are correct, they are just part of my question.

Claims-based example

I have read through an interesting blogpost in which it is explained how we could use claims-based authentication in MVC / Web API. It seems that (in that blogpost) a method is secured (authorized) by looking at the claims that are associated with the user who is trying to access the method. If that user has a claim to 'view' 'streetaddresses', then he is authorized to view that data.

  [ClaimsAuthorize("Read", "SomeData")]
  public string Get()
  {
      return “somedata”;
  }

Now, the creation of the claims is separated somewhere else, which is not really specified in that blogpost. I'm assuming that hidden method checks whether that user, with that certain role, is allowed to view streetaddresses. Now then what is the difference with role-based authorization?

Role-based example

The difference is not clear to me, let's compare it with the old role-based authorization. I can once again define an attribute for each method, which restricts the execution of that method to certain roles. The 'view streetaddresses' method is for example restricted to users with the role 'admin'. So instead of checking the role in the separate method, we check it right here. Or am I missing something here?

  [RoleAuthorize('admin')]
  public string Get()
     {
         return “somedata”;
     }

Attribute-based example

I do see the advantage of a more fine-granular authorization control. But I would implement  something like this, to define that only a user with the role admin can access 'somedata' during working hours, and only if that admin user has blue eyes.:

  [AttributeAuthorize('role=admin;time=09-17;eyecolor=blue')]
  public string Get()
     {
         return “somedata”;
     }

This last example really seems advantageous to me, but I'm not sure whether or not it is the same as my first example, which is claims-based authorization.

To end, a last question has popped up:

This means that claims ARE different from attributes, as attributes are used to define which rights a user has, whereas claims are these rights?

Attributes are claims. A claim is simply a statement by someone/something that a user has a given attribute. That someone is the issuer which could be an IdP or an internal bit of logic that gets data from the database.

This gives you way more flexibility in how you design your systems as you can specify that a given task will always require a user with a given attribute, e.g. a given right, say 'CanTransferMoney'. What role can you create that would properly describe who can do that? How often would it only be that role that can do that?

At a higher level you could configure it such that all users in role 'Money Manager' have the attribute 'CanTransferMoney', but in doing so that wouldn't require you to make code changes, whereas hard coding a role in the code might.

Regarding your last question conceptually a claim defines which rights you have, and an attribute defines which rights you have. In my opinion at some point it really just comes down to semantics over which name you want to use. If you look at how SAML tokens were originally designed you'll see a claim was/is a function of the attributes provided in the assertion.


Should I hash my passwords even if I am only allowed to generate limited traffic? At this moment I'm busy working on an webapp with a friend of mine. The main problem we have is that we are only allowed to generate 50 GB a month in datatraffic.

My question is: Does hashing the passwords for users (when creating accounts or logging in) negatively affect the maximum datatraffic per month? If so what are the alternatives to make sure the information about our users is safe?

Yes, you should hash your passwords. Storing passwords in plaintext is not acceptable.

No, it does not affect the amount of traffic your site require. The hashing should be done server side, so it does not affect what is transmitted from the client.

Hashing the passwords protect them from theft once they are stored in your database. To protect them from theft when they are transmitted from the client to the server, you need to use HTTPS.

Some related reading:

Why should I hash passwords?
How to securely hash passwords?


Protecting passphrases within an application First off, I'm not very familiar with encryption best-practices.

My use-case is simple: I'm creating an application that will be reading encrypted documents and decrypting them dynamically to do some operation on the data that they contain.

I was reading that I should use 128-bit or 256-bit AES, so I installed OpenSLL to my Linux box to see how encryption / decryption is done. I encrypted and decrypted a sample document and notice that AES requires a passphrase.

How can I store this passphrase in my application securely so that somebody cannot easily reverse engineer the binary, discover my passphrase, and decrypt the documents outside of the application?

What you're talking about, essentially, is DRM. If you provide the user with the data you're trying to protect in any unencrypted form, they have the data and can make copies. It's on their machine, you've given it to them.

If you use AES, or any form of symmetric cryptosystem an attacker can reverse-engineer your application and discover the key.
If the key is only provided at runtime, they can load your program into a debugger and set a breakpoint to capture the key.
When you decrypt the document, anyone can set a breakpoint on your decryption routine and capture the plaintext buffer from memory.

Packing, obfuscation and anti-debug tricks are trivial to bypass for anyone that's even reasonably skilled at reverse engineering. This is self evident; think about every major game / software title that's come out in the last 20 years. Every copy-protection mechanism has fallen to reverse engineering. The same goes for malware and media DRM.

All of this boils down to one thing: Anything you put on your client's computer is theirs to modify and analyse.

I have a feeling that your situation needs to be re-thought. Rather than coming up with a potential solution and trying to find ways to make that work, think about alternative solutions. Can the document processing be done on a central server, out of the hands of the user?


Differences between the Root user and users with AdministratorAccess in AWS I am trying to determine the differences (if any) between using the AWS Root user, or a user within the AdministratorAccess group in AWS. The AdministratorAccess is given the following privileges:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Does this mean the users in the AdministratorAccess group can do everything that the Root user can do?

Does this mean the users in the AdministratorAccess group can do
  everything that the Root user can do?

Yes, barring the fact that IAM users with admin rights cannot delete root, while root obviously can delete any IAM users.

The root user generally should not be used for anything but creating an IAM user with admin rights. This should be then used for everything else.


Having sudo mode in a web application, why use a password instead of one time passwords? Online services, like GitHub, have Sudo mode. Sudo mode means, that a user performing delicate actions has only to authenticate every couple of minutes, but than again, although they are already logged in.

GitHub uses for this reason the user's password. I wonder if this is the best approach. Why should I use the password and not the one time password provided by an authenticator like Google Authenticator? Would that not be more secure? Especially, most browsers save the password and provide them in the password field while the one time password can not be provided per design?

A second factor is not inherently more secure than a password. In many cases (like an RSA SecurID Token) the second factor is vulnerable to physical theft - whereas a memorized password isn't.

It would be more secure to ask for both authentication factors. I imagine github have chosen not to do this for convenience - after-all this is re-authenticating a user who has already successfully authenticated with both factors. You could argue the active session is already a secondary form of authentication.


Snort's great, but BASE isn't. What are some alternative front-ends? BASE is an improvement over ACID, but it's easy to tell that it's maintained by someone who doesn't use it.  There's no at-a-glance overview of network activity like you get with McAfee's NUBA IDS and many others, and searching for patterns is awkward and slow compared to log aggregators like Splunk.

I'm aware of a few alternatives to BASE:

Sguil gives a somewhat nicer view of events, but it's showing its age, and the tcl/tk interface is awkward to use on a remote set of snort sensors from a Windows desktop.
OSSIM provides some pretty charts, but it wants to be your top-level SIEM in a single package, and I need something more modular, configurable, and network-focused than that.
Snorby looks intriguing, but it's the one out of the bunch that I haven't even tried installing and using yet; the demo site hasn't worked for me from my work desktop; only at home.

"and the demo website wouldn't let me log on, which doesn't engender extreme confidence" ouch.. I am the developer of Snorby and i'll bet 100 USD you were typing "snorby@snorby.com" (try .org). I have never had one issue with authentication or demo downtime since the launch of Snorby 2.x.x. Please make sure you verify credentials thoroughly before you post negative comments about a project to a large audience.

Aside from Snorby I would recommend Sguil. Sguil offers full packet capture, session data and numerous other powerful features. A bad UI is a small price to pay for valuable data.


How might the U.K. Government's proposed internet surveillance equipment "bypass" encryption? http://www.channel4.com/news/black-boxes-to-monitor-all-internet-and-phone-data

http://rt.com/news/uk-privacy-internet-freedom-186/

  'Black boxes' will be installed by internet services providers to filter & decode encrypted materials – including social media and email messages, something which critics say will have an impact on personal privacy.

Rather than "bypass" encryption, they can spoof the identity of the server, so as to perform a MITM attack (effectively).

Encryption itself is only one part of the configuration when setting up an SSL/TLS connection: this ensures the confidentiality of the communication between the client and the server. Before that, the client needs to verify the identity of the server, to make sure it's exchanging data confidentially with the party it expects: this is what certificates are used for.

An X.509 certificate is issued by a CA for a given server name. If the browser trusts this CA (there are a number of trust anchors provided by default with most browsers), it can trust its content: the binding between its public key and the name it contains. The browser also has to check that the server name it was looking for is one of the names in the certificate.

What the government can do is to ask you to trust its CA certificate (and/or have the big CAs give them an intermediate CA certificate) so that they can issue certificates for their surveillance device, thereby spoofing the real server certificate. This device would be a server and decipher the connection and then act as a client itself to the real server: you would then have 2 encrypted sections: one between the client and the surveillance device, and one between that device and the real server.

There exist appliances that do this (sometimes referred to as "MITM proxy servers"), typically used on a enterprise network.

Besides the fact that anyone in control of that CA's private key could see and alter any traffic the client makes to an HTTPS site (there are a number of non-technical problems here), there are a number of technical problems when doing this at the scale of a country:

These proxy servers may need to be explicitly configured in the browser (as an HTTP proxy).

Indeed, it's quite difficult to implement a MITM proxy transparently, because it can't always get the name it should put in the certificate it generates dynamically by just looking at the initial TCP packets. If Server Name Indication is not used (SNI is quite common nowadays, but not supported by all clients), all it can get is the IP address of the server, which may not necessarily resolve back to the expected name. For example, if you get the address for www.facebook.com and do a reverse DNS lookup, you'll get something like www-XYZ-XYZ.facebook.com. It could work with a wildcard here, but that pattern can't be expected in general.
This will make any service that uses client-certificate authentication break. Since during the SSL/TLS handshake, when a client certificate is used, the client signs the concatenation of all the handshake messages (including the server certificate) at the end, and the server compares it to what it has sent and received (including the real certificate). If there's something in the middle that inserts it own certificate, this is going to make this verification fail.
There will certainly be a delay in the establishment of the handshake, since the certificates may have to be generated dynamically. (Some could be cached.)
This expects users to "play nice" and use the ports that they are meant to do. Alternative ports might not be monitored or would have to be completely firewalled.
To track down Facebook/Google+/Gmail exchanges in a usable form, these devices will also need to be able to look through the structure of the pages (or JSON payload for AJAX) and be able to extract the relevant data (or to store everything it can't understand somewhere). Any slight change in the internal API of those services would require some costly adaptation.

Doing all this for all HTTPS communications will certainly require a large amount of computing power and yield a substantial electricity bill.

(It's possible that the reports that led the Home Office to make such plans were drafted before Facebook switched to HTTPS for everything, by the way.)


Network configuration: Preventing my computer being used as a proxy? I recently installed an extension for Chrome called Hola (skip to next paragraph if you know it). It calls itself a VPN, but is basically a proxy pool AFAIK. You can choose a country from a list in a per website basis and your connection to that website comes from an IP from the selected country from there onwards. Meanwhile, you serve as a proxy for other users.

I tried using it at my uni but it was stuck at "initializing", and after a few tests (different browsers, different computers) I could only conclude that it was being blocked somehow. Which made me wonder: My computer is in a vulnerable position if it can be used by others as a proxy, possibly without my knowledge. So I was wondering which aspect of my network I need to configure in order to avoid this kind of thing. I am currently using this script to generate my firewall rules (iptables):

# Flush all rules
iptables -F
iptables -X

# Allow unlimited traffic on localhost (breaks MPI programs otherwise)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A FORWARD -o lo -j ACCEPT

# Allow SSH traffic
iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

# Allow incomming traffic from estabilished and related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Policy: Allow outgoing, deny incoming and forwarding
iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP

I imagined the drop policy in "forward" would be enough, but it doesn't seem so. Is there anything I can do at the firewall level to block things like Hola? If not, what should I be doing?

Your question of why the forward rule doesn't work is essentially a networking question, so I'll explain using an analogy. Imagine there are three people involved in the sending of a letter - Alice, Bob, and you. Alice wants to get a message to Bob, but using you as a middleman (proxy). Alice could use one of two techniques:

Method 1: Write a letter containing the message, stick it in an envelope, and address the envelope to Bob. However, instead of giving the envelope directly to Bob, she drops it off on your doorstep. She hopes you'll be kind enough to find it, recognize that the envelope isn't addressed to you, and find Bob to give it to him.

Method 2: Write a letter, to you, that says: "Can you find Bob and tell him [message]?" Stick the letter in an envelope, and address the envelope to you. You (or perhaps the Hola app running on your computer) open the envelope, read the letter, and tell Bob the message.

Firewalls are rather dumb, in that they can only understand basic information like Source IP, Destination IP, port, and some other bits of metadata. They can't actually understand the contents of the packets. It's analogous to only being able to look at the outside of the envelope, without being able to read the letter inside. So even though both of the above methods would result in the same outcome (in essence, Alice getting a message to Bob using you as a proxy), the forward chain only recognizes the first one as forwarding. As far as the firewall is concerned, in the second case Alice and you are the only parties involved in the conversation. It has no idea of Bob's involvement, as it would need to "read" the letter to know that.

As far as blocking Hola, it seems that Hola traffic can be detected, but you'll need a tool that can "read the letter," so to speak, by performing deep packet inspection and application layer filtering. Usually this is accomplished using an intrusion detection system as opposed to a basic firewall, and I suspect it's how your uni is blocking Hola. If you don't want your computer used as a proxy, your best bet would be to just not use Hola.


Is leaving the root user enabled in Mac OS X a security risk? To those unfamiliar, the Mac OSX has the root account disabled by default. In order to enable the root user you have to go deep into System Preferences and authenticate yourself with an administrator name/password. This makes sense that you would want to leave something as powerful as root disabled by default. Then, when you wish to actually use root, you need to sign out of your account and login under the "root" account name.

However, according to this official support page [apple.com]:

  To ensure the security and stability of your computer, disable the
  root user when you are not using it.

At first I thought they simply meant to log out or exit the root account when done, but that doesn't seem to be the case based off how they explicitly said "disable the root user." By their suggestion, whenever I want to use root I must go through the hassle of enabling/disabling root it in addition to signing in/out of the root user.

Does this seem like a complete waste of time to anyone else, or am I missing something here? Are there legitimate security/stability risks that I am leaving myself open to by not disabling the root user?

I don't see the quoted instruction on that Apple KB article; the closest I see is:

After completing a task as the root user, you should log out of Mac OS X and log back in using a normal or administrator account. You should disable root access if you do not use it often.

Which seems (to me) like reasonable advice.  Having the root account enabled is not a serious security risk (provided you follow good password practices), but it's usually an unnecessary security risk.

The biggest problem with having root enabled is that it's the most tempting target around for password-guessing attacks.  For example, if you have SSH enabled & accessible from the internet, you will have bots connecting and trying to guess the root password.

Basically, having root disabled decreases the number of ways for someone to take over your computer; so unless you need it, leave it turned off.


Why use any other password generation method when Diceware/EFF dictionary exists? Recently I discovered method of generating passwords with Diceware/EFF dictionary.

Look at my example, passphrase vs randomly generated password:

rockstar reword gamma banker unwarlike (64,6 bits entropy)
9zbhL=HyWNV (65,7 bits entropy)

Both are considered as strong passwords.

is easy to type and remember. You can spell it to someone else.
is opposite: hard to type and remember, impossible to pronounce.

Password managers deals with typing difficult passwords.
But in the absence of password manager software at the workstation or in other circumstances where PM can't be used (login screen, decrypting system drive), passphrase is better.

I am curious:

Should I create all my passwords with Diceware/EFF dictionary and only fallback to random characters if password policy forces me to include special characters and upper/lower case symbols?
Why in IT systems we still use randomly generated gibberish when we could use words?

Should I create all my passwords with Diceware/EFF dictionary and
  only fallback to random characters if password policy forces me to
  include special characters and upper/lower case symbols?

As long as your systems support using passphrases you should use anything that is more comfortable for you. As long as it is secure enough. Please, when considering security, consider as many vectors as possible. It is easier to target users using social engineering to get their passphrase rather than password.

  2) Why in IT systems we still use randomly generated gibberish when we
  could use words?

IMHO, mostly because IT guys are technical guys, who get their knowledge on the matter from the proven (meaning old) sources. Passphrases are a relatively new thing, and most of the places where IT security is considered business-critical (banks, government, etc) have still active old systems (i.e. AS400) that do not support passphrases. It is mostly a matter of habit and trust.

I would advise you to consult NIST standards, various frameworks and so on to have a better understanding on requirements to passphrases.


How to find dates of a CVE? Is there a way to find the date when a CVE (identified by the CVE-ID) is detected and the date when a fix/patch is available?

The best you can do is read the References associated with a CVE.  The CVE Date Entry Created isn't useful because, as they point out,

  Disclaimer: The entry creation date may reflect when the CVE ID was
  allocated or reserved, and does not necessarily indicate when this
  vulnerability was discovered, shared with the affected vendor,
  publicly disclosed, or updated in CVE.

The References section, however, may include announcements of the vulnerability and announcements of fixed versions, which will likely provide the dates you're looking for.

The downside of all this is that it's clearly a manual process, and your success at finding dates will vary from one entry to the next - again, as the MITRE site says, "The [References] list is not intended to be complete."


What should I store in the case that a user posts a threatening post? I am building a social-media type website. I am going to have the users create a profile with their name, email and phone number. When a post is created I plan to have a spot in the database that holds the username of that user.

What I am wondering is if I should log the IP address of the person who created the post, in the case that the user does post something and the police may need to be notified. (An example would be the student in Rolla, Missouri who 'anonymously' posted and threatened to shoot up a school).

From this answer:

  All you can really do with an IP is find out who is responsible for the IP block with a whois lookup.

If this is the case would it even be worth keeping the IP addresses?

Lastly, if this isn't too broad of a question, what are some things I could/should store about a person who makes a post, without invading privacy of the people who do nothing wrong?

I recommend you to log user id and IP each time someone authenticate. That way, if a user post something, you know where it came from. Having a log like that is also useful for other purposes, like notifying the user in case you identify multiple IPs are connected at the same time, block consecutive attempts, etc.

But for your specific example, I think you don't need to worry about that as most of the webservers (with default settings) will generate a useful log. In case of an extreme case (as you commented), you can go to those logs and correlate times and actions (URL, POST) to identify IP addresses.

As said, an IP is not entirely a good identifier to locate a person, but if its given to the police, they may request to the ISP (who owns that IP block) for personal details. Depending on local laws, the ISP should or should not give such information.

By the way, if you are asking their phone number (and verifying through an SMS), that is by far more useful than the IP. Just handle that phone number to the police and they will know what to do with it.

Personally I dislike when a website asks for my phone number. I think is too private and in most of the cases unnecessary (unless the user wants another way to protect their account).


Could I ever be legally required to decrpyt user information? Suppose I host some web app which stores information about its users. In the interest of confidentiality, that information is stored in an encrypted format. Under what circumstances could a legal authority require I decrypt it and give them access?

Furthermore, suppose that the web app doesn't actually do the encryption, it's encrypted client-side using keys provided by users before being sent server side for storage. Now it's not even possible for me to decrypt it, as I don't have the keys. What could a legal authority that wanted the data require me to do? I'm primarily interested in US law.

In light of the fact that you don't have the private keys (given the way that you've posed the question), it would be impossible for any authority to force you to decrypt information that was encrypted using the accompanying public keys.  You can't get blood from a stone.  But notwithstanding, authorities in the US have been known to force site operators to hand over private SSL keys - perhaps most notably in the case of Lavabit (https://en.wikipedia.org/wiki/Lavabit).

Edit:  Thinking more about this - It seems that this question begs another question.  I understand that all encryption is done at the client side by your application, and that the private keys used for encryption are stored at the client side as well (a la Proton Mail).  But, if your application were to serve some malicious client-side code, would it be possible then for your server to access the client's private keys?  If so, then it doesn't seem like it would all that much more egregious for an authority to force a site that operates in this manner to do this, than it is for an authority to force a site to hand over its private SSL keys. I believe this is one of the reasons why Proton Mail setup shop in Switzerland.


Encryption of headers in IPsec tunnel mode I am learning about IPsec's transport and tunnel modes. I understand that transport mode encrypts only the payload of an IP packet and is used for communication between two entities that both implement IPsec. I understand that tunnel mode encrypts the entire packet and is often used between two gateways (like firewalls at the edges of a network). I have two questions that I think are related:

Why does the header information have to be encrypted in tunnel mode?
If the header information is encrypted,  how are packets routed? Don't headers contain information like: hey, send this packet to 2001:db8:85a3:8d3:1319:8a2e:370:7348. If the header is encrpyted, how is the packet routed?

It is not that the header has to be encrypted in tunnel mode; rather, if the header is not encrypted, it is not really a tunnel.

Tunnel mode is about having two routers linked together with an encrypted tunnel. They exchange packets for other hosts. Schematically, router A is the exit router for network netA, and router B is the exit router for network netB. A and B run an IPSec tunnel. Whenever a machine in network netA wants to send a packet to a machine in network netB, then that machine sends the packet to its exit router, i.e. router A. Router A sends the packet to router B within the tunnel. Router B receives the encrypted packet, but decrypts it upon reception, and discovers for which machine in netB the packet should be sent. Router B proceeds to send the packet to the final destination machine.

With the tunnel:

The source and destination machines which talk to each other don't need to be aware of IPSec; only the two routers at both ends of the tunnel.
Eavesdroppers on the link between routers A and B (i.e. the "bad people on the Internet") only see encrypted data and cannot even know which machine is talking to each machine, since the whole packet is encrypted, including header.


What is a good reason for persisting OAuth credentials? While reviewing the database for some web sites I noticed tables where OAuth credentials (such as the token, refresh token) among other information are stored on the database.

My understanding is that this information is mainly required for the user session duration and no longer after that, so my question is why would it be kept in a database or stored in any medium?

Could it be stored just to save the cost of re-validation after the session has expired?

There are Access Tokens and Refresh Tokens.

The Access Token is typically short-lived (think 30 or 60 minutes), and there is no reason to persist it after it has expired. It has no use to anyone.

The Refresh Token is required to obtain a new Access Token, and is typically long-lived; at least as long as an active session.

If an attacker gains hold of a Refresh Token, they have all the access that the user would have if they had logged in with that token. However, they have access to session(s) for which that particular Refresh Token authorizes them. (Meaning that, if the token was granted for less than normal privilege for that user, the attacker would be at the same lowered privilege).
Also, since it's not a hashed password, they cannot derive the plaintext password from it with rainbow tables.

A Refresh Token can be retracted at any time, without requiring the user to change their password.

From a security point of view, using a Refresh Token instead of requiring the user to log in again protects against shoulder surfing. The drawback is that if the attacker has physical access to the device that contains the Refresh Token, they don't need to authenticate either.

Be careful when deleting the Refresh Tokens. An expired Refresh Token has no use to anyone, and can be safely deleted. But deleting an active Refresh Token requires users to log in again; causing them unnecessary inconvenience.

Make sure the database containing the active Refresh Tokens is properly secured. They are typically not hashed like passwords are.


Blocking access to social media on Windows I would like to block websites like Facebook, YouTube and other social sites as part of my job and would need your advice on how to manage that. There are about 120 PCs in the building. Is something like that possible?

Can it be done with the host file, or is there other way?

I don't think you can solve your problem at the hosts, IP firewall or
DNS blacklisting levels. These methods will fail and won't scale.
If this within your financial possibilities, I'd suggest you to install a
web firewall.
Here are the beginning of the prerequisites to build such a web firewall.
1. Material
A PC with a pretty large amount of RAM (≥ 8 Gb), 2 100 Mbit/s Ethernet ports,
a large disk (≥ 1 Tb).
This PC will have to be inserted as a breaker on your Internet connection cable (hence the 2 Ethernet ports).
2. Basic software
A rock solid OS (FreeBSD, Linux…) correctly secured (most notably everything not usefull will be closed).
A rock solid free software used by ISP to manage web performance and filtering: Squid
3. Real business
The configuration of this application level firewall should progress as follows:

standard configuration of squid as a transparent web proxy,
train yourself to look at the squid logs,
start to analyse what may cause bandwith waste, data leak…
make clear communication about its use and purpose,
turn off the phone,
start to filter…


Why Apache runs as unprivileged user? Apache Web server as a security measure relinquishes its system privileges and runs as a normal unprivileged user before accepting clients over a networks. My Question is

How this measure prevents or restrains bugs to be exploited by malware.
What is idea behind this approach

Because the context of www-data is a lot less privileged than the one of root. For instance as a root user you can alter a lot more configuration files, add or remove users, read protected folders, etc...

As www-data you cannot do this, so even when exploited the attacker can only use all resources and files available to www-data. This helps contain the attack (obviously privilege escalation cannot be stopped if exploits exist).


How to set correctly set Local Host on a payload for a user outside subnet? I'm training with labs and metasploit and there's some payloads I can send to my target and exploit it(in my subnet). If I have to exploit a payload I sent to a target outside my network which options does I need to use in my payload configuration ? I've tried the usual option of LHOST = 192.168.x.x and did not work well.I'm using a payload with only two options of LPORT and LHOST and a handler with LPORT and LHOST with the same options in metasploit. (Using Kali Linux)
 Any Ideas?

The mentioned IP address 192.168.x.x is from the private network block 192.168.0.0/16. So unless your target is in the same network as you, you can’t use that address.

You need to provide an address that is reachable by the target like your public, Internet facing address. And since you’re probably behind some router, you also need to forward the LPORT on your router to your local machine.


Issues with resetting password guess count? Prologue. Imagine a website with a login. You have an account, enter your e-mail address and a password. Error. Password incorrect. You try two other passwords. Both incorrect and now your account is locked. Fortunately, it's not a timed lock, but you do have to change your password. I click the link in the "you forgot your password"-e-mail and enter a new password. The website responds with: "please choose a password other than your current password".

OK, so here's my question: would there be (other) security risks involved if, instead of forcing me to change my password, the e-mail they send me after n invalid passwords, would contain a link that sends me back to the login page, but with n new login attempts?

A lot of websites use the reCaptcha when someone is starting to have failed login attempts. The reason this is good is because 1) it's anti-bot because bots have a hard time reading images and 2)It keeps your user on the page without having to leave or cause any extra hassle such as having to log into their email for a new link.

There wouldn't be that much security risk but in the worse case scenario, if an attacker also had access to your email account, he can write a bot to login into your email, get the link, navigate to the link and start trying again and repeat the process. I think the best solution is to implement reCaptcha after a user gets too many incorrect passwords.


How can Facebook use my Whatsapp data? I use Facebook, but don't have a phone number in my personal details, and don't have a phone number set for recovery. If I lose my FB account, I guess I'll be able to make clear it's mine, so I haven't set a recovery phone number, and otherwise - bad luck! It's not that important to me. I visit FB mainly using my laptop browser, Firefox with Privacy Badger.

On my Android phone I don't have the Facebook app installed, neither FB Messenger. I might open FB in my phone browser, which is Firefox since long, with AdBlock installed. I have used Instagram, but quit using it since they asked for my phone number.

I use Whatsapp, but use a special phone number for this. I do this mainly to keep whatsapp for private use only. Colleagues may use mail, phone and sms. My normal phone number is in my contact list, so I guess that's uploaded to WA, and probably to Instagram as well.

Now I'm wondering, in what ways can Facebook connect this all and know it's all the same person - me?

This all of course considering the recent sharing of data between Whatsapp and Facebook that's going on.

There are lots of Artificial Intelligence tools, which even you can't think about... Most simple to understand is explained below :

Facebook is great in face recognition. Your whatsapp profile picture's and your photos on facebook can be easily matched by face hashes. Facebook's facial recongnition algorithms are very good. So the Facial Tags on facebook link you with your mobile number.

Anyways if you are using an alternate number for whatsapp, I can still say that atleast one of your friend who has facebook app. will be having your all contacts linked together under one contact name and that's where facebook is going to get your all alternate contact numbers too. Facebook and whatsapp both do sync. contact numbers. Its not getting synced from your device but is getting from your friend's device.

It will sync. contacts from all your friends and can confirm your name and identity from name saved in their devices. Whatsapp can also read your call logs, sms, browser history, thumbnails, images, sd card data etc...

Spend some time read about permission used by whatsapp and think about if they are really needed by whatsapp...


Embedded devices with storage for sensitive data I'm looking for some embedded device that will be able to store sensitive data like certificates, private keys, etc. It should comply with following requirements:

Sensitive data, stored in protected persistent memory should not be accessible outside. Sensitive data being destroyed on outside reading attempt or being encoded way that it can't be used after being read are the acceptable options.
Device itself should be able to run program code of some kind and have some common connection interface (ex. usb). You must be able to burn code only once, or there must be assurance that no one can replace your code with code of their own (ex. build in check of code signature).
It must be affordable (lets say no more than 100 bucks per device (sdk, burners and other developer stuff not included))

I've done some of my homework and so far I have:

Smart cards (Basic cards, JCOP JAVA cards). Pros - have protected storage, can run code. Cons - firmware limits, every card need separate reader. They are more like a mobile authentication method, that doesn't make sense in my case, because system will be stationary.
Micro-controllers with embedded crypto features. Ex. http://www.atmel.com/products/security-ics/secure-memory/default.aspx and http://www.atmel.com/products/security-ics/embedded/default.aspx That looks like what I want except for the part that you need to manufacture the rest of "device" for them, and that is not an option. So far I've failed to find any "ready to use" solution with them. Something like raspberry pi or arduino but with such chips will be perfect.
eToken alike devices with flash memory and ability to run code. Probably the closest match for now, except for the price.

All suggestions are welcomed.

A device like Ironkey would do the trick I believe. They're expensive though. Just a device that is hard to destroy or temper with, and can be remotely "destroyed". They're ideal when transferring sensitive data between locations,
but make sure you have a "copy" somewhere else.


After heartbleed, how can you safely distribute new certs? It's been a while since I studied key distribution, so I may have some fundamental misunderstanding..

From what I remember, man in the middle attacks can't occur during cert distribution because the cert being distributed is protected by a higher level cert's key. The root keys are distributed on cd with the OS making them very unlikely to be forged. But with heartbleed, isn't it possible that even the root level private keys were compromised? How can you safely distribute new keys electronically under these circumstances?

Normal, serious root CA are offline. They are hosted on machines which are never connected to any kind of network. This tends to make them immune to remote attacks, and that's the point.

Technically, the reasons which have warranted key renewal ("the bug was there, so there might have been a compromise that we don't know of") are still valid: it would be preposterous to claim that we found and removed the Last Bug Ever in OpenSSL, or, for that matter, in Apache (OpenSSL is a library, it is loaded in the address space of the Apache server, so any similar bug in Apache itself would be equally devastating). So there must be some remaining bugs, and your new key is as "potentially compromised" as the previous one. So don't sweat it...

Or said otherwise: the whole heartbleed panic is based on a suspicion of possible breach, which logically still applies, and has always applied since the first days of networks. The "heartbleed" bug is nothing qualitatively new; bugs with that level of seriousness are found several times per year in any significant piece of software. We can conclude that "we cannot be sure of anything" and that would be mathematically true, but impractical. If we want to cling to the idea that computers and networks are still usable, then we must accept that bugs exists, some of them being vulnerabilities, and that usual strategies (applying security fixes as soon as vendors publish them) is a valid strategy which will allow our servers to remain unscathed most of the time.

As a colleague of mine told me yesterday: fish group into swarms (technically called shoals and schools) to protect themselves from predators. When a dolphin grabs a fish, that specific fish probably thinks "why me ?" and has a feeling of injustice; but the shoaling strategy is still effective on average.

To a large extent, that's what we do with the mechanism of vulnerability publication and security patches. A vulnerability may be found because it has been observed to be used by a predator, and that's too bad for the victim, but at least the rest of the swarm benefits for the experience. We would really like to be more proactive and develop code with no bug, but alas Science has not come up with a way to reliably avoid bugs in software (though languages with strong typing and systematic array bound checks can help a lot).


Do world-writable systemd .service files created as symbolic links in /etc/systemd/system impose a security threat? Do world-writable systemd .service files created as symbolic links in /etc/systemd/system impose a security threat?

Would it be possible to somehow modify the links to target arbitrary .service files on the system, and make systemd execute those files as root?

The permissions for the /etc/systemd/system directory is as follows:

drwxr-xr-x. 11 root root 4096 Aug 30 12:57 /etc/systemd/system/

and the world-writable links in this directory are:

1050594    0 lrwxrwxrwx   1 root     root            9 Apr  9 11:53 /etc/systemd/system/ctrl-alt-del.target -> /dev/null
1050595    0 lrwxrwxrwx   1 root     root            9 Apr  9 11:54 /etc/systemd/system/sensu-server.service -> /dev/null
1052003    0 lrwxrwxrwx   1 root     root            9 Apr  9 11:54 /etc/systemd/system/sensu-api.service -> /dev/null
1052037    0 lrwxrwxrwx   1 root     root            9 Apr  9 11:55 /etc/systemd/system/dataeng.service -> /dev/null

No, because there is no way in Linux to modify a symlink in-place, you can only delete and recreate it, and there is no permission to do that.

Also: the permission of what you can do with a symlink is actually the permission of its target, not what shows in ls.


Is it safe to throw away debit card receipts in the bin? In relation to this question about credit card receipts, is it safe to just throw away receipts where I have used a debit card?

In addition, would it be any more worth while burning/shredding receipts before throwing them away?

"Is it safe to throw away debit card receipts in the bin?" yes and no, factly its just the principle of keeping notes with private information tight with you (every piece of info is costly and reserved). Are DCR's highly detailed and full of information (which normally are not) and is your bin on the edge of street, then you can see this as a potential risk. But in reality, this is not that important if you are working in a well ruled company. Of course someone would have interest in this, but likely doing nothing with it.

There is another option: use an alcohol based marker or black ink, mark the most important lines.

Would it be any more worth while burning/shredding receipts before throwing them away? Now you are free-of-risk.


Can the Truecrypt downloads from the Gibson Research Corporation website be trusted? The Gibson Research Corporation (GRC) website is offering the following page with links to download Truecrypt 7.1a.

https://www.grc.com/misc/truecrypt/truecrypt.htm

My question is, can these downloads be trusted? Is there a way to identify if the downloaded programs have been modified from the original 7.1a release?

They offer a link to another site with the hashes of all Truecrypt 7.1a files, but how can we know if we can trust this site too?

I don't think this is the same as asking can you trust driver download websites? because the history behind Truecrypt is rather unique and the original developers of the software removed the links to the 7.1a version and now offer only a download to a cut down version of the software that doesn't encrypt volumes. The GRC website has stepped in to provide downloads to the 7.1a version, which they still argue is still fully functional and secure. This question is to address how can we trust these claims.

Even if we assume the files on GRC are untainted, I would still recommend avoiding it because Truecrypt is no longer under development.  I would recommend using VeraCrypt instead. For the following reasons:

VeraCrypt is an actively developed fork of Truecrypt
VeraCrypt can manage volumes created using Truecrypt
There was recently an audit performed on VeraCrypt.  26 vulnerabilities were found; 8 of which are critical, which may reflect vulnerabilities in Trucerypt code.  The VeraCrypt developers have patched many of the vulnerabilities already.
More details are available here:
https://ostif.org/the-veracrypt-audit-results/