Does using a live CD make you more vulnerable to remote attacks?

Potentially, yes. That said, many distributions (e.g. Debian, Ubuntu) run package versions which are extremely out of date (years) with few backported security patches, and most people do just fine. You're also usually only exposed on the network you're immediately connected to, so if you're only using a trusted LAN then it's not so much of a concern.

Personally, if I were particularly paranoid, I'd get hold of a cheap Android tablet and lock it down, and use that as a dedicated banking device. This allows for updates and means you're running a much smaller attack footprint, with less likelihood for compromise (you're not doing general purpose browsing on it) so there's less to worry about.


Implications of a 6 digit password reset token

The password reset scheme you describe looks OK, but you are leaving several questions unanswered at point 7, which are relevant for evaluation:

What happens, if the token the user submitted is wrong?
How many tries do you give the user before considering the reset attempt failed and block further token submissions?
If a reset attempt failed, can a user retry resetting his password again?
Is there any rate limiting (e.g. only one password reset attempt per account per day)?
Do you monitor failed attempts and react to such attacks (e.g. block an offenders IP address)?

The answers to these questions allow you to calculate the probability of an successful brute-force attack.

6 digits means a number in the range from 000000 to 999999. This gives you one million different possible tokens. Let's assume you allow up to 10 token submissions per reset attempt before you consider it failed and block further attempts. This gives an attacker a slightly better chance of success than 0.001% for a reset attempt.

That seems like a low probability, but if the attacker can automate the process and there are no limits how often a password reset can be triggered, a successful attack becomes likely fast. If an attacker makes 10000 such attempts, he has a probability of success to reset at least one account of around 10%. Ramp this up to 100000 attempts and you we are talking of a success rate of around 64% to reset at least one account. This does not look secure at all anymore.

So the real question is, can you prevent an attacker from making such a huge amount of reset requests, considering that it doesn't matter if they are done for a single account or multiple accounts.

You also talked about simplicity of the process. If you do not want to use a complex character set for the token, that's totally fine. Length is much more important anyway. If you want to make the token stronger, I would recommend adding a few extra digits. But in the ends, it comes down to protect against brute-force attempts.


What are the privacy and infosec risks with Apple Watches and Android Wear?

I am sorry but I cannot speak for Android Wear, I don't know their technical infrastructure. I know a lot about the Apple Watch. So:

  Do either Apple Watches or Android Wear have local storage, or cache
  data from the connected phone?

Yes, the Apple Watch has 8 gig of internal storage and yes they cache the last data you received on each indiviual app (WatchOS1). So for example if u open your news app, the next time you open that app it will continue with the last data. This is a choice for each developer. Banking apps I use don't cache personal data at all (that's why it is so slow).

  Is there an ability to encrypt, and wipe that cached data?

From the GUI there is no such option. Building your own app you can do that.

  What is the privacy of the data on the device? Can an app on the phone
  read all data on the watch? What constraints exist?

Apps on the Watch always come with an iPhone app. It's part of the download. That app can read all data from the watch app. But no other app can.

  If the watch connects to the internet, is an always-on VPN an option?
  (some phones have this)

The Apple Watch doesn't connect to the internet. It uses the iPhone's connection. So, partly, yes.


How does Windows certificate manager verify a file's certificate, if the root certificate is not in the store?

Regular on demand download
The Windows trust store currently contains some 340 root CAs. But AFAIK not all of them will be installed/visible on your machine right away.
And Windows has a somewhat counterintuitive feature where during certificate path construction when the path ends in an unknown root CA Windows will go online and check if it needs to download one of those 340 roots.
Further reading

http://netsekure.org/2011/04/automatic-ca-root-certificate-updates-on-windows/
Related question: How much of a problem is it that Windows "hides" some of the trusted root CA certs?


You are correct.

Some ways for the site to decrease that attack vector would be to...

Use an HSTS header to prevent any data from being sent to the site in plaintext.

Advertise only the HTTPS URL and do not allow any plaintext connections. This will ensure most bookmarks use encryption.

The point being that sites should force SSL from the beginning, which will help prevent MITM in the future. There is not much protecting the situation that you presented, as when using mixed content forms, you are vulnerable to sslstrip


Automatic vulnerability scanners often produce false positives with timing based payloads.

This is because the scanner only checks if the request takes longer than the injected pause. If there is high network traffic - possibly because your scanner produces a lot of requests - this may happen even though the payload was not executed.

This means that you should always manually confirm timing based payloads (as you should confirm any other findings).

It's not quite clear to me what the actual payload is here. There are really two possibilities:

& is meant to be encoded, so the query string would be: ?from=ACG%22%26sleep%205s%26%22&to=AMR. This is the likely case. The vulnerable parameter would be from, and the payload would be ACG%22%26sleep%205s%26%22. It would exit the current string context via ", then add an additional command via & (which can be used to add additional commands in windows and linux), and finally get rid of the trailing " by adding another command via &.
& is not meant to be encoded, so you would add an additional parameter named sleep%005s with no value (less likely, but still possible).

You should try out both variants, first with a command that produces a visible result - such as id, ls, dir, etc - and then with a timing command such as sleep.


Do we have to take algorithm substitution attacks seriously?

Yes, we need to take these issues seriously. In fairness, cryptographers have long been aware of such issues, and many protocols and ciphers are designed to at least reduce the scope for covert channels.

In different contexts the substituted algorithm will be more or less apparent:

In the source code the data leakage would be fairly obvious. Usually a field that should be totally random would be leaking key data. I've not done a review of any library myself, but I think it unlikely such code would sit in the official repository.
In compiled code the data leakage is still fairly obvious, but it takes an auditor with more tools and skills to find it. I doubt such code would be in the official version of a binary library (such as Microsoft's SSL) as there's too much chance of getting caught. But it is a way to back-door particular installations, and I expect this happens.
In a black box settings (such as a smart card or TPM) it is virtually impossible to spot the data leakage.

I do think the paper has a good idea: remove all randomness from crypto protocols, and make everything deterministic and stateful. How important is this? Well, considering most desktop operating systems are at massive risk from malware, it's not the number 1 priority.


Can we provide our external certificates to a customer's SQL Server for SSL?

You can create your own CA first and then supply the CA certificate to the SQL server (your OEM version). Any future certificate that you (as the CA) generate for the customer will then be trusted by the SQL server.


Choosing TLS / SSL cipher suites - What considerations are there?

Is there a generally accepted criteria for determining which ciphers to support, and in what order? Most importantly, why are those criteria important?

Case 1: You control both ends of the communication.

1.a. (sorry to repeat part of your question but you have no choice than) Use the highest suite components which are supported by your chosen software.
 1.b. If that does not satisfy your needs then create your own implementation of a suite component which is not yet implemented but is published and peer-reviewed in academic environment.
 1.c. If that still does not meet your needs, invent your new algorithm and wait for it to be peer-reviewed before implementing it.

Case 2.1: You don't control the peer, but you are in need of information exchange under his conditions (ex. you are visiting a website, let's say your bank online account)

Accept the highest combination the peer is offering. Lookup online each algorithm details/weaknesses and evaluate what are your loses if/when your communication is compromised. Constantly monitor changes in peers offering.

If you find these loses unacceptable then find alternate means of exchanging information (ex. go to the bank office instead)

Case 2.2: You don't control the peer, but you wish to reach an intended audience (ex. you are selling openvpn accounts)

Constantly monitor progress in cryptography and always offer the highest suites available.
Constantly monitor existing suite for weakness (ex. subscribe to alerts regarding the software you use and the algorithms that are implemented) and when a new weakness is published, evaluate how is that impacting the numbers of intended audience (assuming that you will drop the vulnerable suites knowing that by doing this so will potentially reduce audience)

To summarize all three cases, the strongest criteria is:
In what degree a leak or altering of information I exchange is affecting me, my friends, my business or my business partner(s) and how much do I care about it?

  Presumably, some ciphers are tougher to crack than others. Some are faster than others. Some may have other perks or considerations I don't even know about. Are there resources for figuring this out without getting a graduate degree in cryptanalysis?

Just stay up to date with current official cipher suites list and always choose the highest available. Keep an eye for example on what NSA recommends for their internal use. An expanded view of @bonsaiviking's answer linked in the first comment of your question is detailed on Google's Online Security Blog


Best practices for setting up client connections to a server with app credentials

Your question is essentially one about DRM.

I can't really make out one important fact about the tool. Is this tool hosted on your own servers or your clients servers?

If the tool is hosted on your own servers, this makes the situation a lot easier. Setup a authorization system based on API keys and only allow clients to use the tool if an accepted API key is sent in the request. In this scenario, you have to ensure that none of the relevant (data processing) portion of the code is in the hands of the client.

If the tool is hosted on your clients servers, the API key system still works. Have a functionality that allows the clients to generate and revoke API keys to allow them access into that particular instance of the tool.

If your question is how to prevent unauthorized organizations on installing your tool in their own servers, this problem is probably difficult to solve technically. You might want to rely on legal contracts to prevent authorized organizations from leaking your code.


How is it that tools like Hashcat, JTR able to bruteforce an NTLMv2 hashes?

I actually spent a good deal of time looking into this when I got a little sidetracked one day.  The NTLM suite of protocols is complicated.  There are many versions out there and some have distinct weaknesses such as the one I discussed in this question a while back.  This reference page provides a lot of technical details and code examples on how to build and verify these messages.

With the specific attack you point to one factor is that the attacker controls the server.  That means that the attacker can see all the challenges and actually control things such as the server challenge.  It's also possible for the server to attempt negotiate to a weaker version of the protocol but it's not clear if that's part of it.  You could tell if you want to go through all the packets in the article.


What are the risks of uploading and downloading data in binary (non-encoded) format to servers and browsers?

On the network, bytes are sent and received. What these bytes represent is a matter of convention between client and server. However, if the client and server use some sort of open encoding (e.g. Base64) that everybody knows, then it is easy for any attacker in-between to apply and unapply that encoding at will. So this will have zero benefit for security.

If the encoding used a secret convention between client and server, then we enter the realm of cryptography, and then "it depends".

There is nothing inherently toxic in "binary data"; conversely, there is nothing tame in "characters". Bytes are bytes. If some code has trouble with arbitrary bytes, that it would not have with "characters", then this means that the code in question is interpreting raw bytes as characters, and that's a bug all right. You can call it "corrupted data page tables" if you like; it does not change things in any way: a bug is a bug. It does not occur through accumulation of time; it occurs through programming mistakes or hardware errors. There is no byte value which makes such issues more probable than any other.

What makes bugs more probable are unwarranted assumptions from careless programmers. E.g. a programmer who expects, in his code, some bytes representing characters, and not putting in any code to deal with null bytes or other "invalid" incoming data. That's the deal with attackers: they do not always follow encoding rules. There is no encoding thingy which will protect a careless programmer against carelessness. There are tools which will mitigate consequences, e.g. programming languages which check for array bounds and enforce strong typing; but these operate at another level.


Is Google 2-factor "Remember this Computer" secure against adversaries with root access?

Yes it is possible.

If tokens are server generated by creating a cryptographically secure random sequence stored against the account, this token could be refreshed and reissued on a certain interval, invalidating the old one.

The token would only be refreshed on active use so it won't invalidate the old one when the client computer is off. This approach ensures that a copied cookie only has a limited time to be reused, limiting exposure of the attack. In the case that the attacker uses the cookie in time, the original session would be expired and the real user would be logged out (depending on how the interval is set). A message could be displayed that the account is being used elsewhere, alerting the user to the attack.

If the attacker has persistent access though and can grab any new identifiers, she has already won. The above only protects against a one time theft of the token. For example if the user left their screen unlocked and the attacker had physical access and only enough time to steal the cookie value, or if the value was stolen via a reflected XSS attack, which is code execution in the browser, and the attack cannot be repeated easily.

An attacker with root access though may or may not be able to grab a normal user's cookie. Chrome encrypts cookies when saved to disk, allowing only the current user to decrypt them as the key is derived from their password. Therefore an attack on tokens in cookies would be more difficult.


Full disk encryption and remote unlocking a mail server in the hand of a possible attacker, what could go wrong?

Ten immutable Laws of Security, Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.
You are susceptible to the Evil Maid Attack.
He has the SD Card, he can clone it, change the initrd to log LUKS password, and with the LUKS password in hand it's game over. Shutdown your Pi, clone the card, replace the initrd, say there was a power outage here, and as soon as you send the key remotely, he has too. Another "power outage" and all your binaries are backdoored, or there's another root user, or a suid bash somewhere.

He could forward the external port 25 of its router to his rogue mail server, but could he read my email?

He now has the certificate, he can forward the emails to his own server, save a copy, send it back to your server. You cannot detect this, because he is using your certificate.
He can setup a proxy that does a reverse lookup on every connection to the port 25, checks if it's from a MX record, and says "TLS not implemented" and saves everything before sending data to your server. If you try to connect, he passes straight to your daemon, so if you test it from any non-MX IP, it will show you the correct certificate. He can even create a list with the largest SMTP sending services (major email providers, major list services, and so on) and sniff only those.

Can he read the wireguard initramfs configuration? If so he could use the peer key to connect to VPN

He can. He now has the LUKS key.

Is there a way to protect from cold boot attacks?

No. He has unrestricted physical access. Pull the plug, every single software protection is dead. The Pi does not have any hardware protection.

Other paranoid things I'm missing?

You cannot protect your Pi. Not even against basic attacks.


SYN flooding attack causing high CPU on hardware firewall

If you have a router in front of your firewall, configure the router to drop the packets originating for the IP address. Your router should be better equipped (I hope....) to deal with that level of network activity compared to the firewall.


I am not a master of NFS, but a reading of RFC 7530 (and some NFS discussion archives) shows that NFSv4 has callbacks: a NFS server can contact a NFS client, and delegate certain responsibilities to the client.  The callbacks allow improved network performance.

The presence of callbacks answers your final question "why does every client need a keytab?"  The client needs a keytab so the server (during a callback) can authenticate the identity of the client.  If a client keytab is stolen, the attacker could potentially imitate being that NFS client, and intercept or spoof NFS network traffic.

Access control is performed by the server, with the credentials sent by the client in the RPC request.


Since the HTML was assembled from heterogeneous sources, chances are that you're not interested in any scripts it may contain. So your approach looks viable to me.

I believe that the most practical and maintainable approach would be to make a list of allowed HTML tags and attributes (you are likely to not want, more than simply not need, CSS code; so id, style and class attributes may be discarded altogether). Tags like IFRAME and attributes such as onfocus would very likely not be included in the list at all.

Once you have this, you can run your HTML through a parser that will drop any unknown tags and attributes. You may want to do this in two stages, a "tagsoup" cleaner (HTML Tidy or TagSoup or HTMLClean or BeautifulSoup - I'd try HTML Tidy first) and a full-fledged HTML parser.

This way you'd end up with a well-formed and defanged HTML code which can be then manipulated much better and in more safety.

I'd avoid regexp matching unless I really had no other alternative.


Your flow looks correct as stated, but there are difficulties. Let me explain.

First is the distinction between "authentication" and "authorization." Social login focuses on authentication: Rather than logging in with your application's user/password (or whatever), you're allowing your user to be already-logged-in with Google, Twitter, or Facebook.

Once your user is logged in (by whatever means), YOUR application decides what this user is authorized to do. We can forget that we got here via OAuth 2 (social login) rather than normal site login. That flow looks fine.

Where is the security issue? In that "OAuth 2 dance" which is your step 1, be sure you follow the current docs provided by Google, Twitter, and/or Facebook. Do NOT expose your application's secret API key to the client side (browser or native app). In other words, part of the dance needs to be done server-side. It's very easy to get this wrong, and THAT is the pitfall.

There's another way to look at this. Your application could choose to act as an OAuth 2 client. The token provides not just authentication, but also authorization. The token tells your application what this user is allowed, and not allowed, to do in your application. This is the classic OAuth use case: A third-party application is authorized to perform some task (such as obtaining and printing photos) without having the user's login credentials.

In working with OAuth 2, you can avoid many pitfalls by careful attention to the distinction between authorization and authentication. The OP correctly makes this distinction.


A PKCS#10 request contains attributes. One of the possible attributes is Extension Request defined in section 5.4.2 of PKCS#9: it contains a list of certificate extensions that the requester would like to see in the certificate. If OpenSSL shows no such attribute, or that attribute is present but does not contain a Basic Constraints extension, then the request indeed does not suggest that the certificate should be tagged as "CA".

Note, though, that these extensions are just hints. The CA still decides what goes in the certificate.


Should Stack Exchange be more obscure in its systems' structure?

No. You should always assume that the attacker knows everything. Security by obscurity is considered bad practice by most non-govt developers and architects. The obstacle it provides is minimal, and if something is kept secret, it may be so to hide a flaw.
Kerckhoffs's principle is important to look at.

Edit: This answer discusses security by obscurity in general; not particularly for StackExchange.


Using OAuth SPA app to provide third party with access token

Adding more accurate answer based on the discussion above.

Based on your clarification in the comments the flow is to try to download a resource through the SPA, after sign in. Then the appropriate course of action is to change the third party service to verify the access token that SPA will send to it, on behalf of the user. This way SPA will not know and neither should it care how access tokens are generated. This will make sure no one can exploit the mechanism to generate access tokens freely.

Given that secure channels(TLS) should always be used for all interactions between OAuth service and any other subsequent interactions with thirdparty service to make sure no one can eavesdrop and obtain tokens. Make sure the access token has a shorter TTL to minimize the possibility of replay attacks. Have a look at the OAuth Threat Model since you are writing your own OAuth server.

[

Of course this means you have to be able to configure your user permissions per resource.


Can Amazon's AWS Identity and Access Management (IAM) be used to manage server access?

However, I don't believe IAM can be used to manage Linux and Windows credentials on the instances within our AWS account.

You can pretty much do this via OpsWorks for Linux instances. OpsWorks lets you register IAM users with a stack and then orchestrate creating their account and managing their public SSH key. You also have the option to let them manage their public SSH key if you want and control whether they have sudo privileges.

  Does having root and administrator accounts running on our instances
  mean that we cannot meet this requirement using IAM?

There's an option in OpsWorks to launch instances without a default SSH key which I believe means the only way to log in is via one of the IAM users. This can make debugging a little bit difficult if any issues occur before the OpsWorks agent has started though.

I'm not an expert in PCI DSS though so I'm not sure if there's any aspects of how OpsWorks manages instances which would prevent compliance.


Programatically encrypt data on Windows using login

DPApi will apply using the current user context - so if code can execute in the same context an attacker could access the credentials. A simple powershell script run on the machine while in the same context can decrypt the contents with a single command.

Its hard to determine the best approach without knowing more about your environment.

Will the automation be running under a service account?
Can you use MSA?
Are certificates an option?
Can you store these credentials in a secure store?

Sorry a lot more questions than answers - I would use DPApi if writting a desktop application that needs to secure data on a multi user system.
Chrome for example uses this to secure cookies - I don't know if I would use it in an automated process if its running under your own user account.


How to use standalone meterpreter exe with a USB key connected to an unlocked victim session

But, when I use meterpreter (for example through psexec with a domain
  user creds (not privileged)), I can really easily obtain SYSTEM
  privilege by using the lazy getsystem command.

I don't think this is generally true. meterpreter is not generally able to escalate privileges. Furthermore, priv esc depends on poor configuration and/or vulnerable software/drivers whatever. In a well protected Windows system you won't easily escalate privileges to local system. As far as I know getsystem only adds privilege tokens to the process but you already need to be member of the administrators group at that point.

As stated in the previous reply, meterpreter is just a powerful reverse shell that helps you do stuff on the target computer (i.e. load modules to perform a privilege escalation). if you're looking for something that automatically performs a privilege escalation in order to run mimikatz I doubt you will find that.

If you want to demonstrate that it is dangerous to leave desktops unlocked I suggest you demo a meterpreter or simple reverse shell and then you simply download upload files from/to the target computer (even though unprivileged you can access everything from the user running the meterpreter session). If that is not convincing enough then you probably waste your time...


secure the code of a server physically rented to the client

I'm not sure why you allow untrusted users root access to server, but the only approaches I can think of is to deny such users access to the directory containing the PHP code.

This can either done by:

Encrypting the directory containing the PHP code and decrypting it on the fly with a key that is obtained from a secure server
Fetching the PHP code from a secure location at boot-up, then caching it in memory and using that
Running the PHP code on a different server that the users don't have access to, fetching data from the shared server (e.g. via NFS) where necessary.

Note that the first two approaches are susceptible to various ways of someone sneaking a look at the code; e.g. by adding an extra PHP file that examines the other PHP files and returns their code content. You might be able to get around that by doing something clever with php-fpm so that the encrypted code is run in a single php-fpm instance and everything else is run in a second, but I wouldn't bet against someone with root access getting around that.

I would go for the third approach myself, as that's the only way to secure it.


Best ways to keep a website safe without web security and cybersecurity knowledge?

what are best ways to keep a website safe without web security and cybersecurity knowledge?

Shut it down, delete the code.

But since this is not the answer you want to hear, let's take a deeper dive:

Depending on the website we're talking about - Is it a CMS like WordPress? Is it something an intern clicked together in Dreamweaver? Is it a simple index.html only containing an address and a phone number? - it's impossible to give informed recommendations. So try to get a basic understanding of what area you want to improve next and ask a more focused question.

However, as a general rule of thumb you can do the following:

Keep it up to date!
Get a pentest from a reputable source to get your most critical vulnerabilities and fix them ASAP.
If you use a regular CMS you can start by scanning it with a vulnerability scanner like OpenVAS/Nessus
If you coded/customized it yourself (e.g. no off the shelf CMS) you can additionally run it through SAST (static application security testing) and DAST (dynamic application security testing) tools.
OWASP has a plethora of guidelines, checklists, cheat sheets etc. - read them, apply them.
Don't forget about key-, password- and access management to the website and infrastructure. The best website security is useless if you enable unauthenticated SSH to your production server. Same goes for social engineering.
Get another pentest after you fixed your issues to find even more issues (quality management is a cycle for a reason).
Set up secure network segregation between dev, test and prod.
Monitor network traffic with IDS/IPS.
Logging, logging and more logging - log everything: access, failed logins, destinations, successful logins etc. etc. (but beware of GDPR et al).
And most importantly, get educated. Read up on everything web security related. Watch tutorials, read books, news sites, blogs etc.

Or, if you really care about your website's security, hire a professional to guide you through this process. My guess is that this option will be more thorough, more secure and a lot cheaper than trying to fix this on your own.


Worst-case scenario OPEN URL REDIRECTION and why google not covering it in bug bounty

You seem a bit confused about the concept. An open redirect is just a redirect. You browse to http://google.net/redirect?http://stackexchange.com and it tells your browser: please go to http://stackexchange.com.

That it is an open redirect means that I can make it send you to anywhere (like an attacker web page), usually by embedding in the link the page where you will be sent.

  1> Victim can be tricked by phising

Yes, it is possible that the victim saw a link to google.net and then thought he is visiting that site (and thus blindly enters his google credentials), without noticing that the url now shows evilattacker.com.

  1> Can i run some system commands by webpage ?

I wouldn't consider the above like running system commands. It may be possible to use an open redirect to bypass the same-origin policy protections, though.

  2>If it found in any login page (because login pages mostly redirect after entering credentials) which is using HTTP not HTTPS, can the user sessions be hijacked or Can the credentials be stolen

Mostly no. Unless the redirect back (ie. when it sends you back to the attacker-controlled url) is added a token, or there is some information in the Referer header (a token, your user name…), the final page doesn't gain any additional privilege from having made you login, as it will be handled by cookies that aren't sent to the attacker page.

  2> Root access by serving some browser exploits ,

This is incorrect. If your goal was to serve the browser an exploit, you could have done that directly. Remember that the first step is to make the user follow an attacker-controlled url. The open redirect may help you trick the user (see 1), but Root access can't be considered a consequence of an open redirect.

  3> Can the victims traffic be routed as desired (by acting as a proxy by malicious user or generally MITM) .

No. The server doesn't act as a proxy (getting content in your behalf and passing it to you), just as a redirector: sending you somewhere else.

And specifically:

  3> Victim can be made a part of BOT network by opening a connection to some IRC.

An open redirect doesn't allow you to connect to irc, as the browser won't be able to follow an irc:// link (if it is able to handle it -most won't-, that would launch an application/plugin, not automatically connect you¹).

¹ And connecting to irc doesn't automatically compromise you, anyway.


Allow apache to write to users' .ssh dir's

I'd probably suggest having cron fire a script that does nothing but edit those files with whatever is queued in the database to do.

Allow that part of the script to act entirely outside of the realm of the apache user and be able to lock down the account to only do that task.

That's just off the top of my head though as a simpler solution.


Proxy between web server in DMZ and SOAP-service in internal network?

Web Proxy vs Port Forwarding:

Proxy is easier to hijack and reconfigure (it's an application) then kernel routing tables etc. Additionally web proxy will create more load then kernel TCP/IP stack. So proxy i worse from security and machine load point of view.

Architecture Problem:

Every configuration where you allow connections from DMZ to internal network is bad and should be avoided. The problem is in

  I need to access the SOAP-service (internal network) from the web server (DMZ).

It's not how DMZ should work. We create DMZ to separate outside world (internet) facing services from internal network, so when (because it really is WHEN, not IF) they got compromised, attacker can't move easily to exloit local network.

Suggested Solution:

You can create second, restricted DMZ for SOAP-service and cofigure port forwarding only for traffic comming from your web service in DMZ and internal network. This way SOAP-service is protected in the same way as when it's in internal network, but in addition, when compromised, you don't open internal network to attacker.


Netflix logout does not revoke secure netflix ids

One benefit of signed auth tokens is the ability to implement them stateless. This means that the server doesn't have to keep track of active tokens, but verifies the validity of a token by checking its signature and the claims contained in the token. Those claims usually contain a short lived expiration date, something like 5 minutes.

A simple logout routine might just delete the token on client side, which results exactly in the behavior you have witnessed. A copy of this token is still valid, until the lifetime has ended.

So you are right - this leaves you vulnerable for a short amount of time, if someone was able to steal your auth token.

The application can actually implement a clean logout, by remembering the active token in a "logged-out list" on server side, until the lifetime of the token has ended. If someone tries to use the token, the server would find its id in the "logged-out list" and denies access. Based on your observation, Netflix decided against this mechanism.


Lattice based encryption, current status?

The NIST post-quantum crypto competition is currently underway. When it is completed, NIST will be ready to issue a new standard for post-quantum cryptography. Until this happens, many people are reluctant to roll out their own favorite PQ scheme. There are three specific projects which are working on post-quantum cryptography (specifically PQ key exchange) that I can think of:

WolfSSL is a TLS library which supports NTRUEncrypt in its cipher suites.
The Tor Project has an open ticket for introducing a hybrid handshake into the protocol.
Google has been experimenting with their CECPQ1 algorithm recently.

Many post-quantum designs are actually hybrid designs. Both Tor Project's and Google's designs combine x25519 with NewHope so that, if a classical algorithm is found that can break the relatively new lattice-based crypto, the handshake is still at least as secure as x25519.


SQL injection most commonly happens when a programmer builds an SQL command by appending together (or interpolating) strings, using user-supplied input.

e.g. Imagine this extract from a vulnerable piece of user authentication (login) pseudocode from a fictional web application.

username = getPostData( "username" );
password = getPostData( "password" );

sql = "select id, username from users'
      + ' where username='" + username + "' and password='" + password +"'";
result = executeQuery( sql );

if (result[ 0 ]) {
  loginUser( result[ 0 ][ 'id' ] );
  print "You are logged in as " + encodeAsHtml( result[ 0 ][ 'username' ] );
}

At first glance you may think this looks sensible, but the problem is that it makes no distinction between the user-supplied data and the SQL code; data can be treated as code. This means that a malicious user can change the logic of the SQL statement.

A malicious user could completely bypass the login protection if he could change the logic of the SQL command to produce an answer that guarantees at least one row is always returned.

For example, if he entered a real username bob, but put the password as:

' or 1=1 --

Then this would grant him access to someone else's account. This is because the resultant SQL would look like this:

select id, username
from users
where username='bob' and password='' or 1=1 --'

Note that the logical expression 1=1 always evaluates to true. Also note that the injection vector ended with two hyphens, which marks the rest of the line as a comment. Thus the SQL is logically the same as

select id, username
from users
where (username='bob' and password='') or true

which is logically the same as

select id, username
from users
where true

which is logically the same as

select id, username
from users

Thus, all the users in the database will be returned, and he will be logged in as the first one in the list - which is usually the administrator.

Also SQL injection can be used to read the all data out of the database. Entering the username as follows (SQL Server syntax) will list the user-defined table names

' union select -1, name, from sysobjects where xtype = 'U' order by id --

because this produces

select id, username
from users
where username = ''

union

select -1, name
from sysobjects
where xtype = 'U'

order by id asc

because our injected data has an id of -1 and we are sorting the data by id, the first row returned from the database will be our select in the sysobjects table. So our displayed "username" will now be the name of the first user-created table in the database. Similar techniques can be repeated to read out all the data of every column of every row of every accessible table. Please note that this can still be done even when the feature being attacked produces no output at all!

Some combinations of programming language database libraries and DBMSs also allow query-stacking. This is a technique where a whole new SQL command is appended on the end. The database will then execute both queries. Username:

'; delete from users --

produces

select id, username
from users
where username='';

delete from users

Now your application doesn't have any users (and requires SQL injection to log in).
See mandatory XKCD comic.

See this SQLi cheat sheet if you are interested in more techniques commonly used by attackers and vulnerability testers.

So how do I avoid this?

Actually, in many common scenarios, it is so easy. Prepared statements separate data from code and do not allow parameters to be treated as SQL code. Simply recode your query to use prepared statements and bind individual parameters to the placeholders.

in pseudocode:

username = getPostData( "username" );
password = getPostData( "password" );

sql = "select id, username from users where username=? and password=?";
query = prepareStatement( sql );

query.setParameter( 0, username );
query.setParameter( 1, password );
result = executePreparedStatement( query );

As always this isn't the whole story...

Don't forget to defend in depth and always do input validation too, as you always would (should). WHERE clauses need extra attention as special characters such as % may not be wanted. Be particularly careful when passing user-data as arguments to database functions and be aware how they can be abused. If you have stored procedures that generate dynamic queries you may need further protection within the procedures themselves.


I think the performance and security level is the same between those two because they use the same level encryption, we only change the order. Is my reasoning right?

Yes, the performance is exactly the same, and I can't see why Veracrypt would even offer a choice, as I can't see any security implications in changing the order in which the ciphers are applied. Maybe someone on crypto.stackexchange.com could offer a reason why I'm wrong, though.

I'd go further and say that triple encryption, while it certainly protects against there being catastrophic failures in two of the three ciphers, is paranoid. I'd only consider this worthwile if I needed to directly hand over my encrypted hard drive to an attacker and leave him alone with it for the next 20 years, in which all kinds of breakthroughts might be made.

I can't say much about Whirlpool vs Streebog, except that just because the NSA touches something doesn't mean it's containing a backdoor. The SHA-2 family has been reviewed by lots of renowned cryptographers who have found it solid and while that doesn't prove anything, withstanding analysis by experts is really the only measure of quality we have in the field of cryptography.

There are some attacks against both Whirlpool and Streebog, but the best ones are still completely impractical for real-world attacks (AFAIK). I think the best attack on reduced-round Whirlpool can create a collision with a time complexity of 2^120. That's still out of reach. The best known attack against Streebog has an even higher time complexity. There are also attacks against reduced-round SHA-2 hash functions, but it's difficult to put these 3 hash functions in any order security-wise.

Finally, while I'm not entirely sure what the hash function is used for in Veracrypt (besides key derivation), a weakness in the hash function should not affect the security of the encryption if you use a strong passphrase.

  2) I did a container on my usb stick. Does encryption use more storage than non-encrypted files

No, it doesn not use more storage (except for a very small header that doesn't exist with unencrypted partitions).

Veracrypt encrypts disk blocks, not files. Each encrypted block is exactly the same size as the unencrypted block. It has to be; otherwise the encrypted partition would not fit into the space reserved for the partition on disk.


An active attack is one where the attacker modifies network packets while they are in transit, or sends forged network packets.

A passive attack is one where the attacker merely eavesdrops on packets that others are sending, without injecting any new packets and without modifying any of the packets others have sent.

This should be covered in any cryptography textbook.


The NX bit is a feature of the Memory Management Unit of some CPU (including recent enough x86). It allows to mark each memory page as being "allowed" or "disallowed" for code execution. The MMU is under control of the kernel; the kernel code decides which pages get the execution privilege and which do not. Therefore, whether the stack space is protected against execution depends on the OS. It also depends on a lot of other things:

Though the kernel may apply default values for the page properties, application can request changes. E.g. on Linux systems, the mprotect() system call can be used to enable or disable execution on any page that is under control of the calling process. In particular, any application which contains a JIT compiler (e.g. Web browsers, for efficient Javascript support) must play with mprotect(), because it must generate code (i.e. write bytes into some memory) and then execute the said code.
A mono-threaded application gets its stack in a dedicated area that the kernel knows of; in particular, the stack pages are automatically allocated upon first usage. In a multi-threaded application, things change: each thread has its own stack, which is, from the point of view of the kernel, heap-allocated. Depending on the OS, there may or may not be special support from the kernel for thread stacks.
GCC in particular supports a C language extension called nested functions. Because of the semantics of these functions, the compiled code for a nested function must dynamically produce some executable code on the stack; this is called a trampoline. See this page for some details. The bottom-line is that, for a trampoline to actually work, the stack (or at least the page in which the trampoline resides) must be marked executable.

It so happens that in the ELF file format, which is the format of executable files and DLL on Linux, there is a field which allows to specify whether the stack should be executable or not. When GCC compiles some code which contains a nested function, it sets this flag in the produced binary.

I have made some tests on a fairly recent Linux (Ubuntu 13.10, on 64-bit x86, with NX bit activated). Whether a given page is executable or not can be inferred from the contents of the special file /proc/$$/maps where $$ is the process ID. These tests have shown the following:

By default, the main stack is not executable. The NX bit is set for the stack pages.
If code contains a nested function, the executable is marked with the "executable stack" flag and, indeed, the main stack is now executable.
Thread stacks are created with the same "executable status" as the main stack.
If a "normal" executable, with its main stack non-executable, dynamically loads a DLL (with dlopen()) which contains code for a nested function, then the main stack is automatically switched to executable status.
If a normal multi-threaded executable, with its main stack and all its thread stacks non-executable, dynamically loads a DLL which contains code for the nested function, then the main stack and all the thread stacks are en masse promoted to executable status. Note that this implies that on this Linux system, "something" (probably the kernel, I have not checked) is aware of all the current thread stacks, and can change their mapping rights dynamically.

From all of this we conclude that on at least some recent versions of Linux, the stacks (main and threads) will usually be marked as non-executable (i.e. NX bit set). However, if the executable code of the application, or some executable code somewhere in a DLL loaded by the application, contains a nested function or otherwise advertises a need for an executable stack, then all stacks in the application will be marked as executable (i.e. NX bit not set). In other words, a single loadable plugin or extension for an application may deactivate NX stack protection for all threads of the applications, simply by using a rarely used but legitimate and documented feature of GCC.

There is no need to panic, though, because, as @tylerl points out, protection afforded by the NX bit is not that great. It will make some exploits more awkward for the least competent of attackers; but good attackers will not be impeded. Also, all this talk about NX is about trying to contain damage once a buffer overflow or use-after-free has occurred, and that's arguably a bit late to react.


Are there any websites that gather hash sums of different disk image files?

The National Software Reference Library is a catalog of valid hashes for OS and application files.  This listing can then be used, for example, to validate installed OS files on a system.  To quote from their site, "In most cases, NSRL file data is used to eliminate known files, such as operating system and application files, during criminal forensic investigations."

I don't know if it includes Ubuntu or OpenBSD, and their index page looks lost at the moment.


Does SHA-512 become suitable to store a password if we use salting and iteration with it?

Today I have read this discussion about wheels and that we should not simply strap ourselves to a wheel to travel on a multilane highway. And I have read here that instead we can take the bus, because it has safety features. That is great, but what about if I use a seatbelt with my wheel?

Salting is good. Iterations are good. SHA-512 is a good general-purpose hashing algorithm. But you can't just take a bunch of good things and strap them together and expect to have something safe to use. Like a commercial bus, PBKDF2 (or bcrypt, or scrypt, or Argon2) has lots of advantages over a homemade solution, primarily:

It has been tested extensively by experts.
There are multiple implementations, so your user database can be copied to a new platform with minimal fuss.
It has protections against problems you don't know are even problems (i.e. it was built by experts).


Which remote desktop protocol offers the smallest attack surface?

You're asking a question about protocol security, but it's not entirely clear how you would compare these as they aren't exactly equal. You're also not considering the supply chain security of the software that will speak these protocols. It hardly matters if VNC were the most secure protocol if you're running a 20 year old VNC server that's never been audited and is full of buffer overflows on your linux machine.
Additionally I don't think you have put sufficient effort into the threat modelling. If someone compromises your browsing machine and hooks the SSL traffic, they will still be able to see all your private data, usernames and passwords. Which might allow them to chain further attacks against your internal network infrastructure.
Additionally the browsing machine is likely situated behind a SOHO grade router which are notoriously vulnerable. If the same router is shared between the networks then the attacker could affect one network from the other by say, changing the DNS settings.
IMHO you should decide what you want to protect against, how you will remain secure if the browser server gets compromised and then consider the holistic view of remote management, including supply chain, not just a popularity contest of protocols based on people's gutfeel/opinion.


Verifying server's identity via encrypted timestamps

If you can include a public key then you can also include a long-lived, self-signed certificate (which you can generate e.g. using the openssl command line tool). If you explicitly trust this certificate in the client then you can use a normal run-of-the-mill TLS or DTLS to create a secure connection with the server.

This way you would not require all the PKI, trusted third party etc., but still have an X509 certificate based hybrid solution.

Note that your certificate should be able to encrypt if you directly want to use RSA encryption for the session key and sign (authenticate) for the DHE or ECDHE schemes providing forward security.


The worst you can probably do is forging analytics data. Then again there's no way to generate a key per install (and even if there was this could be spoofed too). So yes you can abuse it, but the only way to secure it is probably by not doing crashanalytics at all.


Mitigate MS17-010 on Windows XP? (wannacry ransomware)

Microsoft released patches for all operating systems in custom support. Please see here.

For English language patches, direct links are Windows XP SP2 x64 and Windows XP SP3 x86. Localized version of the patch can be found here. Rest of the links can be found on the bottom of the blog post.


Vulnerability in which part of the Android architecture would allow an attacker to take control of the hardware

Specifically, is it the Linux Kernel, the Android OS, or the DVM?

All of this. And also the firmware.
Bugs in the virtual machine would allow the attacker to change what an application is supposed to do, which is especially a problem if the application is allowed to access the specific hardware. Bugs in the Android OS could mean that an attacker could exploit bugs in privileged applications and thus gain access to the hardware. Bugs in the kernel could mean that separation between processes and also restrictions regarding access to hardware are not properly implemented. And bugs in the firmware might even allow direct manipulation from outside, like from WLAN or bluetooth.


IANAL - I would guess that the business would be liable for the data protection breach since they would usually be the ones in control of the data before its input/uploaded to the system. If they could show that the breach was due to a security failure in the software, they would probably be in a good position to sue the development company for any losses since it would have been their proffessional negligence that caused the breach.

Whether the individual developer that worked on it was junior/senior does not really matter since its the development company that would be the legally responsible entity. Of course the development company could then choose to take disciplinary action against its employee if they find them to be responsible, but I don't think that would have any connection to the legal responsibility (this may be different for the case of company directors and companies without limited liability).


What packet parameters should be checked to detect layer-7 DDoS attack?

could you supply more info.  Parameter's in what app/system?

The things you're talking about (packet features) are layer-3 (packet level) features.

These have nothing to do with whatever's happening at layer 7 (application) level - different things can be happening at the different layers with no relation, and an attack mostly working at layer 7 (like someone spamming, say, a search field in your website) won't necessarily have any defining features at layer3.  If it does, it could likely be easily changed on their side without changing the rest of the attack.


This is not a problem that cryptography can solve.  This is problem that can only be addressed with the Operating System's Access Control by removing read privileges to the file.

Or put another way,  DRM is a fundamentally flawed approach,  and will never work.


Is it possible that same IP shows up in Gmail even if the hacker is reading my emails?

Although you did not provide that much information,
the only way the hacker reading your emails would have the same IP as you is if he is accessing your email through your computer/network.

A few things you can do:

Make sure no one is on your WiFi other than authorized devices (as in devices you expect to be connected).
Run an anti virus scan to see if any malware is installed on your computer
Make sure any remote tools you are using are secure (do they all have a strong username and password?).
Make sure it is not anyone from your family/friends that are in your house or even on your computer.

If after doing all the above the hacker still can access your email, using a device you know is clean reset your email password and then restore your computer.

Note: If your computer is in fact infected you should assume the hacker has all your credentials from any site/services you use.


Why do some online banking sites (and others who desire secure login pages) sometimes add autocomplete="off" on their login page input fields?

The problem with autocomplete is that your browser stores information, which may be as sensitive as credit card info, and potentially anything stored in the browser could be grabbed by an attacker who compromises the browser.

Autocomplete="off" tells the browser it is not to store this information. Just a layer of safety which will require the user to type it in each time.


How to keep an origin / referer check for CSRF prevention from blocking URLs that are typed in?

If you follow the often cited best practice of not mutating data or other application state on HTTP Get requests, the referrer check on the Get request becomes a non-issue. You can just use the referrer check on all your HTTP Posts (or other methods if you're using them).

CSRF exploitation is essentially blind (barring massive CORS misconfigurations), so as long as Get requests only ever return data/JSON/HTML/etc. and don't change anything, you're fine not enforcing anti-CSRF on them. They're simply not sensitive to this kind of attack.

Posts (Puts, etc) are presumably only expected to come from a known app, therefore should have the correct referrer unless they're being stripped by a proxy or some other software or device "in the middle".


GSM uses three different security algorithms - A3, A5, and A8.
The A3 algorithm is used to authenticate the mobile device,
the A5 algorithm to encrypt the data transmitted,
and the A8 algorithm is used to generate the session key.

Hence, I believe you are interested in the A8 algorithm which deviates the session keys through a  challenge and response handshake. However, I the session keys are shared between the user and his base station only and not between two communicating parties. The base station will decrypt the data and transfer it (most probably in plain text) to the other party's base station which then encrypts the data with the key shared with the other party of the conversation.


Not Secure means not secure. If they can't get HTTPS on their site or HTTPS to work well, I wouldn't trust their website.

You do have options:

Call them and place the order over the phone.
Just heard about this: https://privacy.com/ - they give you a one time use, a changing credit card number, or something similar

This is really about you protecting yourself from credit card theft.

And if you're worried about credit card theft, know that your bank actually will cover you. It's a hassle, but you aren't liable for stolen credit information (in America).

So, rather than spending time to understand "not secure," assume the website is not secure, and decide how to mitigate your risk.


ASIC/FPGA hardwares to compute Scrypt hashes

scrypt is designed to be expensive to implement in hardware because of the memory requirement. Technically it's possible to create an ASIC that will compute scrypt hashes, but such a device would require very large amounts of RAM and would be cost-prohibitive to produce.


Can an attacker sniff Mac addresses on a wifi?

An attacker can always determine the client's MAC address if they can sniff packets to or from the client.  This is true regardless of whether encryption is used or not.  The MAC address is in the outer encapsulation layer of the 802.11 packet, and there is no encryption applied to that level.  Here's a good link at Microsoft that lays out the packet encapsulation, including where encryption happens in 802.11.

This is kind of the expected result.  By definition, the physical and data link layer information has to be openly available to other network devices so that they all can figure out who's supposed to send what where.

Standard tools like Netstumbler will display MAC addresses for you.  Your followup question will be "But doesn't that make it trivial to bypass MAC address filtering as a security measure on the AP?"  And the answer is, yes.  Yes it does.


What would be a simple example of an asymmetric encryption function (asymmetric function)?

RSA is about the simplest known instance of asymmetric encryption. There are a few others, but all of them rely on mathematics.

Symmetric encryption is easy (conceptually), because it is just about making a big knot with the data, and remembering how the knot was made; with that knowledge (that's the "key") you can untie the knot, basically by undoing all operations in reverse order.

Asymmetric encryption requires something magical. If you want to go with the knot metaphor, then it is a kind of knot where even knowing how things were tied up does not reveal how to untie them. In cryptographic terms, it must not be feasible to recover the private key (which is the power to decrypt data), even if the public key (the power to encrypt data) is known. Private and public key share a common mathematical structure, since one decrypts what the other encrypts, but that structure must resist analysis.

In this answer, I tried to explain RSA in simple terms. If you want to understand asymmetric cryptography, then you have to grasp enough mathematics to understand RSA. The good news is that such knowledge is not that hard, and it is reusable. So I encourage you to work up your algebra. Basically, you have to get familiar with the notion of computing things "modulo" an integer.


How does releasing exfiltrated data increase the chances of an attacker getting caught?

tl/dr: Data exfiltration here means the process of copying data from the victim to the attacker, which generates a lot of network
traffic and may therefore be noticed before the encryption/attack is
finished.  Moreover, publishing stolen data is not quite as simple as
it seems, because it is most effective when done "publicly", and in
that case legal channels may be used to stop an attacker from doing it
effectively.

It's easy to misunderstand what is meant by "data exfiltration" here.  So to be clear, when this article talks about data exfiltration they aren't talking about releasing data publicly.  Rather, they are talking about the simple act of copying data off of the infected systems and onto a system controlled by the attacker.  Consider a typical "lifecycle" of a ransomware infection:
Standard Ransomware

Ransomware is downloaded/executed somehow
Ransomware begins encrypting files locally
Ransomware (theoretically) sends encryption keys back to C&C servers so the files can be unecrypted after payment

All-in-all this is a pretty "low profile" attack, and antivirus and other anti-malware solutions have adapted to try to catch such things early on before they encrypt everything.  This is typically done by noting sudden and large spikes in disk usage, which are a sign of ransomware doing its thing (and also a sign of many other typical computer tasks, which can make detection a bit tricky).  Sending the keys to a C&C server takes up effectively zero network traffic, so detecting that is virtually impossible.
Blackmail ransomware
Compare that to the lifecycle of a ransomware attack in which the attacker wants to hold data hostage to be released later:

Ransomware is downloaded/executed somehow
Ransomware begins encrypting files locally
Ransomware sends the encryption key to C&C servers
Ransomware begins sending unencrypted copies of all files to the C&C Servers

The big difference is step #4, aka data exfiltration.  The important thing here is that this is very noisy.  Now not only does the attacker have to worry about local antivirus/antimalware systems noticing the attack in progress, but they also run the risk of being detected at the network level.  For a home user that doesn't even use an antivirus program (aka an easy target), their ISP may instead notice, start blocking traffic, and perhaps try to notify the user.  In a corporate environment it is even worse: even if policies on the individual machines are lax, there may be network level logging and alerts which may notice the increase of traffic, bring it to someone's attention, and shut the whole thing down before much encryption has happened.
In essence, like any thief, ransomware will be the most successful when it has plenty of time to do its thing before getting detected.  Trying to extract the data as you encrypt it is very "loud", and increases the risk of detection for the attacker.
It's like the difference between someone silently trying to steal the TV from your living room while everyone is asleep, versus someone who lights the kitchen on fire so they can steal the phones and laptops out of the bedrooms.
Publishing data
You also asked, in essence, why someone who has stolen data wouldn't publish it if their ransom isn't paid?  That's tricky.  Of course an attacker may very well do exactly that.  However it isn't always that simple.  There are a number of complicating factors:

Due to the above, they may have chosen to limit the amount of data they stole, and therefore may know that they don't have anything worth publishing.
The advantage of the classic ransomware attack is that, with the use of Bitcoin, it can be completely anonymous.  Staying anonymous gets much trickier when you have to publicly publish your victims data.
Actually publishing the data may itself be tricky to do well.  Such data would obviously be published in violation of copyright, so the victim may be able to use legal channels to have the data taken down (which has actually happened).  The attacker could publish it in the "dark" web or somewhere that is harder for legality to matter, but then it may not have the same impact to the victim's business (depending on the nature of the secrets).

All this to say that this whole "we'll publish your data if you don't pay up" situation is not quite as simple for the attacker as it seems.  That's not to say it is safe to ignore such threats, but I think it may still be a bit unclear if this new take on ransomware will have much more success than the original kind.


What compliance problem does "Common Criteria Certification" solve?

Common Criteria is a checkbox on DoD and other government department procurement processes.  As you are probably aware, CC evolved from TCSEC in the states and combined ITSEC (Europe) and CTCPEC (Canada).  So there are those that argue that Common Criteria sets down a standard model of security awareness for any product that goes through its process.

With that said, and as a Canadian Common Criteria evaluator, I can tell you that there are constant disagreements within the CC industry as to whether the process helps provide any assurance or whether it is merely an unsatisfactory checkbox.

Ultimately the big end-vendors -- your Microsoft's, your HP's, your Oracle's -- all want to sell to the government.  They cannot do this without the CC certificate, so they consent to have their system evaluated.  They are interested in the final certificate (technically, as long as they are "in-evaluation" that may be all they need to sell).

Assurance is a two-dimensional beast in CC. On one axis, you have the security functions that the product is claiming to offer (eg. smart-card identification and authentication for workstations). On the other dimension, you have the level of rigour and effort put into testing that those claims work and are securely implemented.

The CC industry has decided to force to reduce the rigour of the evaluation (you can only go up to Evaluation Assurance Level 2 instead of 4 [higher the number, more rigour applied]).  The idea is to speed up the evaluations, make them cheaper, and allow more vendors to seek them.

The question that always comes up within CC is: does the process make a difference?  It does, and it doesn't.  CC is mostly about analysing the security of the architecture and end-to-end development process.  Only a very small component of the overall assurance is related to testing and vulnerability analysis.  It is this lack of testing which many people (including myself) see as a problem within CC.  There are changes coming through now which aim to increase the focus on testing while reducing the amount of effort spent on analysing documentation.  This is a good thing.

Does it help other industries?  It can, but it certainly isn't mandated.  Many industries have their own certification processes.  CC has been attempted to be applied to health care (the BITS framework) and also for industrial control and analysis systems (eg. SCADA systems).


Questions about in-scope information assets for an ISO27001 ISMS

An asset is whatever your company considers that have value for its business. Information asset is every asset related to information, that in theory, could be anything from people, technology, physical sites, devices, documents, etc.

Choosing a correct scope for ISO 27001 can be difficult. If you broaden it too much, it will be difficult to implement the standard. If you narrow it too much, you will let important things out and it also could be difficult to implement due to interfaces management.

My advice is to consider out of the scope only things that are:

Not related to your core business
Not related to the objectives of the ISMS or the information that your organizatio would like to manage under the ISMS
Independent of the assets that are in the scope

For example, the VPN you mention. It is completely independent of the processes of your company that are in the scope? If the VPN is used by people in the scope or it opens connection to a network where data in scope is transmited, it is in scope.

A wifi access? The same, probably is in scope.

For example, if you have multiple offices and one of them does only administrative tasks that are not in the scope and its network is isolated (completely independent) from the rest of the company, you can put this office and its technology out of the scope.

Remember that if you put some part of your company out of the scope, you have to identify the interfaces (communication of information between the parts in scope and out scope) and apply additional security controls there to protect that information going to a less secure zone. That can increase the complexity of ISO 27001 implementation and thus sometimes it is easier to broaden the scope that to narrow it.

If you have doubts, it is better to broaden the scope.

Another very related question and maybe is your problem is which granularity choose when doing the inventory of information assets? Do I have to write down the number of pencils as them can be considered information assets? Mouses? Monitors? Faxes? I'm sorry, there are no definitive answer to this question. The organization has to choose how deep it wants to go with the inventory. The assets in the inventory have to be important for the organization and the inventory have to be manageable to be updated properly.


Information Security Audit - Employment Contract

Employment contracts do things like describe limits of liability, employee responsibilities, remediations, punishments, etc. There's a lot in there that will tell an auditor about how the company views security and data protection.

As someone who had to supply all this documentation, it was not an unusual request from 3rd party auditors.


somewhat complex dev domain https on local network cert problems

I ended up going back through the whole process and manually deleting my custom root CA from firefox and clearing the cache. After that everything seemed to be ok


Mutual Authentication and Authorisation with Certificates from various CAs

Mutual/client authentication via certificates is not a common configuration, thus you may not find much information on this topic, e.g. for nginx, as you might expect.

That said, you asked:

"Can I use a certificate that a user has had signed by a registered CA such as VeriSign, GoDaddy, etc, in place of signing a certificate myself?"

Yes.  Let's assume that your client has a certificate, issued by one of the above CAs.  To get that client to send its certificate to your server (e.g. nginx), you need to configure your server with a list of CAs that it will trust.  As part of the SSL/TLS handshake, the server "requests" that the client send its client certificate by sending to the client a list of CAs that the server trusts; the client can then choose one (among possibly several) certificate that has a "trust path" to those of those CAs that the server trusts.

This means that on the server end, you can configure the list of CAs you trust, using their certificates (and public keys); you do not need the private keys of the CAs for this.

"If so, what mechanism do I need to use to verify it? Will CRL or OCSP have details from all CAs or will I need to check their individual registers?"

OK, this is where things might be a little tricky.  The practical answer to this question is "it depends on the software/application you are using".  Since mutual/client authentication is not very common, many applications may not have CRL/OCSP functionality for client certificate verification implemented.  But let's assume, for the sake of discussion, that nginx (or mysql) can do this.

Within an X509v3 certificate itself, there are extensions which define where to find the CRLs for verifying that certificate, and/or for defining the OCSP responder to contact for verification.

The CRLs relevant to the presented certificate should be defined, in that certificate, by the CRL distribution points extension.  There are many possible formats for this extension; the linked RFC 5280 documentation goes into specifics.  But this extension, if present, is what any software (such as your website server) would look for, in order to discover where/how to get any CRLs that might mention this certificate.

The URL for the OCSP responder to contact, for example, might appear in the "authority information access" extension of the certificate.  For example, using openssl x509 -noout -text < /path/to/cert.pem on a certificate, you might see this displayed like so:

Certificate:
    Data:
        Version: 3 (0x2)

        ...

        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE

            ...

            Authority Information Access:
                OCSP - URI:https://ocsp.example.com

Thus the server in question has to parse these attributes/extensions out of the client-provided certificate in order to discover who to contact, for that certificate, for CRLs or OCSP data for that certificate.  In most cases, the CAs signing/issuing the certificates will also be the organizations maintaining the CRLs and/or OCSP responders for those certificates.

Hope this helps!


Is silverlight and Java running on the web browser capable of saving "state" into the user's local machines?

Actually, depending on the browser and plugins used, there are many ways for a website to store persistent information on users' computer. It's not cookies and cache anymore. Some of these new methods require user confirmation, some don't - it also varies by browser. Flash has Local Shared Objects, Silverlight has Isolated Storage, HTML5 itself gives Offline Application cache, Session Storage and Local Storage.

It's not easy to clean them all at once. In fact, there is a proof-of-concept project that uses all those tricky ways and many others to create a super-persistent-and-resurecting-cookie - Evercookie. Of course, there is also an Evercookie killer called Nevercookie.


Is secure Caller ID possible for SIP / VOIP?

When the call is coming from an external PBX, then the Caller ID you receive is what the caller's service provider sends to your service provider. This could by anything the caller's service provider wants. Many service providers choose to respect that and send the real Caller ID to your service provider (and eventually, to you).

Many SIP / VOIP service providers give their users the option to set an arbirtrary Caller ID which will be sent to the callee's service provider (and eventually, to the callee).

That's how the whole Caller ID system works, it is inherently insecure because it relies on the information provided to you being accurate. Think, HTTP_REFERE.


Does the Flash installer use an encrypted download?

Is this installer to be trusted?

No? As you said, you have no way of trusting what it downloads – even if it did encrypt and cryptographically authenticate the download, you wouldn't know whether what you're downloading is what you want. So this question is the same as "Can I trust any software downloaded from anywhere?", which probably is "no".

Anyway, as you said, there's no way for you to look inside and tell whether it's doing crypto, and if it does, if it's doing it right (i.e. verifying the authenticity of the server according to built-in keys, hoping these are untampered with, since you've downloaded the downloader from somewhere you trust).  So even just capturing the traffic (using e.g. wireshark), which is trivial, will only let you confirm the unencryptedness (if that is the case), not the correctness of implementation.

So, short answer: no.

EDIT also: Is that a Windows XP window decoration?!


Is it possible to automate use of passphrase-encrypted private keys?

A server restart is a serious occurrence, and should never happen on its own. Ideally there should be an admin logged on to trigger the restart - or at least to restart the server after he/she has diagnosed why it went down in the first place, if it was an unscheduled down.

So the admin may supply the passphrase manually.

As a weaker alternative, the SSLPassPhraseDialog may be used to supply the passphrase.

To strenghten the scenario, the script itself has to be secured (otherwise it's no better than a cleartext passphrase, or no passphrase), so it would have to ask for the passphrase to a second server that has some means to ascertain whether the request is legitimate or not.

For example, if there is a diagnosed down on the server, then and only then a SSH login for the servermaint user from that one IP is granted and the correct password echoed:

ssh -i identity_file servermaint@passphraseserver "getpassphrase"

And the identity_file only identifies that one server with a known IP address.

An attacker gaining access to the Web server would find no passphrase, and would be unable to login to passphraseserver (actually he would, but such an attempt would trigger an alert and log him instantly off instead of supplying the passphrase - and would also mark the server as compromised).

An attacker would then have not only to break into the server, but also to cause a webserver shutdown, and remain in control of the webserver while shutdown diagnostics and forensics are carried out - an unlikely event at best: with that kind of control, he might be able to exploit the Apache process and get a copy of the passphrase when the real sysadmin types it in.

Of course, in a simpler and way more common scenario ("I just want my server to go back up if it goes down, as fast as possible - don't care why it went down, it will always happen every now and then"), it would be easier to leave out the passphrase altogether.


PEM encoded rsa keys have different sizes

If you look at the keys in an online tool like: https://lapo.it/asn1js/ , you'll find the RSA private key consists of 9 different fields, some of which are variably sized.

In particular, if you look at the key file format here: https://tls.mbed.org/kb/cryptography/asn1-key-structures-in-der-and-pem (PKCS#1) you'll see the definitions for the 9 fields.

First key is:

SEQUENCE (9 elem)
INTEGER 0                     -- version
INTEGER (2048 bit) 24080037…  -- modulus
INTEGER 65537                 -- e
INTEGER (2044 bit) 19418496…  -- d
INTEGER (1024 bit) 17612182…  -- p
INTEGER (1024 bit) 13672376…  -- q
INTEGER (1024 bit) 11858803…  -- d mod (p-1)
INTEGER (1024 bit) 10382218…  -- d mod (q-1)
INTEGER (1022 bit) 41657306…  -- (inverse of q) mod p

And the second key is:

SEQUENCE (9 elem)
INTEGER 0                     -- version
INTEGER (2048 bit) 20717013…  -- modulus
INTEGER 65537                 -- e
INTEGER (2048 bit) 16271218…  -- d
INTEGER (1024 bit) 14737271…  -- p
INTEGER (1024 bit) 14057563…  -- q
INTEGER (1022 bit) 42347422…  -- d mod (p-1)
INTEGER (1021 bit) 18275240…  -- d mod (q-1)
INTEGER (1022 bit) 25417766…  -- (inverse of q) mod p

So, as you can see, some of the components of the key are different sizes (upto 4 bits on the d field), and those will be encoded somewhat differently in the ASN1 and base64 format.

As to your questions:

I don't know of a way to generate exact size RSA key components; if you can I would just prefix the length of the string in the file format. Or alternatively search the file for the '----' bit. You may be able to generate the ASN file with additional leading 0's on fields to get everything to a fixed length. Or you could generate RSA keys until you get the size you want. /s

Public key, so long as you're using the default e=65537 (default everywhere, for everyone), it's probably safe to say size==451. Though I'd still length prefix any plain text in a binary file.


Why do salts for hashing passwords need to be globally unique, not just system/site-unique?

The goal of salting is resistance to precomputation.

While you can't guarantee that a salt is globally unique, you can (just as you said) generate salts of sufficient size as to make it infeasible to generate a rainbow table in advance (making them "unique enough").

More generally, if you're asking about how to create a salt, it sounds like you're rolling your own hashing method, which may be educational but is not generally recommended.

Instead, use an existing hash (such as PBDKF2 or bcrypt) (or even better, as CBHacking rightly suggests in the comments, scrypt or Argon2). Not only will you automatically inherit their existing salting methods (which are quite sufficient), but your experimentation will be aligned with password storage best practices ... which would probably be better practice.

Update 2018-04-03: Steve Thomas (sc00bz) makes a good point here that Argon2 and scrypt are actually worse for the defender when used at speeds generally considered to be compatible with authentication at scale (<0.1 seconds), while being better for the defender for speeds compatible with encryption of individual files (1 to 5 seconds). (This means that the gap from 0.1 seconds to 1 second is probably interesting, and bears testing for your specific environment). In other words, his assertion is that if you try to tune Argon2 or scrypt to <0.1s speeds, the results are less resistant to cracking than bcrypt is at those speeds.

In the same thread, Aaron Toponce also makes a great suggestion for working around bcrypt's length (72 characters max) and pre-hashing limitations, by using bcrypt(base64(sha-256(password))). (See also Thomas Pornin's similar answer here). The reason that the base64 is needed is also interesting - don't leave it out.

So if your use case is scaleable, cracking-resistant authentication with a fast authentication experience, bcrypt(base64(sha-256(password))) is probably a good approach. (And you'll need to adjust bcrypt's work factor to the highest value that fits within your authentication speed window). If your users can tolerate waiting a second or more to authenticate, Argon2i or scrypt may be better. And note that relative performance will shift over time, as hardware capabilities improve - so increasing the bcrypt work factor every X months for new hashes (as Dropbox does) would allow the approach to adapt to future capabilities over time.

Update 2019-09-01 It turns out that wrapping a faster hash in a slower hash without salting/peppering that faster hash first is dangerous, because fast uncracked unsalted hashes from another source (such as another leak) can be tested in bulk against the wrapped hashes without having to crack those faster hashes first. The faster hashes can then be attacked in a separate job at a much higher rate. So my advice above should be updated to  bcrypt(base64(sha256(password.salt))).


Why is the issuer certificate different at my workplace and at home?

Yes, a company doing SSL interception could in theory read all your traffic if you use the company network. Depending on where you live and what kind of contract you have the ability for the company to do this might also be somehow part of the contract or working rules which might also include that you are only allowed to use the company network for work related stuff.

  can I workaround this?

Yes, you might use a different machine and network like your mobile phone for your private, not work related, traffic. Depending on the configuration of the firewall it might also be possible to use some VPN tunnel through the firewall. But it is usually explicitly forbidden to do this so you risk to get fired for this.


Is saving passwords in Chrome as safe as using LastPass if you leave it signed in?

NOTE This answer may be outdated due to improvements in Chrome since this answer was written.

First of all, Chrome does encrypt your passwords and other secret data. But there's are different aspects to this depending on the setting, plus a few details that you should keep in mind.

On your Computer, In your OS

When passwords are saved locally on your computer, Google will attempt to use whatever local password vault might exist. So for example, if you're on OSX, that's the system's Keychain. If you're on Windows, it's the Windows Data Protection API (Microsoft has a peculiar skill for naming products), if you're on KDE, it's the Wallet, in GNOME it's Gnome Keyring.

Each of these products has its own implications that are worth noting. For example, if you ever sync your passwords on an OSX device, those passwords go into the Keychain (as mentioned) which has been re-branded the iCloud Keychain -- the implications of which are exactly what they sound like: now Apple knows your saved passwords too, and will sync them to your iPhone, your iPad and any other Apple devices. That may be precisely what you wanted. And maybe not. Just be aware.

The Windows Exciting Names And Data Protection API Professional Edition boasts no such features. Your passwords are on your computer, and there they stay until further notice. Call it old-fashioned or call it safe. But bear in mind that Microsoft has a history of chasing Apple, and may decide to do so here as well.

In the Cloud

In addition to any unintentional iCloud syncing as mentioned above, Chrome will also sync your passwords between Chrome instances. This means sending your data to Google. Yes it's encrypted.

How is it encrypted? That's up to you. You can either use your Google Account (the default), or you can set a special "sync passphrase". While I have no special knowledge of the internals of these two options, the implications appear pretty straight-forward.

If you use your Google Account password, then the passwords are decrypted with no further intervention on your part. Note that the actual password is in fact required; access to the Google Account alone isn't sufficient. I've seen situations where Chrome had successfully managed to log in and fetch its sync data through external authorization but was not able to decrypt it until I typed in the original Gmail password. The advantage, therefore, of using a separate "sync passphrase" is to make sure that anyone who has your Gmail password (presumably Google could, for example) will not have your sync password.

Remembering autocomplete=off Passwords

The geek.com article mentioned brings up an interesting point, but that point is traditionally argued from a position of... unenlightenment. It's a common position held by "privacy advocates" (particularly the kind for whom I'd put that term in quotes) but the security implications are very, very, very clear, and very definitely, squarely on the side Google takes.

I've written about this already. Go read that other answer and then come back. I'll wait.

Go on.

OK, back? OK, here are the critical points while they're fresh on your mind: autocomplete=off was an intervention added to turn off a very dangerous feature. That feature is not the password saving we've been talking about.

The feature we've been talking about helps users. That other one was a misguided attempt at being useful by filling in forms using things you typed on other websites. So imagine an autocomplete assistant like Clippy, but with worse social skills: "I see you're trying to log in to Ebay; I'll just fill in your login from Yahoo and we can see if that works." Yeah, we had funny ideas about security back in the 90's. You can see why putting autocomplete=off into everything even remotely security-related quickly became a bullet-point in site audits.

By comparison, the autocomplete that we've been talking about is a very carefully-controlled security-enhancing solution. And if you use it for anything at all, you'll want to use it for your most secure passwords? Why? Phishing.

Phishing is literally the single most dangerous online attack facing you. It's super-effective and super-devastating. It doesn't get nearly the attention it should because we always just point a finger at the stupid user who gave the Syrian Electronic Army his password. But defending against phishing is really, really hard, and exploiting it is therefore really, really easy. Furthermore, a successful phishing exploit has unlimited damage potential, all the way up to shutdown-the-whole-bloody-company sort of disasters.

And in protecting against phishing, your single greatest weapon is a browser-integrated password manager. It knows where your passwords should be used, and locks you out from using them unless you're actually looking at the right site. It's not fooled by look-alike domains or "site seal" graphics, it knows to check the SSL certificate and knows how to check the SSL certificate. It keeps your passwords locked up until you're ready to use them and staring at the correct login prompt.

Should the Chrome password manager ignore the autocomplete=off message? MOST DEFINITELY YES.

Should you use it? If you're using LastPass then you're fine sticking with that. But this should be considered a reasonable alternative if the caveats mentioned above don't bother you.

If you're not using any password manager, then start using this one right now. It's safe by any reasonable measure, and in particular, far safer than not using it.


Is the Station-to-Station protocol secure?

The important premise of STS is that Alice and Bob already know each other's public keys. Possibly, this "knowledge" is acquired through certificates, as part of a PKI. See the relevant quote from the Wikipedia page on STS:

  Public key certificates may be sent in steps 2 and 3 if the keys are not known in advance.

The SSL/TLS protocol, when used with the "DHE" cipher suites and with certificate-based client authentication, is actually an incarnation of STS.


What encryption (if any) is used on electronic credit cards?

EMV cards and smart cards in general do indeed have an embedded private key and enough horsepower to do the crypto math needed to sign a transaction without revealing the secret.

https://secure.wikimedia.org/wikipedia/en/wiki/EMV
https://secure.wikimedia.org/wikipedia/en/wiki/Smart_card


How secure are self decrypting HTML files for data storage?

At least the author wrote a rather clear page on how his encryption works. Notwithstanding, this looks like a rather old-style homemade stream cipher, which is not good news, since most of such systems have been thoroughly broken. It appears to consist of a basic LFSR subsystem (two LFSR with key-dependent polynomials; the bit about the polynomials operating in "reverse direction" is a red herring, because this subsystem is still wholly linear) and another LFSR which acts as a non-linear selection engine. There are a few select designs which roughly look like that and appear to offer a non-negligible cryptanalytic resistance (e.g. the Alternate Step Generator), but this comes at a price, namely that you need quite much more than n internal bits of state if you want to achieve a 2n security level. Also, many such designs turned out to be weak.

We can trust in the resistance of a cryptographic algorithm based on the combination of the following properties:

The designer is known to be very good at designing algorithms (e.g. his name is Rivest).
The design got wide exposure, such as being published in some high-profile conference and/or being deployed at a large scale.
Several years have elapsed, and nobody found any issue.

This design is a bit lacking on the three points.

Edit: I had not noticed it (I need more coffee in the morning) but the generated stream is deterministic for a given password. This means that if you encrypt two archives with the same password, you are in the infamous "two times pad" situation, and you have basically lost.

Another point is that the password is derived into a key with only a pair of invocations of MD5. MD5 is very fast; a good, but off-the-shelf and not utterly expensive GPU can evaluate MD5 at a rate of roughly one billions per second. If the first bytes of the encrypted data are guessed by the attacker (since cleartext is supposed to be Javascript, the first bytes are probably "var" or "function"), then the whole thing is vulnerable to dictionary attacks, aka "exhaustive search on password" (trying out potential passwords until a match is found). It is possible to have a big fat random password which defeats dictionary attacks, and a human brain could still remember it with some effort. But most passwords are weak in that respect. Also, no salt: for a given password, you always get the same stream. Therefore, one could precompute the first bytes of the stream for each potential password, and afterward cracking any instance would be a matter of a few lookups in the table (the table could take the form of a rainbow table for more compact storage).

For the password-handling part, this scheme is definitely weak.

The use case is also dubious. Since this is Javascript code in which the user enters his password, this is vulnerable to active attacks: an active attacker could simply alter the Javascript code, so that when the user enters his password, a copy of the password is also recorded somewhere (e.g. the decrypted data -- which is supposed to be Javascript itself -- gets an additional code snippet which prints out a hidden <img> tag with a URL pointing to an attacker-controlled server and encoding the password).

To defeat active attacks of that kind, the solution is known, and that's SSL. The "self-decrypting archive" should be served only over HTTPS. But if HTTPS is used, why would self-decryption be needed ? Instead, have the server give the sensitive piece of Javascript only after having duly authenticated the user, with the password. This is a very common model, existing Web servers implement it out of the box, and it is stronger since it thwarts offline dictionary attacks (from the outside, the attacker cannot "try passwords" at the maximum speed of his GPU; he has to ask to the server for each guess, and the server can answer as slowly as it wishes).

Summary: I recommend against using this piece of code. I still note that, at least, the designer of SDA appears to have made commendable efforts at documentation, and to be sane -- sanity alone puts him in a minority, among the crowd of cipher designers on the Internet.


As your present domain is blacklisted, Google will consequently suspect (blacklist) any other domain to which it forwards. So it is useless to purchase a new IP address for that purpose.

You have to  do the necessary to request Google to remove your domain from its blacklists and be patient (it can take several weeks even if you have done everything correctly. Reading my detailed answer here will let you understand better).

Depending on the activity you are running, I think it is better, if possible, to contact your clients directly and inform them of your new domain.


Is there any technology that allows to run code in untrusted environment?

You are effectively asking if it is possible to hide some activity in a fully monitored environment. First, there is no thing as a fully monitored environment because everybody including your adversary has only limited resources (i.e. time, money, people...). Thus while he might be able in theory to watch every traffic and take process snapshots at every time he will not be able to analyze all the data. But if the adversary would have unlimited resources there would be no place to hide for you.

Thus in reality you just have to make it too hard for the adversary to find you. The best way would probably be to make your activity look innocent (i.e. blend in) so that a closer look at it does not seem to be worth. Again, the adversary has only limited resources so he must decide where to use these for the best results. How blending in can be done is specific to the environment and the task and the more you know about the environment and how it is monitored the better you can hide your activity.


How does a server obtain the IP Address of a user?

When you send a request to the server, the server need to know where to answer, it's with your ip address. This is directly based on the TCP/IP protocol and in a lower level than web servers.

For the reason why Firebug doesn't show your IP address, it's like when you receive mail (paper), you have your address written in front, and the sender in the back. Firebugs shows you the content of the letter, not the sender and the receiver address (IP in IT).